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.