Subject: [lisp] Any objections for posting draft-ietf-lisp-04.txt?

From: Dino Farinacci <[email-masked]>
Date: Fri, 11 Sep 2009 12:54:06 -0700

The deadline has arrived (we are one hour past it). Anyone have  
objections to posting the -04 draft?

We can start on a -05 revision in a few weeks for any additional issues?

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 11 Sep 2009 16:08:10 -0400

I have a new issue that should probably go in the tracker (for  
resolution in -05 or later, not to hold anything up now).

The UDP-TUNNELS document contains the following restriction:

2. The tunneling protocol and implementation must not use  
fragmentation of the inner packets being carried.

This is inconsistent with one of our two options for MTU handling, the  
one described in section 5.4.1: A Stateless Solution to MTU Handling.   
To address this issue, we could remove the option in section 5.4.1 and  
just require that ITRs implement the stateful solution described in  
section 5.4.2.

Margaret

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Sep 2009 14:47:03 -0700

Margaret,

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Friday, September 11, 2009 1:08 PM
> To: [email-masked]
> Subject: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU
Handling
> just require that ITRs implement the stateful solution described in

The UDP-TUNNELS text also says that the restriction only
applies for a UDP checksum of 0. IMHO, the UDP-TUNNELS
text should be carefully examined before suggesting any
changes in LISP.

Fred
[email-masked]

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

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 11 Sep 2009 21:25:21 -0400

On Sep 11, 2009, at 6:24 PM, Sam Hartman wrote:

>>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:
>
>    Margaret> I have a new issue that should probably go in the
>    Margaret> tracker (for resolution in -05 or later, not to hold
>    Margaret> anything up now).
>
>    Margaret> The UDP-TUNNELS document contains the following
>    Margaret> restriction:
>
> Margaret, I think this would be a duplicate of an open issue.  Your
> existing issue requires us to normatively reference a spec that makes
> appropriate standards track changes to permit what we're doing.
>
> If you believe that Marshall's draft doesn't do that, then we either
> need to convince Marshall to do what we want or reference another
> draft.
>
> I don't see how an extra issue will help.
>
> Does this work for you?

No, I don't see why this is a duplicate.  I am saying that if we use  
IPv6/UDP zero checksums, the UDP-TUNNELS spec contains a restriction  
that we can't send fragments.

After reading Fred Templin's mail, I realize that there is another  
possible solution to this problem -- to state in the fragmentation  
section that you MUST NOT set the UDP/IPv6 chekcsum to zero for  
packets that contain fragments.

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

Margaret

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 12 Sep 2009 13:45:09 -0400

Dear Margaret;

>> need to convince Marshall to do what we want or reference another

I might point out that our draft has not yet been accepted by 6Man,  
and we are certainly open to changes. This
entire discussion here has been very good for our draft.

> that we can't send fragments.

It says " The tunneling protocol and implementation must not use
       fragmentation of the inner packets being carried."

This comes from an email of Magnus Westerlund
-----
[MBONED] WGLC for <draft-ietf-mboned-auto-multicast-08.txt> - UDP  
checksum?
	Date: 	December 5, 2007 3:12:05 PM EST
I think it will be acceptable to update RFC 2460 to say that the UDP
checksum may be turned of[f] under the following restrictions:

1. The UDP payload must have the capability to verify its integrity by
itself, for example by being a complete IP packet in itself.

2. That IP packet fragmentation must not be used.
------
We interpreted "2" as coming from "1" - i.e., the total "outer" packet  
could be fragmented, but the "inner" packet should not be a fragment  
of the original "inner" packet, as then I could not  verify its  
integrity by itself.

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.

I personally think that we could live with fragments. Here is my  
reasoning

- If I want to send fragments over IPv6 LISP, my understanding is that  
only the first will have the inner UDP header, and thus the inner  
fragments after the first will not have any data checks _inside their  
fragment_. However, when the inner packet is reassembled, it _will_  
have a checksum check. This to me fits within the "other integrity  
checks" mentioned below.

- The current draft draft-ietf-lisp-04.txt says (Section 5)

   It is recommended, in IPv4 that packets do not
   get fragmented as they are encapsulated by the ITR.  Instead, the
   packet is dropped and an ICMP Too Big message is returned to the
   source.

   For this reason, there is currently no plan for LISP to add any new
   additional, complex mechanism for implementing fragmentation and
   reassembly in the face of limited-MTU transit links.

I am assuming that the discussion in Section 5.4.1 applies to IPv6 as  
well as IPv4.

Section 5.4.1 :

   When an ETR receives encapsulated fragments, it treats them as two
   individually encapsulated packets.  It strips the LISP headers then
   forwards each fragment to the destination host of the destination
   site.  The two fragments are reassembled at the destination host into
   the single IP datagram that was originated by the source host.

So, again, this would lead to unprotected fragments but errors in the  
inner packet should be caught at the end. In the Tunneling draft
there is an implicit assumption that catching errors only at the end  
is acceptable.

In IPv6 itself, it is also not possible to perform a checksum test  
except at the end node, as there is
no separate checksum for any fragments, so if tunneling was not used,  
any errors would still only be caught at the end.

Magnus might care to provide more insight as to the push-back here, so  
I have cc:ed him.

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

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.

Regards
Marshall

---

From: Sam Hartman <[email-masked]>
Date: Fri, 11 Sep 2009 18:24:01 -0400

Does this work for you?

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 13 Sep 2009 09:24:48 -0400

Hi Marshall,

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

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

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

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 13 Sep 2009 14:48:16 -0400

On Sep 13, 2009, at 9:24 AM, Margaret Wasserman wrote:

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

I think that is a good principle, and one that would certainly apply  
here.

>
>>> The UDP-TUNNELS draft is written with a different notion of  
>>> tunnels than LISP -- like somehow the tunnel will be used for one  
>> - My understanding is that LISP is such a situation, and that is  
>> how I read the draft.
>
> 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.
>

It also, AFAIKT, verify those integrity checks in any way.

IPv6 in IPv6 tunnels and IPv6 in IPv4 tunnels in LISP should not have  
this problem, correct ? (As incoming UDP packets, they would be  
subject to RFC 2460.)
Now, IPv4 in  IPv4 is not an issue, and that leaves IPv4 in IPv6  
tunnels - do you agree with this reasoning ?

It might be possible to treat 4n6 traffic as a corner case. Suppose,  
for example, that LISP requires 4n6 traffic to have checksums. Now, if  
the same traffic arrives for a 4n4 tunnel, and the ITR _doesn't check  
the incoming checksum_ and puts the traffic in the tunnel, it seems to  
me that that the 4n4 traffic is also unprotected end-to-end.

A question that occurs to me is to what extent control traffic (i.e.,  
non-UDP and non-TCP traffic) would be carried over LISP, and to  
whether any of that
traffic is not protected by other means.

> 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 look forward to the thrashing out of the needs for this in LISP, and  
also the reasons not to allow unprotected tunnels-in-tunnels.

> meantime, we have two drafts, one of which normatively references  
> the other, that are incompatible in certain ways.
>
> 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.
>

I think that all of this is reasonable. We will our this draft soon,  
and I hope to summarize all of this discussion at 6Man in Hiroshima.

Regards
Marshall

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 13 Sep 2009 15:33:25 -0400

On Sep 13, 2009, at 2:48 PM, Marshall Eubanks wrote:
> for example, that LISP requires 4n6 traffic to have checksums. Now,  
> if the same traffic arrives for a 4n4 tunnel, and the ITR _doesn't  
> check the incoming checksum_ and puts the traffic in the tunnel, it  
> seems to me that that the 4n4 traffic is also unprotected end-to-end.

The difference is that the UDP checksum does two things in IPv6, while  
it only does one thing in IPv4...

- In IPv4, the UDP checksum is used to provide end-to-end integrity  
checking for the UDP header and data.  Its coverage of the IP header  
fields is redundant, and sometimes annoying.  The IPv4 header checksum  
is responsible for ensuring that the packets are delivered to the  
correct destination.

- In IPv6, the UDP checksum performs both functions:  it offers end-to- 
end integrity checking _and_ assurance that the packet reaches the  
right destination.

To get something in IPv6 that behaves like IPv4/UDP with zero UDP  
checksums, you can't just set the IPv6/UDP checksum to zero.  That  
would be like an IPv4 packet with no IPv4 header checksum AND no UDP  
checksum.  To get something like an IPv4/UDP packet with no UDP  
checksum in IPv6, you need to use IPv6/UDP-Lite.  That way, the  
important IP header fields are checksummed, and the data is not.  We  
should realize, that when we start proposing that IPv6 header  
checksums are not needed for lightweight tunnels, this is the same as  
proposing that we turn off IPv4 header checksums AND UDP checksum for  
the tunnel.

I understand that there are objections to using UDP-Lite as the  
encapsulation protocol for IPv6, as some currently deployed load  
balancing equipment won't use the UDP-Lite source port or the IPv6  
flow label as part of its flow hash.  I'm beginning to strongly  
believe, though, that using IPv6/UDP-Lite/LISP as the IPv6  
encapsulation might be the best choice that we have available, since  
our other choices seem to be that we could eliminate the possibility  
of implementing LISP on commodity systems any time soon, or we could  
significantly reduce its performance on existing router hardware.   
Neither of those choices seems good to me, and they both seem worse  
(at least in the mid-term) than not having our LISP flows properly  
identified by load balancing equipment.

> A question that occurs to me is to what extent control traffic  
> (i.e., non-UDP and non-TCP traffic) would be carried over LISP, and  
> to whether any of that

We'd actually _like_ to create a world in IPv6 where there can be new  
transport layer protocols that _aren't_ just used for special-purpose  
or control traffic.

Margaret

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 13 Sep 2009 16:29:10 -0400

If we are willing to expect load balancers to handle UDP-Lite, we can as 
easily expect them to just use the flow-id filed.  Then we don't bother 
with a UDP header at all.
I can see reasons for sticking with UDP.  But once we step past that, I 
do not follow the reason for some other intermediate between the IP and 
LISP headers.

Yours,
Joel

Margaret Wasserman wrote:
> - In IPv6, the UDP checksum performs both functions:  it offers 
> end-to-end integrity checking _and_ assurance that the packet reaches 
> the right destination.
> 
> checksums, you can't just set the IPv6/UDP checksum to zero.  That would 
> be like an IPv4 packet with no IPv4 header checksum AND no UDP 
> checksum.  To get something like an IPv4/UDP packet with no UDP checksum 
> in IPv6, you need to use IPv6/UDP-Lite.  That way, the important IP 
> header fields are checksummed, and the data is not.  We should realize, 
> that when we start proposing that IPv6 header checksums are not needed 
> for lightweight tunnels, this is the same as proposing that we turn off 
> IPv4 header checksums AND UDP checksum for the tunnel.
> 
> balancing equipment won't use the UDP-Lite source port or the IPv6 flow 
> label as part of its flow hash.  I'm beginning to strongly believe, 
> though, that using IPv6/UDP-Lite/LISP as the IPv6 encapsulation might be 
> the best choice that we have available, since our other choices seem to 
> be that we could eliminate the possibility of implementing LISP on 
> commodity systems any time soon, or we could significantly reduce its 
> performance on existing router hardware.  Neither of those choices seems 
> good to me, and they both seem worse (at least in the mid-term) than not 
> having our LISP flows properly identified by load balancing equipment.
> 
> transport layer protocols that _aren't_ just used for special-purpose or 
> control traffic.
> 
> Margaret
> 
>

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 13 Sep 2009 17:07:04 -0400

On Sep 13, 2009, at 4:29 PM, Joel M. Halpern wrote:

> If we are willing to expect load balancers to handle UDP-Lite, we  
> can as easily expect them to just use the flow-id filed.  Then we  
> don't bother with a UDP header at all.
> I can see reasons for sticking with UDP.  But once we step past  
> that, I do not follow the reason for some other intermediate between  
> the IP and LISP headers.

Well, the problem is that if we run LISP directly over IPv6, the LISP  
header would (I believe) be required to include an IPv6 pseudo-header  
checksum...  Of course that can fit in 2 bytes, while a UDP-Lite  
header takes 8 bytes, so that still might be the better way to go.  It  
makes the differences between IPv4 and IPv6 extend into the LISP  
header, though, instead of being constrained to the IP(v4/v6)/UDP(- 
Lite) encapsulation.

Margaret

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 13 Sep 2009 18:09:31 -0400

I do not follow your reasoning.
Yes, IPv6 decided that it could dispense with the header checksum, 
because the carried thing has checksums.
But the thing that needs to be protected (if something needs protection) 
is that actual data packet.
I read the IPv6 decision as sensibly leaving the degree of pr4otection 
desired to the carried protocol.  It dispenses with a delivery header 
checksum.  That does not mean that everything else is required to 
protect every byte.

The LISP header is serving a function very similar to an IP header. 
IPv6 in IPv6 is a well defined tunnel, and is not required to carry a 
header checksum.  We have a LOT of tunnels.  Many of them are permitted 
over IPv6 without a header checksum.

Yours,
Joel

Margaret Wasserman wrote:
>> If we are willing to expect load balancers to handle UDP-Lite, we can 
>> as easily expect them to just use the flow-id filed.  Then we don't 
>> bother with a UDP header at all.
>> I can see reasons for sticking with UDP.  But once we step past that, 
>> I do not follow the reason for some other intermediate between the IP 
>> and LISP headers.
> 
> 
> checksum...  Of course that can fit in 2 bytes, while a UDP-Lite header 
> takes 8 bytes, so that still might be the better way to go.  It makes 
> the differences between IPv4 and IPv6 extend into the LISP header, 
> though, instead of being constrained to the IP(v4/v6)/UDP(-Lite) 
> encapsulation.
> 
> Margaret
> 
>

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 13 Sep 2009 23:10:08 -0400

On Sep 13, 2009, at 6:09 PM, Joel M. Halpern wrote:

> But the thing that needs to be protected (if something needs  
> protection) is that actual data packet.
> I read the IPv6 decision as sensibly leaving the degree of  
> pr4otection desired to the carried protocol.  It dispenses with a  
> delivery header checksum.  That does not mean that everything else  
> is required to protect every byte.
>
> IPv6 in IPv6 is a well defined tunnel, and is not required to carry  
> a header checksum.  We have a LOT of tunnels.  Many of them are  
> permitted over IPv6 without a header checksum.

If we can do IPV6/LISP without the need to add an IPv6 pseudo header  
checksum to the LISP header, I think that is probably better than IPV6/ 
UDP-Lite/LISP, if only because it saves 8 bytes.  It does, of course,  
make the IPv6 encapsulation more different from the IPv4  
encapsulation, but I don't see why that is a major problem.

Margaret

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Sep 2009 08:42:01 -0400

I don't see it.  There is not that big a difference between an outer 
packet corruption (if an IP-IP tunnel packet) that happens to change 
both the dest IP and the protocol ID, or an outer packet corruption (of 
a UDP encapsulated tunnel packet) that happens to change only the dest 
address, but arrives at a place where some other entity is processing 
that particular UDP port.

I am not saying that we should not expect UDP encapsualted data packets 
to carry UDP checksums.  That is a debate which I will leave to others, 
as it is an applicaiton behavior debate.

But we have a large number of tunnel protocols.  We have generally 
expected tunnel encapsulations, even if they happen to use UDP, to 
basically deliver the same semantics as the IP that they encapsualte. 
Tunnels are an IP extension.  There are services that need higher 
reliability tunnels (Secure SSH tunnels).  There are tunnels that 
provide much stronger checks (IPSec ESP with non-null authentication). 
But that is the choice of the tunnel mechanism, not a mandate from the 
IP service model.

Yours,
Joel

Magnus Westerlund wrote:
> Joel M. Halpern skrev:
>> The LISP header is serving a function very similar to an IP header. IPv6
>> in IPv6 is a well defined tunnel, and is not required to carry a header
>> checksum.  We have a LOT of tunnels.  Many of them are permitted over
>> IPv6 without a header checksum.
>>
> 
> Joel and LISP WG
> (as an individual)
> 
> My view is that there is a big difference between IP in IP tunnels and
> IP/transport/IP tunnels. The reason is that when the outer header gets
> corrupted and ends up on the wrong host there is a big difference who
> handles that wrongly addressed packet. In a IP in IP tunnel, the next
> header is IP, thus only if you have a tunnel decapsulator will you
> really  handle it and determine what to do with it. If it is not there
> it gets dropped on the floor. Even if there is a decapsulator the packet
> will be delivered according to the inner IP header. Which may or may not
> make sense. It might even be correctly delivered, only having taken a
> detour. A packet is only wrongly delivered to an application if the
> following is true for IP in IP with corrupted headers:
> 1. Destination host has an IP tunnel decapsulator
> 2. Inner header is routable in the reached domain
> 3. The destination address of the inner IP header is a private address
> and there exist another host then the intended in the reached domain.
> 4. That host has an application listening on the inner transport port.
> 
> When you have IP/transport/IP then you hand of the packet to your
> transport protocol stack for demultiplexing on port. So if the packet
> arrives at the wrong host and there happens to be an application
> listening on that port, it gets the packet. There is no defense against
> detecting this corruption than what can be implemented on application
> level. So the corresponding list for what ifs are need to be satisfied
> for this option are:
> 1. Destination host has an application listening on port given by the
> tunnel transport protocol.
> 
> It appears to me that the the weeding out factor for IP in IP tunnels
> are significantly larger than it is for IP in transport in IP tunnels.
> Thus I still think turning off the UDP checksum for IPv6 is a bad idea.
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Sep 2009 10:28:27 +0200

Marshall Eubanks skrev:
> [MBONED] WGLC for <draft-ietf-mboned-auto-multicast-08.txt> - UDP checksum?
> could be fragmented, but the "inner" packet should not be a fragment of
> the original "inner" packet, as then I could not  verify its integrity
> by itself.
> 
> 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.
> 

As you note, the email is from 2007, not particular recent. Secondly, it
says "I think". That is not the same as saying that I am right. And if
you actually read the whole email from which the above citation was made
it is clearer that I was not at all certain that what I was proposing
was right. I don't classify myself as an IPv6 expert.

Thus, don't take that email as an decreed limitation on the solution
space from an AD.

What I am today agreeing with from that email is the need for discussing
this in general and get IETF consensus on the solution. I still think
the 6man WG mailing list is the right place to discuss these issues.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Sep 2009 10:49:25 +0200

Joel and LISP WG
(as an individual)

Cheers

Magnus Westerlund

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 14 Sep 2009 08:39:27 -0700

> packets that contain fragments.

I just wanted to clarify that I am not arguing for this
alternative - quite the opposite. I have kept quiet about
MTU since Sam forbade me from discussing it further several
weeks ago. Are we now open to discussions on MTU and, if
so, is it permissible for me to participate?

Thanks - Fred

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Sep 2009 17:41:28 +0200

Joel,

> that particular UDP port.

It comes down to probabilities. If you have an IPv6 outer header being
corrupted in the next header field, then it still needs to pass checksum
test of that transport protocol that it has become. In an IPv6 in IPv6
header, the position that corresponds to UDP and TCP checksum field is
the inner packets Next Header and Hop Limit field. Thus the packet
contains hop-by-hop options and should be discarded due to hop limit to
achieve an all 0 checksum. Thus you need to have data that matches the
present value. Thus it is quite likely to be discarded anyway.

So by deliberate setting the UDP checksum to zero for an IPv6 packet you
are actually significantly reducing any hosts capability to filter away
corrupted packets.

> as it is an applicaiton behavior debate.

Yes, that is not the question here. The question is what impact of the
proposed change of allowing 0 checksums for UDP when using IPv6. This
change is attractive for the tunnel ingress, has little impact on the
tunnel egress, but the cost is born by all hosts on the Internet by
reduced capability of detecting and discarding corrupted packets.

> But that is the choice of the tunnel mechanism, not a mandate from the

As I said above, the cost of this change does not primarily affect the
tunnel end-points or the tunnel service. It is the other hosts on the
network that has to pay the cost of this change. That is why I am
against it.

Regards

Magnus Westerlund

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Sep 2009 11:58:07 -0400

Looking at the same issue, I come to a very different conclusion.

If we have a UDP checksum mandatory in the LISP boxes, we are mandating 
extra work in every LISP ITR and ETR on eveyr data packet handled by 
those boxes.

Conversely, if we do not have the checksum, we will have a small number 
of packets directed to the wrong place, in which case it is almost 
certain that no one will be listening on those ports.  A very small 
portion of the time, some UDP applications somewhere will get a complete 
garbage packet.  In fact, since it is a UDP host stack that you are 
hypothesizing gets this packet, it probably will not be configured to 
accept zero checksums, so it will junk the packet.  Only if we have a 
UDP app at the host the packet gets misdirected to, reading the 
particular port used by UDP data, and which is configured to accept 
packets with checksum 0, from an IPv6 source it has never heard from, 
will any real harm be done.  This seems unlikely in the extremed. 
Paying even a small packet processing cost on every packet handled by 
LISP seems a very high price for protecting from this extreme corner case.

Yours,
Joel M. Halpern

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Sep 2009 16:45:15 +0200

Joel M. Halpern skrev:
> will any real harm be done.  This seems unlikely in the extremed. Paying
> even a small packet processing cost on every packet handled by LISP
> seems a very high price for protecting from this extreme corner case.

Well turning off the checksum makes it 32000 times more likely to occur
than it currently does. I am at least lacking current data on how often
corruption occurs. The data that I know of indicates that it was fairly
common 10 years ago, when the investigate sites sent or received packets
with corruptions in them in varying degrees between 1:1100 to 1:32000.
This is from Stone and Partridge paper:

http://doi.acm.org/10.1145/347059.347561

And of these 8% was single bit-errors, than can be caused anywhere on
the path, such as links, buffer memories, etc.

I know this is old data and I do hope the real error rates are
significantly lower today. If anyone knows of publication of more
current data then please reference that.

But, considering that data rates has gone up, that we have more hosts on
the Internet, and that LISP is intended for tunneling across the
backbone and move large amounts of data I think we should be careful
consider what it means to increase the probability of receiving spurious
data with a factor of 32000.

At the same time I do understand the gain of not having to do the checksum.

No, I am not making a decision based on a 10 year old paper. But, I do
speak for caution considering the potential effects here.

Cheers

Magnus Westerlund

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Sep 2009 12:09:04 -0400

Hi Magnus,

> http://doi.acm.org/10.1145/347059.347561

Although less scientific than the Stone Partridge paper, some folks  
have circulated error logs on the LISP list that indicate that the  
current rate of corruption is still about the same.  The largest  
sample we saw had corruption of about 1:7000 packets.  I've checked a  
few systems that I have access to, and they are in the same range.   
So, it's unlikely that the numbers have changed all that much in the  
last 10 years.

Margaret

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 15 Sep 2009 12:46:36 -0400

On Sep 15, 2009, at 12:09 PM, Margaret Wasserman wrote:

> sample we saw had corruption of about 1:7000 packets.  I've checked  
> a few systems that I have access to, and they are in the same  
> range.  So, it's unlikely that the numbers have changed all that  
> much in the last 10 years.

That mail thread was titled : Flow label redux [Re: IPv6 UDP checksum  
issue]

I don't remember this exact number, the ones I saw were all smaller.  
Note that

1/7000 = 1.4 x 10^-4

Can you send me the email with that result ?

Looking at some http servers here at AmericaFree.TV (we get plenty of  
IPv4 UDP inbound) the rates seem to be
a bit lower for UDP on Gig-E fiber :

udp:
	2562490909 datagrams received
	1 with incomplete header
	8 with bad data length field
	706 with bad checksum
	400791 dropped due to no socket
	0 broadcast/multicast datagrams dropped due to no socket
	314287 dropped due to full socket buffers
	0 not for hashed pcb
	2561775116 delivered
	2923557119 datagrams output

706 / 2,562,490,909 = 3 x 10^-7

udp:
	1705417676 datagrams received
	0 with incomplete header
	0 with bad data length field
	10 with bad checksum
	915464 dropped due to no socket
	0 broadcast/multicast datagrams dropped due to no socket
	19332 dropped due to full socket buffers
	0 not for hashed pcb
	1704482870 delivered
	2728246320 datagrams output

10 / 1,705,417,676 = 6 x 10^-9

udp:
	2736395896 datagrams received
	0 with incomplete header
	0 with bad data length field
	2 with bad checksum
	233675 dropped due to no socket
	162 broadcast/multicast datagrams dropped due to no socket
	28232 dropped due to full socket buffers
	0 not for hashed pcb
	2736133825 delivered
	3163915652 datagrams output

2 / 2,736,395,896 = 7 x 10^-10

udp:
	37512759 datagrams received
	0 with incomplete header
	0 with bad data length field
	6 with bad checksum
	33335 dropped due to no socket
	0 broadcast/multicast datagrams dropped due to no socket
	2315 dropped due to full socket buffers
	0 not for hashed pcb
	37477103 delivered
	41487516 datagrams output

6 / 37,512,759 = 1.6 x 10^-7

I think that checksum loss rates on fiber will be low - the lower ones  
here are not that far from what you
would expect from fiber bit error rates < 10^-12.

Clearly, the checksum rates on fiber will be higher. As it happens, I  
use some laptops as wireless routers. Here is data from one :

UDP : 3732883 datagrams received
4 with bad checksum

4 / 3,732,883 = 10^-6

So, this is higher, but still not as high as 10^-4.

I am working on a writeup of the implications of these numbers.

Regards
Marshall

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Sep 2009 12:54:14 -0400

Assume for now that the corruption rate is really 1 in 7000.
Of those, how many arrive at a real machine with a client sitting on the 
UDP port that is being read.
And on which (assuming we permitted it) IPv6 UDP checksums are not enabled.
And where the application does not have other check logic allowing it to 
safely ignore irrelevant packets (probably with a log message.)

Because unless that compound number is noticeable, we are still talking 
about asking every LISP instance to do significant work on every packet 
to protect against a corner case.

Yours,
Joel

Margaret Wasserman wrote:
> Although less scientific than the Stone Partridge paper, some folks have 
> circulated error logs on the LISP list that indicate that the current 
> rate of corruption is still about the same.  The largest sample we saw 
> had corruption of about 1:7000 packets.  I've checked a few systems that 
> I have access to, and they are in the same range.  So, it's unlikely 
> that the numbers have changed all that much in the last 10 years.
> 
> Margaret
> 
>

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Sep 2009 13:08:27 -0400

On Sep 15, 2009, at 12:46 PM, Marshall Eubanks wrote:
>
> That mail thread was titled : Flow label redux [Re: IPv6 UDP  
> checksum issue]
>
> Looking at some http servers here at AmericaFree.TV (we get plenty  
> of IPv4 UDP inbound) the rates seem to be

Tell me a little more about your environment...  Is this UDP sourced  
locally?  Or from across the Internet?  In other words, do you know  
the average number of hops that it would traverse before hitting this  
server?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Sep 2009 13:12:55 -0400

> I don't remember this exact number, the ones I saw were all smaller.  

Steiner Haug from nethelp.no sent these numbers to the list on 11  
August, 2009:

 > - 11,125,766,153 IP packets received, with 0 bad header checksums
 > -  9,311,954,730 UDP datagrams received, with 1,300,228 bad checksums

This is a little more than 1:7000.

Margaret

---

From: Loránd Jakab <[email-masked]>
Date: Tue, 15 Sep 2009 19:15:37 +0200

On Tuesday, September 15, 2009 18:46:36 Marshall Eubanks wrote:
> I think that checksum loss rates on fiber will be low - the lower
>  ones here are not that far from what you

CAIDA, The Cooperative Association for Internet Data Analysis, in 
cooparation with the DNS Operations, Analysis, and Research Center 
organize each year since 2006 a 1-day (recently 2-day) DNS data 
collection event, collecting traffic at DNS root servers, TLD servers 
and client side iterative/caching resolvers. This may be the most 
representative UDP dataset currently available.

They have a page with statistics on checksum mismatch from the 2009 data 
collection event here:
https://www.dns-oarc.net/node/210

It seems that the failure rate is in the order of 10^-3 (with some 
outliers in the 50% range).

We could contact them for more details, I suppose.

Regards,
Loránd Jakab