Subject: [secdir] Security participation in the LISP WG appreciated

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

I'm chairing LISP.  I opened an issue
(http://trac.tools.ietf.org/wg/lisp/trac/ticket/2 ) that one of our
existing security mechanisms doesn't meet IETF security requirements.
I suggested TLS over TCP as a good fit for what I think we're trying
to do, but enumerated a number of other solutions that will also meet
reasonable security requirements.

The editors of the spec continue to believe that statically configured
RFC 2402 AH with md5 is a good solution for a mechanism that needs to
scale to thousands of peers.
Here is the reply below.

I think having some additional participation in the discussion would
be useful.  Participants need to be able to work without a written
threat model or well defined security analysis.  Yes, some of that
will come by the time we're all done--some of our work is even
blocking on it.  However it's not there now, and it would be
disasterous to wait until all that work is done before starting to
look at mechanisms.

Forming consensus to change the documents in this group proves fairly
challenging.

Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism
From: Dino Farinacci <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Date: Wed, 12 Aug 2009 09:57:55 -0700

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

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