gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)

["Black, David" <[e-mail]>]

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:[e-mail]] On Behalf Of [e-mail]
> Sent: Wednesday, January 08, 2014 3:58 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> 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: [e-mail] [[e-mail]]
> Sent: 08 January 2014 12:55
> To: Wood L  Dr (Electronic Eng)
> Cc: [e-mail]
> 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 [[e-mail]] On Behalf Of IETF Secretariat
> > [[e-mail]]
> > Sent: 07 January 2014 20:20
> > To: [e-mail]
> > 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/
> >
> 
>