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

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Jul 2009 12:30:26 +0300

Wes,

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

OK

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

OK. As long as the document is clear on these points, I'm fine.

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

I understand. However, I think that particular worry is just one among 
many. Its OK for you to state a requirement to handle this, but at the 
same time you should also have requirements for the other things.

Please remember that if your security is only based on hiding data, you 
may in fact be vulnerable. For instance, RO signaling packets are not 
the only potential source of information about, say, aircraft prefixes 
or server addresses. Parts of this data would also appear in public 
registries, be visible to anyone working on the network, etc.

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

That's fine, but as noted above, you also need to require the RO 
mechanism to be secure in other ways as well.

>>> 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."
>>     
>
>
> Ok; that makes sense to me, and sounds like a good change.
>   

Great!

>>> 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.
>>     
>
>
> :)  Yes, of course.
>   

OK

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

Agree.

> Maybe we have so much rationale that we made it confusing?  We could
> definitely trim it a bit.
>   

Yes, I think that was the problem. Please trim. If flow-based traffic 
separation is needed, some amount of configuration will be necessary. Of 
course we all agree that the software should allow all protocols and ports.

>>> 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...
>>     
>
>
> Not a requirement at this stage of the game.
>   

Is this something that you are prepared to state explicitly?

FWIW, I think it is a reasonable expectation that in a carefully 
controlled environment such as the aircraft communications, loops will 
not happen.

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

OK

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

Ok -- interesting!

Jari