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

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Aug 2009 16:25:06 -0400

Currently, the interface between the ITR and map resolver has two
security concerns.

 * There is no integrity protection of the exchange between the ITR and map resolver

 * An ITR accepts a reply from any ETR, which makes it hard to add security.

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.  It will be impossible to provide protection against on-path
attackers who can observe the nonce unless cryptographic security is
used.  I understand that the alt does not currently provide
cryptographic security.  I don't know whether we'll conclude that is
adequate (although suspect we'll decide it's the best we can do for
the experimental version).  However even if that is adequate, it seems
like in many deployments the path between the ITR and map resolver is
more open to attack than the path over the alt.  For this reason I
suspect that cryptographic security is needed to the map resolver even
if it is not provided in the alt.

If others disagree, I'm happy to hold this issue open until we've
actually done security analysis of the ITR map resolver security.  I'm
not comfortable closing this issue before that analysis.

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.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Aug 2009 13:32:22 -0700

> not comfortable closing this issue before that analysis.

I disagree of course. If we build all this machinery, what you might  
be suggesting, into these protocols, they will never get deployed.

The LISP authors have stated that man-in-the-middle attacks on  
infrastructure components are unlikely to occur so we believe they are  
not problems. We made a judgement call so we can actually build a  
usable architecture that can be deployed quickly and soon.

> resolver, it must meet the same requirements as security between the

Where is the cryptographic security between a host and a DNS resolver?

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Aug 2009 16:53:29 -0400

Actually, Dino's last note (which I suspect he meant satirically) does 
suggest a different path.  If we can use an SIDR-like approach to secure 
the origin information, this would seem to lead us to a simpler solution 
to use.  If there are appropriate ROAs, and if the leaf ROAs point to 
the right thing, then with a slight variation we ought to be able to end 
up with a signable piece of information provided by the ETR into the 
system.  (If someone can masquerade / intercept / pretend to be the MS 
and prevent the information from making its way into the system, they 
can probably do so even if there is more security in place.)
Corrspondingly, the ITR does not need to know if it really reached the 
right MS, as long as it gets validly signed answers.

Yes, there are a LOT more details needed.
But that path avoids our needing to authenticate yet more pieces.  And 
that path is needed anyway to get a meaningful security level on the system.

Yours,
Joel

Dino Farinacci wrote:
> I disagree of course. If we build all this machinery, what you might be 
> suggesting, into these protocols, they will never get deployed.
> 
> not problems. We made a judgement call so we can actually build a usable 
> architecture that can be deployed quickly and soon.
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 11 Aug 2009 17:05:41 -0400

> be suggesting, into these protocols, they will never get deployed.

I don't have enough knowledge of the alternatives to know if TLS is  
the best choice for securing LISP, but the IETF requires strong  
security with algorithm agility and automatic keying as a "must  
implement" in all IETF protocols.  So, I do know that IPsec AH with  
manual shared keys won't cut it...
> infrastructure components are unlikely to occur so we believe they  
> are not problems. We made a judgement call so we can actually build  
> a usable architecture that can be deployed quickly and soon.

I'm sorry but "the LISP authors have stated" is not enough of an  
explanation for me to understand why man-in-the-middle attacks on  
infrastructure components are unlikely...  Is there some compelling  
data or a sound argument to support this assertion?

> Where is the cryptographic security between a host and a DNS resolver?

The DNS has been identified as a major security concern for the  
Internet, and a massive effort is underway to deploy DNSSec to secure  
the DNS.  I don't think we want to use the DNS as a model for the  
level of security required for a newly-defined RLOC-to-EID mapping  
system.

Personally, I believe that including real security in the LISP  
specification, at a level that would allow standardization in the  
IETF, is important.  We might be able to get away with something less  
on the basis that this is an "experimental protocol", but I'm afraid  
that would significantly lower the value of the experimental results,  
especially in the areas of performance and scalability.

Margaret

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 11 Aug 2009 23:39:44 +0200

Sam,
>  * An ITR accepts a reply from any ETR, which makes it hard to add security.
...
> not comfortable closing this issue before that analysis.

I think that this kind of discussion cannot start before we agree on the
type of security attacks that LISP must avoid. For example, I'm not
convinced that we need to counter on-path attacks with LISP. However,
LISP should probably not be vulnerable to off-path attacks, including
those with spooffed packets.

Olivier
-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium