Re: [MEXT] A Proposed Solution for Aeronautical RO

[Tony Whyman <tony.whyman at mccallumwhyman.com>]

Marcelo and Carlos,

Thank you for taking the time to look at my paper. However, I am 
slightly confused by your question, in the sense of what does "change" mean.

In my proposed scheme, the CN is required to support IKEv2/MOBIKE as a 
minimum. I have also proposed extensions to IKEv2 to include a means of 
negotiating the use of the use of the Home Address Option/Type 2 Routing 
Header and this extension is obviously a "change" from published RFCs - 
although not necessarily an essential change - it is proposed to improve 
performance.

So, if the question is "is the functionality of the CN different from 
that required by RFC 3775", the answer is "of course it is". My proposal 
observes that trying to keep within the confines of RFC 3775 when 
introducing IPsec to the MN to CN relationship leads to an inefficient 
protocol and I have hence proposed to improve it.

Is change a problem? Not in the context of the proposal. Air Traffic 
Control is a controlled environment where all systems have to be 
compliant and certified or approved before operation. The industry is 
only at the start of a development process for an ATN-IP and there is 
still plenty of scope for refining the specification before freezing it.

How big a change is being proposed? Conceptually, it is probably a big 
one. The MN to CN relationship changes from being an optimisation to the 
normal mobility relationship. Home Agents are only brought into the 
picture when you need a transition aid to support communication with CNs 
that don't support IKEv2/MOBIKE and/or do not recognise the MN's 
credentials, or when the DNS is used for (mobile) name to address 
resolution and hence you need a rendezvous point.

In the civil aviation environment  for ATC and AOC it may be assumed 
that all CNs will be compliant and part of the same trust framework. The 
(existing) Context Management application manages the very dynamic 
relationship between the "Flight", an "aircraft" and any IP Addresses 
assigned to it, and avoids the need for rendezvous points. Home Agents 
are not needed for such reasons, and are anyway undesirable because of 
the availability and regulatory issues I referred to. Hence a proposal 
that focusses on the MN to CN relationship.

Regards

Tony Whyman

marcelo bagnulo wrote:
> Carlos Jesús Bernardos Cano escribió:
>> Hi Tony,
>>
>>     Thanks for proposing a solution.
>>
>>     While I admit I've not gone through all your paper yet, I'd like 
>> to ask
>> you a question: does your solution require changes on the CN side? from
>> what I've read so far, I tend to think so, but I'd like to check that. I
>> understood in the last MEXT interim meeting that changing the CNs was
>> not a valid assumption.
>>   
> right
> but rephrasing Carlos question, would the solution support CN proxies 
> that perform the RO operations on behalf of the CN? (that would be 
> acceptable according to the requirements)
>
> Regards, marcelo
>
>
>>     Thanks a lot,
>>
>>     Carlos
>>
>> On vie, 2008-04-04 at 12:22 +0100, Tony Whyman wrote:
>>  
>>> Dear all,
>>>
>>> I have prepared a proposed IPsec based RO scheme that is intended to 
>>> meet the requirements contained in draft-ietf-mext-aero-reqs-01. The 
>>> paper can be downloaded from:
>>>
>>> http://www.mccallumwhyman.com/papers/Proposal%20for%20Aeronautical%20RO.pdf 
>>>
>>>
>>> It's a large paper (15,000+ words) but that is because of the large 
>>> Appendix A, which is an analysis of how the proposal meets the 
>>> current aeronautical use cases. Appendix B also provides a 
>>> compliancy check against draft-ietf-mext-aero-reqs-01.
>>>
>>> The main body of the paper is likely to be of most interest to this 
>>> group. In this, I have tried to evolve the IPsec RO approach 
>>> proposed in draft-ietf-mip6-cn-ipsec-07 into a common framework with 
>>> the recommendations of Eurocontrol 2006  IP Study. This study was 
>>> intended to "assess the feasibility of using IP to support the next 
>>> generation of collaborative ATS applications, in the 2020+ 
>>> timeframe". The published results of that study can be downloaded 
>>> from the ICAO website (URL in the references list of my paper).
>>>
>>> Although the focus of the paper is on meeting the requirements for 
>>> Aeronautical use, I do not believe that the requirements are unique 
>>> to civil aviation. The UK Railways Safety and Standards Board (RSSB) 
>>> is also about to publish a Guidance Note (Ref: GE/GN8579) which is 
>>> intended to co-ordinate the use of IP Networking for mobile 
>>> networking to trains. SATCOM, GPRS, WiFi and WiMAX networks are 
>>> already being used to support passenger "on train" internet access 
>>> and some operational use, and this Guidance Note is intended to 
>>> co-ordinate the use of IP for operational comms, leading into Safety 
>>> Related applications. It was the result of industry consultation and 
>>> workshops and resulted in a very similar set of operational 
>>> scenarios to those seen in ATC, and a similar proposal for IPsec 
>>> based mobile communications.
>>>
>>> My own conclusion from all this, is that there is a real need for an 
>>> IPsec based Mobility Framework to meet the needs of Operational 
>>> Communications in (at least) Transport Infrastructure applications.
>>>
>>> My paper has made some specific criticisms of 
>>> draft-ietf-mip6-cn-ipsec-07, where I do not believe it meets the 
>>> needs of aeronautical communications. However, the underlying 
>>> criticism is that draft-ietf-mip6-cn-ipsec-07 is relatively neutral 
>>> as regards IKEv1 and IKEv2. My view is that IKEv2 is not just a 
>>> better protocol, but with improved Traffic Selection signalling and 
>>> the MOBIKE (RFC 4555), it is the only flavour of IPsec IKE that 
>>> should be considered for an IPsec based mobility framework.
>>>
>>> Starting with the assumption that IKEv2/MOBIKE is used, I believe 
>>> that it is possible to demonstrate a much improved strategy for 
>>> IPsec based Route Optimisation, that starts with the use of the Home 
>>> Address as the MN SA end-point and then moves it to the care-of 
>>> address. Thus demonstrating both authorisation to use the Home 
>>> Address and Return Routability to both addresses before any user 
>>> data is exchanged. Interestingly, if user data is to be protected by 
>>> ESP or AH tunnelling then there seems to be no need to exchange a 
>>> Binding Update, as Child SAs with appropriate Traffic Selectors seem 
>>> to be sufficient.
>>>
>>> A further step is also possible if both MN and CN support a common 
>>> PKI that provides both authentication and authorisation of the MN to 
>>> use its Home Address. In this case, it appears possible for the MN 
>>> to start the IPsec based RO procedure direct from its care-of 
>>> address without there needing to be any Home Agent involvement. This 
>>> is particularly interesting to aeronautical use, where communication 
>>> is generally aircraft initiated, as it avoids both availability and 
>>> regulatory issues with Home Agents, and fits with the 
>>> recommendations of the Eurocontrol IP Study. Although it did not 
>>> call it as such, this study essentially proposed an IPsec based RO 
>>> scheme, which it called "tunnel movement" and assumed a PKI that 
>>> authenticated aircraft and their use of their static IP Addresses.
>>>
>>> The study limited itself to what was possible with published RFCs, 
>>> and thus all air/ground communications had to be ESP tunnelled, due 
>>> to the use of IKEv2/MOBIKE to manage the communications paths. Two 
>>> specific criticisms arise from this. One is that there are many 
>>> cases where an RFC 3775 Home Address Option/Type 2 Routing Header 
>>> and Transport mode ESP would be more efficient than ESP tunnelling, 
>>> and the other is that it forces all air/ground communications to be 
>>> protected, even when the overhead of doing so is not otherwise 
>>> justifiable.
>>>
>>> In my paper, I have tried to resolve both criticisms.
>>>
>>> I have resolved the first, by proposing a new IPsec SA mode that 
>>> essentially combines ESP/AH transport mode with use of the RFC 3775 
>>> Home Address Option/Type 2 Routing Header.
>>>
>>> I have resolved the second by proposing the notion of "No 
>>> Protection" SAs - i.e. using the IKEv2 to negotiate IP-in-IP 
>>> tunnels, or use of the RFC 3775 Home Address Option/Type 2 Routing 
>>> Header. Although this seems to be counter-intuitive for the IPsec 
>>> IKE to negotiate off security, the benefit is in having a single 
>>> mechanism to manage unprotected mobile communications, when there is 
>>> also a need for secure mobile communications.
>>>
>>> My paper also examines the case where the IKE is used to manage 
>>> secure mobile communications but has no means of authenticating the 
>>> MN to the CN. This appears to be interesting as part of a wider 
>>> framework, but is not of direct interest to aeronautical 
>>> communications.
>>>
>>> I have also investigated possible implications for MN to HA 
>>> communications, and proposed IKEv2/MOBIKE scenarios where Binding 
>>> Updates are no longer needed here. Again, this is not of direct 
>>> interest to aeronautical communications, but should be of wider 
>>> interest.
>>>
>>> Looking back on the paper, although I started writing assuming IPv6 
>>> only, almost everything proposed is also relevant to IPv4. Only the 
>>> use of the RFC 3775 Home Address Option/Type 2 Routing Header is 
>>> IPv6 specific.
>>>
>>> Using the IKE to manage mobility also seems to have some other 
>>> interesting implications. Like it or not, NAT Gateways are well 
>>> supported by IPsec, and a Mobile Node that uses  IKEv2/MOBIKE to 
>>> manage both its HA binding and RO, seems to be able to move behind 
>>> NAT Gateways and then re-emerge without any obvious problems - 
>>> although this mode of operation is limited to ESP tunnels.
>>>
>>> Basic NEMO operations should really be just a case of an appropriate 
>>> set of SA Traffic Selectors for MN to SA tunnels. If a PKI exists 
>>> that allows a CN to authenticate a Mobile Router and authorise the 
>>> routes it offers, then the use of the IKE to manage Mobile Router 
>>> Route Optimisation also appears to be an interesting approach. This 
>>> is very relevant to Aeronautical use.
>>>
>>> IKEv2/MOBIKE has limited multi-homing capability, in respect of 
>>> supporting the use of multi-homing for increasing availability. Load 
>>> sharing is not part of the current framework. The use of 
>>> multi-homing for increasing availability meets a perceived 
>>> aeronautical requirement to enable high availability of air/ground 
>>> communications through agility in the use of alternative networks. 
>>> Extension to load sharing seems to a suitable topic for future work, 
>>> but not essential for aeronautical use.
>>>
>>> The purpose of this paper is to develop an IPsec based RO strategy 
>>> suitable for aeronautical use and one that is also suitable for 
>>> similar transport infrastructure uses, but I believe the use of 
>>> IPsec based mobility management using IKEv2 and MOBIKE should be of 
>>> general interest.
>>>
>>> Regards
>>>
>>> Tony Whyman
>>>
>>>
>>>
>>> _______________________________________________
>>> MEXT mailing list
>>> MEXT at ietf.org
>>> https://www.ietf.org/mailman/listinfo/mext
>>>     
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> MEXT mailing list
>>> MEXT at ietf.org
>>> https://www.ietf.org/mailman/listinfo/mext
>>>     
>
>
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext