Subject: [lisp] comments on lisp-ms

From: Jari Arkko <[email-masked]>
Date: Mon, 22 Mar 2010 13:51:50 -0700

I have read this document and had a few comments:

In general, the document looks good and I have no major issues beyond 
the security mechanism.

Technical:

> 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.  In
> addition, a Map-Server will typically perform additional verification
> checks, such as matching any EID-prefix listed in a Map-Register
> message against a list of prefixes for which the ETR is known to be
> an authoritative source.

This seems weak in a number of ways. First, shouldn't there be some RFC 
2119 language that makes it clear exactly what aspects of this are 
required? This may also apply to other aspects of the document. Or are 
there other documents that have the normative specifications?

Second, I think we should at the very least require that the additional 
verification is mandatory. And it needs to be spelled out in more exact 
terms, not with "such as".

Third, the security considerations need to be clear about the security 
properties of this. What it can do and what it cannot do. In particular, 
if there is no additional verification then a local ETR can claim EID 
space that it does not own, and the Map-Server will happily distribute 
this to the world.

Fourth, personally I would prefer to see a mechanism that allowed global 
verification of EID ownership. I believe this would be almost as easy to 
implement and and far easier to deploy than the current security model. 
Perhaps something SIDR like.

> Note that Map-Server associations with ETRs
> should NOT use anycast addresses as doing so could cause
> unpredictable forwarding of Map-Requests to the ETRs.
>   

I do not understand this. If the Map-Servers are on an anycast address, 
how does this affect forwarding to the ETRs? The ETRs are still on 
unicast addresses...

> A key-chaining scheme may also be employed to facilitate
>    re-keying as needed.
>   
This is a weak statement. If we have a chaining scheme to point to, lets 
reference it and say it SHOULD/MUST be supported. If not, maybe we can 
just say "A key-chaining scheme may be developed in the future as an 
extension of this specification." If we say the latter, we should also 
document the implications in the security considerations section.

Missing things:

- Is there some discussion somewhere about propagating changes to 
mapping data. AFAICT, caching Map-Resolvers and ITRs both store data for 
some amount of time. Can a change be propagated to them, or is this 
something that is not necessary based on some assumptions about the 
dynamics of the network?

- Also, Map-Servers get updated with fresh information every minute. 
Perhaps the document should state that this puts a limit on how fast the 
information can change. Note that I'm not trying to argue that you 
should design the system for higher speed of change, I'm just asking for 
the characteristics of the design to be described.

- There should probably be an operational considerations section, to 
talk about things like configurable parameters.

- What issues do we expect the experiment to resolve? It would be good 
to document what implications of the design we do not currently fully 
understand.

Editorial:

The document would benefit from a more systematic description of what 
the different message types, encapsulation modes, and src/dst addresses 
are. I had trouble following what addresses each message has in all 
cases, for instance.

>    EID-to-RLOC mapping as that would introduce a circular dependancy.

dependency...

>    in a caching mode, where it saves information about oustanding Map-

outstanding...

>    Encapsulated Map-Reqeust to a matching ETR.  It does not otherwise
>    Reqeusts, originates new Map-Requests to the correct ETR(s), accepts

Request...

>       ETR, though static configuration or another out-of-band mechanism

through

> authoratative

authoritative?

> Encapsulated Map-Request:   a LISP Map-Request with an additional
> LISP header prepended.  Sent to UDP destination port 4342.  The
> "outer" addresses are globally-routeable IP addresses, also known
> as RLOCs.  Used by an ITR when sending to a Map-Resolver and by a
> Map-Server when sending to an ETR.
... when forwarding a MAP-Request to an ETR?

> provides better information about the set
>    of define EID prefixes.
... defined EID ...

RFC 2402 is a normative reference, but not used anywhere.

Jari

---

From: Vince Fuller <[email-masked]>
Date: Tue, 30 Mar 2010 12:41:15 -0700

Hi Jari-

Thanks for your review and comments on the LISP-MS draft. 

> terms, not with "such as".

The LISP authors have generally tried to err on the side of designing the
protocols to be deployable rather than mandating very high security. The
history of the IETF and of the Internet is littered with examples of
protocols that were designed with very strict security requirements that
rendered them undeployable or unusable in the real world. On the other hand,
protocols that initially offered little or no security (DNS, BGP, HTTP,
etc.) enjoyed successful, operational deployment and were later modifed to
incrementally add security mechanisms as needed.

For initial deployment, we believe it would be better to build something that
has relatively simple, common-sense security checks in place, experiment
with adding additional security measures, and use the results of that
experimentation to when it comes time to move LISP to the standards track.

The current implementation of the Map Server interface does support MS
verification of EID prefix registration and we do configure that today
on the pilot LISP network. I can certainly modify the existing document
text to encourage such a check but am uncomfortable mandating it for
experimental use of LISP.

As for RFC2119 langue - is it even appropriate to use that for an
experimental RFC? During the Routing Directorate review of the ALT
document, I had an exchange with John Scudder on this topic and wound
up removing all RFC2119 references and language from that document.

> space that it does not own, and the Map-Server will happily distribute 

If I modify the existing text to encourage prefix verification by the MS,
I will also state that failure to do so does create a vulnerability.

> Perhaps something SIDR like.

ALT, being BGP-based, is quite amenable to use of SIDR (once implementation
and infrastructure are widely available) and the ALT document specifically
mentions that ALT can use existing BGP-based security mechanisms. I'm not
averse to suggesting that the MS/MR infrastructure be similarly protected
and would welcome both suggested text and an idea of where you think it
belongs in the document.

> how does this affect forwarding to the ETRs? The ETRs are still on 

EID registration from an ETR to a Map Server needs to be deterministic. In
other worse, a specific ETR must know that it is registering to a specific
MS. Using an anycast address for the Map-Register packets would not be
deterministic. I can certainly adjust the existing text if this isn't
clear (and, as always, would welcome suggested improved text).

> document the implications in the security considerations section.

This is a good idea and I will add it to the next rev of the document.
Not being a security expert, though, I'm not really sure how the new text
in the security considerations section should read. Suggested text?

> something that is not necessary based on some assumptions about the 

There is no explicit "push" mechanism for propagating changes. Instead,
we rely on Map-Reply TTLs as a signal for how often ITRs should refresh
cached information.

The upcoming -07 version of the base LISP spec is expected to include
a new mapping entry versioning mechanism which will be used, in combination
with Solicit Map Request indication, to allow ITRs and PITRs to more
rapidly learn about invalid cache entries.

Note that our early experimentation with caching Map-Resolvers suggests
that they may be problematic for a number of reasons. That is one reason
why the current document is vague on the use of caching by a Map-Resolver:
it mentions the possibility but does not encourage it.

> the characteristics of the design to be described.

This is a good suggestion. The authors will need to mull it over a bit,
particularly given the pending changes to the LISP spec for versioning.

> talk about things like configurable parameters.

Good suggestion and something that we can hopefully add once we have a
little more operational experience with the pilot network.

> to document what implications of the design we do not currently fully 

Ultimately, we hope that the experiment will demonstrate that ID/locator
separation using LISP is both useful (it facilitates ubiquitous site
multihoming while at the same time improving the scalability of the
routing system, etc.) and feasible (the needed infrastructure can be built
and operated, etc.). I'm not sure how to better quantify this, though.
Can you offer suggested text?

> are. I had trouble following what addresses each message has in all 

We have chosen to document all of the message types, use of RLOC vs. EID
in packet headers, etc. in the base LISP specification, which is why it
is normative for all of the other LISP drafts. We feel that centralizing
those definitions in one place rather than spreading them throughout the
different components of LISP is more straightforward. The downside is, of
course, that reading and understanding the base spec is a prerequisite for
reading and understanding the others. Do you feel that this is not a valid
approach and that we should append certain material to all of the LISP
specs, perhaps as a new appendic to each? That would seem unweildy from a
change control point of view.

Thanks for catching all of the typos and other editorial issues - I have
fixed them all in the master copy of the next document revision.

	--Vince