Subject: [MBONED] WGLC for <draft-ietf-mboned-auto-multicast-08.txt> - UDP checksum?

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 27 Nov 2007 08:12:11 +0000

Glad to see AMT progressing. I have some comments on the draft.

The UDP checksum is the primary way of validating correct endpoint
selection - i.e. this endpoint on this host was the intended recipient. 
This is needed to offer some basic protection to the receiving stack at 
whichever host this packet is finally delivered to (even if corrupted 
and/or mis-routed - albeit with 1/64k chance of a mistake). Setting it 
to zero can lead to other hosts/apps receiving packets with errors or 
the wrong payload - although they may not expect to receive these, nor 
have any way of detecting this.

---
1) In section  6.1:
"The UDP checksum MUST be valid in AMT control messages."
- Agreed, but what does valid mean? (This is echoed in 6.2, 6.3, 6.4)

I would expect that the transport-layer checksum is the responsibility 
of the transport layer. All stacks MUST set a valid UDP checksum on 
transmission and MUST reject datagrams that do not have a valid checksum 
on reception.
---
2) I do not agree with section 6.6 for IPv4:
"The UDP checksum SHOULD be 0 in the AMT IP Multicast Data message."

In the case of IPv4, this is not good practice. It would be bad practice 
to encourage widespread deployment of a new protocol that disables the 
UDP Checksum. I think the tunnel SHOULD enable UDP checksums, as in
[draft-ietf-tsvwg-udp-guidelines-04.txt].
---
3) The above recommendation in section 6.6 goes against the design 
rationale for IPv6, a Draft Standard (RFC2460), and seeks to update it. 
This is inappropriate. IPv6 applications MUST enable UDP checksums 
(there is no option offered).
---
4) The document does not cite RFC2460, which I would have expected as a 
normative reference for IPv6 use of UDP. RFC2119 is also normative.
---

Best wishes,

Gorry

_______________________________________________
MBONED mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Nov 2007 13:53:10 +0100

Hi,

I was alerted to the discussion on this topic. I do have a few comments
on the discussion so far:

Dino, the transport checksum is quite important in detecting malfunction
inside routers and other entities that aren't links that process the
packet. In those entities the link checksum isn't protecting the packets.

I don't know about any recent investigation on how common these failures
are. But there is at least this investigation by Stone and Partridge
published 2000 that shows that this was quite common and because of a
multitude of different reasons. Please see:
http://portal.acm.org/citation.cfm?id=347561&dl=GUIDE&dl=ACM

Thus turning off the UDP checksum would mean that the receiver has no
possibility to verify that the packet was really intended to reach this
destination.

For IPv6 you even don't get the choice. Please consider what will happen
at the reception of your IPv6/UDP packet with UDP checksum field = 0
according to section 8.1 of RFC 2460:

      o  Unlike IPv4, when UDP packets are originated by an IPv6 node,
         the UDP checksum is not optional.  That is, whenever
         originating a UDP packet, an IPv6 node must compute a UDP
         checksum over the packet and the pseudo-header, and, if that
         computation yields a result of zero, it must be changed to hex
         FFFF for placement in the UDP header.  IPv6 receivers must
         discard UDP packets containing a zero checksum, and should log
         the error.

It will be discarded. It may in fact be discarded en-route also if some
node decides to verify the checksum. I don't find at all okay to
disregard to such fundamental processing rules of basic internet
protocol stacks.

Based on the glance of the AMT spec I took you need to have port numbers
in the gateway. Thus the two possible choices as I see it are:

1. Use UDP and bite the bullet in having to compute the checksum

2. Use UDP-Lite and likely have failures if there is NAT between the
tunnel ingress and the AMT gateway.

I think this is a choice your poison situation.

I also have two WG last call comment myself.

A. This specification needs to discuss MTU issues with the data tunneling.

B. Possible fragmentation issues with AMT messages. What are the largest
payloads you can put into the signalling messages.

Is it at all intended that AMT should work with the AMT gateway behind a
NAT?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------