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 13:05:51 -0400 (EDT)

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

    > One major difference is that this is an issue for both IPv4 and IPv6.

?? 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, the details of the 'intermediate boxes bash checksums' issue are
probably subtly different between v4 and v6 (since it's clearly _already_ a
protocol violation in v4), but was that what you meant?

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

Indeed - hence my prior comment to Sam about 'choice of teeth-grinding'.
Bad choices to the left of us, bad choices to the right...

    > Personally, I would choose the flexibility to implement and deploy
    > LISP on a wide variety of systems ... over the ability to run it
    > through buggy NATs that corrupt packets.

In general, I tend to lean towards the 'boxes which can't do X cannot be
xTRs' bad choices, because there at least, it's very visible, and you know
right up front that you have a problem. In other words, you have _some_
control over the problem - it's right there in front of you, in a local
device over which you have some influence.

To me, preferring the choices which allow more boxes to be xTRS, but which
also can cause random pairings of xTRs to fail, because the path between them
_may_ contain devices which cause packets to vanish - something which the
end-nodes have no control over (either the path, or what boxes are out there
in the network) - is a more user-unfriendly approach.

(That also makes me realize that my prior comment about 'there is a way around
this, but it is painful' is only half-correct. We _can_ work around the
problem of 'non-UDP-checksum ITR talking to UDP-checkum ETR', albeit at a
certain level of complexity. The 'box on the path bashes a zero checksum'
problem causes me to truly shudder with horror... although now that I think
about it, one can work around that one too - test the path, and treat like
non-UDP/UDP if failure... but then there are path changes, so the path
characteristics will change over time.... oh, and even better, what do you do
if there's a bad box on the path _to_ to the intermediary box from the non-UDP
box - yuck.)

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

Well, you can probably just simplify that to 'How important is it for LISP to
work through NAT boxes', because there seem to be a _lot_ of the non-compliant
ones out there, and requiring their extermination from the Internet before
LISP can work reliably seems like a 'boiling the ocean' solution.

But maybe I'm wrong there - there are numerous web site that just won't work
unless you have the latest and greatest Flash player, or whatever, loaded
onto your machine... :-(

Anyway, _iff_ requiring people to eliminate them (which is another choice) is
unreasonable, it does seem to boil (sic) down to either i) we accept that
LISP doesn't work through NAT boxes at all, or ii) we have to work around the
buggy ones - option iii) 'sometimes it works, and sometimes it doesn't' is, I
claim, really just another name for i), for the average user.

    > (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?

Well, I can't think of any... as long as we are using UDP... but then we get
back to _that_ question! :-)

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

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 21 Aug 2009 14:38:24 -0400

> on reception, otherwise black holes' issue holds for both v4 and v6  

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

> in the network) - is a more user-unfriendly approach.

Actually, the simplest way to make LISP (or any UDP-based protocol)  
work through NAT boxes that bash packet with zero checksums is to use  
non-zero checksums.

The only reason we're talking about using zero checksums at all is  
because there are boxes on which we want to implement ITRs/ETRs that  
don't support them efficiently.

> ones out there,

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

> and requiring their extermination from the Internet before

Hmmm...  I get your point.  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...

Let's consider your reworded question, though...  How important it it  
that LISP work through NAT boxes?

There are a number of things about the current LISP protocol that  
won't work through NAT boxes.  I have only just started experimenting  
with LISP myself, but already I know that LIG doesn't work through NAT  
boxes, because the response comes back from a different port than the  
port to which the request was sent.  Also, LISP allows map replies to  
come from a different IP address than the address to which the request  
was sent.  And AH doesn't work through NAT boxes, does it?

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.

Personally, I don't understand why working through NAT boxes is  
important enough to make these sorts of changes, so I would prefer to  
leave LISP more like it is, and just drop the "works through NAT"  
requirement.  But, are there good reasons why LISP should work through  
NATs that I haven't considered?  I understand that there may be  
reasons why we need this, and if the WG decides that it _is_ important  
for LISP to work with NATs, I'll help to identify what needs to change  
to make that work.

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....
> Interesting how we keep going in the same circles, isn't it? :-)

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

Margaret

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 21 Aug 2009 14:42:17 -0400

Procedural suggestion:
It is perfectly reasonable to have two items where
Item 1 suggests a change X
Item 2 says "If you do 1, figure out what to do about this corollary."
The existence of item 2 in the tracker helps one avoid losing track of 
the pieces.  Using two items allows one to focus ones discussion.

I am not all that fond of using trackers.  But if we are going to use 
them, may I suggest we actually use them to enable divide-and-conquer.

Thank you,
Joel

Margaret Wasserman wrote:
> Actually, the simplest way to make LISP (or any UDP-based protocol) work 
> through NAT boxes that bash packet with zero checksums is to use 
> non-zero checksums.
> 
> 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...
> 
> There are a number of things about the current LISP protocol that won't 
> work through NAT boxes.  I have only just started experimenting with 
> LISP myself, but already I know that LIG doesn't work through NAT boxes, 
> because the response comes back from a different port than the port to 
> which the request was sent.  Also, LISP allows map replies to come from 
> a different IP address than the address to which the request was sent.  
> And AH doesn't work through NAT boxes, does it?
> 
> 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.
> 
> NATs that I haven't considered?  I understand that there may be reasons 
> why we need this, and if the WG decides that it _is_ important for LISP 
> to work with NATs, I'll help to identify what needs to change to make 
> that work.
> 
> Yes.  I keep hoping we'll find a way out that we hadn't noticed before!  
> :-)
> 
> Margaret
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>