Re: [MEXT] A Proposed Solution for Aeronautical RO

[Carlos Jesús Bernardos Cano <cjbc at it.uc3m.es>]

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.

	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
-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

Attachment: signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext