Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling

[Margaret Wasserman <[e-mail]>]

Hi Marshall,

Just FYI -- the UDP-TUNNEL draft is now expired.  You might want to  
update (or resubmit) it.

On Sep 12, 2009, at 1:45 PM, Marshall Eubanks wrote:
> We also interpreted this as both a AD proscription, and as feedback  
> from IPv6 guru's, so we didn't question it much. However, the issue  
> can certainly be raised here.

These issues  can definitely be discussed further, alhtough perhaps it  
would be better to discuss them in 6man.  I'll wait for an explanation  
from Magnus about why he proposed this restriction before stating an  
opinion on whether or not to remove it.  In general, though,  it would  
be good to explain the reasons for all of the restrictions in your  
draft, so that people won't be inclined to ignore them without  
realizing why they are important.  If we can't give a good explanation  
of the reasons for a particular restriction, perhaps we should take it  
out.

>> The UDP-TUNNELS draft is written with a different notion of tunnels  
>> than LISP -- like somehow the tunnel will be used for one  
>> application or one type of traffic.  So, it doesn't actually talk  
>> about using zero checksums for some packets and non-zero checksums  
>> for others.  It just says that you must discard, or can't send,  
>> certain types of packets.  Presumably we don't want LISP ITRs to  
>> simply discard packets that are not integrity checked, but I think  
>> it would be consistent with UDP-TUNNELS to just use non-zero IPv6/ 
>> UDP checksums for those packets...
>>
>
> It certainly would.
>
> - draft-eubanks-chimento-6man is intended to allow for tunneling  
> uses without an outer packet checksum in the case where the inner  
> packet does have a checksum. That way, on an end to end basis, the  
> packets will be checked.
>
> - Yes, that does imply it is intended for applications that only  
> send inner packets with checksums or check to verify that the inner  
> packet checksum is present.
>
> - My understanding is that LISP is such a situation, and that is how  
> I read the draft.

LISP currently does nothing to ensure that "inner" packets have any  
sort of integrity checking.  LISP does not (currently) discard UDP  
packets that have zero checksums before tunneling them as required in  
UDP-TUNNELS, and it doesn't do anything else to check that the inner  
packets have integrity checks.

The LISP documents also describe a case where LISP packets would be  
tunneled in another LISP outer header for Traffic Engineering  
purposes.  In that case,  encapsulating an existing LISP packet (with  
a zero UDP checksum) in an  IPv6/UDP/LISP header with a zero UDP  
checksum would clearly violate the restrictions in UDP-TUNNELs.
>
> I regard how stringently this should be enforced as open to  
> discussion and debate (i.e., what other integrity checks are  
> acceptable), but I don't think we are going to get a "ignore all  
> checksums" addition to IPv6.=

I do understand that some of this could change, and hopefully LISP  
Folks will work with 6man to try to get our needs met.  But in the  
meantime, we have two drafts, one of which normatively references the  
other, that are incompatible in certain ways.

IMO, we should log a LISP issue indicating that LISP (-04) is not  
fully compatible with UDP-TUNNEL (-00) in four ways:

(2) LISP does not discard packets with zero UDP checksums before  
enapsulating them in IPv6/UDP with a zero UDP checksum.
(2) LISP does not ensure that all encapsulated packets contain an  
inner integrity checking mechanism before encapsulating in IPv6/UDP  
with a zero UDP checksum.
(3) LISP contains an option that would result in fragmentation of  
inner packets, and it does not indicate that non-zero UDP checksums  
must be used when these packets are encapsulated in an IPv6 LISP header.
(4) The LISP specifications provide for encapsulating LISP packets  
within a second LISP header and it does not indicate that non-zero UDP  
checksums must be used when the new outer header is an IPv6 LISP header.

This issue will insure that we don't forget to check for compatibility  
between LISP and UDP-TUNNELS before we publish the LISP RFCs.

After we enter the issue in the tracker, I think we should park the  
issue (for the LISP group, at least) and re-visit it after the 6man  
group (with help from those of us who participate) reaches consensus  
on the final form (if any) of the UDP-TUNNEL document.  When UDP- 
TUNNEL is no longer a moving target, we can assess what changes (if  
any) will be required for LISP to use it properly.

Margaret