Subject: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 20 Aug 2009 13:37:08 -0000

#7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation
-------------------------------+--------------------------------------------
Reporter:  [email-masked]  |       Owner:                             
    Type:  technical           |      Status:  new                        
Priority:  major               |   Component:  draft-ietf-lisp            
Severity:  -                   |    Keywords:  LISP Decapsulation Checksum
-------------------------------+--------------------------------------------
 Discussion on the list focused on whether the IPv4/IPv6 UDP checksum may
 be ignored when received as a non-zero, and what the potential costs and
 benefits of this behavior would be. There was also a discussion of which
 RFCs this violates and would need to be updated if the LISP WG decided
 that not checking IPv4/IPv6 checksums was an acceptable behavior.

  Background:

 The LISP Draft authors chose to specify that an ETR ignore the UDP
 checksum on receipt/decapsualtion of a LISP packet.  The reasons mentioned
 on the LISP for this were:

 1) Ease of implementation.  Since checksums were not typically used on
 encapsulation (see issue tracker ticket #6) they aren't considered
 critical for LISP.

 2) Some NAT devices will ignore the UDP packet's 0 checksum, and re-
 calculate and add a new checksum when translating the packet.  This
 prevented the ETR requiring the packet's checksum be 0.  There was a
 report that some (older) IPv4 NATs incorrectly did this calculation.

 Some input from participants on thread on the WG list are included below,
 since they help summarize the outstanding issues and the potential impacts
 of the authors original decision.

  -------------------

  Margaret Wasserman contributed the following analysis:
  (text edited to focus on checksum decapsulation issue)

 #1:  Not Checking Inbound Non-Zero UDP Checksums Violates RFC 1122 and RFC
 2460  Not checking non-zero UDP checksums on inbound traffic (at the ETR
 in LISP) violates RFC 1122 (for IPv4) and RFC 2460 (for IPv6).  There is
 concern that checking the checksums would cause two problems:
 performance issues for existing routers that lacks the ability to
 perform the checksum efficiently, and problems when the zero UDP
 checksums themselves are corrupted en route (particularly by poorly
 implemented NAT boxes).  This issue could be addressed in one of two
 ways:  (1) require standards-compliant behavior in LISP ETRs, or  include
 a normative reference to a standards-track RFC that updates  RFC 1122 and
 RFC 2460 to allow receiving nodes to ignore non-zero UDP checksums.

 #2: Not Checking Inbound Non-Zero Checksums not Universally Implemented.

 There are TCP/IP stacks that do not have any way to turn off checking of
 non-zero UDP checksums on receipt.  If this functionality can be turned
 off, it may not be possible to turn it off for LISP traffic only , while
 it remains enabled for other traffic.  Also, the checksum may be checked
 in hardware before the software sees the packet.  This issue could be
 resolved by changing the text that indicates that LISP ETRs "MUST" ignore
 incoming UDP checksums to a "MAY".

 -----------

 Sam Hartman suggested text, and Dino Farinacci responded:

 On Aug 11, 2009, at 8:17 PM, Sam Hartman wrote:

 <Sam> You'd need to word it as an ITR MAY send a zero checksum, an ETR
 MUST accept a 0 checksum and MAY ignore the checksum completely.

 <Dino>Anyone object to me putting this text in the -04 spec now?

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/7>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 20 Aug 2009 13:55:41 -0400

Hi Darrel,

Thank you for attempting to enter the issues that I sent into the  
tracker, but I think that there has been some mistake...

I was asked, by multiple people on the list, to make a distinction  
between the different issues that were raised as part of the UDP  
checksum discussion, and I went to some trouble to review the entire  
discussion and call out what I considered to be the _7_ separate  
issues that were raised during the discussion.  It was not my  
intention that this would result in two tracker issues, one that  
covers two of the issues from my list, and one that covers four of  
them.  (Is there still an issue coming that covers the 7th?).  Please  
correct this mistake by opening seven issues that match my original  
mail.

I'm also somewhat put off by the fact that these issue entries include  
the authors' justification for the current text _before_ they even  
state the issue that was raised.  Is writing up these justifications  
what made it take _over a week_ for my issues to be entered into the  
tracker at all?

Margaret

On Aug 20, 2009, at 9:37 AM, lisp issue tracker wrote:

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

---

From: David Meyer <[email-masked]>
Date: Thu, 20 Aug 2009 12:07:06 -0700

Hey Margaret,

> discussion and call out what I considered to be the _7_ separate issues 
> that were raised during the discussion.  It was not my intention that 
> this would result in two tracker issues, one that covers two of the 
> issues from my list, and one that covers four of them.  (Is there still 
> an issue coming that covers the 7th?).  Please correct this mistake by 
> opening seven issues that match my original mail.
>
> the authors' justification for the current text _before_ they even state 
> the issue that was raised.  Is writing up these justifications what made 
> it take _over a week_ for my issues to be entered into the tracker at 
> all?

	It seems there are a misunderstandings here. First, both
	Darrel and I read the tracker procedure Sam posted to say
	that only the authors, WG chairs, or the WG secretary
	could open issues in the LISP tracker; see for example
	the email included below (Message-ID: <[email-masked]>).
	So Darrel was trying to get your issues into the tracker
	on the assumption that you couldn't do it yourself; issue
	#8 (#8: Limits on "Gleaned" Map Entries Not Clear)
	suggests that you can indeed add your own issues so that
	assumption was apparently false. 

	Second,  Darrel and I discussed whether it would be
	correct to open an issue for each of your seven issues or
	to summarize. Since it was unclear that you wanted seven
	issues opened, we summarized (on the theory that such
	summarization would help the group resolve the issues
	more efficiently).

	In any event, I see that you intended that each be opened
	as a separate issue. Now the question is how would you
	like to resolve this? The reason I ask is that one
	approach would be just to cut and paste from your email
	and if possible, cross reference the relevant issue that
	Darrel opened to the newly created one. I'm not sure if
	the tracker can do that. Alternatively, if the tracker
	can delete an issue, then we can just open 6 new ones (#8
	is what I believe was #7 in your original list).

	This is a relatively simple process issue that should be
	easy to resolve, and I'm glad to help you and/or the
	chairs do so. Just let me know if I can help.

	Dave
	
----
From: Sam Hartman <[email-masked]>
To: Noel Chiappa <[email-masked]>
Cc: [email-masked]
Subject: Re: [lisp] Checksum-related issues for the tracker
Date: Tue, 11 Aug 2009 17:26:49 -0400

Can we please wait until the authors or secretary opens these
issues and assigns numbers before discussing in this thread?
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 20 Aug 2009 15:15:28 -0400

Hi Dave,

> 	assumption was apparently false.

I can't add issues to the tracker, and I didn't add issue #8.  I  
assumed that Darrel did so in response to my mail...
> 	is what I believe was #7 in your original list).

I'm not sure what the best way forward would be (from a tracker  
organization standpoint), because I don't know how this tracker system  
works.  But I do think it is important that we separate issues for  
that separate questions that were raised.  For example, there seemed  
to be a lot of confusion about the discussion of RFC 2460 compliance,  
since it got all entangled with the discussion of whether turning off  
IPv6 UDP checksums is the right thing to do, technically.  I think we  
need to decide on the right technical choice (based on the interests  
of the whole Internet, not just LISP).  Then, if our choice is at odds  
with an IETF standards track or BCP RFC, we will need to figure out  
how to get that RFC updated.  Of course, this all very complex on the  
UDP checksum issue, because there are a lot of other people involved  
in deciding what the right technical choice is, and there are already  
proposals out there to change the existing RFCs.   Because of all of  
this, I thought it would best to make these issues explicitly separate.

Perhaps we could just open 6 separate issues and then close the two  
that were opened as duplicates of (at least some of) the other 6,  
assuming the tracker will support that?

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Aug 2009 15:17:00 -0400

Darrel, 

One of the nice things that Margaret did in her initial issue
write-ups was separate the technical issues from the process issues.
For me as the chair who will be judging consensus on these, that
actually helps a lot.  I can ask the WG to focus on the technical
issues and once we have resolution there,then confirm that we're good
on the process issues.  The way in which you have entered the issues
manages to lose that.

I agree with Margaret that the background text is problematic.  I can
understand adding some context to an issue so that someone reading the
issue can understand what the issue is.  For example if we were having
a discussion in which I said "Md5 is a bad choice; we should use
sha-256 instead because it does not suffer from the collision attacks
that have been demonstrated against md5," it would be entirely
reasonable to add context explaining where we were using md5 when
opening an issue.

However I agree with Margaret that it is generally a bad idea to add
an explanation of why the current text is the way it is to an issue
someone else has reported.  It's way too easy for editors to use that
to give way too much weight to their own personal opinions as
individual contributors.  It's possible that if you were very careful
to maintain a neutral tone you could make this work, but it's
definitely not worth the effort.  In this specific instance, you
stated several things as requirements--NAT traversal, support for
LAGs--that we have not decided as a WG actually are requirements.  I
understand that a significant subset of the WG, including the authors of the drafts that form the basis for our work, believe these are
requirements.

I don't think we can have a WG discussion of this until we have the
discussion of LISP deployment models that you and I discussed the
other day.

It's really important that when you're acting as an editor or as a
chair, you maintain a neutral tone.

A better approach is to respond as an individual contributor
explaining in your opinion why the text is the way it is; often it
will be appropriate to include this in the tracker as a comment.

The point of the issue in the tracker is to explain what the person
who has reported the issue believes is wrong with the document and how
they propose to improve it.  The point of the following discussion is
to evaluate whether this is true.

Also, especially if we're going to try and have issue discussions in
threads with the issue number, it's really important that we open
issues promptly.  While I appreciate that you were trying to combine
both the issue opening and discussion summary steps, I think it would
have been better to just cut&paste the issues quickly and then defer
the summarization of the discussion.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Aug 2009 15:19:21 -0400

I opened issue #8 in my role as WG chair.

---

From: David Meyer <[email-masked]>
Date: Thu, 20 Aug 2009 12:21:24 -0700

On Thu, Aug 20, 2009 at 03:15:28PM -0400, Margaret Wasserman wrote:
> I can't add issues to the tracker, and I didn't add issue #8.  I assumed 
> that Darrel did so in response to my mail...

	Humm, ok. I have to admit I'm not well versed in tracker
	usage.

> works.  

	Me either.

> But I do think it is important that we separate issues for that 
> separate questions that were raised.  For example, there seemed to be a 
> lot of confusion about the discussion of RFC 2460 compliance, since it 
> got all entangled with the discussion of whether turning off IPv6 UDP 
> checksums is the right thing to do, technically.  I think we need to 
> decide on the right technical choice (based on the interests of the whole 
> Internet, not just LISP).  Then, if our choice is at odds with an IETF 
> standards track or BCP RFC, we will need to figure out how to get that 
> RFC updated.  Of course, this all very complex on the UDP checksum issue, 
> because there are a lot of other people involved in deciding what the 
> right technical choice is, and there are already proposals out there to 
> change the existing RFCs.   Because of all of this, I thought it would 
> best to make these issues explicitly separate.

	Well taken.

>
> Perhaps we could just open 6 separate issues and then close the two that 
> were opened as duplicates of (at least some of) the other 6, assuming the 
> tracker will support that?

	That seems completely reasonable. Hopefully someone who
	knows if that can be done will answer up.

	Thanks for the comments,

	Dave

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 20 Aug 2009 12:40:05 -0700

Margaret,

The below message with my author's hat on, rather than as a WG co-chair.

So speaking as an author, let me articulate why I opened the issues the
way I did, and see if I can address some of your concerns below.
However if you feel that you'd like each of your issues directly (and
they need to be opened in a more timely manner), then perhaps its better
to have individual WG members open their own issues.

When thinking about what would be useful for the issue, I wanted to have
each open ticket do the following:

1) general description of the issue in the title
2) spec viewpoint (why the text in the draft says what it says)
3) list of important points of view/criticism from list of that
viewpoint
4) resolution of problem (if exists yet)

Dave and I conferred and came up with the idea was that the tracker
ticket would provide a central location for capturing the main themes of
the thread/issue.  In my mind, that included the original concept, the
comments/criticisms and the possible resolutions.  That way, if the
issue came up again one could refer the questioner to the tracker to
explain the facets of the solution.  

So that was my intent in opening up the issues.  I attempted to be
neutral in describing the motivation for the text being involved, and
reference relevant mails summarizing the issues. I hadn't opened your
gleaning issue yet because I didn't fully understand the thread and
wanted to ask you for clarifications first.  

However, if merely cutting and pasting your email into 7 tickets is what
the Sam and the WG feels is best, that's fine by me, it certainly won't
take as long to open tickets.

-Darrel

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Thursday, August 20, 2009 10:56 AM
> To: [email-masked]
> Cc: Darrel Lewis (darlewis); [email-masked]
> Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in 
> LISP UDP outer header on decapsulation
> 
> 
> Hi Darrel,
> 
> > Discussion on the list focused on whether the IPv4/IPv6 UDP 
> checksum  
> > may
> > be ignored when received as a non-zero, and what the 
> potential costs  
> > and
> > 2460  Not checking non-zero UDP checksums on inbound 
> traffic (at the  
> > ETR

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 20 Aug 2009 16:37:00 -0400

This WG can do something different, but in most WGs that use trackers, 
"spec viewpoint" is not part of the base item.  The problem statement is 
just that, the problem statement.  Discussion is then included as 
separate items, typically because the tracker picks up the discussion as 
long as the tracker number is in the subject.

One of the points of this is to avoid biasing the entry either towards 
or away from any specific resolution.  We all know that it works better 
to separate the problems from the solution.  It also helps avoid 
defensiveness on the part of the author (or of the issue raiser) if they 
know that they are not expected or even allowed, to defend themselves. 
The existing text relative to an issue may be perfect.  But the issue 
has been raised.  It needs to be discussed and resolved.

Yours,
Joel

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 20 Aug 2009 13:42:11 -0700

> has been raised.  It needs to be discussed and resolved.

Thanks Joel, and well taken.  I can definitely see my ideas of what the
tracker was tracking was out of step with the others in this thread.  

-Darrel

---

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

>>>>> "Darrel" == Darrel Lewis (darlewis) <[email-masked]> writes:
Thanks Joel, and well taken.  I can definitely see my ideas of what the
    Darrel> tracker was tracking was out of step with the others in
    Darrel> this thread.

I actually think you are more or less completely in step with what we
eventually want to get into the tracker by the time we close an issue.
I appreciate you were trying to do that.  However I think what we're
saying here is that it is far more important to get things written
down soon than to try and get a complete record in the beginning.
Also, people get upset when they perceive bias--and right now, we're
all a bit trigger happy on the issue of bias.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Sat, 22 Aug 2009 06:40:16 -0400

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

>>>>> "Darrel" == Darrel Lewis (darlewis) <[email-masked]> writes:
    Sam> Thanks Joel, and well taken.  I can definitely see my ideas
    Sam> of what the
    Darrel> tracker was tracking was out of step with the others in
    Darrel> this thread.

    Sam> I actually think you are more or less completely in step with
    Sam> what we eventually want to get into the tracker by the time
    Sam> we close an issue.  I appreciate you were trying to do that.
    Sam> However I think what we're saying here is that it is far more
    Sam> important to get things written down soon than to try and get
    Sam> a complete record in the beginning.  Also, people get upset
    Sam> when they perceive bias--and right now, we're all a bit
    Sam> trigger happy on the issue of bias.

It was pointed out to me off-list that I was misleading above.

The description of the issue should not contain more than what is
wrong in the opinion of the person raising the issue along with any
suggestions for fixing it raised by that person.  It's reasonable to
add context so others can understand what they were saying--context
from surrounding messages, or for example if putting in an issue based
on discussion at a meeting, context about what was being discussed.
This context doesn't need to include motivations, typically doesn't
need to include text from the draft beyond what the pe.person already
included.

However, by the time we close an issue it's often very desirable for the ticket as a whole to include some or all of the following:

* Pointes of view raised in the discussion 
* Explanations of what motivated the previous text in the opinion of WG participants
* The resolution of the issue

These will typically be in separate comments in the tracker, or in a
summary message prepared by the chairs.
  Hope that helps.