Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks
draft-ietf-mext-aero-reqs-04

[Ballot comment]
I don't believe these requirements adequately cover the requirements for ATS data. For example, "Req3 - Latency" is a solution to mitigate latency, not an actual requirement that bounds latency.

[Ballot comment]
Please consider the comments in the Gen-ART Review by Vijay Gurbani
  posted on 20-Aug-2009:

  1) What is the "Gatelink system"?  There are at least two
    instances of it in the draft.  Any reference or a short
    sentence describing this would help the reader not
    verbose in this particular domain.

  2) Missing closing bracket ')' in Section 2.1.1, third paragraph,
    third line; i.e., should be "... in Appendix A.)"

The document is generally well written and it was easy to read. There were no major problems, but there are a number of issues that I think warrant producing a new version. Here are my comments:

Substantial comments:

> This version has been reviewed by members of the International Civil
> Aviation Orgnanization (ICAO) and other aeronautical communications
> standards bodies, and contributed to by a number of aeronautical
> communications experts outside the normal IETF process.

What kind of review was actually performed? The above text sounds like a formal review and acceptance was given. If something more informal was actually done, please change the text accordingly. Also, "this version" may not be appropriate as we intend to publish this as an RFC. Maybe "Input to these requirements was given by aeronautical communications experts outside the IETF, including members of the ...".

> A need for high availability of connectivity to ground networks
> arises from the use of IP networking for carrying safety-of-life
> critical traffic.  For this reason, single points of failure need to
> be avoided.  If an RO solution assumes either a single MR onboard, a
> single HA, or some similar vulnerable point, and is not usable when
> the network includes standard reliability mechanisms for routers,
> then the RO technique will not be acceptable.  An RO solution also
> MUST NOT itself imply a single point of failure.

Hmm. There's a hidden requirement here that you actually cannot cope with the basic NEMO at all (even without RO), because Mobile IP is by its nature relies on a single point of failure (the HA). You _also_ need another type of an extension to support multiple HAs for the same home address. You should explicitly indicate that such a hidden requirement exists and that its outside the scope of the RO work. Its good that the end of 3.4.1 already says that Internet-less operation is ruled out, and that HA/MR redundancy mechanisms are ruled out. But it would be good to add the explicit note about this.

Or are you thinking of using the RO solution as a way around this requirement? To some small extent this would be possible. E.g., prefix certificates could indicate to CRs that you can claim yourself as the destination for a particular prefix. This would enable applications to work. However, it would not enable a CN in some random location to send a packet to the aircraft, unless the aircraft's MR had already established RO with a router near the CN.

> The first security requirement is driven by concerns expressed by ATS
> communications engineers.  The concern is with the air-ground links
> to a craft, and their current lack of security.  If an RO scheme
> exposes the MNP to eavesdroppers on these links, it may enable
> attackers to easily send packets towards onboard networks of crafts.
> The RO scheme should use some reasonable form of encryption (e.g.
> standard ESP transforms) in order to protect any new RO signalling
> data that contains the MNP.

I think you mean integrity protection or authentication, not encryption. Encryption may not prevent the attacker from falsifying a signaling packet. I would simply say ... reasonable security mechanisms (e.g., strong authentication).

Also, I do not think the security of your networks can be based on the MNP being a secret. The text is fuzzy about what the real issues are. Note that I think the requirement from 3.8 was crystal clear. But the 3.8.1 text is making things a little more less clear. I would suggest cutting some of the text.

> The second security requirement is driven by the greater risk of
> flooding attacks that are started by an attacker redirecting an MNP's
> traffic to some target victim CoA.  This is somewhat worse than the
> case for MIPv6 mobile host RO, because the MNP's traffic is
> potentially a higher rate than that of a single mobile host's HoA.
> To protect bindings to bogus CoAs from being sent, the RO scheme must
> somehow validate that an MR actually possesses any CoAs that it
> claims.  In typical Mobile IPv6 RO, the return routability test
> provides a form of validation, under certain assumptions.  For the
> purposes of aeronautics, to demonstrate ownership of the CoA, it is
> safe to assume ingress filtering on the part of the access network
> providers, in conjunction with the ability to correlate a BU's source
> address and the decrypted alternate CoA at the end recipient of the
> BU.  (Note: this is particularly subject to MEXT discussion)

Again, the requirement in 3.8 was great. The justifications are less convincing. For instance, its not clear to me at all that a malicious MR will have greater bandwidth than a malicious MN. I would simply say:

"The second security requirement is driven by the risk of flooding attacks that are started by an attacker redirecting an MNP's traffic to some target victim CoA. To protect bindings to bogus CoAs from being sent, the RO scheme must somehow validate that an MR actually possesses any CoAs that it claims. For the purposes of aeronautics, it is safe to assume ingress filtering is in place in the access networks."

> It is felt by many individuals that by the time the IP-based ATN
> grows into production use, there will be a global PKI useable for
> ATS, though it is agreed that such a PKI does not currently exist,
> and will take time to develop both technically and politically.

I think you mean s/global PKI/global ATN-specific PKI/. You should not hold your breath for a global all-purpose PKI.

> If the RO solution assumes that some amount
> of preconfiguration of flow properties (port number ranges, etc.) is
> required, this could make the integration of new applications or
> protocols difficult.  An RO scheme might assume this in order to
> classify between flows that prefer the MRHA tunnel to an optimized
> path per requirement Req1, for instance, among other reasons.

Req1 and this text under Req9 are in conflict. There is no way for a middlebox like the MR to look at anything else than the 5-tuples for doing traffic separation. Even without NEMO, your choices for providing differentiated treatment for IPsec packets are limited. Basically, its down to looking at addresses. (I think this would in fact most cases suffice, so I do not see the real world problem.)

So if Req9 is about disallowing 5-tuple based policies, we have a problem. Perhaps you meant to say that RO still needs to be possible for unrecognized stuff, and that it then get some sort of default treatment.

> 4.2. Des2 - Nesting
>
>
>    It is desirable if the RO mechanism supports RO for nested MRs, since
>    it is possible that for PIES and astronaut spacesuits, that PANs with
>    MRs will need to be supported.  For oceanic flight, ATS and AOS may
>    also benefit from the capability of nesting MRs between multiple
>    planes to provide a "reachback" to terrestrial groundstations rather
>    than relying solely on lower rate HF or satellite systems.  In either
>    case, this mode of operation is beyond current strict requirements
>    and is merely desirable.  It is also noted that there are other ways
>    to support these communications scenarios using routing protocols or
>    other means outside of NEMO.

Is loop detection a requirement? That is something that we do not currently support in NEMO...


Editorial comments:

> This document describes the requirements and desired properties of
> NEMO Route Optimization techniques for use in global networked
> communications systems for aeronautics and space exploration.

Expand NEMO in the title and abstract.


> As background the NEMO terminology and NEMO goals and requirements
> documents are suggested reading [4] [5].  The drafts produced as part
> of the Mobile Platform Internet (MPI) effort are also of relevence,
> and some of the material in this document is borrowed from the MPI
> drafts [6] [7].

This part jumps out a little bit as the first paragraph, particularly when [6] and [7] are expired I-Ds. I would suggest the borrowing part should move to the acknowledgment section, and NEMO goals and requirements could be placed a little bit later in the Section, e.g., after the current second paragraph.

>    The base NEMO standard [1] allows Mobile IPv6 [2] to be used by
>    mobile routers, although NEMO does not support Mobile IPv6's Route
>    Optimization (RO) features for mobile network nodes other than the
>    NEMO Mobile Router (MR) itself.

Again, the part that begins with "although" is a little bit early as you have not explained even the basic NEMO yet. Explain the basic NEMO first, and then put the lack of RO support to the end of the paragraph.

>    imposed by using the MRHA tunnel.  Avoiding the delay from

Expand the acronym MRHA before first use.

> using Plain
>      Old Aircraft Communication Addressing and Reporting System (ACARS)

Unless "Plain Old" is the formal name, I would use "using the old Aircraft ..." instead.

It would be good to get references to a few of the concepts and technologies. E.g., Section 2 talks about ACARDS, VDL modes, Electronic Flight Bags, B-AMC, AMACS, P34, LDL, WCDMA, 802.16, etc. Some of these acronyms were not defined either.

> Both current and planned datalinks used
>    for PIES and/or AOS

Undefined acronyms.

> satcom links employed by Connexion by Boeing support much higher data rates than current ATS links.

Isn't this history now? I would suggest rephrasing this without any mention of specific products. E.g, satcom links employed by passenger Internet access systems support much higher...

> it may tolerable be if some
>    special configuration is required for NEMO RO
... may be tolerable ...


> new ATN architecture


Expand the acronym and provide a reference if one exists.

> As a minimum, if an RO solution is
>    integrable with the MONAMI6 basic extensions

It would be better to find a non-WG name for these extensions. Please refer to draft-ietf-mext-multiplecoa specification, for instance.

>  (Note: this is particularly subject to MEXT discussion)

This should be removed or reformulated, as this draft becomes published as an RFC the context may no longer be there for the readers.