Subject: [lisp] Deadline for proposed changes to draft-ietf-lisp-04.txt is Friday Sep 4th

From: Dino Farinacci <[email-masked]>
Date: Mon, 31 Aug 2009 11:01:33 -0700

Just a friendly reminder that the proposed changes to draft-ietf- 
lisp-04.txt is this Friday September 4th.

Thank you to all who have sent us comments last week. For those of you  
who have not reviewed the diffs yet, you can look at the updated html  
diff file enclosed.

The change-log of the proposed changes is also enclosed. Please note  
there are 6 additional change-log entries at the end reflecting  
comments we received last week.

Thanks a lot,
Dino/Dave/Darrel/Vince

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

Changes planned for draft-ietf-lisp-04.txt:

* How do deal with record count greater than 1 for a Map-Request.  
Damien and
   Joel comment. Joel suggests:

     1) Specify that senders compliant with the current document will
     always set the count to 1, and note that the count is included for
     future extensibility.

     2) Specify what a receiver compliant with the draft should do if it
     receives a request with a count greater than 1. Presumably, it  
should
     send some error back?

* Add Fred Templin in ack section.

* Add Margaret and Sam to the ack section for their great comments.

* Say more about LAGs in the UDP section per Sam Hartman's comment.

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

   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.  And of
   course we'd need to confirm that can actually be implemented.  In
   particular, hardware that verifies UDP checksums on receive needs to
   be checked to make sure it permits 0 checksums.

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

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

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

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

* More Fred comments on MTU handling.

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

* Margaret's comment on gleaning:

     The current specification does not make it clear how long gleaned  
map
     entries should be retained in the cache, nor does it make it clear
     how/ when they will be validated.  The LISP spec should, at the  
very
     least,  include a (short) default lifetime for gleaned entries,
     require that  they be validated within a short period of time, and
     state that a new  gleaned entry should never overwrite an entry  
that
     was obtained from  the mapping system.   The security  
implications of
     storing "gleaned"  entries should also be explored in detail.

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

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

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

* Change LISP header to allow a "Research Bit" so the Nonce and LSB  
fields
   can be turned off and used for another future purpose. For Luigi et  
al
   versioning convergence.

* Add a N-bit to the data header suggested by Noel. Then the nonce  
field could
   be used when N is not 1.

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

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

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

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

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

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

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 31 Aug 2009 14:19:37 -0400

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

[I see my comment but not Brian's]

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 31 Aug 2009 11:35:29 -0700

> the list.  Can you point me to the list discussion involved?

There isn't any because the commenters choose to not use the list. The  
diff file should be able to explain why the changes were made.

If people want to bring the changes up on the list, they should. This  
review period is to review the changes proposed and not the document  
per say.

But I will reply to each item below to make things more clear.

>  a random nonce. Comment from Jesper.

There are two uses for the nonce when the E-bit is 0. The first  
version of the proposed text only referred to using the nonce when it  
was being echoed as part of the Echo-Noncing locator reachability  
algorithm.

But Echo-Noncing is not used, the nonce value is a random 24-bit  
number chosen by the encapsulator.

>  corruption by a 3rd party. Comment from Pedro.

So a cache corruption problem can occur (as specified in the diff  
file) when a third-party uses its on address (which would pass uRPF on  
the path from itself to the guy it wants to attack) to a decapsulator  
that will send a verifying Map-Request to the outer source of the LISP  
encapsulated packet (the third party) which in turn can return a bogus  
Map-Reply which the decapsultor would cache.

The verifying Map-Request needs to go to the authoritative ETRs for  
the site and sending the verifying Map-Request to an EID will cause it  
to go over the mapping database system which is secure.

>  sent over the the ALT (or to the EID).

Same as above but for the piggyback mapping data in Map-Request packets.

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

You and a private email from Brian asked for the change.

>  Comment by Pedro and Dino.

Previously enabling Echo-Noncing is an all-or-nothing deal. So this  
let's us incrementally deploy it so you know what ETRs can echo your  
nonce by looking at the E-bit in the Map-Reply. A really good idea by  
Pedro.

>  violate the "MUST" clause. Changed from MUST to SHOULD in section

There is nothing more to say about this then what is said above.

Are you okay with this now Sam?

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 17:02:15 -0400

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.

Does that make sense?  Saying "When an ITR transmits...an ETR may 
compute is confusing.  It is particularly confusing since the note 
indicates that the ETR can not tell whether the ITR or someone else 
filled in the checksum field with a non-zero value.

Yours,
Joel

Dino Farinacci wrote:
> Just a friendly reminder that the proposed changes to 
> draft-ietf-lisp-04.txt is this Friday September 4th.
> 
> there are 6 additional change-log entries at the end reflecting comments 
> we received last week.
> 
> Thanks a lot,
> Dino/Dave/Darrel/Vince
> 
> * How do deal with record count greater than 1 for a Map-Request. Damien 
> and
>     receives a request with a count greater than 1. Presumably, it should
>     send some error back?
> 
> * Sam wants to use MAY instead of SHOULD for ignoring checkums on ETR. From
>   the mailing list:
> 
> * Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs
> * Isidor comment about specing better periodic Map-Registers. Will be fixed
>     The current specification does not make it clear how long gleaned map
>     how/ when they will be validated.  The LISP spec should, at the very
>     state that a new  gleaned entry should never overwrite an entry that
>     was obtained from  the mapping system.   The security implications of
> * Change LISP header to allow a "Research Bit" so the Nonce and LSB fields
>   can be turned off and used for another future purpose. For Luigi et al
>   versioning convergence.
> 
> * Add a N-bit to the data header suggested by Noel. Then the nonce field 
> could
>   be used when N is not 1.
> 
> * Clarify that when E-bit is 0, the nonce field can be an echoed nonce or
>   to the source-EID of the gleaned data packet so we can avoid map-cache
> * Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-noncing.
> * Jesper made a comment to loosen the language about requiring the copy of
>   violate the "MUST" clause. Changed from MUST to SHOULD in section 5.3.
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 17:04:58 -0400

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?

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

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 17:22:57 -0400

In the map reply, I am not sure I follow the reasoning for the "M" bit. 
  At a guess, it is intended for mobility cases.
As far as I can tell, it does not help.  If the sender of the mapping 
data wants the receiver to validate the data frequently, then the sender 
should use a short ttl.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 31 Aug 2009 14:47:35 -0700

>    UDP packets with invalid non-zero checksums.

There are a couple of problems with your text:

(1) Valid does provide any value to the description, we should say  
accept and continue processing the packet or say "do not drop it".

(2) If an ETR does choose to compute the checksum to validate it and  
it fails the checksum check, it must drop the packet.

How about this text:

    UDP Checksum:  this field MAY be transmitted as zero by an ITR and
       when received by an ETR, MUST accept the packet for forwarding.
       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 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.

Sound better and more specific?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 31 Aug 2009 14:52:36 -0700

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

> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 17:59:49 -0400

If setting the N or L bits is really illegal with the R bit, then 
shouldn't something talk about what error to generate upon reception?

The other alternative is to simply treat the R bit itself as reserved, 
and stop talking about the interaction with the N and L bits until we 
define a use for the R bit.  After all, if an ETR which doesn't know 
what the R bit is being used for receives a packet with it set, the only 
choices are to either ignore the setting or error the packet.

Yours,
Joel

Dino Farinacci wrote:
> The R-bit is allowed to user the other 2 fields as long as the 
> enable-bits for each one is set to 0.
> 
>> set, the N and L bits are considered reserved, meaning that they must 
>> be set to 0 on transmission, and ignored upon reception.
> 
> 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.
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 31 Aug 2009 15:12:36 -0700

> shouldn't something talk about what error to generate upon reception?

It's a question of which bit has preference over the other. The R-bit  
set is suppose to mean that the other fields can be used only when the  
N-bit is 0 and the L-bit is 0. But if either is set, the R-bit can  
define the field for the field which isn't enabled.

That is N and L take preference over R. So the text as written is  
accurate. If a router that doesn't support the future defined  
functionality of the R-bit, can still look at the Nonce and Loc-Status- 
Bit fields when the R-bit is set.

> The other alternative is to simply treat the R bit itself as  
> reserved, and stop talking about the interaction with the N and L  
> bits until we define a use for the R bit.  After all, if an ETR  
> which doesn't know what the R bit is being used for receives a  
> packet with it set, the only choices are to either ignore the  
> setting or error the packet.

And we believe it will be ignored.

I don't have a strong feeling. Let the others who discussed this speak  
up to their preferences so we can converge.

Dino

---

From: David Meyer <[email-masked]>
Date: Mon, 31 Aug 2009 15:41:04 -0700

> data wants the receiver to validate the data frequently, then the sender  

	Joel,

	My original thinking was that the M-bit would be conveyed
	in the register message so that an ETR could tell the
	map-server that it needs to watch the RLOC(s) for this
	registration (because they might be changing more rapidly
	that the default behavior; a kind of hint). Its really
	more like of the negative of that; the M-bit tells the
	map-server that it might be able to suppress running a
	high(er) frequency locator-reachability algorithm for
	those registrations that *do not* have the bit set.

	However, the M-bit also is carried in a Map-Reply so you
	can convey the bit to an {I,P}TR for for the same reason
	(i.e., so an {I,P}TR could take advantage of the same
	"hint").

	Dave

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 19:20:25 -0400

There are two kinds of locator liveness, I think.
One kind is where the set of locators changes, in particular where new 
unanticipated locators are added to the set.  The other kind of issue is 
where the connectivity of the RLOCs to the EID block is itnermittent / 
unreliable, and therefore should be monitored with probes or something 
similar.
I guess the problem is that I assumed that "check for RLOC changes" 
(which is what the document says" would translate to the first kind, and 
would need to be done with map requests.  The way a server tells the ITR 
to perform frequent map requests is with a short lifetime (TTL).

Apparently, what you are suggesting is that this is intended as a hint 
for the second kind of issue / behavior.  If so, please find clearer 
words for that.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 31 Aug 2009 16:40:13 -0700

> There are two kinds of locator liveness, I think.

Locator liveness and mapping update changes are two different  
mechanisms.

Locator liveness test the liveness of the locators in a locator-set of  
a map-cache entry. Locators are not removed from the locator-set when  
they become unreachable.

Mapping update changes is done when a locator is added or removed or a  
priority or weight has changed for an existing locator. In the former  
case, when a LISP mobile-node moves a mapping update does the delete  
and add at the same time (when it is single-homed).

A mapping update mechanism is achieved 3 ways (and 3 is needed to  
handle all the traffic directionality cases):

(1) An ITR is RLOC-probing and a Map-Reply is returned with a  
different locator-set. The ITR replaces the information from what it  
had previously stored.

(2) An ITR gets a Map-Request from the ETR and the ITR is configured  
to "ip lisp etr accept-map-request-mapping verify" (sorry to use cisco  
CLI syntax). In this case, a "verifying Map-Request" is sent by the  
ITR and a returning Map-Reply from the ETR replaces the locator-set  
stored. In this case, the ETR can be a MN that moves often and it has  
cleared its cache to who it is doing bidirectional communication with  
so the opportunity for the ITR to cache a mapping-update arises.

(3) An ITR gets a SMR-based Map-Request which solicites the ITR to  
send a verifying Map-Request to use the procedures in (2).

The final method is to have short TTLs where a normal EID-based Map- 
Request is sent.

> One kind is where the set of locators changes, in particular where  
> new unanticipated locators are added to the set.  The other kind of  
> issue is where the connectivity of the RLOCs to the EID block is  
> itnermittent / unreliable, and therefore should be monitored with  
> probes or something similar.

Right, two completely separated problems and solutions we have to them.

> I guess the problem is that I assumed that "check for RLOC  
> changes" (which is what the document says" would translate to the  
> first kind, and would need to be done with map requests.  The way a  
> server tells the ITR to perform frequent map requests is with a  
> short lifetime (TTL).

Let's refer to this terminology wise as "mapping updates". Luigi  
coined the phrase, so I kept using it. We use the term "locator  
reachability" for the other problem space.

> Apparently, what you are suggesting is that this is intended as a  
> hint for the second kind of issue / behavior.  If so, please find  
> clearer words for that.

No, that is not what I think Dave meant. Dave to clarify. But I think  
he just was referring how to do mapping-updates with method (1) above.

That is, if you are testing locator reachability with a Map-Request/ 
Map-Reply exchange, you not only get an ack to the request but you get  
a fresh mapping-update at the same time.

Dino

>>> In the map reply, I am not sure I follow the reasoning for the "M"  
>>> bit.  At a guess, it is intended for mobility cases.
>>> As far as I can tell, it does not help.  If the sender of the  
>>> mapping  data wants the receiver to validate the data frequently,  
>>> then the sender  should use a short ttl.
>> 	Joel,

---

From: David Meyer <[email-masked]>
Date: Mon, 31 Aug 2009 17:06:00 -0700

> No, that is not what I think Dave meant. Dave to clarify. But I think he 
> just was referring how to do mapping-updates with method (1) above.

	Yes. Dino's language was much clearer than mine.

	Dave

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 20:13:19 -0400

After some discussion of-line, I will simplify my request.

If the text is intended, as I believe from the discussion, to be talking 
about locator liveness monitoring, and the frequency with which that is 
done, then please
1) Say that.  "RLOC changes" which is the current document wording says 
leads at least some readers (me) to look for changes in the RLOC set, 
not changes in the RLOC liveness.
2) Please be more explicit about what the receiver is supposed to do 
when the bit is set.  If I were trying to implement taht text, I would 
be guessing as to what I am supposed to do in relation to seeing the M 
bit set or clear in a response.  Should this control probing?  Should it 
multiply the probing rate by a factor?  (If so what factor?)  Should I 
just ignore it because I do not know what conditions would cause the 
sender to set the bit?

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 31 Aug 2009 17:28:05 -0700

> If the text is intended, as I believe from the discussion, to be  
> talking about locator liveness monitoring, and the frequency with  
> which that is done, then please

The M-bit setting is not talking about that.

> 1) Say that.  "RLOC changes" which is the current document wording  
> says leads at least some readers (me) to look for changes in the  
> RLOC set, not changes in the RLOC liveness.

There is still confusion. The M-bit is there because we want to use if  
for LISP-MN. We will spec out the usage in a future draft-meyer-lisp- 
mn draft. We are allocating the bit in the main LISP draft. So we  
can't be precise right now.

> when the bit is set.  If I were trying to implement taht text, I  
> would be guessing as to what I am supposed to do in relation to  
> seeing the M bit set or clear in a response.  Should this control  
> probing?  Should it multiply the probing rate by a factor?  (If so  
> what factor?) Should I just ignore it because I do not know what  
> conditions would cause the sender to set the bit?

We will in a future LISP-MN spec update. This spec is not focusing on  
MN as focus on the main charter. We allocate the bit to hold a spot  
for it. That is why the description is vague.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 20:46:03 -0400

Then say "This bit is for reserved for future usage by a LISP Mobility 
Solution."    Having a bit in a spec that is described as doing 
something, but actually doesn't do that, is no help.

Yours,
Joel

Dino Farinacci wrote:
>> says leads at least some readers (me) to look for changes in the RLOC 
>> set, not changes in the RLOC liveness.
> 
> for LISP-MN. We will spec out the usage in a future draft-meyer-lisp-mn 
> draft. We are allocating the bit in the main LISP draft. So we can't be 
> precise right now.
> 
>> bit set or clear in a response.  Should this control probing?  Should 
>> it multiply the probing rate by a factor?  (If so what factor?) Should 
>> I just ignore it because I do not know what conditions would cause the 
>> sender to set the bit?
> 
> We will in a future LISP-MN spec update. This spec is not focusing on MN 
> as focus on the main charter. We allocate the bit to hold a spot for it. 
> That is why the description is vague.
> 
> Dino
> 
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 31 Aug 2009 17:47:48 -0700

> hen say "This bit is for reserved for future usage by a LISP  
> Mobility Solution."    Having a bit in a spec that is described as  
> doing something, but actually doesn't do that, is no help.

Great suggestion. I will do that. Thanks Joel!

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 20:48:04 -0400

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.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 31 Aug 2009 17:53:29 -0700

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

How about this:

    M: this bit is reserved for use by the LISP mobile-node design
       documented in [LISP-MN].

Okay?

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Aug 2009 21:08:48 -0400

I can live with it.
It does mean that if we don't use it there, the base spec will need to 
be revised in order to use that bit for something else.

But that is much better than what is there currently.
Joel

Dino Farinacci wrote:
>> 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.
> 
> How about this:
>