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

From: [email-masked] (Noel Chiappa)
Date: Fri, 21 Aug 2009 11:41:01 -0400 (EDT)

PS:

    > From: [email-masked] (Noel Chiappa)

    > My impression is that there is probably _no_ set of UDP checksum
    > choices which does not have _some_ problems. 

There is 'of course' a way 'around' all this, but it involves i) a lot more
mechanism in LISP, ii) taking an extra hope when trying to get from an ITR
which _can't_ generate a UDP checkum to an ETR which _can't_ accept a
non-zero checksum , and iii) deploying an infrastructure of intermediary
boxes.

As such, I don't think it's appropriate for an experimental protocol - and in
any event, then we'd need to have the 'is the cure worse than the disease'
discussion.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 21 Aug 2009 12:16:08 -0400 (EDT)

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

    >> So we merely get to chose which problem(s) we will grind our teeth and
    >> accept...

    > There is also the ... possibility that we will weigh all of the UDP
    > checksum-related problems against the cost of using a non-UDP
    > encapsulation .., and decide that is preferable to move to a different
    > encapsulation.

Ah, that's just a choice of a different set of teeth-grinding-actuating
problems... :-)

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 21 Aug 2009 15:09:38 -0400 (EDT)

>> The 'if you allow sending zero, you have to have a MUST for allowing
    >> zero on reception, otherwise black holes' issue holds for both v4 and
    >> v6 too, no?

    > Yes, although there is no need to say this about IPv4, as IPv4 stacks
    > already treat zero checksums as "no checksum calculated".

Perhaps I'm reading RFC-1122 wrong, but it does say, in "4.1.3.4 UDP
Checksums":

  "An application MAY optionally be able to control whether UDP datagrams
  without checksums should be discarded or passed to the application."

which I take to mean that one can build an 1122-compliant host which _does
not_ provide to applications the option to accept UDPv4 datagrams without a
checksum, but rather simply discards them.

So it seems that one wouldn't be able to run LISP as an application in such
boxes, and have it accept packets with zero checksums (since the OS would
discard them first)? Or am I reading RFC-1122 incorrectly?

Does anyone know of OS's which display this UDPv4 behaviour?

	Noel

---

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

> Boxes where the software can't be upgraded to fix this?

I dunno about that. The real issue would be if those intermediate boxes are
something the LISP-user has no control over...

    > On the one hand, it isn't possible for the IETF to write standards that
    > work around every bug that people manage to introduce in their
    > software... But, on the other hand, it doesn't do much good to write
    > standards that won't work in the real world...

Exactly... very concisely put!

    > How important it it that LISP work through NAT boxes?

The $64M question - probably best to answer that first, because a lot of the
other questions depend on the answer to that one.

    > So, if we _do_ consider it a requirement for LISP to work through NATs,
    > I think we have quite a bit of work to do to make it so.

Dunno - I just don't recall off the top of my head how far people have already
gotten with through-NAT operation (see next message).

    > What doesn't make sense to me, though, is to define a protocol that
    > won't work through NATs while requiring that LISP xTRs ignore inbound
    > UDP checksums, and thus making it harder to implement on most systems,
    > supposedly so that LISP will work through buggy NATs....

Yes, that's a good point.

    >> Interesting how we keep going in the same circles, isn't it? :-)

    > I keep hoping we'll find a way out that we hadn't noticed before! :-)

ROTFL!

Although every so often, I do notice something new (e.g. the bit about how it
would be possible to create a mechanism to allow interoperation between
no-UDP-checksum ITRs and no-UDP-checksum-ignore ETRs - maybe we will add that
in the future).

    > Hmmm... Which becomes a reason why it is important to be able to run
    > LISP on common desktop operating systems... and around and around it
    > goes. :-)

:-) Well, at least we're all getting a good chuckle out of it on _this_ turn
around the wheel... :-)

	Noel