RE: [tsvwg] Milestones changed for tsvwg WG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]