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

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Aug 2009 06:46:49 -0400

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.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Aug 2009 21:40:40 -0400

>>>>> "Davis," == Davis, Terry L <[email-masked]> 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.

---

From: "Davis, Terry L" <[email-masked]>
Date: Fri, 21 Aug 2009 15:48:55 -0700

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:[email-masked]]
> Sent: Friday, August 21, 2009 3:47 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: secdir review of draft-ietf-mext-aero-reqs8
> 
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 Aug 2009 13:48:35 +0300

> all on the same page on that point, then this draft is fine.

You raise a valid point and I think we have it under control. But its 
actually a bit more complicated than what you state above.

I have treated the document as an input from a particular stakeholder's 
perspective. I have assumed that there are more general protocol design 
and even security aspects that an actual solution should take into account.

However, I do not necessarily believe that there is a single NEMO route 
optimization solution that should cater for everyone's needs. The 
group's charter was written with the assumption that there are different 
use cases and that their solutions might be different. For instance, 
federated tunnel servers advertising the same BGP space is likely a good 
match for the aeronautics requirements, as it can solve the continental 
dogleg routing problem. Its not clear that this solution solve every 
other application's NEMO RO problems, however.

So, if and when we actually design a solution, I'd like that solution to 
be generally usable and be able to run on the Internet as well as in a 
closed ATC network. But the solution will probably still be limited to a 
particular type of movements, and be able to address only some of the 
needs for NEMO RO. Note that the group is probably not unanimous in 
these beliefs; at least in the past we've seen arguments favoring the 
construction of a solution that can handle everything. I just don't 
personally believe this is achievable.

> software may rule out nemo.  However, perhaps I'm missing something.

The document obviously prefers solutions where as small number of 
components as possible is touched. However, I do not remember a 
statement that says no software is allowed (but maybe I missed it). In 
fact, you would assume that for any sort of route optimization, you have 
to touch at least your router.

The document says:

"The MRs and MNNs onboard a spacecraft are highly-customized computing
platforms, and adding custom code or complex configurations in order
to obtain NEMO RO capabilities is feasible,
...
Since for ATS, the MRs and MNNs are under regulatory control and are
actively tested and maintained, it is not completely unreasonable to
assume that special patches or software be running on these devices
to enable NEMO RO. In fact, since these devices are accessed by
skilled technicians and professionals, it may tolerable be if some
special configuration is required for NEMO RO. Of course simplicity
in setup and configuration is highly preferable, however, and the
desirable feature labeled "Des1" below in this document prefers
solutions with lower configuration state and overhead. To minimize
costs of ownership and operations, it is also highly desirable for
only widely-available off-the-shelf operating systems or network
stacks to be required, but not a full requirement.

... it is desirable that a
NEMO RO solution be as simple to configure as possible ..."

Jari

---

From: Sam Hartman <[email-masked]>
Date: Mon, 24 Aug 2009 08:33:28 -0400

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:

    Jari> Thanks for your review, Sam. A few responses below:
    >> 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.
    >> 

You raise a valid point and I think we have it under control. But its
    Jari> actually a bit more complicated than what you state above.

    Jari> I have treated the document as an input from a particular
    Jari> stakeholder's perspective. I have assumed that there are
    Jari> more general protocol design and even security aspects that
    Jari> an actual solution should take into account.

    Jari> However, I do not necessarily believe that there is a single
    Jari> NEMO route optimization solution that should cater for
    Jari> everyone's needs. The group's charter was written with the
    Jari> assumption that there are different use cases and that their
    Jari> solutions might be different. For instance, federated tunnel
    Jari> servers advertising the same BGP space is likely a good
    Jari> match for the aeronautics requirements, as it can solve the
    Jari> continental dogleg routing problem. Its not clear that this
    Jari> solution solve every other application's NEMO RO problems,
    Jari> however.

I think some of this discussion took place while I was still on the
IESG.  Regardless, I was definitely aware that there would be multiple
solutions for different use cases; I was basically trying to capture
what you say above.  So, what you're thinking is definitely in
alignment with what I was thinking when I wrote my review.

---

From: "Davis, Terry L" <[email-masked]>
Date: Mon, 24 Aug 2009 10:50:19 -0700

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

> Sent: Friday, August 21, 2009 6:41 PM
> To: Davis, Terry L
> Cc: 'Sam Hartman'; [email-masked]; [email-masked]; 'Ivancic, William D.
> (GRC-RHN0)'; [email-masked]; [email-masked]; draft-ietf-
> [email-masked]
> Subject: Re: secdir review of draft-ietf-mext-aero-reqs8
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Aug 2009 22:10:28 -0400

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

---

From: "Davis, Terry L" <[email-masked]>
Date: Tue, 25 Aug 2009 16:34:28 -0700

Steve

Sorry if I confused this issue in this way.  Aviation does not want to be "special" in any area; PKIs or protocols.  And aviation has long recognized that no single PKI will ever serve it; hence our creation of the Exostar Certipath bridge.  By governmental requirements around the globe, we will deal with a multitude of different PKIs and specific key/hash requirements in our environment.  We want to use generic standard Internet services but our security environment will be more demanding than a typical enterprise or agency as we move from OSI to IP for new aviation communications.

Aviation will be the first try (I'm aware of) at utilizing the IP security protocols in a truly dynamic global heterogeneous environment.
- An aircraft will have generally 1 to 4 active communications links at any given time.

- These will change almost continually between service providers and ground portals.

- Some aircraft, especially those that do continuous global circle routes, will have 20 or more service providers for those various links in a 48 hour period.

- Each service provider is likely to have its' own unique security environment and PKI.

- There is no onboard IT staff!  It all has to happen automatically to make new security associations with the next link provider.

Hence my skepticism on our ability to utilize the IP security protocols (regardless how you spell IPSec ;-) in a dynamic global mobile environment.

If the IETF had not adopted the DHCP protocols they were provided with over 15 years ago, we would not have global roaming connectivity today.  No hotspots, no international hotel usage, no laptop portability even between sites within the laptop's own enterprise, etc.  

And providing global "dynamic security association negotiation" is outside of the scope of IETF standards?

To me, not providing a simple "dynamic security association" to insure that our security protocols are fully interoperable and easily implementable in a heterogeneous environment between different vendors would be an abdication of our responsibility to the security of the Internet.

I'll leave at "I think we have some more work to do!"

Take care
Terry

PS: You can see some of these same issues in the various CI sectors also as they attempt interoperation of between the various entities within sectors.

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Monday, August 24, 2009 7:10 PM
> To: Davis, Terry L
> (GRC-RHN0)'; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8
>