Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outerheader on decapsulation

From: [email-masked] (Noel Chiappa)
Date: Fri, 21 Aug 2009 17:54:31 -0400 (EDT)

> From: "Darrel Lewis (darlewis)" <[email-masked]>

    > the IPv4 packet's checksum

It take it you mean the UDPv4 checksum, not the IPv4 header checksum, right?

    > is changed from 0 to a non-zero (but correct) value on the NAT'd
    > packet.			       ^^^^^^^^^^^

Oh! Big (and _important_) difference! :-) That makes our life significantly
simpler. (Yah! :-)

I just (naturally - see below) assumed that what they were doing was updating
the UDP checksum, assuming it was already correct, without bothering to check
to see if it was zero. Sorry, should have read your note more carefully!

The following is something of an aside, but.. _Calcalating_ the correct
checksum when it's zero is... somewhat bizarre - and, I would argue,
incorrect behaviour.

For one, it makes the recipient think the data can be relied upon - but it
can't, because it might have been damaged _before_ it got to the NAT box.
(Depending on exactly _what_ they are doing, they might even be causing a
problem, on non-zero-checksum packets. E.g. if they always recalculate the
checksum on outgoing packets, then iff the packet had a bit-error _while it
was sitting in the NAT's buffer memory_, they have now created a damaged
packet with a 'correct' checksum. The checksums are _supposed_ to be
_end-to-end_ for a reason!)

For another, it might cause the recipient to expend cycles calculating the
checksum to make sure it's right, instead of just blowing past it. (Will that
be an issue for LISP?) Finally, if applications are setting the checksum to
zero, it's because they have some use for damaged packets - only now, damaged
packets will likely (depending on the OS) be tossed due to bad checksums,
rather than being given to the application anyway.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Sun, 23 Aug 2009 12:21:32 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > This makes a _big_ (and very positive) difference in the discussions
    > we've been having!
    > ...
    > it is a _much_ less heinous bug than I had previously understood.

Indeed, ditto.

    > Since these packets will contain a valid UDP checksum value, they will
    > not be thrown away by an ETR checks non-zero checksums. Doesn't this
    > remove our justification for forbidding ETRs from checking these checksums?

Yes, as far as I can see.

Is it OK to say 'ETRs MAY ignore non-zero UDP checksums on incoming
encapsulated user-data packets'? (Or perhaps even 'SHOULD'?) It's not doing
anything useful (the encapsulated packet is still protected by its own
checksum), and so it's just useless overhead to check that checksum.

Is it also the case that some forwarding boxes can't easily do the check (I'm
assuming that if they can't _compute_ a checksum easily, they probably can't
_check_ it either, for the same reason, whatever it is)? If so, we would have
to have at least a 'MAY' on that.

	Noel