Subject: [lisp] An operational problem

From: Ronald Bonica <[email-masked]>
Date: Fri, 20 May 2011 18:51:01 -0400

Folks,

I think that the issue of TTL specification for EID-RLOC mappings might require a little more exploration. In the nominal case, the TTL for EID-RLOC mappings is configured by the advertising party and accepted by the receiving party. In some cases (for example, prefix overlap), the receiving party MUST decrease the TTL.

However, is the receiving party allowed to increase the TTL because the specified value was so low that it would cache-churn? If so, can a unilateral TTL increase frustrate the intentions of an advertising party (for example, a data center that might move a service from list site to lisp site at a moment's notice?

                                                             Ron

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 20 May 2011 22:06:11 -0700

> Folks,
>
> I think that the issue of TTL specification for EID-RLOC mappings  
> might require a little more exploration. In the nominal case, the  
> TTL for EID-RLOC mappings is configured by the advertising party and  
> accepted by the receiving party. In some cases (for example, prefix  
> overlap), the receiving party MUST decrease the TTL.

No the receiving party must not decrease the TTL. The spec says:

    ...  When more than one EID-prefix is
    returned, all SHOULD use the same Time-to-Live value so they can all
    time out at the same time.  When a more specific EID-prefix is
    received later, its Time-to-Live value in the Map-Reply record can  
be
    stored even when other less specifics exist.  When a less specific
    EID-prefix is received later, its map-cache expiration time SHOULD  
be
    set to the minimum expiration time of any more specific EID-prefix  
in
    the map-cache.

The TTL is *in the packet*, the expiration time is when the ITR  
removes the map-cache entry.

> However, is the receiving party allowed to increase the TTL because  
> the specified value was so low that it would cache-churn? If so, can  
> a unilateral TTL increase frustrate the intentions of an advertising  
> party (for example, a data center that might move a service from  
> list site to lisp site at a moment's notice?

The above text does not indicate that. So the answer is no. But a map- 
cache entry may be refreshed if there is activity against it. So there  
is no cache-churn.

Dino

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

---

From: Ronald Bonica <[email-masked]>
Date: Sat, 21 May 2011 16:05:10 -0400

Dino,

I'm sorry. I used the terminology sloppily in my initial question. Let me rephrase it now that I understand the difference between the terms "TTL" and "expiration time".

I think we might want to explore how ITRs manage the map-cache. (In the best of all possible worlds, we might add a section on cache management algorithms. For example, when an ITR needs to add an entry to the cache, how does it decide which cache entry to bump? Next to expire? Least recently used? Least frequently used? In order to maintain cache integrity, do some entries need to be deleted before others?)

But back to my original question: In the nominal case, the map-cache expiration time is set by the ITR as a function of the received TTL. In some cases (for example, prefix overlap), the ITR MUST adjust the expiration time.

However, is the receiving party allowed to increase the cache-expiration time because the specified value was so low that it would cache-churn? If not, could this be used as an attack vector? If so, can a unilateral expiration time increase frustrate the intentions of an advertising party (for example, a data center that might move a service from list site to lisp site at a moment's notice?

                                         Ron

P.S. I hope that this makes more sense.

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Saturday, May 21, 2011 1:06 AM
> To: Ronald Bonica
> Cc: [email-masked]
> Subject: Re: [lisp] An operational problem
> 
> > Folks,
> >

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 21 May 2011 14:32:05 -0700

> Dino,
>
> I'm sorry. I used the terminology sloppily in my initial question.  
> Let me rephrase it now that I understand the difference between the  
> terms "TTL" and "expiration time".
>
> I think we might want to explore how ITRs manage the map-cache. (In  
> the best of all possible worlds, we might add a section on cache  
> management algorithms. For example, when an ITR needs to add an  
> entry to the cache, how does it decide which cache entry to bump?  
> Next to expire? Least recently used? Least frequently used? In order  
> to maintain cache integrity, do some entries need to be deleted  
> before others?)

If one ever has to be bump, yes, you can use any of the above criteria.

> But back to my original question: In the nominal case, the map-cache  
> expiration time is set by the ITR as a function of the received TTL.  
> In some cases (for example, prefix overlap), the ITR MUST adjust the  
> expiration time.

Right. Okay.

> However, is the receiving party allowed to increase the cache- 
> expiration time because the specified value was so low that it would  
> cache-churn? If not, could this be used as an attack vector? If so,  
> can a unilateral expiration time increase frustrate the intentions  
> of an advertising party (for example, a data center that might move  
> a service from list site to lisp site at a moment's notice?

I am not sure what the motivation is for wanting to manipulate the  
expiration timer. If the entry is used, it stays in the cache. If the  
locator-set changes, the SMR procedure updates the cached entry.

Therefore, you are putting too much emphasis on TTL usage.

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Sat, 21 May 2011 18:57:09 -0400

> Sent: Saturday, May 21, 2011 5:32 PM
> To: Ronald Bonica
> Cc: [email-masked]

This may require more thought (and more specification). For example, in Section 6.1.5, we were very careful that less specifics expired before or concurrently with more specifics. But now, if we need to bump an entry due to cache churn, we probably want to be sure that a that the less specific is bumped before the more specific, even if they have the same expiration time.

                                           Ron

P.S. Thanks for sticking with all of my annoying questions. I promise to take Sunday off ;-)

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 21 May 2011 16:12:41 -0700

> This may require more thought (and more specification). For example,  
> in Section 6.1.5, we were very careful that less specifics expired  
> before or concurrently with more specifics. But now, if we need to  
> bump an entry due to cache churn, we probably want to be sure that a  
> that the less specific is bumped before the more specific, even if  
> they have the same expiration time.

I would say if space needs to be made for a new entry, that an entire  
overlapping set should be removed, just avoid the complications.

> promise to take Sunday off ;-)

No prob.  ;-)

Dino

---

From: Terry Manderson <[email-masked]>
Date: Sun, 22 May 2011 22:58:20 -0700

So I'm not sure that this discussion results, as yet, in any text changes.

I can foresee a discussion ending up in a BCP on operational cache
maintenance as a 'learning goal' of an experimental BCP, and even as a WG
milestone document perhaps.

Ron, Can you please clarify if you are requesting text changes, and if so
please provide a parsimonious set of words that forms your concerns for
inclusion?

Cheers
Terry

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 23 May 2011 15:06:54 -0400

Terry,

I would applaud another draft on cache management. However, until that draft has been reviewed, I wonder if the base LISP specification is ready for deployment in environments that require availability and scalability.

                                                   Ron

> From: Terry Manderson [mailto:[email-masked]]
> Sent: Monday, May 23, 2011 1:58 AM
> To: Dino Farinacci; Ronald Bonica
> Cc: [email-masked]

---

From: Terry Manderson <[email-masked]>
Date: Mon, 23 May 2011 17:00:51 -0700

Hi Ron,

Given that the LISP spec is Experimental I think that it's quite fine for
deployment questions like these to exist.

So I would encourage anyone who has, or can summarily acquire, resources to
build an implementation based on the current LISP spec and deploy it in an
environment (simulated or otherwise) where availability and scalability are
the prime inputs to derive a problem statement that can be brought back to
the WG for either a new draft, or a bis on the appropriate LISP* document.

At this stage, given the Experimental designation of the draft I don't see
any reason to halt progress of this document to deduce if the specification
can handle that type of deployment.

Cheers
Terry

On 24/05/11 5:06 AM, "Ronald Bonica" <[email-masked]> wrote:

> Terry,
> 
> I would applaud another draft on cache management. However, until that draft
> has been reviewed, I wonder if the base LISP specification is ready for
> deployment in environments that require availability and scalability.
> 
> 
>                                                    Ron
>

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 May 2011 15:21:42 -0400

Hi Terry,

Granted, the requirements for publication as EXPERIMENTAL are low. However, I believe that there is a "truth in advertising" requirement, even for EXPERIMENTAL RFCs.

We wouldn't want someone to deploy LISP for mission critical, production traffic thinking that its availability and scalability attributes were well known. Maybe it would be a good idea to add a section (up front) that spells out where we need operational experience and additional specification.

                                                   Ron

> Sent: Monday, May 23, 2011 8:01 PM
> To: Ronald Bonica; Dino Farinacci
> Cc: [email-masked]
> >> maintenance as a 'learning goal' of an experimental BCP, and even as
> a
> >> WG
> >> Ron, Can you please clarify if you are requesting text changes, and
> if
> >> so

---

From: Terry Manderson <[email-masked]>
Date: Thu, 26 May 2011 22:07:07 -0700

Hi Ron,

There are a number of references in the document for where future work is
required.

I've started a discussion with my co-chair on the topic. I will come back to
the list shortly.

Cheers
Terry

On 25/05/11 5:21 AM, "Ronald Bonica" <[email-masked]> wrote:

> Hi Terry,
> 
> We wouldn't want someone to deploy LISP for mission critical, production
> traffic thinking that its availability and scalability attributes were well
> known. Maybe it would be a good idea to add a section (up front) that spells
> out where we need operational experience and additional specification.
>