Re: [MEXT] A Proposed Solution for Aeronautical RO

[marcelo bagnulo <marcelo at it.uc3m.es>]

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