Subject: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism

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

Currently draft-ietf-lisp-ms describes the use of RFC 2402 H with MD5
preshared keys as the mandatory to implement mechanism between an ETR
and a map server .

This mechanism fails to meet IETF security requirements in the following ways:

 * RFC 4107 (a BCP) requires that in many cases automated key
   management be used. If that analysis is followed, it is clear that a number of LISP map servers will need to have automated key management so we must provide that.

* MD5 is probably not appropriate hash in  our usage as a new protocol.  Algorithm agility--the ability to change and negotiate hash algorithms is definitely required.

 * RFC 4301 moves AH from a MUST to MAY implement feature of IPsec.  Using ESP in null mode (no encryption) would be more correct if we use IPsec.
 * 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.

 * RFC 2401 and 2402 have been obsoleted by a new and somewhat different IPsec model.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 11 Aug 2009 16:26:37 -0400

Hi Sam,

> * RFC 2401 and 2402 have been obsoleted by a new and somewhat  

Where is the new model documented?

Thanks,
Margaret

---

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

Speaking very much as an individual.

I think the right way to secure ETR->MS is to use TLS over a TCP
connection.  I've heard the arguments about why IPsec and TLS are
inappropriate for BGP and I agree to a very large extent with these
arguments.

However I don't think they apply to a map server.  You definitely
should not time out a registration simply because a TCP connection
goes down, so the fake RST issue will be hugely less of a big deal
than with BGP.

If you still care about RST issues, then use TCP AO+TLS keyed by the
TLS extractor.

Using TLS does not imply several things:

* It does not imply a PKI: self-signed certificates or even preshared keys can be used.

* It does not imply encrypting everything: TLS supports integrity only mode.

* You can implement TLS on a router. You probably already do.

I may have missed something that makes TLS inappropriate but if I have
it's something relatively non-obvious; a message of the form "this is
a non starter," will be remarkably unconvincing.

---

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

> inappropriate for BGP and I agree to a very large extent with these

And what are the reasons you think TLS over TCP is inappropriate for  
BGP?

Don't forget the map-server must support up to 1000s of registered  
sites. We chose a soft state solution so it can scale.

Dino

---

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

> sites. We chose a soft state solution so it can scale.

How are you planning to pre-share keys between 1000s of registered  
sites?  And, when keys need to be updated, how are you planning to  
send new keys to all of them?

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Aug 2009 14:20:15 -0700

>> And what are the reasons you think TLS over TCP is inappropriate  
>> for BGP?
>>

You configure them on each side. You do it at the same time on the map- 
server when you configure an EID-prefix and locator-set for the site.  
On the ETR side, you configure the key when you configure the address  
of the map-server.

Dino

---

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

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:

    Margaret> Hi Sam,

> * RFC 2401 and 2402 have been obsoleted by a new and somewhat

    Margaret> Where is the new model documented?

RFC 4301.

---

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

Sam,
> preshared keys as the mandatory to implement mechanism between an ETR

I agree with you that this is unlikely to be the best standardised
solution to authenticate the exchange between an ETR and a map server.
However, as for issue #3, I think that we should first define whether we
consider that LISP should work correctly even if there is
- an on-path attack
- only off-path attacks

Once we have decided the capabilities of our target attacker, then we
can discuss the mechanisms that need to be used to counter such attackers.

Olivier

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Aug 2009 23:20:22 -0400

>>>>> "Olivier" == Olivier Bonaventure <[email-masked]> writes:

    Olivier> Sam,
    >> 
    >> Currently draft-ietf-lisp-ms describes the use of RFC 2402 H
    >> with MD5 preshared keys as the mandatory to implement mechanism
    >> between an ETR and a map server .

    Olivier> I agree with you that this is unlikely to be the best
    Olivier> standardised solution to authenticate the exchange
    Olivier> between an ETR and a map server.  However, as for issue
    Olivier> #3, I think that we should first define whether we
    Olivier> consider that LISP should work correctly even if there is
    Olivier> - an on-path attack - only off-path attacks

    Olivier> Once we have decided the capabilities of our target
    Olivier> attacker, then we can discuss the mechanisms that need to
    Olivier> be used to counter such attackers.

I can see your point for #3.  However for #2, I disagree, because what
we have is very clearly not good enough to get published in the IETF
at all.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Aug 2009 06:30:55 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    >> I think the right way to secure ETR->MS is to use TLS over a
    >> TCP connection.  I've heard the arguments about why IPsec and
    >> TLS are inappropriate for BGP and I agree to a very large
    >> extent with these arguments.

    Dino> And what are the reasons you think TLS over TCP is
    Dino> inappropriate for BGP?

1) in BGP, having a connection torn down has significant effects; TLS alone does not protect against connection resets
2) Architecturally on deployed routers implementing TLS would be tricky without exposing the control plane processor to DOS concerns.
3) It would be a significant implementation change to decouple the transport and session states for BGP

The deployment model of a map server looks a lot more like the TLS
deployment model we have highly optimized in hardware: the map server
talks to a large number of clients (ETRs) each of which talks to one
or a small number of map servers.

    Dino> Don't forget the map-server must support up to 1000s of
    Dino> registered sites. We chose a soft state solution so it can

Yes.  This is one of the main reasons I suggest TLS: it has proven
scaling to this size and hardware acceleration is easily available.
Honestly, I'm not sure you'd need it for the work loads you're talking
about, although it might be desirable if you had thousands of ETRs all
cold-starting against a map server with no state.

I'm not going to say much more on TLS; I need to preserve my ability
to judge consensus on this issue and don't want to get too involved in
advocating a specific solution.

Here are some other solutions that would almost certainly be able to
meet your needs:

* DTLS+UDP -- used by capwap

If you dislike TCP, you can do this.  It will be more
complicated to specify than TLS over TCP, and I don't see what it buys
you since I think both solutions scale to more than you care about.

As mentioned, CAPWAP is the best example of this.

* DTLS +extractor for a MAC in a packet

Use the DTLS initial exchange to set up keys that you then use for
some per-packet MAC. Significantly more complicated to specify than
the above, although perhaps not as bad as IPsec (although perhaps
worse).  The benefit is that you don't need DTLS wrapping on each
packet; the disadvantage is that it performs the same, is more
complicated to analyze, and may be more difficult to code.

I think that SRTP's use of DTLS is similar enough to this to count as
a success story.

* IPsec (IKEV2 + esp null)

May interact poorly with other uses of IPsec on the same device.
Fairly difficult to standardize; there are a lot of tricky bits to
specify.  May end up involving more state than TLS between the PAD
entry, the SPD entry, and the SAD entry.

I can't think of any success stories with this approach.  OSPF V3 does
this, but I think both the security community and the routing
community were vaguely unhappy with the results.

* Kerberos

You could do this; it would work fine although it would be an unusual
application of Kerberos.  Kerberos doesn't typically have hardware
acceleration available.  For this application that's probably not a
show stopper, although I suspect a lot of people on this list would
feel more comfortable adopting a technology with hardware
acceleration.  This would actually involve very little state on the
map server, although it would involve a Kerberos KDC somewhere.
That's stateless (except for the configuration of the principal
database) too, although seems like a lot of unneeded complexity for
this application.  It would be easy to specify.

I include this only for completeness.

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 12 Aug 2009 10:30:05 +0200

Sam,
> we have is very clearly not good enough to get published in the IETF

I agree that RFC2402 H with MD5 preshared keys is not a good solution
and should be removed from the draft. However, it is too early to
discuss a particular security mechanism. The ETR-MS segment is not the
most problematic segment from a security viewpoint.

Olivier

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Aug 2009 09:39:14 -0700

The solution works and is simple. We have been using it for a while.

We are doing experiments. The LISP working group is chartered for  
experimental RFC, so we don't have to dot the Is and cross the Ts at  
this point in time.

Please, oh please. Let's keep this working group practical.

Dino

On Aug 12, 2009, at 1:30 AM, Olivier Bonaventure wrote:

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Aug 2009 12:45:41 -0400

I think Sam has a fair concern here.

If you wanted to claim "this is an experiment, no one will attack it, so 
we are not securing any of the links" then we could have something to 
discuss.  (I think folks would aruge that doing a decent job is 
definable and deployable, but we could have the discussion.)

But, to say "yes, we need some security" and then adopt something that 
is known to be too weak, and not designed to let you experiment with 
other approaches (you mandate a specific mechanism), is difficult to defend.

Practical is important.  But it does not justify making bad security 
choices.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Aug 2009 09:49:07 -0700

> Practical is important.  But it does not justify making bad security  

The way we do MD5 or SHA-* authentication with the AH header for Map- 
Registers is not a bad security choice.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Aug 2009 09:57:55 -0700

> community were vaguely unhappy with the results.

Well I am happy with the results we have on our test LISP network. It  
is:

(1) Easy to configure
(2) Stateless
(3) No overhead (i.e. no TCP connections to keep up)
(4) Easy to rekey at any point.
(5) No chit-chat before getting the data you need to get from the ETR  
to the map-server.

That is, using HMACs transmitted in AH headers. It is simple and it  
works. We have running code that proves it. There is no reason to  
change it. We need to focus on other more important issues with LISP.

Dino