[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Zero UDP checksum also runs head on into the reassembly hazard described in RFC 4963. Given that some tunnels ignore DF and use silent fragmentation to get around MTU problems, this is inviting the pathological worst case:

(Note that several tunnel specs expressly permit ignoring DF.)

If the sender uses a traditional single IP-ID space for all peers (per peer IP-ID is now preferred), and has other high rate streams, then any pair of consecutive UDP packets might have the same IP-ID and no checksum. If some other party does silent fragmentation and the first fragment of the first datagram is lost then the head of the second datagram will be spliced to the tail of the first datagram. If the lengths are ok (e.g. the same) then this "frankengram" will be completely valid and will be delivered to the application.

UDP checksum=0 should be deprecated for all cases except backward compatibility with legacy applications. An exception might be made if the payload has some other integrity check (e.g. a crypto signature), but even then the UDP checksum is probably cheaper.....

I am not on mboned.  Please cc replies to me if you want further input.

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

On Thu, 29 Nov 2007, Magnus Westerlund wrote:

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: magnus.westerlund at ericsson.com
----------------------------------------------------------------------




_______________________________________________
MBONED mailing list
MBONED at ietf.org
https://www1.ietf.org/mailman/listinfo/mboned