[secdir] Security participation in the LISP WG appreciated

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

Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id D4C343A6CCC for <secdir@core3.amsl.com>; Wed, 12 Aug 2009 13:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.483
X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=1.257, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id y2Ik-hOauO7o for <secdir@core3.amsl.com>; Wed, 12 Aug 2009 13:22:21 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU []) by core3.amsl.com (Postfix) with ESMTP id D6B093A6B5E for <secdir@ietf.org>; Wed, 12 Aug 2009 13:22:20 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu []) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7CKLXmA028773 for <secdir@ietf.org>; Wed, 12 Aug 2009 16:21:33 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU []) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7CKLVq6028755 for <secdir@PCH.mit.edu>; Wed, 12 Aug 2009 16:21:31 -0400
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU []) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7CKLQee010034 for <secdir@mit.edu>; Wed, 12 Aug 2009 16:21:27 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (localhost []) by mit.edu (Spam Firewall) with ESMTP id 541EB1A9304D for <secdir@mit.edu>; Wed, 12 Aug 2009 16:21:26 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org []) by mit.edu with ESMTP id YQRK2jEA6FzIOud4 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for <secdir@mit.edu>; Wed, 12 Aug 2009 16:21:26 -0400 (EDT)
X-Barracuda-Envelope-From: hartmans@mit.edu
Received-SPF: softfail (mit.edu: domain of transitioning hartmans@mit.edu does not designate as permitted sender) receiver=mit.edu; client_ip=; envelope-from=hartmans@mit.edu;
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 41EBB51C6; Wed, 12 Aug 2009 16:21:22 -0400 (EDT)
To: secdir@MIT.EDU
From: Sam Hartman <hartmans-ietf@MIT.EDU>
Date: Wed, 12 Aug 2009 16:21:22 -0400
Message-ID: <tsly6pohjgd.fsf@mit.edu>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Sender: secdir-bounces@MIT.EDU
Errors-To: secdir-bounces@MIT.EDU
Subject: [secdir] Security participation in the LISP WG appreciated
X-BeenThere: secdir@ietf.org
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:21 -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

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

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


--- End Message ---
secdir mailing list