Joel, I'd already read them, I explicitly referenced them in my mail that prompted Noel's reply (text not included below, I see - copy at http://www.ietf.org/mail-archive/web/ietf/current/msg85351.html ) and I have explained where those RFCs have gone wrong. Those proposed standards are written from the perspective of the tunnel user, not the rest of the network. Tunnel user is fine and unaffected, rest of the network bears the pollution costs. regards Lloyd Wood http://about.me/lloydwood ________________________________________ From: Joel M. Halpern [jmh@xxxxxxxxxxxxxxx] Sent: 09 January 2014 02:47 To: Wood L Dr (Electronic Eng); jnc@xxxxxxxxxxxxxxxxxxx; ietf@xxxxxxxx; lisp@xxxxxxxx; tsvwg@xxxxxxxx Subject: Re: [lisp] [tsvwg] Milestones changed for tsvwg WG Rather than repeat the arguments, might I ask that you read RFCs 6935 and 6936, which represent the IETFs conclusion about this topic? The LISP work complies with the requirements of those RFCs. Yours, Joel On 1/8/14 9:35 PM, l.wood@xxxxxxxxxxxx wrote: > Noel, > > I'm claiming that IPv6 has only the pseudoheader checksum to prevent misdelivery, > as the header checksum was removed from v6 (rather than simply covering non-mutable fields, > and leaving out TTL). > > When a UDP checksum is set to zero, there is a risk to the payload traffic carried - which, > as you point out, is protected against for the carried traffic if it has its own checksum, > which is at a higher layer and more end-to-end. > > However (and this is the subtle point), while the carried traffic is protected against > corruption if the packet is delivered to LISP, any IP/UDP header corruption goes > undetected at the endhost because the pseudoheader checksum has been disabled. > This does not matter for your application; the header corruption takes > the packet to some other destination/port, so you don't see it; it's just a drop as > far as you are concerned. But it matters for whatever actually receives > that corrupted packet on e.g. an altered port value. How do they detect and reject it > from their stream? > > Bare IPv4 has the header checksum, so at least you can tell the endhost is probably > right. But sans UDP checksum, there's no (weak) ports check. > IPv6 has no header checksum, so unchecked corruption to header or ports can take > the packet anywhere. > >> It's not the internetwork layer's job to second-guess the users; we can assume >> that if someone sent a packet without an end-end checksum, they must have >> worked out that for whatever they are doing, it's OK to leave it out. > > For what they're doing, but not for what everyone else is doing. Sure, LISP or > tunnels are fine, but odd behaviour on other applications at the same endpoints > (or, with IPv6, in the same network) caused by missent packets with corrupted UDP > packets? Hey, not your problem. Hey, you're working just fine. > > It's pollution and tragedy of the commons, basically. > > When you send with a zero UDP checksum, it's possible for the packet to be > received and processed anywhere. > > Secondguessing users who don't understand the problems they create IS > the internetwork layer's job. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: ietf [ietf-bounces@xxxxxxxx] On Behalf Of Noel Chiappa [jnc@xxxxxxxxxxxxxxxxxxx] > Sent: 08 January 2014 23:32 > To: ietf@xxxxxxxx; lisp@xxxxxxxx; tsvwg@xxxxxxxx > Cc: jnc@xxxxxxxxxxxxxxxxxxx > Subject: RE: [tsvwg] Milestones changed for tsvwg WG > > > From: <l.wood@xxxxxxxxxxxx> > > > 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 > > If the content above the UDP header in this case were that of some sort of > application, you'd be right. > > But it's not. > > The UDP, outer and inner IP headers of LISP _together_ are effectively a > layer three header ('get the packet from the source host to the destination > host - and that's all, ffffolks - no reliability of any kind'). So the fact > that it's not providing protection against misdelivery is... _exactly_ like > the service that bare IPvN provides. > > In fact, since IPv6 doesn't even _have_ a header checksum, UDP in LISP is > doing exactly what IPv6 does. Are you now claiming that IPv6 is fundamentally > defective because it doesn't have a header checksum to guard against packet > mis-delivery? > > > and 'usually' is not a good defence > > To say it at slightly greater length, 'the inner packet _either_ already has > an end-end checksum (the usual case), in which case adding another one is of > little or no value, _or_ the sender deliverately sent their packet _without_ > an end-end checksum, in which case they are _no worse off_ than they were > before the packet was encapsulated'. > > It's not the internetwork layer's job to second-guess the users; we can assume > that if someone sent a packet without an end-end checksum, they must have > worked out that for whatever they are doing, it's OK to leave it out. > > > Note that I am solely answering regarding the omission of UDP checksums when > UDP is used as part of the internetworking layer, for encapsulating traffic. > I have not considered, and make no statement about, use of zero checksums > in other ways/places. > > Noel > _______________________________________________ > lisp mailing list > lisp@xxxxxxxx > https://www.ietf.org/mailman/listinfo/lisp >