[MEXT] A Proposed Solution for Aeronautical RO

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

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