Subject: Re: [lisp] [#3] lisp-ms needs security between ITR and map resolver

From: [email-masked] (Noel Chiappa)
Date: Tue, 11 Aug 2009 17:06:00 -0400 (EDT)

> From: Dino Farinacci <[email-masked]>

    > If we build all this machinery, what you might be suggesting, into
    > these protocols, they will never get deployed.
    > ...
    > We made a judgement call so we can actually build a usable architecture
    > that can be deployed quickly and soon.

I basically agree with you, with one tiny potential difference: I'd like to
see the right hooks (i.e. packet fields) added now, for things we are going
to need eventually, even if we don't actually use them now (e.g. insert as
AuthType '1 = No Authentication').

I know that may sound kind of silly, but it avoids having to i) rev the
protocol, ii) design interoperability mechanisms between different protocol
revs so that deployed base can talk to new stuff, etc, on down the road.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 11 Aug 2009 16:55:47 -0400 (EDT)

> From: Sam Hartman <[email-masked]>

    > The only protection of the map reply is that it needs to have the same
    > nonce as the map request. Long term, that is unlikely to be good
    > enough.

Sure, but in the short term, it's no worse than most DNS lookups are today
(and maybe better, since it does require on-path visibility into the
packets). Acceptable for an experiment; something we should fix in the long
run.

Someone had a proposal to add some authentication stuff in the Request/Reply
packets, which I basically agree with - the Request/Reply packet format
should include the right fields to authenticate mapping entries, even if they
are blank during the experimental phase.

(Note: I am not talking about node-node security, on a hop-by-hop basis - I
am talking about authentication of _mapping entries_, which stays with them
from the time the mapping is created, until it gets to the ultimate consumer.
Then of course there's a whole key-distribution thing to deal with, but
that's a separate nightmare.)

    > I understand that the alt does not currently provide cryptographic
    > security.	

Right, and the ALT itself might be replaced in toto at some point.

    > If cryptographic security is provided between the ITR and map resolver,
    > it must meet the same requirements as security between the ETR and map
    > server.

I'm uncomfortable having link-based security (i.e. "between the ITR and map
resolver", or "between the ETR and map server"). I'd rather secure the
mappings 'at birth', and distribute the authentication along with the
mapping. That way, nobody has to trust any entities between the i) ultimate
creator of the mapping, and ii) the ultimate consumer. Also, a break-in to
any intermediate node cannot compromise the mapping either. (Yeah, you can
DoS, but that's a given for any break-in.)

	Noel