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(_at_)ietf(_dot_)org] On Behalf Of
l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk
Sent: Wednesday, January 08, 2014 3:58 PM
To: gorry(_at_)erg(_dot_)abdn(_dot_)ac(_dot_)uk
Cc: lisp(_at_)ietf(_dot_)org; jnc(_at_)mit(_dot_)edu;
tsvwg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
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(_at_)erg(_dot_)abdn(_dot_)ac(_dot_)uk
[gorry(_at_)erg(_dot_)abdn(_dot_)ac(_dot_)uk]
Sent: 08 January 2014 12:55
To: Wood L Dr (Electronic Eng)
Cc: tsvwg(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org] On Behalf Of IETF
Secretariat
[ietf-secretariat-reply(_at_)ietf(_dot_)org]
Sent: 07 January 2014 20:20
To: tsvwg(_at_)ietf(_dot_)org
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/