Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8

Stephen Kent <kent@bbn.com> Tue, 25 August 2009 02:10 UTC

Return-Path: <kent@bbn.com>
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 6D4693A6E5A; Mon, 24 Aug 2009 19:10:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.389
X-Spam-Level:
X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
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 eFdfmp7szVG6; Mon, 24 Aug 2009 19:10:24 -0700 (PDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A7D643A6963; Mon, 24 Aug 2009 19:10:24 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[169.223.4.160]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1MfkYN-0006Eg-Fo; Mon, 24 Aug 2009 21:10:28 -0400
Mime-Version: 1.0
Message-Id: <p06240808c6b8f2972618@[169.223.4.160]>
In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841CCF748F@XCH-NW-CCR1V.nw.nos.boeing.com>
References: <tsl8whdqw9y.fsf@mit.edu> <2557049CDBC35B4EBD79CFACFEC045841CCF748F@XCH-NW-CCR1V.nw.nos.boeing.com>
Date: Mon, 24 Aug 2009 22:10:28 -0400
To: "Davis, Terry L" <terry.l.davis@boeing.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "mext-chairs@tools.ietf.org" <mext-chairs@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, 'Sam Hartman' <hartmans-ietf@mit.edu>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-mext-aero-reqs@tools.ietf.org" <draft-ietf-mext-aero-reqs@tools.ietf.org>, "weddy@grc.nasa.gov" <weddy@grc.nasa.gov>, "'Ivancic, William D. (GRC-RHN0)'" <william.d.ivancic@nasa.gov>
Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8
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: Tue, 25 Aug 2009 02:10:25 -0000

At 3:48 PM -0700 8/21/09, Davis, Terry L wrote:
>Sam
>
>One of the items that continues to seriously concern me across the 
>whole IP protocol RFC set is the basic lack of simple 
>vendor-to-vendor IP security interoperability!  All of NEMO and MEXT 
>assumes that simple, easy to implement, IPSec, PKI, and IKE 
>interoperability exist; they do NOT.

Terry,

IPsec (not IPSec :-)) and IKE have been available in major host 
operating systems for a few years, so the phrase "easy to implement" 
is not generally a true assertion.  Are you stating that the aviation 
industry needs to implement its own versions of these and analogous 
Interent protocols? Also, as for interoperability, I believe Paul 
Hoffman has reported a number of good results through his VPNC 
testing experiences.

As for PKI, there are relying party implementations in all browsers, 
and in some OSes, and OpenSSL.  The browsers interoperate with web 
servers (using SSL) developed by a few different vendors, which is a 
decent demo of interoperability for core PKI features. OpenCA and 
OpenSSL are decent (not perfect) examples of open source software for 
both RP and CA functions.

Later you seem to be arguing that a single PKI (vs. IETF PKI and 
IPsec/IKE standards) is an essential feature for IPsec solutions. 
This is clearly not true in general. Is this another situation where 
aviation is "special?"

I will not disagree with your assertion that many of the Ipsec/IKE 
and PKI products have hard to configure admin interfaces. But, that 
is an issue outside the scope of IETF standards. Also, I would 
observe that the typical CLI for a router is not an easy to use 
interface either.


Steve