Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2011 09:10:36 -0000

#27: ETR may claim a larger prefix than is delegated to it

Changes (by luigi@…):

  * status:  new => resolved
  * resolution:  => fixed

-- 
----------------------------------+-----------------------------------------
Reporter:  hartmans-ietf@…        |        Owner:                 
    Type:  technical              |       Status:  resolved       
Priority:  major                  |    Component:  draft-ietf-lisp
Severity:  -                      |   Resolution:  fixed          
Keywords:                         |  
----------------------------------+-----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/27#comment:1>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2011 09:11:00 -0000

Changes (by luigi@…):

  * status:  resolved => closed

    Type:  technical              |       Status:  closed         

Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/27#comment:2>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2011 20:02:22 -0000

Changes (by yakov@…):

  * status:  closed => reopened
  * resolution:  fixed =>

Comment:

 Before closing the ticket please document how the issue raised by the
 ticket is resolved.

-- 
----------------------------------+-----------------------------------------
Reporter:  hartmans-ietf@…        |        Owner:                 
    Type:  technical              |       Status:  reopened       
Priority:  major                  |    Component:  draft-ietf-lisp
Severity:  -                      |   Resolution:                 
Keywords:                         |  
----------------------------------+-----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/27#comment:3>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Mar 2011 16:23:21 -0400

The general issue of authorization for address claims was noted early on 
as being something for later work, not within scope for the experiment.

This is dealt with in greater detail, including some pointers to ideas 
that we believe will address the over-claiming problem (some initial, 
and some more complete ideas) are described in 
http://datatracker.ietf.org/doc/draft-saucez-lisp-security/, which will 
be discussed in the upcoming meeting and likely be a future work item 
for the working group.

Based on this, I do not see any changes needed to the LISP document to 
resolve this ticket.

Yours,
Joel M. Halpern

---

From: Vince Fuller <[email-masked]>
Date: Fri, 18 Mar 2011 14:30:20 -0700

> as being something for later work, not within scope for the experiment.

Actually, this particular issue is directly addressed by LISP-SEC, which
will be presented at the Prague IETF and proposed as a WG item.

	--Vince

---

From: Sam Hartman <[email-masked]>
Date: Fri, 18 Mar 2011 17:41:28 -0400

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

    Joel> The general issue of authorization for address claims was
    Joel> noted early on as being something for later work, not within
    Joel> scope for the experiment.

I certainly think it's true that SIDR-level authorization of addresses
was  noted even as early as chartering as out of scope.

However, this sort of issue, especially to the extent that LISP differed
from the existing Internet was definitely not ruled out for any
definition of early that involved time when  I was active.

There were some discussions with Jari about what would be out of scope
for the experiment and what would not.
In any of those discussions I participated in, I don't recall anything
that would rule this out of scope.

So, I'd like a bit more detail about when this was ruled out of scope.

Thanks,

--Sam

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Mar 2011 18:00:07 -0400

What I was refering to as out of scope, which is what seems to be asked 
for in the ticket, is the SIDR / RPKI work.  (That work clearly applies. 
  But it is not part of the current phase of the effort.)

Having said that, I do not know what more you arse asking for relative 
to over-claiming.

Also, I should also have pointed to 
http://datatracker.ietf.org/doc/draft-maino-lisp-sec/?include_text=1 as 
a relevant document.  (two lisp-security documents, evne the chairs get 
confused.)

Yours,
Joel

On 3/18/2011 5:41 PM, Sam Hartman wrote:
>>>>>> "Joel" == Joel M Halpern<[email-masked]>  writes:
>

---

From: Sam Hartman <[email-masked]>
Date: Fri, 18 Mar 2011 18:34:13 -0400

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

    Joel> What I was refering to as out of scope, which is what seems to
    Joel> be asked for in the ticket, is the SIDR / RPKI work.  (That
    Joel> work clearly applies. But it is not part of the current phase
    Joel> of the effort.)

For a single address we get authorization through the combination of the
nonce, return routability, and relationships of the map server and ALT.
We get security similar to what the internet gives us today.

When that ticket was written the difference is that the ETR can claim a
larger block than is desired.
In today's internet, to do that, some BGP speaker near the person
claiming the address needs to claim the larger prefix. Then the BGP
speakers between me and the point where that route get chosen need to
not filter that information.

In LISP, we push that all to the ETR.
You could instead involve the map server  in the dicision so that the
ITR  knows  both the map server and the ETR agree with the claim of how
big a block should be mapped.
That brings it back to a BGP speaker.
It's not perfect obviously and is not quite the same as today's model.

I can think of a way to do this  that I think involves no extra packets
and no keying material, although it does involve a couple of hash
operations.
I'd be happy to discuss if people are interested.

I actually think SIDR-like solutions are a bad fit for LISP or at least
this problem in LISP. They're probably fine for securing the ALT.
My rationale is that you don't want every ITR to need to download an
entire RPKI repository, or to evaluate CRLs and signature chains.
You want something far simpler than that.

Another place to look for this sort of thing is how we've looked at
securing route optimizations for NEMO. I don't think they have any
standards (and I realize it's no longer in the NEMO group), but I
thought they had non-RPKI-based approaches as well.

---

From: Vince Fuller <[email-masked]>
Date: Fri, 18 Mar 2011 15:44:50 -0700

> I'd be happy to discuss if people are interested.

Please see LISP-SEC (http://tools.ietf.org/html/draft-maino-lisp-sec-00)
which describes a mechanism for adding authentication to the ITR-MS-ETR-ITR
interaction.

One of the LISP-SEC authors will also be following-up in this thread.

	--Vince

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Mar 2011 18:55:02 -0400

I had missed one line in reading LISP-SEC.
The suggestion is that the Map Server signs a block, based on the 
business registration, carrying the prefix information.
And then the ETR forwards that.

If I read this right, this provides over-claiming protection up to the 
level of the business relationship between the Map-Server and the ETR?

I would not claim it is complete coverage, but that does provide more 
coverage.

Are we intending to hold up the base LISP spec for this?  Or phrased 
differently, do you folks think the LISP-SEC material is important 
enough that we should ensure it is in all the implementations?

Yours,
Joel

---

From: Vince Fuller <[email-masked]>
Date: Fri, 18 Mar 2011 16:20:49 -0700

> level of the business relationship between the Map-Server and the ETR?

Where else could one propose putting such checks?

> I would not claim it is complete coverage, but that does provide more 

As with so many other things in the Internet, security will be used if the
operations community decides it is important. LISP-SEC is intended to offer
a mechanism for implementing authentication between ITR, MR, MS, and ETR;
whether it is actually enabled and used is quite beyond the scope of both
this discussion and the LISP WG charter.

> enough that we should ensure it is in all the implementations?

No, we should absolutely not hold up publication of the documents that are
already within the charter of the LISP WG.

Past attempts to mandate security in parts of the Internet architecture
have pretty much universally resulted in failure of technology to be
adopted; the lesson of history is that one can define robust security
mechanisms and encourage their implementation and deployment but the market
will ultimately decide whether they are actually used. I believe that the
LISP effort has done proper "due dilligence" in addressing security concerns
by defining appropriate technology; we cannot reasonably be expected to do
more than that.

	--Vince

---

From: Fabio Maino <[email-masked]>
Date: Fri, 18 Mar 2011 16:29:40 -0700

> level of the business relationship between the Map-Server and the ETR?
No, it's more than that. The threat model assumes that the Mapping 
System is trusted, but the ETR can get compromised (or be malicious). To 
prevent the ETR from overclaiming, the EID prefix information is signed 
by the Map-Server with the OTK. A KDF is applied to the OTK to derive 
the OTK-ETR, that is passed to the ETR to protect the integrity of the 
Map-Reply. The KDF is non-invertible, so the ETR cannot impersonate the 
Map-Server and forge the authenticated EID-prefix authorization data 
signed by the Map-Server.

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

-- 
Fabio Maino
[email-masked]

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Mar 2011 20:57:08 +0100

Joel,

Recalling that we're producing experimental RFCs, I don't see a need to
hold up any of this.  I would expect continued evolution of the work
even after the docs go to the editor.  Do others disagree?

Eliot

---

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 29 Mar 2011 16:20:50 -0000

Changes (by jmh@…):

  * status:  reopened => resolved
  * resolution:  => fixed

Comment:

 While the base question of over-claiming is valid, it is also complicated
 and multi-faceted.  As such, we will not be adding additional mechanisms
 in the base LISP specification to address this.  Significant improvements
 are proposed in LISP-SEC, including noting that the use of a structure
 such as RPKI is for further study.

Ticket URL: <https://trac.tools.ietf.org/wg/lisp/trac/ticket/27#comment:4>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 29 Mar 2011 11:26:28 -0700

Folks,

>  such as RPKI is for further study.

The base LISP specification should just document the issue of over-claiming, 
and then point to LISP-SEC.

Yakov.

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 30 Mar 2011 15:18:29 -0000

Comment(by yakov@…):

 If the base LISP spec is not going to have additional mechanisms to
 address over-claiming, then I would suggest to add to the base LISP spec
 some text that would just describe the issue of over-claiming, and state
 that handling this issue is outside the scope of the document.

Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/27#comment:5>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 30 Mar 2011 09:55:21 -0700

We did in -11. Here is the text at the end of section 12.

    There is a potential security risk implicit in the fact that ETRs
    generate the EID prefix to which they are responding.  In theory, 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].

Dino

On Mar 30, 2011, at 8:18 AM, lisp issue tracker wrote:

> ---------------------------------- 
> +-----------------------------------------
> ---------------------------------- 
> +-----------------------------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/27#comment:5 
> >

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 31 Mar 2011 08:11:15 -0700

Dino,

>     examined in the future, [LISP-SEC].

The text should elaborate a bit on what  is exactly the "potential
security risk", and specifically what are some of the implications
of that risk.

Also, replace "In theory" with "Thus" (as the ETR can do this not just
"in theory", but in practice as well). 

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 31 Mar 2011 08:24:19 -0700

> security risk", and specifically what are some of the implications

"ETR can claim a shorter prefix than it is actually responsible for".

> "in theory", but in practice as well).

In practice the implementation test mask-lengths and don't install  
coarse routes.

Dino