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

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

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.

In aviation we do not have the luxury that Enterprise or Entity organizations have in being able to deploy "single vendor" solutions!  In the aviation space, if someone made one, aviation will have it somewhere in our infrastructure and we need to interoperate with it as our aircraft operate in a truly heterogeneous global space.  An aircraft in flight will usually 1 to 4 open communications links and these will be continuously changing as we hand off between communication providers and "Navigation Service Providers" who utilize entirely different vendors and PKIs.  

Nor can we have a "single PKI" global solution; nation/state laws preclude this in many cases as they reasonably require credentials that they control for authentication in their territory and bridge assurances, although fine for business level relationships, may reasonably not meet nation/state requirements for operations within their nation.

I continue to state that the lack of easy to use/configure vendor interoperability parameters for our basic IP security protocol associations is a major failure in of Internet architectures.  It cannot require a senior network engineer, a senior PKI analyst, and dozens of Wireshark traces to establish a secure link!  Entry level engineers/analysts and techs need to be able to perform this function as we do with basic network (DHCP) connectivity.  We need a "dynamic security association protocol" like DHCP for industries like aviation (and most the CI sectors too!).  

To me, this lack of a simple, easy to use, interoperability security association configuration is one of our most pressing issues in our efforts to establish "cyber space security" regardless of what CI sector we are looking at.

Take care
Terry

PS: I might also remind the IETF that DHCP came from commerical industry development not communications or academia.

> -----Original Message-----
> From: Sam Hartman [mailto:[e-mail]]
> Sent: Friday, August 21, 2009 3:47 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: secdir review of draft-ietf-mext-aero-reqs8
> 
> 
> 
> This is a security directorate review; editors should treat these
> comments as any other last call comments.
> 
> Sorry that the review is late.  I read the draft, prepared my comments
> and failed to send them out.
> 
> This draft describes requirements from the air and space communities
> for nemo route optimization for aircraft and spacecraft.
> 
> Within that scope, I have no additional security concerns.
> 
> However it is important to make sure that everyone involved
> understands meeting these requirements alone without more general
> security requirements would not produce an acceptable solution.  If
> the intent of this draft is to state all the requirements that mext
> needs to consider in developing a solution that meets IETF standards
> and that meets the needs of the air/space community, then it falls
> significantly short.  I don't think that is the intent though; I think
> this is simply intended to be one stakeholder's input.  Presumably,
> even if we are only targeting deployment in air/space enviroments, we
> will look at more general security and management requirements
> necessary to make the technology deployable on the internet.  If we're
> all on the same page on that point, then this draft is fine.
> 
> I think the stated requirements seem reasonable.  However, I'm not
> actually sure that a solution exists as an extension to current basic
> nemo.  In particular, requirements about minimizing or avoiding custom
> software may rule out nemo.  However, perhaps I'm missing something.