Subject: Re: [lisp] Suggested UDP checksum text

From: Margaret Wasserman <[email-masked]>
Date: Tue, 1 Sep 2009 09:37:26 -0400

On Aug 31, 2009, at 5:02 PM, Joel M. Halpern wrote:

> I think the wordsmithing on the UDP checksum got tangled up.
> Whenever you get to making a revision, assuming that the WG stays  
> with the intent of what you have written (which seems like a good  
> choice to me), I would suggest:
>
> UDP Checksum: this field MAY be set to 0 by an ITR on transmission.
>    Alternatively, an ITR MAY compute and store a valid UDP checksum
>    in this field during transmission.   Upon receipt, and ETR MUST
>    accept a value of 0 as valid for this field, and consider the UDP
>    packet valid.  If an ETR receives a non-zero value  in the
>    checksum, field it MAY compute and validate the UDP checksum for
>    the packet.  If it chooses to do so, it is expected to discard
>    UDP packets with invalid non-zero checksums.
> Then include the note text you already have.

I think that this rewording is a substantial improvement over the  
wording in the diffs that Dino sent.  One typo:  "checksum, field it"  
should be "checksum field, it" in the 6th line.

Personally, I think that we should (at least) encourage people to  
check the checksum when a non-zero checksum is received.  In other  
words, I would prefer to change "If an ETR receives a non-zero value  
in the checksum field, it MAY compute and validate"  to "If an ETR  
receives a non-zero value in the checksum field, it SHOULD compute and  
validate".  This would better correspond to what I thought we'd agreed  
on the list earlier, which is that an ETR may ignore a non-zero  
checksum, while still allowing systems to ignore inbound non-zero UDP  
checksums when they have a good reason for doing so.

The reference to the Eubanks-Chimento draft (which is in the note Joel  
mentions above) should be changed to a normative reference, as it  
contains normative text necessary to implement this protocol (similar  
to the UDP RFC 768 reference).

Assuming that you move the reference to the normative reference  
section, I believe that these changes would address tracker issues #9,  
#10 and #12.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 1 Sep 2009 09:42:02 -0400

On Aug 31, 2009, at 5:47 PM, Dino Farinacci wrote:
>
>
>   UDP Checksum:  this field MAY be transmitted as zero by an ITR and
>      when received by an ETR, MUST accept the packet for forwarding.

Aside from the grammatical issue with this sentence (no subject), the  
ETR does not really "accept a packet for forwarding", it decapsulates  
it and forwards the inner packet.  So, this isn't quite right, either...

>
>      When an ITR transmits a non-zero value, an ETR MAY verify the
>      checksum value.

The ETR validates a checksum when it receives it, not when the ITR  
transmits it...

>  If the checksum is verified, the packet is
>      accepted for forwarding, otherwise, it is silently dropped.   
> Note,
>      even when the UDP checksum is transmitted as zero an intervening
>      NAT device can recalculate the checksum and rewrite the UDP
>      checksum field to non-zero.  See draft [UDP-TUNNELS] for details.

Is it really necessary for us to describe the normal parts of UDP  
checksum handling here?  What about saying less?  Something like:

UDP Checksum:  This is the UDP checksum field, as described in [RFC  
768] as updated by [UDP-TUNNELS].

And leave it at that?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 1 Sep 2009 09:44:54 -0400

Hi Dino,

You and Joel are digging into the details of the R-bit here, but  
personally I don't understand why we need an R-Bit at all?

Could you please explain the purpose of the R-bit and what the  
structure of the LISP header will be when it is set?

 From what I've heard so far, it sounds like the R-bit is a one-bit  
version field, where (at least some) of the fields in the LISP header  
will have other purposes when it is set.  If so, why do we believe we  
need to use a version bit for that purpose, rather than using one the  
other extensions methods we've discussed (new UDP port or control- 
plane signaling)?

Thanks,
Margaret

On Aug 31, 2009, at 5:52 PM, Dino Farinacci wrote:

>> What is supposed to happen if an ETR receives a packet with an R  
>> bit set to 1, and the N and L bits set to some combination other  
>> than 00?
>> Is that an error?
>
> The R-bit is allowed to user the other 2 fields as long as the  
> enable-bits for each one is set to 0.
>
>> I would think it would make more sense to state that if the R bit  
>> is set, the N and L bits are considered reserved, meaning that they  
>> must be set to 0 on transmission, and ignored upon reception.
>
> Well, we *could* run with the R-bit to 1 and still do echo-noncing  
> perhaps if the N bit is used. Since we are defining a bit for the  
> future (and don't know how its going to be used -- which I don't  
> like to do generally) it's hard to say how the Research header will  
> work when the standard header is also being used.
>
>> That leaves us free to assign a meaning to the R bit, and decide  
>> when we do so how to use the other two bits.
>
> We (Luigi, Damien, Noel, Andrew, Dave, Darrel, Vince, and Dino)  
> talked about this but agreed to keep the semantics for each bit.
>
> Dino
>
>>
>> Yours,
>> Joel
>>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 1 Sep 2009 09:48:39 -0400

On Aug 31, 2009, at 8:48 PM, Joel M. Halpern wrote:

> My last reply said "then reserve it for Mobility."
> However, immediately after I sent that I realized that I at least  
> suspect that we will end up with a solution that doe snot need a bit  
> with that meaning.
>
> So, rather than trying to guess, just mark the bit as reserved (must  
> be 0 on transmission and ignored on reception.)  Then, if we decide  
> to use it for something specific later, we can.  And if we don't use  
> it for that, then it is available for some other use.

 From what I've heard so far, this seems like the best choice.  After  
we've run some experiments and have better understanding of the  
problems that we run into with locator liveness, etc. we will be in a  
better position to know how/if this sort of hint could be useful in  
practice.  If we reserve the field for now, we can use it for whatever  
makes sense when we know more.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 1 Sep 2009 10:00:09 -0400

On Aug 31, 2009, at 8:53 PM, Dino Farinacci wrote:
> How about this:
>
>   M: this bit is reserved for use by the LISP mobile-node design
>      documented in [LISP-MN].
>
> Okay?

This doesn't seem like a good choice to me, because this bit is  
completely useless if mobile nodes (ones that implement LISP-MN) are  
the only ones that know about it.  In order for this bit to be useful  
to mobile nodes, the LISP xTRs at their (non-mobile) correspondent  
sites need to recognize this bit, and act differently when it is  
present.  Since we don't know, at this point, the specifics of what  
the remove LISP nodes should do when this bit is present, I think we  
should leave the bit undefined until we do.

If we discover, in our experiments, that there are things that non- 
mobile LISP nodes should do to work well with mobile LISP nodes, we  
can add the appropriate bit(s), if any, along with the description of  
what to do when they are present, to the main LISP draft at that time.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Sep 2009 10:25:20 -0400

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:

    Margaret> Is it really necessary for us to describe the normal
    Margaret> parts of UDP checksum handling here?  What about saying
    Margaret> less?  Something like:

I think we need to at least say that for LISP data plane packets, an
ITR MAY send a 0 checksum.  I'd assume that the udp-tunnels draft will
not mandate that all tunneling protocols allow senders to send 0
checksums, but instead will create that option and allow tunnel
protocols to enable sending 0 checksums after doing the necessary
analysis (your issue #13, I believe).
So, simply referring to that draft   doesn't seem enough.

My personal preferences are

1) Joel's text with Margaret's updates  saying receivers SHOULD verify checksums
2) Joel's text with typo corrections
3) Margaret's short text above with the additional of "LISP ITRs MAY send a zero checksum"
4) Margaret's text  in the thread about closing issues #9, #10 and #12

---

From: Michael Höfling <[email-masked]>
Date: Tue, 01 Sep 2009 16:45:13 +0200

Hi Dino,

while I read the -04 diff I found one thing that sticked into my eyes.
Section 13 states that only echo-noncing is described in -04.

 > 13.  Prototype Plans and Status
[...]
 >    As of this writing the following accomplishments have been achieved:
[...]
 >    13.  An experimental implementation has been written for three
 >         locator reachability algorithms.  One is called echo-noncing,
 >         which is documented in this specification.  The other two are
 >         called TCP-counts and RLOC-probing, which will be documented
 >         in future drafts.

This is however not correct and should thus be changed to the following:

### START ###
An experimental implementation has been written for three
locator reachability algorithms.  Both the so-called echo-noncing and 
the so-called RLOC-probing are documented in this specification. The 
third one is called TCP-counts, which will be documented in future drafts.
### STOP ###

Regards,
Michael

-- 
Michael Hoefling, M.S.
University of Wuerzburg, Institute of Computer Science
Department of Distributed Systems (Informatik III)
Am Hubland, D-97074 Wuerzburg, Germany, room A202
phone: (+49)-931/31-86634
mailto:[email-masked]

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 1 Sep 2009 10:58:22 -0400

On Sep 1, 2009, at 10:25 AM, Sam Hartman wrote:

> ITR MAY send a 0 checksum.

Good point.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 1 Sep 2009 08:34:41 -0700

> locator reachability algorithms.  Both the so-called echo-noncing  
> and the so-called RLOC-probing are documented in this specification.  
> The third one is called TCP-counts, which will be documented in  
> future drafts.
> ### STOP ###

Thanks Michael. I will make the change.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 1 Sep 2009 08:40:20 -0700

> 4) Margaret's text  in the thread about closing issues #9, #10 and #12

How about Joel and Margaret get together and write the text and I will  
include it. Provided it is detailed and accurate enough. Joel's text  
was not specific enough to implement from.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 1 Sep 2009 08:41:00 -0700

> The reference to the Eubanks-Chimento draft (which is in the note  
> Joel mentions above) should be changed to a normative reference, as  
> it contains normative text necessary to implement this protocol  
> (similar to the UDP RFC 768 reference).

Consider it done.

Dino

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Sep 2009 11:52:36 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    >> Dino, the following entries reference comments I can't seem to
    >> find on the list.  Can you point me to the list discussion
    >> involved?

    Dino> There isn't any because the commenters choose to not use the
    Dino> list. 

OK, it definitely seems reasonable to me for people to suggest changes
to fix obvious bugs with basically one solution to you privately and
for you to go forward like you've done here.  Some of these additional
changes depend on changes in your first message I'm still reviewing.
However, unless we have some concerns about dependent changes, all of
these look fine.

    Dino> The diff file should be able to explain why the
    Dino> changes were made.

Not really; it does a much better job of explaining what changes were
made rather than why.  The level of detail you provided in your second
message is about right for changes based on private comments.

Thanks for the great work,

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Sep 2009 12:09:52 -0400

>> 1) Joel's text with Margaret's updates saying receivers SHOULD
    >> verify checksums 2) Joel's text with typo corrections 3)
    >> Margaret's short text above with the additional of "LISP ITRs
    >> MAY send a zero checksum" 4) Margaret's text in the thread
    >> about closing issues #9, #10 and #12

    Dino> How about Joel and Margaret get together and write the text
    Dino> and I will include it. Provided it is detailed and accurate
    Dino> enough. Joel's text was not specific enough to implement
    Dino> from.

I'm happy with this provided that it's consistent with this discussion
and no one objects to it.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Sep 2009 19:45:49 -0400

Dino, the following issues   require positive WG consensus to make changes.
That is, we need to see on the WG LISP that people have  reviewed, understood and agreed with the change.
(We also need to deal with any objections).

In general, each of these issues or each group of issue should have
been addressed in a separate message to the WG describing the issue,
the specific text change and most importantly the reasoning for the
change.  Including issues this large batched together with other
changes ultimately reduces the review that changes get, and by the
time where all going to be done, will end up creating more work for
the editors and chairs than if they had been called out separately.

I want to stress that I'm not complaining about your actions or those
of any of the other editors; we're all still learning to work
together.  The fact that we don't have the process entirely ironed out
for major changes should not be considered a mark against anyone: it
really does take some time to get going.

In general it would be best to use the issue tracker, and using the
issue tracker is required when proposing text to address an issue that
is already open there.

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:
* How do deal with record count greater than 1 for a Map-Request.

This was discussed on the list.  You proposed a solution different
than the one that Joel agreed to in your revised text.  However, as
far as I can see, you did not follow up with Joel as required by our
issue policy.  I've opened an issue for this in the tracker. (As an additional note, I don't think your proposal actually works.)

    Dino> * Add the mobility bit to Map-Replies. So PTRs don't probe
    Dino> so often for MNs but often enough to get mapping updates.

There are process and consensus problems with this.  Opened in the issue tracker.

    Dino> * Margaret's comment on gleaning:

I didn't see discussion of the text on the list; follow up required for issue #8.

    Dino> * Add section on RLOC-probing per working group feedback.

This should have been called out to the list,  and the chairs should have issued a consensus call.
I'm issuing the consensus call now.
Based on discussion in Stockholm I think we'll end up being fine here.

    Dino> * Remove SMR-bit from data-plane. Dino prefers to have it in
    Dino> the control plane only.

This definitely needs to be discussed on the list.  While I believe
this was mentioned in passing in the Stockholm meeting and may have
even come out of that meeting, there was no sense of the room.  So, we
cannot make this change until we actually get people to review and
evaluate the proposal.

    Dino> * Change LISP header to allow a "Research Bit" so the Nonce
    Dino> and LSB fields can be turned off and used for another future
    Dino> purpose. For Luigi et al versioning convergence.
    Dino> * Add a N-bit to the data header suggested by Noel. Then the
    Dino> nonce field could be used when N is not 1.

This definitely should have been proposed on the list, not just put
forward in the proposed text.  We seem to be moving forward on this,
and may converge in a few days.  I'll try to make an explicit
consensus call shortly.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Sep 2009 19:55:07 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

For the changes listed below, it's fine to submit, or to wait until we
get closer on some of the open issues.

Note that the issue tracking policy we agreed to requires there to be
a change log section in the draft, not just in mail to the list.  I
don't see that in 04; that will need to be added before it is
submitted.

The level of detail for the changes below is fine.

    Dino> * Add Fred Templin in ack section.

I certainly don't object to you calling this out in the changelog, but you need not do so.
    Dino> * Say more about LAGs in the UDP section per Sam Hartman's
    Dino> comment.

According to the issue tracking policy, you should have followed up with me.
However I've reviewed the text and it is fine; thanks.

    Dino> * Sam wants to use MAY instead of SHOULD for ignoring
    Dino> checkums on ETR.  From the mailing list:

    Dino>   You'd need to word it as an ITR MAY send a zero checksum,
    Dino> an ETR MUST accept a 0 checksum and MAY ignore the checksum
    Dino> completely.  And of course we'd need to confirm that can
    Dino> actually be implemented.  In particular, hardware that
    Dino> verifies UDP checksums on receive needs to be checked to
    Dino> make sure it permits 0 checksums.

    Dino> * Margaret wants a reference to
    Dino> http://www.ietf.org/id/draft-eubanks- chimento-6man-00.txt.

I think we're still waiting for Joel and Margaret to give us final wording on the UDP checksum text.
Feel free to include what is in 04: it is clearly closer to WG consensus than 03.

    Dino> * Fix description in Map-Request section. Where we describe
    Dino> Map-Reply Record, change "R-bit" to "M-bit".

This may be small enough that it doesn't need to be called out.

    Dino> * Indicate SHA1 can be used as well for Map-Registers.

Note that the text is still broken.  The IPsec sha-1  is 96-bits long not 128-bits long.
Also, according to some software I'm using but not verified with the spec, 0 is an illegal SPI.
However this change is small and is supported by WG discussion.

    Dino> * More Fred comments on MTU handling.

    Dino> * Isidor comment about specing better periodic
    Dino> Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt.

    Dino> * Change "loc-reach-bits" to "loc-status-bits" per comment
    Dino> from Noel.

    Dino> * Clarify that when E-bit is 0, the nonce field can be an
    Dino> echoed nonce or a random nonce. Comment from Jesper.

    Dino> * Indicate when doing data-gleaning that a verifying
    Dino> Map-Request is sent to the source-EID of the gleaned data
    Dino> packet so we can avoid map- cache corruption by a 3rd
    Dino> party. Comment from Pedro.

Fine if the gleaning text in general is OK.

    Dino> * Indicate that a verifying Map-Request, for accepting
    Dino> mapping data, should be sent over the the ALT (or to the
    Dino> EID).

    Dino> * Reference IPsec RFC 4302. Comment from Sam and Brian Weis.

Note this probably has bigger implications than you expect; it moves
you from 2401 to 4301 for the base architecture and that has huge
implications.

    Dino> * Put E-bit in Map-Reply to tell ITRs that the ETR supports
    Dino> echo- noncing.  Comment by Pedro and Dino.

This might have needed an explicit wg list message, but I'm going to
let it slide: it's a really obviously useful idea.

    Dino> * Jesper made a comment to loosen the language about
    Dino> requiring the copy of inner TTL to outer TTL since the text
    Dino> to get mixed-AF traceroute to work would violate the "MUST"
    Dino> clause. Changed from MUST to SHOULD in section 5.3.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 7 Sep 2009 17:02:38 -0700

> (We also need to deal with any objections).

That is what the review period is for, no?

> the editors and chairs than if they had been called out separately.

We tried to aggregate to be a bit more efficient.

> really does take some time to get going.

No offense taken.

> issue tracker is required when proposing text to address an issue that

That creates more work for us and more overhead. We want to  
concentrate on the technology and experiments and not the process.

> issue policy.  I've opened an issue for this in the tracker. (As an  
> additional note, I don't think your proposal actually works.)

Revision 1 of this text was given to me by Joel. I inserted it. Then  
Vince word-smithed the text which I added in a revision 2. I have  
contacted Joel to see what he wants to do. I am neutral.

> There are process and consensus problems with this.  Opened in the  

I thought we resolved by not stating how to use the bit but keep its  
allocation in the spec. The current diff file reflects this.

> Based on discussion in Stockholm I think we'll end up being fine here.

Margaret said it needed to be more clear. So I added a paragraph to  
the diff file. I sent the diff file to the list so people can comment.  
What makes that different than "discussing it on the list"?

> cannot make this change until we actually get people to review and

We have discussed this to death on the list. What more do you expect  
to be discussed?

> and may converge in a few days.  I'll try to make an explicit

Same comment. We got Luigi to agree to use the N and L bits set to 0.  
He even commented about this during vacation. What more do you want to  
discuss?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 7 Sep 2009 17:15:25 -0700

I am responding to the technical issues of this email.

> Feel free to include what is in 04: it is clearly closer to WG  

We already got wording. I tried to capture everyone's comments while  
still making the text clear and accurate for implemetnation.

> However this change is small and is supported by WG discussion.

There is no reference to SHA-1 being 128 bits. Or do you mean the  
reference to SHA-128 should be changed to SHA-256.

> you from 2401 to 4301 for the base architecture and that has huge

We do not say we use IPsec in the document. We say we use the IPsec  
header format (i.e. AH).

> let it slide: it's a really obviously useful idea.

Thanks.

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 9 Sep 2009 20:52:37 -0400

Hi Dino,

On Sep 1, 2009, at 11:40 AM, Dino Farinacci wrote:

>> verify checksums
> How about Joel and Margaret get together and write the text and I  
> will include it. Provided it is detailed and accurate enough. Joel's  
> text was not specific enough to implement from.

Joel and I came up with the following text:

UDP Checksum: An ITR MAY set this field to 0 in both IPv4 and IPv6
              outer headers [RFC 768, UDP-TUNNEL].  If the ITR does
              not set this field to 0, it MUST be set to a valid UDP
              checksum value.  Upon receipt, an ETR MUST accept IPv4
              and IPv6 packets with an outer header UDP checksum of 0,
              and process them normally.  If an ETR receives a packet
              with a non-zero value in the UDP checksum field, it MAY
              choose to ignore the UDP checksum value, and treat the
              packet as if it had a 0 checksum.  If it an ETR does  
compute the
              received UDP checksum, it SHOULD discard packets with  
invalid
              non-zero UDP checksums.

If anyone has concerns about this text, please let us know.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 9 Sep 2009 21:49:38 -0700

Well I thought what we had was pretty good. I will include it below so  
others can compare. But see my specific comments below.

>             outer headers [RFC 768, UDP-TUNNEL].  If the ITR does

First off, this first sentence is misleading. It makes one think the  
UDP checksum is in the IPv4 and IPv6 header or leads one to believe  
the checksum in the IPv4 header is part of this description.

It also makes me think there are two headers by the reference to  
"outer headers". Talking about IPv4 and IPv6 in parallel leads to the  
confusion.

>             checksum value.  Upon receipt, an ETR MUST accept IPv4

What is a valid UDP checksum. I didn't like that in previous text that  
was proposed. The checksum is a computation that is performed. That is  
what is placed in this field. The receiver computes a checksum to  
compare against this one to determine if the checksum in the packet is  
valid.

>             and process them normally.  If an ETR receives a packet

"process them normally" IMO is not specific enough. Unless you want to  
define what abnormal processing is. ;-)

>             packet as if it had a 0 checksum.  If it an ETR does  

"If it an ETR" doesn't parse well so the text as is needs improvement.

> If anyone has concerns about this text, please let us know.

Compare it to what is in the latest diff (with Marhsall's two  
editorial changes):

    UDP Checksum:  this field MAY be transmitted as zero by an ITR and
       when received by an ETR, it MUST accept the packet for
       decapsulation.  When an ITR transmits a non-zero value, an ETR  
MAY
       verify the checksum value.  If the checksum is verified, the
       packet is accepted for decapsulation; otherwise, it is silently
       dropped.  Note, even when the UDP checksum is transmitted as zero
       an intervening NAT device can recalculate the checksum and  
rewrite
       the UDP checksum field to non-zero.  See draft [UDP-TUNNELS] for
       details.

And let me annotate why the text is better and sufficient on a  
sentence by sentence basis:

>       when received by an ETR, it MUST accept the packet for
>       decapsulation.

The first sentence indicates the zero checksum case. Tells you who  
puts it in and the level of conformance that should be placed on it.  
Then it says what the receiver should do and the level of conformance  
that should occur.

>       When an ITR transmits a non-zero value, an ETR MAY
>       verify the checksum value.  If the checksum is verified, the

Then the next sentence indicates what to do for non-zero values.

>       packet is accepted for decapsulation; otherwise, it is silently
>       dropped.  Note, even when the UDP checksum is transmitted as  
> zero

The third sentence indicates what happens when the checksum is good  
and when it is bad, for non-zero values.

>       an intervening NAT device can recalculate the checksum and  
> rewrite
>       the UDP checksum field to non-zero.  See draft [UDP-TUNNELS] for
>       details.

And the final sentence talks about the NAT corner case.

I think we can't do better than this current text. I move to keep it  
the way it is.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Sep 2009 08:54:06 -0400

I am willing to work from this text (sorry, I had lost track of it.  You 
had sent it to the list.)
However, to claim "We can't do better" is not appropriate.  There are 
multiple hanging pronouns and unspecified antecedents which are actually 
confusing.

Dino Farinacci wrote:
...
>       decapsulation.  When an ITR transmits a non-zero value, an ETR MAY
>       an intervening NAT device can recalculate the checksum and rewrite
...
> I think we can't do better than this current text. I move to keep it the 
> way it is.
> 
> Dino

Using that as a base:

UDP Checksum: this field MAY be transmitted as zero by an ITR.
     When a packet with a zero UDP checksum is received by an ETR,
     the ITR MUST accept the packet for decapsulation.  When an ITR
     transmits a non-zero value for the UDP Checksum, it MUST send a
     correctly computed value in this field.  When an ETR receives a
     packet with a non-zero checksum, it MAY choose to verify the
     checksum value.  If it chooses to perform such verification, and
     the verification fails, the packet MUST be silently dropped.
     If the ETR chooses not to perform the verification, or performs
     the verification successfully, the packet MUST be accepted for
     decapsulation.  Note, even when the UDP checksum is transmitted
     as zero, an intervening NAT device can recalculate the checksum
     and rewrite the UDP checksum field to non-zero.  See draft
     [UDP-TUNNELS] for details.

Feel free to wordsmith further if needed.
Joel

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Sep 2009 10:19:41 -0400

On Sep 10, 2009, at 12:49 AM, Dino Farinacci wrote:

> Well I thought what we had was pretty good. I will include it below  
> so others can compare. But see my specific comments below.
>

Can you suggest rewording that would still make it clear that this  
applies to both IPv4 and IPv6 encapsulations?  Perhaps "An ITR may set  
this field to 0 in both IPv4 and IPv6 encapsulations to indicate that  
a UDP checksum has not been calculated [RFC 768, UDP-TUNNEL]."  ?
> "outer headers". Talking about IPv4 and IPv6 in parallel leads to  
> the confusion.
>
> What is a valid UDP checksum. I didn't like that in previous text  
> that was proposed. The checksum is a computation that is performed.  
> That is what is placed in this field. The receiver computes a  
> checksum to compare against this one to determine if the checksum in  
> the packet is valid.

s/valid/correctly calculated?
> "process them normally" IMO is not specific enough. Unless you want  
> to define what abnormal processing is. ;-)

:-).

We could change this to "should accept the packet for decapsulation",  
if you find that clearer.
> "If it an ETR" doesn't parse well so the text as is needs improvement.

s/If it an/If an
>      verify the checksum value.

The "it" in your first sentence is awkward.  I understand that you are  
referring to the ETR, but on initial parsing it seems to refer to the  
UDP checksum field, as that is subject of the previous clause.

More importantly, you are saying that an ETR "MAY verify", which is  
different from what I think the WG had agreed upon, which is that an  
ETR MAY ignore non-zero checksums.  If we state it as "MAY ignore",  
then we aren't forced to state a requirement level (MAY or SHOULD) for  
verifying them.  If you do want to phrase it this way, then I think we  
should say that "an ETR SHOULD verify the checksum value."

> If the checksum is verified, the
> Then it says what the receiver should do and the level of  
> conformance that should occur.

The first sentence does not reference UDP-TUNNEL, and does make it  
clear that you can use a zero checksum in IPv6, so I consider this to  
be ambiguous for the IPv6 case.
> Also, you say "may verify" the checksum, using verify as the process  
> of checking, then you say "verified", indicating that the checksum  
> was correct, but I think that "verified" in this context is at least  
> as vague as "valid".  You could say "If the checksum is correct" or  
> "If the checksum verification process indicates that the packet has  
> not been corrupted..." if you want to go all the way.

As indicated above, I don't think this matches what we had agreed to  
say.

Also, you say "may verify" the checksum, using verify as the process  
of checking, then you say "verified", indicating that the checksum was  
correct, but I think that "verified" in this case is more vague than  
"valid".  You could say "If the checksum is correct" or, if you want  
to go all the way, you could replace "verify" with "calculate a UDP  
checksum for the packet as described in [RFC 768] and [RFC 2460]" and  
say "if the checksum in the packet matches the calculated UDP  
checksum".  But, I think we're going kind of crazy a that point,  
because we're essentially re-writing what it means to check a checksum.
> And the final sentence talks about the NAT corner case.

I don't like the idea of including the NAT case here.  For one thing,  
this could be interepretted as _allowing_ NATs to do this.  If we want  
to mention the "NAT corner case" as you put it, we should do so in a  
separate paragraph, and we should make it clear that recalculating the  
UDP checksum in forwarded packets is a _bug_ in these NATs, as it  
gives the
assurance of end-to-end integrity protection when that has not been  
provided.
> I think we can't do better than this current text. I move to keep it  

I was responding to a message where you asked me and Joel to provide  
UDP checksum text for the document.  So, I guess I move that we use  
the text that you asked me and Joel to provide.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Sep 2009 10:25:15 -0400

> Feel free to wordsmith further if needed.

This is well-written, and what is says is close to good enough, I  
think.  I have only three issues:

(1) It should make it clear that we are allowing 0 UDP checksums in  
IPv6, as well as IPv4.  Perhaps by adding "in both the IPv4 and IPv6  
encapsulations." to the first sentence?

(2) IMO, it should cite UDP-TUNNELS where it says that we can sent 0  
checksums in IPv6.  It should also cite RFC 768 (the UDP RFC), I think.

(3) I would prefer that the NAT text move to a different paragraph,  
and that we make it clear that this is a situation that may be  
encountered during operations, not an allowed behavior.

Margaret

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 10 Sep 2009 14:54:58 -0400

>      when received by an ETR, it MUST accept the packet for

s/it/the ETR/

(which "it" is meant might confuse some).

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 10 Sep 2009 20:12:06 -0400

I agree with Margaret about referencing both RFC 768 and the draft  
when zero checksums first appear.

> On Sep 10, 2009, at 8:54 AM, Joel M. Halpern wrote:

How about

>> UDP Checksum: this field MAY be transmitted as zero by an ITR.

s/ITR/ITR in either IPv4 or IPv6 [RFC 768, UDP-TUNNEL]/

I would suggest this change in Dino's variant of this text as well,  
for the same reason.

Marshall

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 10 Sep 2009 23:19:30 -0700

>    the ITR MUST accept the packet for decapsulation.  When an ITR

ITRs don't decapsulate.

> Feel free to wordsmith further if needed.

Okay, so here is what I have to capture Margaret and Marshall's  
comments:

    UDP Checksum:  this field MAY be transmitted as zero by an ITR for
       either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].   
When a
       packet with a zero UDP checksum is received by an ETR, the ETR
       MUST accept the packet for decapsulation.  When an ITR  
transmits a
       non-zero value for the UDP checksum, it MUST send a correctly
       computed value in this field.  When an ETR receives a packet with
       a non-zero UDP checksum, it MAY choose to verify the checksum
       value.  If it chooses to perform such verification, and the
       verification fails, the packet MUST be silently dropped.  If the
       ETR chooses not to perform the verification, or performs the
       verification successfully, the packet MUST be accepted for
       decapsulation.

       Note, even when the UDP checksum is transmitted as zero, an
       intervening NAT device can recalculate the checksum and rewrite
       the UDP checksum field to non-zero.

Thanks all,
Dino

---

From: Sam Hartman <[email-masked]>
Date: Fri, 11 Sep 2009 09:06:15 -0400

>> 
    >> Note that the text is still broken.  The IPsec sha-1 is 96-bits
    >> long not 128-bits long.  Also, according to some software I'm
    >> using but not verified with the spec, 0 is an illegal SPI.

    Dino> There is no reference to SHA-1 being 128 bits. Or do you
    Dino> mean the reference to SHA-128 should be changed to SHA-256.

You claim that the value in the AH header  for the ICV (in RFC 4302 terms) is 16 bytes long.
AS far as I can tell reading 4302 and 2404 it's 96 bits long.

    Dino> We do not say we use IPsec in the document. We say we use
    Dino> the IPsec header format (i.e. AH).

That's not going to work.  You either need to use IPsec or not; you
cannot borrow IPsec headers and codepoints without actually using
IPsec.  There are significant process problems with this: this is the
sort of issue that created the T-MPLS mess between the ITU and IETF.
More importantly though, it means I cannot use LISP and IPsec on the
same system or they stop on each other.

---

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

Hi Dino,

>      the UDP checksum field to non-zero.

The first paragraph is fine.

I'd prefer to drop the second paragraph, as it isn't really possible  
for us to catalog every buggy implementation that might have bad  
implications for LISP.  If the IETF does want to publish this  
operational information, I think this would be better discussed in a  
middle-box operations document where its implications could be  
discussed more broadly.

If people insist on keeping this paragraph, though, I'd prefer:

Note, there are some currently deployed, improperly implemented IPv4  
NAT boxes that will recalculate a zero UDP checksum and overwrite it  
with a correct UDP checksum value.  LISP implementors and operators  
may wish to consider the existence of this equipment in their  
implementation and deployment decisions regarding UDP checksums.

This would make it clear that we are pointing out something about  
existing operational networks, and that we are neither condoning nor  
advocating NAT boxes that behave this way.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 11 Sep 2009 09:15:28 -0700

> IPsec.  There are significant process problems with this: this is the

So what does this mean specifically?

If the spec says Map-Registers use the AH header format from the IPsec  
spec what does "using IPsec" mean from your point of view?

> same system or they stop on each other.

Why does it mean that. You have to explain more Sam.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 11 Sep 2009 09:58:52 -0700

> middle-box operations document where its implications could be  

Well you mentioned in a previous email that if we were going to keep  
it to make it a separate paragraph.

I wanted to keep it because it gives another justification why ETRs  
MAY ignore the UDP checksum.

> NAT boxes that will recalculate a

Well I don't think it is necessarily improper. If NATs are changing IP  
addresses in UDP headers they have to change the UDP checksum to  
reflect the address change.

I'd rather not put in text that judges this.

> zero UDP checksum and overwrite it with a correct UDP checksum  
> value.  LISP implementors and operators may wish to consider the  
> existence of this equipment in their implementation and deployment  
> decisions regarding UDP checksums.
>

I believe the existing paragraph conveys this too.

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 11 Sep 2009 13:09:58 -0400

On Sep 11, 2009, at 12:58 PM, Dino Farinacci wrote:
>>
>> Note, there are some currently deployed, improperly implemented  
>> IPv4 NAT boxes that will recalculate a
>
> Well I don't think it is necessarily improper. If NATs are changing  
> IP addresses in UDP headers they have to change the UDP checksum to  

No, they don't.  They should incrementally update the checksum, so it  
remains an end-to-end integrity protection mechanism.  If they write a  
correct checksum over a zero value, they are giving the illusion that  
the packet was end-to-end protected when it was not, which might be  
problematic for some applications.  Even worse, if they re-write non- 
zero values with new, correct values, they could be incorrectly  
asserting that the packet has not been corrupted when it already was.
>> existing operational networks, and that we are neither condoning  
>> nor advocating NAT boxes that behave this way.
>

The existing paragraph says that NATs _may_ do this, as though it is  
okay (in the LISP universe) for them to do so, which is not something  
that I think we should.  At the very least, you should change the  
sentence to say that they _some currently deployed IPv4 NATs do_ this  
(not that they may do it), so that it is clear we are talking about an  
operational issue with currently deployed hardware.

The existing paragraph also doesn't make it clear that the NATs  
overwrite the checksum with a correct UDP checksum value for the  
packet they are transmitting, which lead to a lot of confusion in the  
LISP WG earlier.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 11 Sep 2009 10:29:57 -0700

> No, they don't.  They should incrementally update the checksum, so  
> it remains an end-to-end integrity protection mechanism.  If they  
> write a correct checksum over a zero value, they are giving the  
> illusion that the packet was end-to-end protected when it was not,  
> which might be problematic for some applications.  Even worse, if  
> they re-write non-zero values with new, correct values, they could  
> be incorrectly asserting that the packet has not been corrupted when  
> it already was.

We all know NATs are evil. And we shouldn't create any more NAT  
solutions.   ;-)

> okay (in the LISP universe) for them to do so, which is not  
> something that I think we should.  At the very least, you should  
> change the sentence to say that they _some currently deployed IPv4  
> NATs do_ this (not that they may do it), so that it is clear we are  
> talking about an operational issue with currently deployed hardware.
>
> packet they are transmitting, which lead to a lot of confusion in  
> the LISP WG earlier.

Rather than saying more about this. I will remove the paragraph. The  
discussion it too complicated to me and the text doesn't add enough  
value. If the first parapgraph is conformed to, then we can deal with  
NATs.

Dino

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 11 Sep 2009 13:34:27 -0400

> talking about an operational issue with currently deployed hardware.

First, could this paragraph go in the Security Section, which would  
make it clearer that its not something we want people to do ?

Second, how about this tweak for the paragraph in the security section :

       Implementors should be aware that even when the UDP checksum is  
transmitted as zero,
       it is possible that intervening devices (such as NATs)  
recalculate the outer UDP checksum and rewrite
       that checksum field to non-zero. Integrity of the encapsulated  
data is provided by the UDP checksum
       in the inner packet [UDP-TUNNELS].

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 11 Sep 2009 13:35:24 -0400

On Sep 11, 2009, at 1:29 PM, Dino Farinacci wrote:

>>> Well I don't think it is necessarily improper. If NATs are  
>>> changing IP addresses in UDP headers they have to change the UDP  
>>> checksum to reflect the address change.
>>
>> be incorrectly asserting that the packet has not been corrupted  
>> when it already was.
>
>>>> existence of this equipment in their implementation and  
>>>> deployment decisions regarding UDP checksums.
>>>>
>> The existing paragraph says that NATs _may_ do this, as though it  
>> is okay (in the LISP universe) for them to do so, which is not  

Despite the message I just sent, this WFM.

Marshall

> value. If the first parapgraph is conformed to, then we can deal  
> with NATs.
>
> Dino
>
>

---

From: Sam Hartman <[email-masked]>
Date: Fri, 11 Sep 2009 15:34:46 -0400

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

Dino, I've reviewed the issues I said we do not have consensus on and
I think we now have enough discussion to call consensus on several.

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:
    Sam> * How do deal with record count greater than 1 for a
    Sam> Map-Request.

We have converged on the original text in Dino's proposal.

    Sam> I didn't see discussion of the text on the list; follow up
    Sam> required for issue #8.

I believe this has been discussed enough that including the current text is a clear step forward.
I'm not sure whether we're entirely done and am a bit behind on the discussion.

We're good here as well.

    Dino> * Change LISP header to allow a "Research Bit" so the Nonce
    Dino> and LSB fields can be turned off and used for another future
    Dino> purpose. For Luigi et al versioning convergence.  * Add a
    Dino> N-bit to the data header suggested by Noel. Then the nonce
    Dino> field could be used when N is not 1.

I think we're good here as well.  I need to write up a resolution to
#16 and friends, but I believe the text in Dino's current diff is
something we've all said we can live with.

---

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

Here are the latest diffs as of 5 minutes ago.

Dino

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 11 Sep 2009 12:44:19 -0700

Hello Dino,

> So what does this mean specifically?

It means that IPsec is a whole, it defines an access control model as well as on-the-wire protocol syntax that support realization of the access control model. The access control features of IPsec are a central part to IPsec and requires an IPsec implementation to process AH (and ESP) as specified by the IPsec architecture document (RFC 4301), because that's how the IPsec access control features are enforced. If it does something different, the IPsec access control model is not respected.

IOW you can't have it "a la carte" and use the on-the-wire protocol without the rest of it without compromising the access control feature of IPsec.

So either AH is _always_ processed as per 4301 and you have an IPsec implementation, or it is not and you can't have an IPsec implementation on that node. Which is what Sam points out below when he says "it means I cannot use LISP and IPsec on the same system or they stop on each other."
 
Suppose the node uses IPsec as per RFC 4301 to protect some communications, and the AH format to protect some LISP communications. How is the node supposed to process incoming AH packets, per 4301/IPsec or per LISP? 

> Why does it mean that. You have to explain more Sam.

Hopefully I've answered that above.

--julien