Subject: Re: [lisp] Can I get opinions?

From: [email-masked] (Noel Chiappa)
Date: Thu, 28 May 2009 16:04:51 -0400 (EDT)

> From: "Joel M. Halpern" <[email-masked]>

    > Looks like an improvement to me.

I expect that Dino was particularly concerned that a change of this sort
might present a problem for someone who's already implementing stuff, so if
there's anyone in that boat, it would be important to hear from them while
this is still being tossed around as an idea.

	Noel

---

From: Damien Saucez <[email-masked]>
Date: Thu, 28 May 2009 22:12:09 +0200

looks better.

As we are talking about changing the header, it would be the perfect 
time to discuss versioning again, isn't it? Or at least to discuss on 
the mailing list what we would really see in the headers.

Noel, I think that functionalities in the protocol are more important 
than implementation issues. I  hope we will not limit the changes in the 
protocol just because of "legacy" code.

Damien Saucez

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 28 May 2009 13:25:33 -0700

> time to discuss versioning again, isn't it? Or at least to discuss  
> on the mailing list what we would really see in the headers.

Well, that is a big change.  ;-)

Dino

> Noel, I think that functionalities in the protocol are more  
> important than implementation issues. I  hope we will not limit the  
> changes in the protocol just because of "legacy" code.
>
> Damien Saucez
>
> Noel Chiappa wrote:

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 28 May 2009 22:38:25 +0200

> changes in the protocol just because of "legacy" code.

On this I totally agree with Damien.
Even if we struggle in keeping the pace of the official LISP dev team  
(and we are getting closer ;-) ), this is the time to introduce (deep)  
changes for the sake of a better protocol, not the time to be  
conservative on legacy code.

 From my point of view (and I already pointed out this to Dino in some  
mails exchanged while talking about versioning) radical changes are  
not a big deal now. If it is worth.. the sooner the better ;-)

Luigi

---

From: Sam Hartman <[email-masked]>
Date: Thu, 28 May 2009 17:34:06 -0400

By versioning, are we talking about the sort of versioning that
Margaret discussed today, or are we talking about versioning of map
entries as discussed at the last IETF?

---

From: "Damian Lezama" <[email-masked]>
Date: Thu, 28 May 2009 21:51:01 -0700

Hi,

We have a prototype implementation. I strongly agree that it's a non sense
restricting LISP progress because of current code at this point...

That said, I noticed that now we have a different header for control and
data packets. And I think this is an inconsistency in the draft:
	"the R-bit for each locator must
      have a consistent setting with the bitfield setting of the 'Loc
      Reach Bits' field in the early part of the header"
Because it looks like reach bits are not being used in control messages
anymore (set to 0 always since draft 11).
What makes me think that the first 4 bytes of the control messages are never
used, and now the header is already different, so I think maybe the draft
should be updated accordingly (mark as unused or figure out something to put
there:).

BTW: which is the max number of locators allowed in a record? We considered
it 31 (because of 31 reachability bits). Should we consider 32 as limit now?
Shouldn't it be explicit in the draft? (is it there but I missed it?)
 
Regards,
Damian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Noel Chiappa
> Sent: Thursday, May 28, 2009 1:05 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [lisp] Can I get opinions?
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 28 May 2009 22:18:05 -0700

If we agree to the data-plane format, we can set the first 4-bytes to  
reserved per your comment below.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 29 May 2009 09:07:26 +0200

> entries as discussed at the last IETF?

Map versioning as discussed at the last IETF.

Cheers

Luigi

---

From: Damien Saucez <[email-masked]>
Date: Fri, 29 May 2009 09:24:17 +0200

> Shouldn't it be explicit in the draft? (is it there but I missed it?)
I personally believe that you should not have a limit in the number of 
the RLOCs in the reply (except the size of UDP segment). And consider 
the 31(32) first best RLOCs in the R bits. You have thus to know the 
order of the RLOCs in the Rbits, this is an open question that you also 
have when you limit the number. What if you have removed an RLOC and 
that a correspondent is still using an old mapping (e.g., the position 
of the RLOCs is not the same in the two mappings as you do not have the 
same number of RLOCs)? It seems to be a major issue of the R bits (in 
addition to the big security hole). Versioning has been thought to avoid 
these problems. Yes I try to sell versioning! ;-)

Cheers,

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 29 May 2009 10:51:18 -0700

> I personally believe that you should not have a limit in the number  
> of the RLOCs in the reply (except the size of UDP segment). And  
> consider the 31(32) first best RLOCs in the R bits. You have thus to  
> know the order of the RLOCs in the Rbits, this is an open question  
> that you also have when you limit the number. What if you have  
> removed an RLOC and that a correspondent is still using an old  
> mapping (e.g., the position of the RLOCs is not the same in the two  
> mappings as you do not have the same number of RLOCs)? It seems to  
> be a major issue of the R bits (in addition to the big security  
> hole). Versioning has been thought to avoid these problems. Yes I  
> try to sell versioning! ;-)

Damien, the spec indicates ways to deal with this. A removed RLOC from  
an RLOC-set can simply be marked down with a loc-reach-bit so any ITRs  
which have an old mapping instance cached, can just stop using it.  We  
have tested this in our implementation. Adding an RLOC to the end of a  
list is simple by having an ITR notice that a loc-reach-bit is set for  
an RLOC it doesn't have. So it can then go request a new Map-Reply. We  
have not tested this.

As for the loc-reach-bits and security, there is no reason that an ITR  
can take the change as advisement and then send a Map-Request to  
solicit a reply which will tell you if the loc-reach-bit change is  
authoritative and legit.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 29 May 2009 11:08:51 -0700

And I presented this at the Dublin LISP BOF. See the pertinent slides  
enclosed.

Dino

On May 29, 2009, at 10:51 AM, Dino Farinacci wrote:

>> consider the 31(32) first best RLOCs in the R bits. You have thus  
>> to know the order of the RLOCs in the Rbits, this is an open  
>> question that you also have when you limit the number. What if you  
>> have removed an RLOC and that a correspondent is still using an old  
> Damien, the spec indicates ways to deal with this. A removed RLOC  
> from an RLOC-set can simply be marked down with a loc-reach-bit so  
> any ITRs which have an old mapping instance cached, can just stop  
> using it.  We have tested this in our implementation. Adding an RLOC  
> to the end of a list is simple by having an ITR notice that a loc- 
> reach-bit is set for an RLOC it doesn't have. So it can then go  
> request a new Map-Reply. We have not tested this.
>
> As for the loc-reach-bits and security, there is no reason that an  
> ITR can take the change as advisement and then send a Map-Request to

---

From: Damien Saucez <[email-masked]>
Date: Fri, 29 May 2009 23:20:11 +0200

Dino Farinacci wrote:
>> mappings as you do not have the same number of RLOCs)? It seems to be 
>> a major issue of the R bits (in addition to the big security hole). 
>> Versioning has been thought to avoid these problems. Yes I try to 
>> sell versioning! ;-)
>
Are you sure that you proposal support the following case:

R_1 receive the mapping x:X (1,100,R), y:Y (2,100,R)at time 1
the mapping is changed at time 2 and becomes a:Z(1,100,!R) b:G (2,100,R)
R_1 receives the mapping only at time 4

> solicit a reply which will tell you if the loc-reach-bit change is 
You then consider the Rbits information during the mapping delay. It is 
then possible to have a DoS attack on existing flow by setting the Rbits 
at 0. Then, if you manage to slow down the mapping system for this 
mapping, it is a more important problem because you manage to break the 
current flows and limit the possible new flows. Would a better solution 
be to consider the mapping as it was and wait for the reply before 
changing the way packets are sent?

Damien Saucez

---

From: Damien Saucez <[email-masked]>
Date: Fri, 29 May 2009 23:28:32 +0200

Oops, the case I would like to present is this one:

R_1 receive the mapping X (1,100,R), Y (2,100,R)at time 1
the mapping is changed at time 2 and becomes Z(1,100,!R) G (2,100,R) 
P(3,100, R)
R_1 receives the mapping only at time 4

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 30 May 2009 15:59:47 -0700

> You then consider the Rbits information during the mapping delay. It  
> is then possible to have a DoS attack on existing flow by setting  
> the Rbits at 0. Then, if you manage to slow down the mapping system

The spec says the loc-reach-bits are a hint. That means if you are  
paranoid about who sets them and reacting to them, it means you send a  
Map-Request first for verification. This is true for data gleaning an  
new RLOC and gleaning mapping information from a received Map-Request  
as well.

> for this mapping, it is a more important problem because you manage  
> to break the current flows and limit the possible new flows. Would a  
> better solution be to consider the mapping as it was and wait for  
> the reply before changing the way packets are sent?

Yes, we spec it that way.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 30 May 2009 16:01:34 -0700

> R_1 receives the mapping only at time 4

Z replaces X and not used because R-bit is clear. G replaces Y and is  
used, and P is a new RLOC but not used because priority 3 > priority 2.

So what is the problem?

Dino