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

Sam Hartman <> Thu, 13 August 2009 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E1C728C197 for <>; Thu, 13 Aug 2009 11:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mn2GRcFz+14x for <>; Thu, 13 Aug 2009 11:55:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D6AB528C14E for <>; Thu, 13 Aug 2009 11:54:58 -0700 (PDT)
Received: by (Postfix, from userid 8042) id 011FF641DA; Thu, 13 Aug 2009 14:54:56 -0400 (EDT)
To: Stephen Kent <>
References: <> <p0624080ec6aa00f744ce@[]>
From: Sam Hartman <>
Date: Thu, 13 Aug 2009 14:54:56 -0400
In-Reply-To: <p0624080ec6aa00f744ce@[]> (Stephen Kent's message of "Thu\, 13 Aug 2009 13\:50\:38 -0400")
Message-ID: <>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Sam Hartman <hartmans-ietf@MIT.EDU>,
Subject: Re: [secdir] Security participation in the LISP WG appreciated
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Aug 2009 18:55:02 -0000

>>>>> "Stephen" == Stephen Kent <> 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

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.