[MEXT] AD review of draft-ietf-mext-aero-reqs

[Jari Arkko <[e-mail]>]

I have reviewed this draft.

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.

Jari