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

I have reviewed this document. My detailed comments are further down.

Overall, the document is well written and a good start for specifying
what the aeronautics community needs. However, there are a number of
issues that still need work:

1) To me, the main issue with airline network access is the extra
continent roundtrip that is introduced if your tunnel has to be used and
has to stay at the same server endpoint all the time. This issue needs
emphasis among the various IMHO less important requirements.

2) The security requirements need significant work to specify what
problems the RO solution must guard against.

3) Transport implications, separability, support VMNs, and some of the
other specific requirements require further clarification.

>       Longer routes leading to increased delay and additional
>       infrastructure load - In aeronautical networks (e.g. using Plain
>       Old Aircraft Communication Addressing and Reporting System (ACARS)
>       or ACARS over VHF Data Link (VDL) mode 2 ) the queueing delays are
>       often long due to ARQ mechanisms and underprovisioned radio links.
>
>       Furthermore, for aeronautical communications systems that pass
>       through geosynchronous satellites, and for space exploration, the
>       propagation delays are also long.  These delays combined with the
>       additional need to cross continents in order to transport packets
>       between ground stations and CNs means that delays are already
>       quite high in aeronautical and space networks without the addition
>       of an MRHA tunnel.  The increased delays caused by MRHA tunnels
>       may be unacceptable in meeting Required Communication Performance
>       [8 <http://tools.ietf.org/html/draft-ietf-mext-aero-reqs-00#ref-8>].
Overall, I felt that the document talks about a large number of
requirements, but fails to highlight the key problem which is talked
about at the end of the above passage: as planes travel from one
continent to another, having a stationary tunnel endpoint will
eventually cause an additional continent roundtrip.

>       Increased packet overhead - Given the constrained link bandwidths
>       available in even future communications systems for aeronautics
>       and space exploration, planners are extremely adverse to header
>       overhead.  Since any amount of available link capacity can be
>       utilized for extra situational awareness, science data, etc.,
>       every byte of header/tunnel overhead displaces a byte of useful
>       data.
Secondary issues like this are not very convincing (what about header
compression, for instance?) and confuse the key problem.

>    Since for ATS, the MRs and MNNs are under regulatory control and are
>    actively tested and maintained, it is not 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 be acceptable even if complex
>    configuration is required for NEMO RO.  Of course simplicity in setup
>    and configuration is desirable, however.
What about CNs, is it reasonable to expect changes to them?

> The set of CNs may be assumed to
>    all share the same network prefix.
This seems unexpected. Why would we assume this?

> 2.1.2. Airline Operational Services Domain
This section talks about the airline's operational processes. What about
the manufacturers, maintenance contract holders, etc -- I would expect
that there will be some communication with them as well.

> in the future, it is expected that the In-Flight
>    Entertainment (IFE) systems may receive movie refreshes of data
>    running into the gigabyte range.
>   
This seems low. A single high-definition movie involves tens of
gigabytes. If you are really talking about movies, I suspect these could
be scheduled to be changed while in the airport. If you talk about
current TV programs (news etc), it may be a different matter. Even then,
I suspect one gigabyte is a small amount of data.

> For the small number of messaging flows,
> however, the CNs are geographically (but not necessarily
> topologically) very close to the aircraft. 
It is not clear that this would be the case. We need to separate what
happens at different layers. Recipients may indeed be close to you, but
applications (chat, e-mail) typically go through central servers at the
home site.

> Due to the great size of the data stored on
> these LFNs compared to the anemic bandwidth available air-to-ground,
> these LFNs will probably not attempt to communicate off-board at all
> during the course of a flight, but will wait to update their content
> via either high-speed links are available on the ground, or via
> removable media inserted by the flight crew.
Hmm. It seems to me that there would be demand for downloading new data
(e.g., current TV programming) if it were possible. I would not
necessarily rule this out...

> The RO solution should be optimized for
> ATS and AOS needs, and consider PIES as a secondary concern.
>
> With this in consideration, the PIES domain is also the most likely
> to utilize NEMO for communications in the near-term since
> relatatively little regulations and beaurocracy are involved in
> deploying new technology in this domain
Are there legal interception requirements that would affect the
passenger domain? Will these requirements affect what we need to do for RO?

> It can be assumed that for manned spaceflight, at least, multiple MRs
> will be present and on-line simultaneously for fast failover.  These
> will usually be multihomed over space links in diverse frequency
> bands, and so multiple-prefixes can be expected, especially since
> some links will be direct to ground stations while others may be
> bent-pipe repeated through satellite relays like TDRSS. 

First, multiple prefixes on the access network that the MRs connect to,
or multiple home prefixes that are presented to the mobile network
nodes? These are very different...

And if it is the latter, I'm not sure I fully understand why multiple
prefixes are needed.

> 3.1.1. Rationale for Aeronautics - Separability

It is not clear to me why separability is needed as a requirement. Or at
least it is unclear to me whether this refers to a functionality within
NEMO or something relating to the ability to employ NEMO on a
case-by-case basis.

Presumably, you should be able to run NEMO, NEMO RO, and various
different techniques on the different domains independently already
today. Simply have some devices in the plane be under an MR that uses
RO, some under an MR that does not, others that don't use NEMO at all,
etc. I think it would be potentially harmful to try to integrate the
different traffic domains under the same MR and NEMO connection.
Particularly given the safety issues.

> 3. Required Characteristics
Should this document talk about the requirements related to transport
effects from the use of RO? Or lack thereof...

> If duplicating a small number of packets sent over
> both the MRHA tunnel and the optimized path is possible until the
> optimized path can be verified to function for a particular data
> flow, then this could be sufficient to meet this requirement (it is
> safe to assume that the applications are robust to this duplication).

I am not sure I understand the transport implications of such
duplication. I could imagine under some conditions it could introduce
reordering or something that causes harm for TCP.

> When an MR is completely disconnected from the
> majority of the network it is intended to communicate, including its
> HA, there is no requirement for it to be able to retain any
> communications involving parties outside the mobile networks managed
> by itself.
Its great to have such non-requirements here as well.

> 3.6. Req6 - Scalability
>
>
> Req6 - An RO scheme MUST be simultaneously usable by ten thousand
> nodes without overloading the ground network or routing system.

This should be formulated more firmly. For instance, I would like to see
an additional requirement that the solution MUST NOT inject updates to
the global BGP routing table when planes move around.

> 3.8. Req8 - Security
>
>
>  Req8 - IPsec MUST be usable over the RO scheme, and the data used to
>  make RO decisions MUST be authenticable, perhaps using some form of
>  IPsec.

This requirement should be split up. The part about payload traffic
being able to use IPsec should be generalized to any security mechanism.
It might make sense to combine this with Req9.

The part about securing the RO itself should be held separate. In
addition, the requirement as it stands not sufficiently detailed to be
useful. Start with the requirement that route optimization decisions
must be taken by such and such nodes involved in the protocol, and that
strong authentication is required for the signaling.  Specify who is
authorized make particular decisions. Specify what security
infrastructure you are prepared to accept to allow all this to happen.
Even so, there are other requirements that you may want to consider,
such as what to do with securing path tests (but these may not be
something that we completely secure).

> Likewise, since the IPsec standards
> seem to be the only widely-agreed upon framework for implementing
> packet authentication and other security services, the use of IPsec
> to authenticate or otherwise secure RO signaling and other data used
> in the RO process is also desirable, but other reasonable
> authentication mechanisms may be acceptable for RO signalling.
As above. IPsec may be the right solution, but the text sounds like
spreading security pixie dust to a hard problem. Specify the security
requirements for your problem, not the solution.

>  This requirement was extrapolated from ICAO's TC-8 - "The approach
>  should be secure."
Against what attacks? Making RO decisions by someone in the Internet? By
someone on the path? By a legitimate participant but who does not "own"
this particular prefix? By a compromised node?

> 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.

This requirement makes sense to me, but it is also something that
focuses on building ad hoc routing style networks. I would suggest that
we have to keep this part of the problem space out of our effort if we
are going to complete something. Lets look at the ad hoc routing aspect
separately.

I also do not necessarily believe that nested NEMOs are the right
approach to doin such multi-hop manet routing. It seems preferrable that
the MR deals with this by also acting as a, say, MANET router.

> 4.4. Des4 - VMN Support
>
> At least LFNs and LMNs MUST be supported by a viable RO solution for
> aeronautics, as these local nodes are within the ATS and AOS domains.
> VMNs within the PIES domain are expected to be numerous, and it is
> strongly desirable for them to be supported by the RO technique, but
> not strictly required.

What does "support" mean here -- presumably if Req9 is followed, it
would be hard for any new technology to break nodes that employ VPNs,
Mobile IPv6, HIP, or something like that.

Or does "support" mean some additional feature that will be beneficial
to the nodes? If so, please specify.

Editorial:

> (e.g. using Plain
>       Old Aircraft Communication Addressing and Reporting System (ACARS)
>       or ACARS over VHF Data Link (VDL) mode 2 )
Style: use "the old" instead of "plain old". Or some other choice of
words...

>    Entertainment (IFE) systems may receive movie refreshes of data
s/movie/television program/ ? I would expect that current news would be
something of value to passengers.

> When an MR is completely disconnected from the
> majority of the network it is intended to communicate, including its
> HA, there is no requirement for it to be able to retain any
> communications involving parties outside the mobile networks managed
> by itself.
s/HA,/HA(s),/

>    [1]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
>          draft-ietf-nemo-terminology-06 (work in progress),
>          November 2006.
>
>    [2]   Ernst, T., "Network Mobility Support Goals and Requirements",
>          draft-ietf-nemo-requirements-06 (work in progress),
>          November 2006.
>    [7]   Ng, C., "Network Mobility Route Optimization Problem
>          Statement", draft-ietf-nemo-ro-problem-statement-03 (work in
>          progress), September 2006.

These are RFCs now.

>    [17]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
>          Levels", BCP 14, RFC 2119, March 1997.

Make this a normative reference.

Jari

_______________________________________________
MEXT mailing list
MEXT@ietf.org
http://www.ietf.org/mailman/listinfo/mext