Lloyd, <tsvwg WG co-chair hat OFF> This is only at the draft adoption stage - the tsvwg WG gets to take a hard look at the zero checksum conditions in the gre-in-udp-encap draft and make sure that they're right (the WG could even remove the support for zero checksums) - that's among the good reasons for adopting the draft in tsvwg as opposed to elsewhere. Speaking of elsewhere, draft-ietf-mpls-in-udp is in IETF Last Call and has language allowing zero UDP checksums - I might suggest that you (and anyone else who cares about this topic) go read that draft and consider whether making Last Call comments would be appropriate. Thanks, --David </tsvwg WG co-chair hat OFF> > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@xxxxxxxx] On Behalf Of l.wood@xxxxxxxxxxxx > Sent: Wednesday, January 08, 2014 3:58 PM > To: gorry@xxxxxxxxxxxxxx > Cc: lisp@xxxxxxxx; jnc@xxxxxxx; tsvwg@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: [tsvwg] Milestones changed for tsvwg WG > > Zero UDP checksums are being selected for convenience, without an appreciation > of the overall effects and costs on other traffic. I see this is occurring in > both tsvwg > and lisp, and it's probably happening elsewhere: > > From the recently adopted by tsvwg draft: > http://tools.ietf.org/html/draft-yong-tsvwg-gre-in-udp-encap-02 > To simplify packet processing at the tunnel egress, packets destined > to this assigned UDP destination port [TBD] SHOULD have their UDP > checksum and Sequence flags set to zero because the egress tunnel > only needs to identify this protocol. Although IPv6 [RFC2460] > restricts the processing a packet with the UDP checksum of zero, > [RFC6935] and [RFC6936] relax this constraint to allow the zero UDP > checksum. > > from http://tools.ietf.org/html/draft-ietf-lisp-introduction-03 > The UDP checksum is zero because the inner packet usually already has > a end-end checksum, and the outer checksum adds no value. [Saltzer] > > (That's a misreading of Saltzer - the UDP checksum is also protecting against > misdelivery and pseudoheader corruption, and 'usually' is not a good defence. > For shame, Noel.) > > After all, the best examples of end2end systems failure are with zero > checksums > at the endhosts. > > The TCP and UDP checksums catch significant numbers of errors, e.g. Stone's > work: > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf > and some of those errors will appear in the headers, where they will send > the data to other ports and destinations. > > The potential for polluting other ports and applications because > there is no pseudoheader demultiplexing sanity check is there. > > IPv6 leaving this check implemented on a per-transport basis has opened the > door, > and rewriting that section of RFC2460 in RFC6935 has taken the door off its > hinges. > These RFCs break the minimal multiplexing pseudoheader sanity check that > RFC2460 > offered; IPv6 is a mess in so many ways, but making it worse? > > I think publishing RFC6935 and 6936 and letting in zero checksums again to > IPv6 > was a mistake, frankly. (alas, I wasn't paying much attention at the time - > moving > countries etc.) > > A strong recommendation that UDP-Lite covering headers offers minimal > computation > overhead on tunnelled packets while protecting against polluting other ports > is one > solution, while acknowledging deployment limitations. Section 2.4 of RFC696 is > mostly there. > But zero UDP checksums should always come with copious warnings on the effects > not on the > carried traffic, which can have its own payload checks, but on traffic sharing > the network > with traffic delivered with zero UDP checksums. Drafts relying on zero > checksums should be discouraged, not adopted by workgroups. > > It's a tragedy of the commons, but the I'm-alright-Jack engineers who want > zero udp checksums for their traffic, and do protect against the effects of > zero > checksums on their own payloads, won't care about effects on other traffic. > Hey, maybe this should be treated as an attack, which falls under perpass? > That > should get it attention... > > tsvwg needs to give (or get) some careful input on the implications here. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: gorry@xxxxxxxxxxxxxx [gorry@xxxxxxxxxxxxxx] > Sent: 08 January 2014 12:55 > To: Wood L Dr (Electronic Eng) > Cc: tsvwg@xxxxxxxx > Subject: Re: [tsvwg] Milestones changed for tsvwg WG > > Lloyd, > > Here is a little context... which could help. The IETF agreed to update > the UDP checksum behaviour for IPv6 in RFC 6935, but only subject to the > applicability specified in RFC 6936. > > One of the reasons why a simple encapsulation like this needs to be done > in tsvwg is to minimise the end-to-end implications on other traffic. > Sure, using a zero checksum has such implications, and my own first > concern is that the new GRE-in-UDP work follows the applicability > statement in RFC 6936. To me, it seems the authors are heading this way - > but maybe more help is needed. It would be no bad thing to highlight the > implications of using zero checksums on other traffic. > > Gorry > > > Am I the only one who finds putting zero checksums in proposed standards > > to be a worrying > > trend? > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: tsvwg [tsvwg-bounces@xxxxxxxx] On Behalf Of IETF Secretariat > > [ietf-secretariat-reply@xxxxxxxx] > > Sent: 07 January 2014 20:20 > > To: tsvwg@xxxxxxxx > > Subject: [tsvwg] Milestones changed for tsvwg WG > > > > Added milestone "Submit 'Specification of GRE in UDP encapsulation' to > > IESG as a PS RFC", due December 2014. > > > > URL: http://datatracker.ietf.org/wg/tsvwg/charter/ > > > >