Subject: [lisp] Fwd: I-D Action:draft-maino-lisp-sec-00.txt

From: Dino Farinacci <[email-masked]>
Date: Fri, 4 Mar 2011 16:39:22 -0800

A proposed mechanism to deal with over-claiming attacks. This document  
is consistent with the general description of security encodings  
referred to in draft-ietf-lisp-10 and draft-ietf-lisp-ms-07.

We are asking chairs for a slot to present this in Prague.

Thanks,
Dino

Begin forwarded message:

> From: Dino Farinacci <[email-masked]>
> Date: March 4, 2011 4:36:15 PM PST
> To: Dino Farinacci <[email-masked]>
> Subject: Fwd: I-D Action:draft-maino-lisp-sec-00.txt
>
>
>
> Begin forwarded message:
>
>> From: [email-masked]
>> Date: March 4, 2011 3:30:01 PM PST
>> To: [email-masked]
>> Subject: I-D Action:draft-maino-lisp-sec-00.txt
>> Reply-To: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts  
>> directories.
>>
>> 	Title           : LISP-Security (LISP-SEC)
>> 	Author(s)       : F. Maino, et al.
>> 	Filename        : draft-maino-lisp-sec-00.txt
>> 	Pages           : 17
>> 	Date            : 2011-03-04
>>
>> This memo specifies LISP-SEC, a set of security mechanisms that
>> provide origin authentication, integrity and anti-replay protection
>> to LISP's EID-to-RLOC mapping data.  LISP-SEC also enables
>> verification of authorization on EID prefix claims.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-maino-lisp-sec-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
> Content-Type: text/plain<BR>Content-ID: &lt;[email-masked] 
> &gt;<BR><BR>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Terry Manderson <[email-masked]>
Date: Wed, 9 Mar 2011 16:13:06 -0800

Thanks Dino,

Its been 6 days since this item was uploaded - I am floored that it hasn't
generated _any_ response from the WG. Please WG, review this document as it
is important.

So taking off the co-chair hat.

The document appears to address the communications between ITR, map server,
and ETR by adding a layer of integrity to the ECM.

And later in the document, the SIDR working group is identified as the place
to deal with the BGP in LISP+ALT.

I didn't see it, and maybe I missed it. What actions does a map-server (or
map server operator) take to confirm that the entity registering at a map
server has the right to present the EID in question? It may be that we
simply have differing ideas of 'origination' and potentially this is
covered.

Cheers
Terry

On 5/03/11 10:39 AM, "Dino Farinacci" <[email-masked]> wrote:

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 9 Mar 2011 16:35:59 -0800

> server has the right to present the EID in question? It may be that we

This is in the draft-ietf-lisp-ms-06 draft. It indicates that there is  
a business arrangement/transaction between the site and the Mapping  
Service Provider. When the locator-set is known by the site and the  
EID-prefix is allocated to the site, the site communicates this by non- 
protocol mechanisms with a shared-key  to the Mapping Service  
Provider. Then the EID-prefix, locator-set, shared-key is configured  
in the Map-Server device(s). Only when the site registers the exact  
EID-prefix and locator-set and signs the Map-Register and the Map- 
Server receives and verifies the ETR signature, does Map-Requests for  
EIDs covered by the registered EID-prefix get sent by the Map-Server  
to the ETRs at the site.

What the LISP-SEC adds to this is to have the Map-Server sign the EID- 
prefix registered and forces the ETR to sign its Map-Reply with a one- 
time-key the Map-Server (the trusted anchor point) chooses with no  
knowledge of the one-time-key the ITR selected. Then the ITR can  
verify that the trusted anchor point is saying the EID-prefix mask- 
length is the same that is being registered and the ETR believes the  
same for the part of the Map-Reply it signs.

Did that answer your question with too much detail?

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Mar 2011 19:50:59 -0500

Is the ETR allowed to later update the locator-set?
What if the locator set changes between the off-line notifcation and the 
on-line registration?
Or is there a requirement that when the set of likely locators changes 
(for example by entering into a contract with a new ISP for a new link), 
there must be an off-line communication with the (all?) MS providers one 
works with?

I realize the locator set changes relatively rarely, but I am trying to 
check the implications.

Thanks,
Joel

On 3/9/2011 7:35 PM, Dino Farinacci wrote:
> This is in the draft-ietf-lisp-ms-06 draft. It indicates that there is a
> business arrangement/transaction between the site and the Mapping
> EID-prefix is allocated to the site, the site communicates this by
> non-protocol mechanisms with a shared-key to the Mapping Service
> Provider. Then the EID-prefix, locator-set, shared-key is configured in
> the Map-Server device(s). Only when the site registers the exact
> EID-prefix and locator-set and signs the Map-Register and the Map-Server
> receives and verifies the ETR signature, does Map-Requests for EIDs
> covered by the registered EID-prefix get sent by the Map-Server to the
> ETRs at the site.
>
> What the LISP-SEC adds to this is to have the Map-Server sign the
> EID-prefix registered and forces the ETR to sign its Map-Reply with a
> one-time-key the Map-Server (the trusted anchor point) chooses with no
> knowledge of the one-time-key the ITR selected. Then the ITR can verify
> that the trusted anchor point is saying the EID-prefix mask-length is
> the same that is being registered and the ETR believes the same for the
> part of the Map-Reply it signs.
>

---

From: Terry Manderson <[email-masked]>
Date: Wed, 9 Mar 2011 17:07:53 -0800

Still no wg-chair garb.

> a business arrangement/transaction between the site and the Mapping

Right, an in particular when I saw "origination" in the maino document and
reflecting on these sentences in LISP-MS:

  " While this check is not mandatory, it is
   strongly encouraged as a failure to so leaves the mapping system
   vulnerable to simple EID-prefix hijacking attacks.  As developers and
   users gain experience with the mapping system, additional, stronger
   security measures may be added to the registration process."

My mind raced to a point further than what the maino-lisp-sec document
covers. Perhaps review what 'origination' means in maino-lisp-sec compared
to the current school of thought on route origination vs the LISP collective
thought on EID to RLOC origination and the ground work needed to confirm an
entity has the right to originate an EID, for what period of time, and if
any preconditions need to exist.

Or perhaps alternatively note in the security considerations that
maino-lisp-sec doesn't cover the registration process, or variances thereof.

Cheers
Terry

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 9 Mar 2011 17:09:27 -0800

> Is the ETR allowed to later update the locator-set?

Yes, the Map-Server can be configured with no locator-set or an  
"allowed-list" of locators which can be a superset of what is  
currently being registered.

> What if the locator set changes between the off-line notifcation and  
> the on-line registration?

If the policy is strict in the Map-Server then the registration is not  
accepted. This allows the mapping system to decide how *mobile* the  
EID-prefix can be.

> Or is there a requirement that when the set of likely locators  
> changes (for example by entering into a contract with a new ISP for  
> a new link), there must be an off-line communication with the (all?)  
> MS providers one works with?

Depends on how loose the policy is in the map-servers.

Dino

> I realize the locator set changes relatively rarely, but I am trying  
> to check the implications.
>
> Thanks,
> Joel
>
>>> generated _any_ response from the WG. Please WG, review this  
>>> document
>>> as it
>>> is important.
>>>
>>> And later in the document, the SIDR working group is identified as  
>>> the
>>> place
>>> I didn't see it, and maybe I missed it. What actions does a map- 
>>> server
>>> (or
>> Server
>> verify

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 9 Mar 2011 17:13:03 -0800

> maino-lisp-sec doesn't cover the registration process, or variances  

That is correct. The spec's main objective is to provide integrity of  
the contents in a Map-Reply message.

Dino

---

From: Fabio Maino <[email-masked]>
Date: Wed, 09 Mar 2011 17:19:18 -0800

> the contents in a Map-Reply message.

Agree. We intentionally left the security of the registration process 
out of the scope of the document. As Dino said today EID-prefix 
authorization is done by configuration.

We'll add the note on registration to the security section.

Fabio

-- 
Fabio Maino
[email-masked]

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Mar 2011 20:25:33 -0500

Reasonable.  But we probably need to say this somewhere.
(And I apologize if it already says it and I missed it.)
Yours,
Joel

On 3/9/2011 8:09 PM, Dino Farinacci wrote:
> "allowed-list" of locators which can be a superset of what is currently
> being registered.
>
>> (for example by entering into a contract with a new ISP for a new
>> link), there must be an off-line communication with the (all?) MS
>> providers one works with?
>

---

From: Vince Fuller <[email-masked]>
Date: Thu, 10 Mar 2011 23:37:47 -0800

> (And I apologize if it already says it and I missed it.)

As I understand it, this comment is in the context of asking what checks
a Map-Server is expected to perform on the information presented to it by
an ETR in a Map-Register message. The current spec says:

4.2.  ETR/Map-Server EID Prefix Registration

   An ETR publishes its EID-prefixes on a Map-Server by sending LISP
   Map-Register messages.  A Map-Register message includes
   authentication data, so prior to sending a Map-Register message, the
   ETR and Map-Server must be configured with a secret shared-key.  A
   Map-Server's configuration should also include a list of the EID-
   prefixes for which each ETR is authoratative and should verify that a
   Map-Register received from an ETR only contain EID-prefixes that are
   associated with that ETR.  While this check is not mandatory, it is
   strongly encouraged as a failure to so leaves the mapping system
   vulnerable to simple EID-prefix hijacking attacks.  As developers and
   users gain experience with the mapping system, additional, stronger
   security measures may be added to the registration process.

The expectation being that a Map-Server will be configured with the list
of EIDs that a particular ETR is permitted to register. When a Map-Register
message is received from an ETR RLOC, the Map-Server will verify that the
EIDs for which it is attempting to register a mapping are in the list of
EIDs configured for that ETR.

Is this not sufficiently clear?

	--Vince

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Mar 2011 14:05:40 -0500

What Dino described included validating more information (the list of 
RLOCs was to be included in the message and validated), and included a 
description of the tradeoff in terms of operability and security with 
regard to validating that information.
If that is what we expect, and if we understand that tradeoff, then we 
need to say so.

Yours,
Joel

---

From: Vince Fuller <[email-masked]>
Date: Fri, 11 Mar 2011 11:43:06 -0800

> If that is what we expect, and if we understand that tradeoff, then we 

In past discussions, I recall the consensus being that it was better to err
on the side of flexibility and not require that all possible RLOCs be checked
by the Map-Server when an ETR registers.

Note that a Map-Server (unless performing proxy replies) doesn't participate
in generation or propagation of a Map-Reply so it can't validate the set
of RLOCs that an ETR returns; for that reason, it seems kind of pointless
to validate them during registration.

A separate email exchange with Dino indicated that he is OK with the
existing text; I will wait one more day before submitting MS-07 through
the Internet Drafts tool in case he wants me to change this.

	--Vince

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Mar 2011 14:52:17 -0500

If we are not expecting the RLOC list to be checked as part of the 
authentication of the registration, then there clearly is no need to 
explain the trade-off associated with that.  As the working group has 
not indicated it requires that, I have no objection if it remains absent.

Yours,
Joel

PS: The reason I care is that there are interoperability issues if what 
the MS expects to validate and what the ETR things are 
authorization-relevant do not match.  This resolution takes care of that 
potential.

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 12 Mar 2011 20:29:18 -0800

Joel, I was describing what an implementation could do. We shouldn't  
describe this in the spec.

Dino

On Mar 11, 2011, at 11:52 AM, Joel M. Halpern wrote:

> explain the trade-off associated with that.  As the working group  
> has not indicated it requires that, I have no objection if it  
> remains absent.
>
> Yours,
> Joel
>
> PS: The reason I care is that there are interoperability issues if  
> what the MS expects to validate and what the ETR things are  
> authorization-relevant do not match.  This resolution takes care of  
> that potential.
>