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 09:03:58 -0400 (EDT)

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

    > I do think it is important that we separate issues for that separate
    > questions that were raised.
    > ...
    > Because of all of this, I thought it would best to make these issues
    > explicitly separate.

I don't have any opinion directly on the tracker items thing, but I would
like to point out that some of these items are fairly inextricably connected
on a _technical_ level.

For example, iff _some_ ITRs are allowed to send packets with zero UDP
checksums (i.e. 'MAY send zero checksums'), then either i) all ETRs MUST
accept zero checksums, or ii) the specification allows configurations in
which user traffic can vanish into a black hole. (I assume that everyone will
concur that this latter behaviour is utterly unacceptable.)

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 21 Aug 2009 10:43:29 -0400

Hi Noel,

> concur that this latter behaviour is utterly unacceptable.)

I agee.  If ITRs can send IPv6 UDP packets with zero checksums  
(meaning no checksum was calculated), then ETRs need to accept packets  
with zero checksums (without checking the checksum on receive).  Those  
two do go together, and it would probably be worthwhile to update the  
issue about whether to allow this to reflect that.

However, that isn't one of the lines on which my 7 issues were  
delineated...  The issue about checksums on received UDP packets  
concerned the LISP spec's current wording that says that ETRs MUST  
ignore all UDP checksums, even non-zero ones, on receive, which is  
counter to current practice and to standards track RFCs for both IPv4  
and IPv6.  Ignoring _non-zero_ checksums on receive does not  
necessarily follow from allowing hosts to send zero checksums.

Magaret

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Aug 2009 11:05:06 -0400

>>>>> "Noel" == Noel Chiappa <[email-masked]> writes:

    >> From: Margaret Wasserman <[email-masked]> I do think it is
    >> important that we separate issues for that separate questions
    >> that were raised.  ...  Because of all of this, I thought it
    >> would best to make these issues explicitly separate.

    Noel> I don't have any opinion directly on the tracker items
    Noel> thing, but I would like to point out that some of these
    Noel> items are fairly inextricably connected on a _technical_
    Noel> level.

    Noel> For example, iff _some_ ITRs are allowed to send packets
    Noel> with zero UDP checksums (i.e. 'MAY send zero checksums'),
    Noel> then either i) all ETRs MUST accept zero checksums, or ii)
    Noel> the specification allows configurations in which user
    Noel> traffic can vanish into a black hole. (I assume that
    Noel> everyone will concur that this latter behaviour is utterly
    Noel> unacceptable.)

Unfortunately it seems completely unavoidable as well.

* high-end routers seem unable to compute checksums efficiently in hardware
* host stacks throw away bad UDP checksums   in hardware; for V6, this often means throwing away 0 checksums

Margaret and I have some experience with the second point. It was
remarkably difficult to get lig working on some hosts--it was
impossible to use the native UDP stack.  (In our case the reason we
were getting bad UDP checksums had to do with a problem on the other
side.  However I have very high confidence that you'd see the same
problem implementing an ETR on that host.)  We can definitely right
self-consistent specs; I agree it would be unacceptable not to do so.
However it seems that in practice, we will have significant problems
with pairings that do not work, especially for IPV6.

--Sam

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 21 Aug 2009 12:01:50 -0400

> * high-end routers seem unable to compute checksums efficiently in  

I think that this would be better stated:  some high-end routers exist  
today that are unable to compute checksums efficiently in hardware.

I don't know that this is a inherent property of all high-end routers  
(now, or in the future), but we know that there are some that cannot  
do this efficiently today.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Aug 2009 12:51:39 -0700

> impossible to use the native UDP stack.  (In our case the reason we

Lig uses Map-Requests and Map-Replies. Those are control packets which  
to use non-zero UDP checksums for both IPv4 and IPv6.

Want to keep it clear from the UDP checksum discussion on zero UDP  
checksums *on data packets*.

Dino

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Aug 2009 16:01:18 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    >> Margaret and I have some experience with the second point. It
    >> was remarkably difficult to get lig working on some hosts--it
    >> was impossible to use the native UDP stack.  (In our case the
    >> reason we

    Dino> Lig uses Map-Requests and Map-Replies. Those are control
    Dino> packets which to use non-zero UDP checksums for both IPv4
    Dino> and IPv6.

Agreed.  I was trying to focus on something we learned while looking
at lig--turning off checksum verification is hard on a number of
stacks.  You're right that it didn't matter much that I was using lig
and bringing that up might have confused people.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Aug 2009 13:20:02 -0700

Ack, gotcha.

Dino