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

["Davis, Terry L" <[e-mail]>]

Sam

My point was:
- With the current extreme level of effort required to obtain interoperability between different vendors' implementations of the various IP security protocols, I don't see we can implement the security recommendations in the draft in our continuously changing communication's environment.

Take care
Terry

> -----Original Message-----
> From: Sam Hartman [mailto:[e-mail]]
> Sent: Friday, August 21, 2009 6:41 PM
> To: Davis, Terry L
> Cc: 'Sam Hartman'; [e-mail]; [e-mail]; 'Ivancic, William D.
> (GRC-RHN0)'; [e-mail]; [e-mail]; draft-ietf-
> [e-mail]
> Subject: Re: secdir review of draft-ietf-mext-aero-reqs8
> 
> >>>>> "Davis," == Davis, Terry L <[e-mail]> 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.