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

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Aug 2009 16:21:22 -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

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Aug 2009 13:50:38 -0400

Sam,

Since the current generation of IPsec specs recommends ESP-NULL over 
AH, any reference to 2402 is very questionable for any new WG 
document, e.g., LISP documents. Also, MD5 is not an algorithm that I 
think most SECDIR folks would recommend at this point in  time. What 
motivates this retro security fetish?

Also, what does "static" AH mean re authentication data, key lifetime, etc.?

I am not volunteering to enter the LIPS WG debate. However, I will 
volunteer to review and comment on LISP documents when they come up 
for IETF LC. The security ADs may choose to pay attention to such 
comments, which might result in a DISCUSS at that stage. Presumably 
the authors would like to avoid that :-).

Steve

---

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Aug 2009 14:54:56 -0400

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

    Stephen> Sam, Since the current generation of IPsec specs
    Stephen> recommends ESP-NULL over AH, any reference to 2402 is
    Stephen> very questionable for any new WG document, e.g., LISP
    Stephen> documents. Also, MD5 is not an algorithm that I think
    Stephen> most SECDIR folks would recommend at this point in
    Stephen> time. What motivates this retro security fetish?

I think what's going on here is that there is a lack of familiarity
with security protocols or some of the thinking about IPsec in the
last 10 years that is built into 4301.

I suspect that the people designing this protocol were familiar with
the tcp-md5 option and picked something that had the closest wire
format to that but ran over UDP without really doing much design or
requirements work.

They don't understand why they need something more complicated than
that.  "Because if you don't, you won't get anything published," is
probably a true statement--I know I'd never send in a publication
request for the current document, and I'll be the chair who reviews
it.

However that approach really frustrates people.  It's far better to
educate them about what the security issues are and what the technical
justification is for a quality security mechanism.  Obviously, I can
help with that.  However we're having similar issues on MTU handling,
transport considerations, middlebox considerations, extensibility,etc.
In short, we're taking a neat protocol idea that works in limited
situations and refining it for the whole Internet.  So, I have my
hands full with the chair role and can't take on the security
education role as well.