Subject: [lisp] Overclaiming side effect

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 21 May 2011 10:23:23 -0400

The problem with talking to security folks is that they come up with 
perspectives one would have preferred not to discover :-)

Stephen raised a question.  I am not sure the issue is real.  If it is 
real, it probably requires only an additional sentence or two in the 
overclaiming.

Imagine a misbehaving ETR.  And a collaborator in a network who 
generates a request that the ALT will direct to that ETR.
That ETR would then get to respond, over-claiming.  (Yes, LISP-SEC has 
what looks to my naive eyes like a good answer to that.  But, for now...)
In principle, it could even overclaim 0/0, couldn't it?
Which would have the side effect of preventing the ITR from generating 
any new queries to anything?

Thanks,
Joel

---

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

> Stephen raised a question.  I am not sure the issue is real.  If it  
> is real, it probably requires only an additional sentence or two in  
> the overclaiming.
>
> That ETR would then get to respond, over-claiming.  (Yes, LISP-SEC  
> has what looks to my naive eyes like a good answer to that.  But,  
> for now...)
> Which would have the side effect of preventing the ITR from  
> generating any new queries to anything?

An implementation can be configured to (1) not accept any EID-prefix  
in a Map-Reply with a small mask-length (nothing smaller than /24 for  
example) or (2) check your existing cache to see if the Map-Reply EID- 
prefix overlaps with existing EID-prefixes where it can claim anything  
longer than the /24 could be suspect.

Dino

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 21 May 2011 19:31:36 -0400

Those both sound like reasonable responses.  Should we say something 
about them in the spec?
Also, should we lsit a check for the response covering a negative cache 
entry (that should be imnpossible in all valid cases, shouldn't it?)

Thanks,
Joel

On 5/21/2011 1:14 PM, Dino Farinacci wrote:
> An implementation can be configured to (1) not accept any EID-prefix in
> a Map-Reply with a small mask-length (nothing smaller than /24 for
> example) or (2) check your existing cache to see if the Map-Reply
> EID-prefix overlaps with existing EID-prefixes where it can claim
> anything longer than the /24 could be suspect.
>
> Dino
>
>>
>> Thanks,
>> Joel

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 22 May 2011 01:29:54 +0100

So am I right in assuming that since the answer is "heuristics" the problem is real?

Sounds like some text is needed all right. I'm not at all sure that these specific countermeasures are sufficiently effective to warrant being listed, but at this stage just clearly, fully, stating the problem is more useful maybe,
Cheers,
S

On 22 May 2011, at 00:31, "Joel M. Halpern" <[email-masked]> wrote:

> Those both sound like reasonable responses.  Should we say something about them in the spec?
> Also, should we lsit a check for the response covering a negative cache entry (that should be imnpossible in all valid cases, shouldn't it?)
> 
> Thanks,
> Joel
>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 22 May 2011 22:00:27 -0700

I will add to this paragraph in the Security Considerations section:

    There is a potential security risk implicit in the fact that ETRs
    generate the EID prefix to which they are responding.  An ETR can
    claim a shorter prefix than it is actually responsible for.  Various
    mechanisms to ameliorate or resolve this issue will be examined in
    the future, [LISP-SEC].

Thanks,
Dino

On May 21, 2011, at 5:29 PM, Stephen Farrell wrote:

> Sounds like some text is needed all right. I'm not at all sure that  
> these specific countermeasures are sufficiently effective to warrant  
> being listed, but at this stage just clearly, fully, stating the  
> problem is more useful maybe,
> Cheers,
> S
>
>> Also, should we lsit a check for the response covering a negative  
>> cache entry (that should be imnpossible in all valid cases,  
>> shouldn't it?)
>>
>> Thanks,
>> Joel
>>
>>>> is
>>>> has

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 May 2011 06:16:26 +0100

>   mechanisms to ameliorate or resolve this issue will be examined in

I think that'd be useful. If if were me writing I'd omit "potential" since this is, actually, a risk.

S

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 22 May 2011 22:21:03 -0700

> since this is, actually, a risk.

How is this:

    There is a security risk implicit in the fact that ETRs generate the
    EID prefix to which they are responding.  An ETR can claim a shorter
    prefix than it is actually responsible for.  Various mechanisms  
exist
    to ameliorate this over-claiming issue.  One mechanism is to check
    the EID-prefix mask-length returned in Map-Replies with other EID-
    prefixes which are already populated in the map-cache.  And if  
longer
    mask-lengths exist in the map-cache, the Map-Reply EID-prefix can be
    rejected.  The over-claming issue can also be resolved by signing  
the
    Map-Reply.  This will be examined in the future, [LISP-SEC].

Dino

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 May 2011 06:29:33 +0100

On 23 May 2011, at 06:21, Dino Farinacci <[email-masked]> wrote:

>   prefix than it is actually responsible for.  Various mechanisms exist
>   prefixes which are already populated in the map-cache.  And if longer
>   rejected.  The over-claming issue can also be resolved by signing the

I think that's maybe less good - how confident are you about those countermeasures? Your first one with s/potential// seemed better to me,
Cheers,
S. (boarding a plane so offline from now;-)