Subject: Re: [lisp] Checksum-related issues for the tracker

From: [email-masked] (Noel Chiappa)
Date: Tue, 11 Aug 2009 17:51:11 -0400 (EDT)

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

    > if you claim that LISP xTRs don't have to comply with RFC 1122 because
    > they are routers, then they do need to comply with RFC 1812
    > (Requirements for IP Version 4 Routers)

Well, if we're going to descend into red-tape legalese, I'll simply argue
that they aren't routers _either_... :-)

But to be serious for a moment:

    > "if a UDP checksum is present in a received datagram, the checksum must
    > be verified and the datagram discarded if the checksum is incorrect."

The problem is that given the large number of NAT boxes _already deployed in
the network_ which don't correctly handle UDP checksums, this is all nice
verbiage, but it's totally overtaken by the tidal wave of reality.

Following the letter of that rule would result in discarding datagrams which
are perfectly fine, but have been damaged in transit by incorrectly operating,
but unfortunately widely deployed, devices.

More generally:

I forget which US Supreme Court justice that said 'the U.S. Constitution is
not a suicide pact'. When slavish adherence to the letter of the written
thing produces results that common sense says are nonsensical, you have to be
willing to step back and apply a little common sense.

Something similar applies to specification documents. Rigid adherence to old
protocol specifications, specifications which i) don't really apply to a new
application which is somewhat sui generis, and ii) have been effectively
obsoleted by the widespread deployment of devices which violate the operation
of the protocol, just doesn't make sense. In cases like that, you just have
to go back to using sound engineering judgment. 

Look, these prior RFCs weren't handed down on stone tablets from super-beings
who are an order of magnitude smarter than us. (And some of the people who
wrote them are still here... :-) I see no reason to treat them with awed
deference. They were put together by people with a practical engineering take
on things.

Good engineering ought to trump papework rules. If the IETF process isn't
able to do that, it has developed a real problem.

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Aug 2009 10:12:01 -0400

> but unfortunately widely deployed, devices.

I understand that some of us want to implement LISP on devices that  
are incapable of calculating UDP checksums at an acceptable rate of  
performance.

I also understand that there are widely deployed low-end NAT boxes for  
which the current software is broken, so that it corrupts all zero UDP  
checksums.

The solution that you propose is to forbid the ETR from calculating  
the received checksum.  Unfortunately, that solution has costs:

(1) It makes LISP less compatible with currently implemented, RFC- 
compliant TCP/IP stacks (which are far more widely deployed than the  
devices mentioned above).

(2) It means that if we discover later that there are problems caused  
by the use of UDP zero checksums (either for LISP or for other hosts  
and applications with
which we need to co-exist, either in IPv4 or IPv6), we _can't_ turn on  
UDP checksums to solve the problem.

Personally, I would rather have language in the specification that  
indicates that all ITRs and ETRs must be capable of supporting UDP  
checksums.  However, for performance reasons, ITRs MAY (or even  
SHOULD) send zero checksums.  I am not at all comfortable with  
language that says that LISP ETRs should ignore non-zero checksums on  
receipt, because of the costs listed above.

I _do_ understand that this means that LISP won't work (at all) when  
used through the aforementioned buggy NAT boxes.  But, it isn't clear  
to me that LISP can work through those NAT boxes, anyway.  Nor is it  
clear to me why we would care to place this requirement on LISP (that  
it work through NAT boxes), any more than we care whether it
works through IPv4/IPv6 translators.

There are a number of reasons why I don't believe that placing an xTR  
behind a typical IPv4 NAT box will work:

(1) Mapping look-up replies do not always come from the same host to  
which they were sent.  Those replies will be dropped by the NAT box,  
since there is no state to indicate where to send them.

(2) NAT boxes do not limit themselves to corrupting the UDP checksum.   
They will also modify the source RLOC (the source IP address), the IP  
header checksum, and the source UDP port in the outer header.  This  
means that the EID to RLOC mapping for all nodes inside the site will  
need to use the external address of the NAT as the RLOC.  However,  
LISP doesn't specify a mechanism for determining what that external  
address is, or noticing when it changes.

(3) The IP addresses used behind these NAT boxes are typically private  
addresses (from net 10 or another private prefix).  If these addresses  
are used as EIDs (by the end nodes that don't even know that their  
traffic will be LISP encapsulated), they will not be translated by the  
NAT box (since there is no LISP ALG).  They will be meaningless (or  
worse) when the traffic is decapsulated on the other end.

There are even bigger problems if _both_ ends are behind a NAT, as  
LISP doesn't contain any mechanism to set-up the state needed for two  
nodes (an ITR and an ETR) behind NATs to set-up communication with  
each other.  I also haven't considered what would happen if a mapping  
server was behind a NAT box.

Now, I realize that a sophisticated person with administrative access  
to the NAT box could do things like:

- set up a static port mapping for traffic to the LISP port(s) to  
reach the LISP xTR.
- configure the NAT box (or another DHCP server) to provide allocated  
EIDs internally, instead of private addresses.  Or even configure the  
internal nodes manually.
- determine the address that is used outside the NAT, and register  
that mapping in the LISP mapping system (although it unclear to me how  
changes will be detected).

But, couldn't a person who has that level of access and expertise just  
upgrade his buggy NAT software?  Or, better yet, _replace_ his NAT  
with something that sucks less?

People who are behind a NAT box that they do not control won't be able  
to configure the NAT to allow LISP to work through it, anyway.

So, exactly what problem are we trying to solve by mandating that ETRs  
must not check non-zero checksums?

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Aug 2009 08:44:54 -0700

> used through the aforementioned buggy NAT boxes.  But, it isn't  
> clear to me that LISP can work through those NAT boxes, anyway.  Nor  
> is it clear to me why we would care to place this requirement on  
> LISP (that it work through NAT boxes), any more than we care whether  
> it

Let me make this crystal clear.

(1) LISP does work through NATs today. We have an existence proof,  
many of the boxes on the LISP network
     are behind NATs.

(2) LISP *is* compliant with RFCs regarding 0 UDP-checksuming when  
IPv4 is the outer header.

What you state is an issue is only when the outer header is IPv6. The  
following combinations are spec and RFC compliant:

(1) IPv4-in-IPv4
(2) IPv6-in-IPv4

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Aug 2009 11:52:15 -0400

Hi Dino,

On Aug 12, 2009, at 11:44 AM, Dino Farinacci wrote:

>> I _do_ understand that this means that LISP won't work (at all)  
>> when used through the aforementioned buggy NAT boxes.  But, it  
>> isn't clear to me that LISP can work through those NAT boxes,  
>> anyway.  Nor is it clear to me why we would care to place this  
>> requirement on LISP (that it work through NAT boxes), any more than  
>> we care whether it

Could you explain what configuration is needed to make this work?

> IPv4 is the outer header.

It is _not_ RFC compliant to ignore non-zero UDP checksums in either  
IPv4 or IPv6.  So, the behavior described in the LISP document is  
_not_ RFC compliant for IPv4 or IPv6 at this point, nor will it be  
when you change the text to indicated that the ETR _MAY_ ignore non- 
zero UDP checksums.  The current RFCs require that receiving nodes  
_check_ non-zero UDP checksums.  This is just a fact, and I don't  
really understand how we could be arguing about it.

It may be the case that there are good reasons for LISP to behave as  
it does.  If so, we need to document those reasons very clearly and  
get IETF consensus that ignoring non-zero UDP checksums is a  
reasonable thing to do in this case.

Margaret

---

From: David Meyer <[email-masked]>
Date: Wed, 12 Aug 2009 09:21:40 -0700

> Could you explain what configuration is needed to make this work?

	Its actually pretty simple. You need to tell ITRs how to
	reach the ETR that is behind the NAT; as normal, the
	outside world reaches devices that are behind the NAT by
	using  whatever the "outside address" is on the NAT. So
	the ETR behind the NAT needs to provide that address in
	its map-reply messages. 

	In practice, you would configured something like

	 ip lisp database-mapping <eid-prefix/mask> <outside addr> p 1 w 100 

	or whatever syntax your implementation uses. Of course,
	the <outside addr> isn't an interface on the ETR, but
	this is easily remedied by configuring a loopback
	interface with this address.  

	BTW, all of this can be automated in the same way the
	name to outside address binding for the NAT is automated
	with dynamic DNS. 

	Dave

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Aug 2009 13:06:33 -0400

Thanks, Dave.  A few further questions...

> 	name to outside address binding for the NAT is automated

This makes sense, as far as it goes...

So, if the outside address changes, how would the devices sending the  
map requests know to reach the ETR at the new address?  If it used the  
DNS to get the address of the ETR originally, how will it know that it  
should re-try DNS?  How would the ETR know to start using the new  
address in its mapping replies?

If the ITR inside the NAT sends a mapping request and the mapping  
reply comes back directly from the remote ETR, not from the mapping  
server, how does that reply reach the ITR behind the NAT?

Margaret

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 13 Aug 2009 10:49:31 +0200

On Aug 12, 2009, at 19:06 , Margaret Wasserman wrote:

> So, if the outside address changes, how would the devices sending  
> the map requests know to reach the ETR at the new address?  If it  
> used the DNS to get the address of the ETR originally, how will it  
> know that it should re-try DNS?  How would the ETR know to start  
> using the new address in its mapping replies?

As far as I have understood the example, this is just a change in the  
mapping, normal LISP mechanisms can be used for that, i.e., SMR,  
Nonce, versioning....

Luigi

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp