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

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Jun 2009 17:12:22 -0400

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Jun 2009 17:53:09 +0200

Just one particular point about looping issues...

Jari Arkko a écrit :
[...]

> currently support in NEMO...

I am not sure what do you mean Jari, by saying that loop detection is 
not supported in NEMO(?)

With Mobile IP based network mobility packets can not travel in loop 
paths (a typical risk of badly behaving distributed algorithm of path 
construction), simply because packets get encapsulated each time, every 
same-level path can't loop.

On another hand, I am not aware of any analysis of Mobile IP based 
network mobility protocols from a looping standpoint.

I wanted to point to a 'stalemate' situation described in RFC4888 
Appendix B which shows a mobility configuration leading to impossibility 
to set up the MR-HA tunnel.  This configuration can occur with a small 
capsule detaching from a larger station, attaching to another larger 
station; subsequently the initial station tries to attach to the 
capsule.  This may lead to a 'stalemate' situation from the Mobile IP 
and RFC4888 standpoint.  A NEMO RO protocol should help avoid this 
situation.

I am wondering about similar description of what looping and NEMO can be 
in the framework of aero-reqs draft.

Alex

> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Wed, 24 Jun 2009 13:16:30 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Jari Arkko
>Sent: Tuesday, June 16, 2009 5:12 PM
>
>Substantial comments:
>

The suggested change sounds appropriate to me; there was discussion at
the ICAO WG-I #1 meeting and prior to that the original requirements
were derived from an ICAO WG-N meeting's materials.  I will update the
draft.

>add the explicit note about this.

Yes, this is right; we were always looking at the HA-redundancy extensions
as well for deployment in this case.  We can add a sentence to clarify.

>established RO with a router near the CN.

The real requirement here is that beyond any existing fragility in the
NEMO system, that the RO solution not add *new* single points of failure
of its own creation.  It could perhaps be rephrased somewhat in the draft
to make that more clear.

It was understood that if an HA was a single point of failure due to not
using HA redundancy mechanisms, and it did in fact fail, then established
sessions using RO could still operate based on the binding cache entries,
but new incoming connections would not reach the MR/MN. So, having RO is
nice in that it increases robustness to HA failure for established
application flows, but it is not in itself a real solution for HA
reliability, and that's not why it's asked for.

>packet. I would simply say ... reasonable security mechanisms (e.g.,

Actually a concern here is that by sniffing the right frequency and
seeing the MNP that is assigned to an aircraft, it will be very easy to
track flights the way people currently do with ACARS, and even worse,
it may be possible to find ways to direct packets at the planes based
on this knowledge.  There are many people sniffing ACARS from the air
and tracking flights based on this today.

>cutting some of the text.

Ok; the MNP being secret is not a foundation of securing the system, but
not broadcasting it to the world is something that raises the barriers to
entry, and it's a request that was brought to us rather than something that
the IETF decided was needed.

>assume ingress filtering is in place in the access networks."

Ok; that makes sense to me, and sounds like a good change.

>hold your breath for a global all-purpose PKI.

:)  Yes, of course.

>unrecognized stuff, and that it then get some sort of default treatment.

What this requirement is saying is that the RO scheme must not assume
only TCP traffic, for instance, and prevent new transports or other
protocols from being deployed over the IP services provided.  An
implementation could still screw this up, but the RO mechanism as
defined itself should be adaptable to new protocols.  The actual
requirement text is pretty clear:
" Applications using new transport protocols, IPsec, or new IP options
   MUST be possible within an RO scheme."
Maybe we have so much rationale that we made it confusing?  We could
definitely trim it a bit.

>currently support in NEMO...

Not a requirement at this stage of the game.

> ...

All the editorial comments are basically good; here's just a quick

>acronyms were not defined either.

"Plain Old ACARS" is actually the industry-used term :), sometimes
abbreviated POA (Plain Old ACARS).  We can put in pointers to a couple
of references on these things.

>Internet access systems support much higher...

Not totally history; Boeing Broadband Satcom Network lives on and is
contracted at least through Feb 2010, based on public announcements.
I suppose the name of the consumer-oriented service (Connexion) is
history though, but the system is largely the same, I believe.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------