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:14:45 -0400 (EDT)

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

    >> 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.)

    > 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 ... Ignoring _non-zero_
    > checksums on receive does not necessarily follow from allowing hosts to
    > send zero checksums.

Actually, it does - but via an intermediate step through 'deployed base'
issues. (I.e. a somewhat separate technical cause/rationale; one that goes
along a different logic path than my prior example.)

There are, it turns out, a lot of forwarding boxes already deployed out there
that _wrongly_ update zero UDPv4 checksums in packets passing through them, so
that a packet that sets out with a zero checksum will arrive with a non-zero
checksum. (Which just goes to show that not much stuff is using the ability to
send 0 checksum, as allowed by the UDP RFC, otherwise this would have shown up
as a problem before now. But I digress...)

Anyway, in this situation, iff _some_ ITRs are allowed to send packets with
zero UDP checksums (i.e. 'MAY send zero checksums'), then either i) all ETRs
MUST _ignore_ the UDP checksums, even (especially!) if non-zero, or ii) the
specification will allow real-world configurations in which user traffic will
vanish into a black hole. (Repeat prior comment.)

But this is turning into a technical discussion about checksums, and I was
merely wanting to point out that the various checksum questions do have some
inextricable technical linkages.

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 21 Aug 2009 11:52:36 -0400

Hi Noel,

> along a different logic path than my prior example.)

I understand this argument, but I think of this as a separate question/ 
issue than the question of whether to allow the use of non-zero UDP  
checksums in IPv6.  One major difference is that this is an issue for  
both IPv4 and IPv6.
> as a problem before now. But I digress...)

Sadly, it also turns out that there is a large deployed base of  
systems on which
it is impossible to turn off UDP checksum calculation on received  
packets.

There is also a large deployed base of hardware and software that  
computes UDP checksums
(on send and receive) that will calculate checksums on all UDP packets  
that are sent and
discard received IPv6/UDP packets with zero checksums, as well as  
discarding all
packets with invalid checksums.

The open questions in my mind are:

(1) How important is it for LISP ITRs/ETRs to work through (buggy) NAT  
boxes that
corrupt UDP zero checksums?

(2) How important is it for LISP ITRs/ETRs to be implementable on  
widely-deployed
hardware and common operating systems?

Are there choices that will allow us to do both?  Or do we need to  
choose?

> vanish into a black hole. (Repeat prior comment.)

If there are buggy NATs in the world that corrupt the packets that go  
through them,
some of their packets will vanish into a black hole.  This is just a  
fact.

But, does LISP really need to work over them?  More than it needs to  
be implementable
on non-custom hardware and software systems?

Personally, I would choose the flexibility to implement and deploy  
LISP on a wide variety of systems, including currently available  Mac  
OS, Windows, Linux and FreeBSD systems (just to name my favorites),  
over the ability to run it through buggy NATs that corrupt packets.   
Because I don't really see why I'd want (in a real world situation, as  
opposed to a test network) to run my LISP ITR/ETR (which is a tunnel  
endpoint that decapsulates traffic from remote networks) _inside_ of  
my NAT/firewall perimeter.  But, YMMV.

> inextricable technical linkages.

I agree that there are linkages.  I was asked (by you amongst others)  
to try to make a distinction between IETF process-related issues and  
technical issues.  I was also asked to clarify the distinction I was  
making between (1) the decision to allow IPv6 UDP zero checksums (on  
send and receive), and (2) the decision to allow nodes to ignore non- 
zero UDP checksums in received packets.  So, I tried to make those  
distinctions in the issue list that I submitted.  The first item, zero  
IPv6 UDP checksums, is the topic covered by Marshall's 6man draft.  As  
far as I know, no one has written a draft that proposes allowing the  
second item, ignoring all UDP checksums on receipt.

Margaret

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 21 Aug 2009 09:10:25 -0700

On Fri, Aug 21, 2009 at 8:52 AM, Margaret Wasserman<[email-masked]> wrote:
> I understand this argument, but I think of this as a separate question/issue
> than the question of whether to allow the use of non-zero UDP checksums in
> IPv6.  One major difference is that this is an issue for both IPv4 and IPv6.
>>
> Sadly, it also turns out that there is a large deployed base of systems on
> which
> it is impossible to turn off UDP checksum calculation on received packets.
>
> There is also a large deployed base of hardware and software that computes
> UDP checksums
> (on send and receive) that will calculate checksums on all UDP packets that
> are sent and
> discard received IPv6/UDP packets with zero checksums, as well as discarding
> all
> (1) How important is it for LISP ITRs/ETRs to work through (buggy) NAT boxes
> that
> Are there choices that will allow us to do both?  Or do we need to choose?
>
> some of their packets will vanish into a black hole.  This is just a fact.
>
> But, does LISP really need to work over them?  More than it needs to be
> implementable
> Personally, I would choose the flexibility to implement and deploy LISP on a
> wide variety of systems, including currently available  Mac OS, Windows,
> Linux and FreeBSD systems (just to name my favorites),

I believe you're referring to deploying LISP specifically on end host
systems, correct? There are routers currently running BSD and Linux
which may not have the UDP checksum performed on a host NICs so I
don't believe this is an OS issue at all, but a hardware platform
issue. I just think we need to be clear here.

> over the ability to
> run it through buggy NATs that corrupt packets.  Because I don't really see
> why I'd want (in a real world situation, as opposed to a test network) to
> run my LISP ITR/ETR (which is a tunnel endpoint that decapsulates traffic
> from remote networks) _inside_ of my NAT/firewall perimeter.  But, YMMV.

I don't really see why I'd want my real-world LISP deployment to run
on a end-host system.

Greg

> I agree that there are linkages.  I was asked (by you amongst others) to try
> to make a distinction between IETF process-related issues and technical
> issues.  I was also asked to clarify the distinction I was making between
> (1) the decision to allow IPv6 UDP zero checksums (on send and receive), and
> (2) the decision to allow nodes to ignore non-zero UDP checksums in received
> packets.  So, I tried to make those distinctions in the issue list that I
> submitted.  The first item, zero IPv6 UDP checksums, is the topic covered by
> Marshall's 6man draft.  As far as I know, no one has written a draft that
> proposes allowing the second item, ignoring all UDP checksums on receipt.
>
> Margaret
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

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

On Aug 21, 2009, at 12:10 PM, Greg Shepherd wrote:
>> LISP on a

As far as I have been able to tell, it is not possible to turn off  
checking inbound, non-zero UDP checksums on any of these operating  
systems, even when UDP checksums are not offloaded to the NIC.

I know that there are lots of routers that run BSD and Linux, which is  
exactly my point.  If people want to update those routers to support  
LISP as specified in LISP -03, they would need to modify their OS TCP/ 
IP stack, so that it will not calculate inbound UDP checksums for LISP  
traffic to the ETR.  This could be somewhat tricky, as the stack would  
still need to calculate inbound UDP checksums for other protocols,  
such as SNMP and TFTP, to avoid corruption of boot images and  
provisioning information.

This is one of the reasons why I don't think that we should require  
LISP ITRs/ETRs to ignore non-zero UDP checksums on receipt.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Aug 2009 14:29:29 -0400

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

    Noel> Actually, it does - but via an intermediate step through
    Noel> 'deployed base' issues. (I.e. a somewhat separate technical
    Noel> cause/rationale; one that goes along a different logic path
    Noel> than my prior example.)

    Noel> There are, it turns out, a lot of forwarding boxes already
    Noel> deployed out there that _wrongly_ update zero UDPv4
    Noel> checksums in packets passing through them, so that a packet
    Noel> that sets out with a zero checksum will arrive with a
    Noel> non-zero checksum

What data if any do we have about how common these broken forwarding boxes are and to what extent we need to care about them?