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

From: Jari Arkko <[email-masked]>
Date: Mon, 07 Sep 2009 23:19:03 +0300

Sam,

I'm reading the mails about security issues, and wanted to reply. I hope 
I have not missed some later mails or a re-opening an already closed 
issue. In any case, you wrote:

>  * IPSec is not a good fit for this application.  If we're going to use IPsec we need to follow the recommendations of the BCP for using IPsec in other protocols.  That includes things like specifying what SPD entries are expected  and fitting our use of IPsec to RFC 2401.

I agree, and see further below about my response to Noel.

> 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.

Not sure about this though. I think the debate about using 
nothing-vs-nonce-vs-ipsec-vs-tls is too early. First we have to figure 
out what the security model is. And frankly I'm not sure we have a good 
idea about that yet, but maybe I'm missing something. If -- as Noel 
suggests below -- the mapping data itself is protected, then the map 
request/reply protection has far less to do, and a nonce is likely 
sufficient to handle DoS attacks.

Also, Noel wrote:
> 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.

This is my preference as well. I'd like to see a security model that is 
based on protecting the data rather than the communications. This will 
also make it easier to distribute, cache, and re-distribute mapping 
information.

And Olivier wrote:
> 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.
>   
I agree, but I would add that mere on/off path designation is probably 
too simple basis for the analysis. For instance, a control protocol 
between an ITR and ETR to set up packet forwarding between the two is 
probably OK even if it is vulnerable to on-path attacks. Once the data 
packets are flowing you'll be vulnerable to on-path attacks anyway. But 
I tend to think of the mapping system as a more valuable, centralized 
resource that needs to be guarded more carefully. And the mapping system 
is a new component, so if we introduce a vulnerability there then you 
have an issue with either the source to destination e2e path OR the 
source ITR to mapping system path. These reasons lead me to believe that 
on-path attacks may not be OK for the mapping system.

Jari

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 7 Sep 2009 16:40:08 -0400

On Sep 7, 2009, at 4:19 PM, Jari Arkko wrote:
>
> Not sure about this though. I think the debate about using nothing- 
> vs-nonce-vs-ipsec-vs-tls is too early. First we have to figure out  
> what the security model is. And frankly I'm not sure we have a good  

When you say "the data itself is protected", I _think_ you mean  
something different than Noel does.

Noel is saying that the mechanism for adding mapping entries to the  
mapping system is protected.  This is currently true by virtue of the  
fact that mapping registrations use IPsec AH, and nothing will be  
added to the mapping system that isn't properly authorized.

However, the data that is passed in a mapping reply is not  
"protected".  An ITR sends a mapping request to its mapping server.   
The response will come back from another node (an ETR), and will  
contain data that is not encrypted and cannot be authenticated.  The  
only "protection" on the response is that it contains a 32-bit nonce  
that matches the request.  So, anyone who can see the request (or  
guess its contents) can send a spoofed response that will be accepted  
by the requesting ITR.  Even if two replies are received (one valid  
and one spoofed), the ITR will have no means to tell the difference  
between them.

> This is my preference as well. I'd like to see a security model that  
> is based on protecting the data rather than the communications. This  
> will also make it easier to distribute, cache, and re-distribute  
> mapping information.

I think this is a good general approach, but there is nothing in the  
current protocol that does this.

> I agree, but I would add that mere on/off path designation is  
> probably too simple basis for the analysis. For instance, a control  
> protocol between an ITR and ETR to set up packet forwarding between  
> the two is probably OK even if it is vulnerable to on-path attacks.  
> Once the data packets are flowing you'll be vulnerable to on-path  
> attacks anyway. But I tend to think of the mapping system as a more  
> valuable, centralized resource that needs to be guarded more  
> carefully. And the mapping system is a new component, so if we  
> introduce a vulnerability there then you have an issue with either  
> the source to destination e2e path OR the source ITR to mapping  
> system path. These reasons lead me to believe that on-path attacks  
> may not be OK for the mapping system.

I agree.  I think that it should be possible for an ITR to somehow  
authenticate the mapping data it receives in a mapping request.   
Something similar to the level of security provided by DNSSEC would be  
appropriate, in my opinion.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Sep 2009 18:47:11 -0400

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:

    Jari> Not sure about this though. I think the debate about using
    Jari> nothing-vs-nonce-vs-ipsec-vs-tls is too early. First we have
    Jari> to figure out what the security model is. And frankly I'm
    Jari> not sure we have a good idea about that yet, but maybe I'm
    Jari> missing something. If -- as Noel suggests below -- the
    Jari> mapping data itself is protected, then the map request/reply
    Jari> protection has far less to do, and a nonce is likely
    Jari> sufficient to handle DoS attacks.

I agree it's really too early to be having this discussion.  I brought
it up because it was on my mind if it didn't get written down I'd
forget it.

My suspicion is that we'll end up divinding the security into three legs:

* ITR to map resolver
* inside the mapping system
* map server to ETR.

My suspicion is that each mapping system will have its own internal
security model.  For example, ALT probably ends up using something
similar to SIDR internally.  Some mapping system based on DHTs and
cryptographically generated prefixes would not benefit from something
like SIDR at all.

In addition, I'm not sure that all ITRs will be in the position to
have the CRLs, trust anchors, trust anchor updates and intermediate
certificates necessary to verify mappings. So, it might be better to
have a simpler trust relationship between an ITR and its map resolver
and to have the map resolver do the heavy lifting for security.

Also, before we have real security in the map system--while the map
system security looks a lot like current core BGP security--then the
link between the ITR and map resolver looks a lot more attractive as a
target.  It may well run over access networks or other relatively low
security links.  We may be able to assure that the alt runs mostly or
completely in the core.q So, before there is real mapping security
within the alt, we may get significant benefit from security the
ITR->map resolver link.

However, as you point out, it's too early for this discussion.  Also,
the above assumes some significant changes to the ITR<->map resolver
protocol.  I believe those changes are needed for other reasons.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 08 Sep 2009 07:19:03 +0300

Margaret,

> something different than Noel does.

OK, I didn't realize that.

> "protected". An ITR sends a mapping request to its mapping server. The 
> response will come back from another node (an ETR), and will contain 
> data that is not encrypted and cannot be authenticated. The only 
> "protection" on the response is that it contains a 32-bit nonce that 
> matches the request. So, anyone who can see the request (or guess its 
> contents) can send a spoofed response that will be accepted by the 
> requesting ITR. Even if two replies are received (one valid and one 
> spoofed), the ITR will have no means to tell the difference between them.
>
>>

Yes, I realized this. I was making a statement on what I would 
personally like to see as the security function.

Jari