Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8
Sam Hartman <hartmans-ietf@mit.edu> Sat, 22 August 2009 01:40 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 D823E3A68BE; Fri, 21 Aug 2009 18:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.154
X-Spam-Level:
X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 VrPlauMZx5C2; Fri, 21 Aug 2009 18:40:36 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 110093A6B73; Fri, 21 Aug 2009 18:40:35 -0700 (PDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 391FB64631; Fri, 21 Aug 2009 21:40:40 -0400 (EDT)
To: "Davis, Terry L" <terry.l.davis@boeing.com>
References: <tsl8whdqw9y.fsf@mit.edu> <2557049CDBC35B4EBD79CFACFEC045841CCF748F@XCH-NW-CCR1V.nw.nos.boeing.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Fri, 21 Aug 2009 21:40:40 -0400
In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841CCF748F@XCH-NW-CCR1V.nw.nos.boeing.com> (Terry L. Davis's message of "Fri\, 21 Aug 2009 15\:48\:55 -0700")
Message-ID: <tsl4os0lj6v.fsf@mit.edu>
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: "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: Sat, 22 Aug 2009 01:40:36 -0000
>>>>> "Davis," == Davis, Terry L <terry.l.davis@boeing.com> writes: Davis,> Sam One of the items that continues to seriously concern Davis,> me across the whole IP protocol RFC set is the basic lack Davis,> of simple vendor-to-vendor IP security interoperability! Davis,> All of NEMO and MEXT assumes that simple, easy to Davis,> implement, IPSec, PKI, and IKE interoperability exist; Davis,> they do NOT. With you so far. Davis,> In aviation we do not have the luxury that Enterprise or Davis,> Entity organizations have in being able to deploy "single Davis,> vendor" solutions! In the aviation space, if someone made Davis,> one, aviation will have it somewhere in our infrastructure Davis,> and we need to interoperate with it as our aircraft Davis,> operate in a truly heterogeneous global space. An Davis,> aircraft in flight will usually 1 to 4 open communications Davis,> links and these will be continuously changing as we hand Davis,> off between communication providers and "Navigation Davis,> Service Providers" who utilize entirely different vendors Davis,> and PKIs. I think the rest of the world is much more similar to this than you believe. Davis,> Nor can we have a "single PKI" global solution; Davis,> nation/state laws preclude this in many cases as they Davis,> reasonably require credentials that they control for Davis,> authentication in their territory and bridge assurances, Davis,> although fine for business level relationships, may Davis,> reasonably not meet nation/state requirements for Davis,> operations within their nation. Davis,> I continue to state that the lack of easy to use/configure Davis,> vendor interoperability parameters for our basic IP Davis,> security protocol associations is a major failure in of Davis,> Internet architectures. It cannot require a senior Davis,> network engineer, a senior PKI analyst, and dozens of Davis,> Wireshark traces to establish a secure link! Entry level Davis,> engineers/analysts and techs need to be able to perform Davis,> this function as we do with basic network (DHCP) Davis,> connectivity. We need a "dynamic security association Davis,> protocol" like DHCP for industries like aviation (and most Davis,> the CI sectors too!). Davis,> To me, this lack of a simple, easy to use, Davis,> interoperability security association configuration is one Davis,> of our most pressing issues in our efforts to establish Davis,> "cyber space security" regardless of what CI sector we are Davis,> looking at. I think I'm in general agreement with you. However I don't see how any of this applies to my comments--unless possibly you are saying that the draft needs to be expanded with additional security requirements.
- [secdir] secdir review of draft-ietf-mext-aero-re… Sam Hartman
- Re: [secdir] secdir review of draft-ietf-mext-aer… Sam Hartman
- Re: [secdir] secdir review of draft-ietf-mext-aer… Davis, Terry L
- Re: [secdir] secdir review of draft-ietf-mext-aer… Jari Arkko
- Re: [secdir] secdir review of draft-ietf-mext-aer… Sam Hartman
- Re: [secdir] secdir review of draft-ietf-mext-aer… Davis, Terry L
- Re: [secdir] secdir review of draft-ietf-mext-aer… Stephen Kent
- Re: [secdir] secdir review of draft-ietf-mext-aer… Davis, Terry L