[secdir] Security participation in the LISP WG appreciated

Sam Hartman <hartmans-ietf@mit.edu> Wed, 12 August 2009 20:22 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDC828C0EA for <secdir@core3.amsl.com>; Wed, 12 Aug 2009 13:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.279
X-Spam-Level:
X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id navDG3pWG1eL for <secdir@core3.amsl.com>; Wed, 12 Aug 2009 13:22:29 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 6904D28C0E1 for <secdir@ietf.org>; Wed, 12 Aug 2009 13:22:29 -0700 (PDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A2C8E51C6; Wed, 12 Aug 2009 16:21:55 -0400 (EDT)
To: secdir@ietf.org
From: Sam Hartman <hartmans-ietf@mit.edu>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Date: Wed, 12 Aug 2009 16:21:55 -0400
Message-ID: <tslws58hjfg.fsf@mit.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Subject: [secdir] Security participation in the LISP WG appreciated
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2009 20:22:30 -0000


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.



--- Begin Message ---
> * 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


--- End Message ---