[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?
I believe the intent for AMT-over-IPv4 was to work the same as
IP-in-IP (RFC 2003).
In these cases the payload has some other integrity check... the payload is a full IPv4 or IPv6 packet with its own upper-layer checksum in it.
-Dave
> -----Original Message-----
> From: Matt Mathis [mailto:mathis at psc.edu]
> Sent: Thursday, November 29, 2007 8:37 AM
> To: mboned at ietf.org; Transport Directorate
> Subject: 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
_______________________________________________
MBONED mailing list
MBONED at ietf.org
https://www1.ietf.org/mailman/listinfo/mboned