Subject: [MEXT] A Proposed Solution for Aeronautical RO

From: Tony Whyman <[email-masked]>
Date: Fri, 04 Apr 2008 12:22:31 +0100

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 11 Apr 2008 00:28:11 +0200

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

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 11 Apr 2008 00:36:05 +0200

> understood in the last MEXT interim meeting that changing the CNs was
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

>> ------------------------------------------------------------------------
>>

---

From: Tony Whyman <[email-masked]>
Date: Fri, 11 Apr 2008 10:34:12 +0100

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:
>>> 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.
>>>
>>> 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).
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Updates are no longer needed here. Again, this is not of direct 
>>> interest to aeronautical communications, but should be of wider 
>>> interest.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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
>>>
>>>
>>>

---

From: "Carlos Jesús Bernardos Cano" <[email-masked]>
Date: Fri, 11 Apr 2008 12:29:27 +0200

Hi Tony,

  Thanks for your reply. Please, see my comments below.

On 11/04/2008, Tony Whyman <[email-masked]> wrote:
> 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.

  I mean requiring some new extension/mechanism that is not supported
by standard IPv6 nodes.

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

I was not saying I disagree with that :-).

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

  Well, that's different from what I understood in the MEXT itnerim
meeting. Maybe I'm wrong, but I think the question regarding modifying
the operation of CNs was specifically asked and the answer was that it
is not possible.

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

I'm not against "big" changes in controlled environments as the
aerospace one, but I just  want to know whether those changes could be
made or not.

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

Do all the people have the same view on that?

Thanks a lot.

Regards,

Carlos

> > 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
> > >
> meet the requirements contained in draft-ietf-mext-aero-reqs-01. The paper
> can be downloaded from:
> > > >
> > > >
> aeronautical use cases. Appendix B also provides a compliancy check against
> draft-ietf-mext-aero-reqs-01.
> > > >
> 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).
> > > >
> 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
> 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.
> > > >
> 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.
> > > >
> 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.
> > > >
> 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.
> > > >
> 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.
> > > >
> 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.
> > > >
> 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.
> > > >
> 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.
> > > >
> 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.
> > > >
> 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.
> > > >
> set of SA Traffic Selectors for MN to SA tunnels. If a PKI exists that
> 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.
> > > >
> 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.
> > > >
> 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
> > > >
> > > >
> > > >

---

From: marcelo bagnulo <[email-masked]>
Date: Sun, 13 Apr 2008 21:33:06 +0200

> aerospace one, but I just  want to know whether those changes could be
 From what i understand, the question on whether updating CNs in the ATS 
domain to support nemo RO was explicitly asked several times and the 
question in all cases was:
- it may be possible sometimes, but any accetable solution MUST be able 
to work with unchanged (legacy IPv6) CNs and offloading the nemo RO 
processing to a proxy box topologically near.

Wes, is my understanding correct? has this been expressed in the 
requirements document? would it be in the next version? I think that it 
is important to nail these requirements down, including all the relevant 
informaiton there (in particular with respect to this issue which seems 
very imporntat), cause, if not people working in solutions are not able 
to design properly

Regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 14 Apr 2008 10:31:48 +0200

Please let me jump in this discussion. I didn't attend last IETF 
meetings and didn't follow all the discussion, but to me, what we stand 
on is:

1. There is a trade-off between unchanged CNs and NEMO Basic Support 
(RFC 3963): NEMO Basic Support has been designed so that CNs (and MNNs, 
etc) are left unchanged so that even though the solution is not optimal 
there is always a possibility to deal with legacy CNs. So, it is 
acceptable to request changes for a RO solution (which MUST NOT prevent 
the use of NEMO Basic Support)

2. We have always said that while leaving CNs unchanged is recommended, 
it is acceptable to require extended features on the CNs to perform RO

3. If there are 2 solutions of an acceptable quality and one of these is 
  keeping the CNs unchanged, that one should be selected.

Regards,
Thierry.

---

From: "CERASI Eivan" <[email-masked]>
Date: Mon, 14 Apr 2008 17:26:54 +0200

Hi, I have the same understanding of where we are.

Looking back at my notes of the interim meeting in Madrid, we discussed
the CN part under the "solution space".

Maybe, Wes can plan adding some of the below words into a document
update ?

Regards,
Eivan Cerasi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thierry Ernst
Sent: Monday 14 April 2008 10:32
To: [email-masked]
Subject: Re: [MEXT] Changes in the CNs (was Re: A Proposed Solutionfor
AeronauticalRO

Regards,
Thierry.

marcelo bagnulo wrote:
>> aerospace one, but I just  want to know whether those changes could 
>> be made or not.
>>
>>   
>  From what i understand, the question on whether updating CNs in the 
> ATS domain to support nemo RO was explicitly asked several times and 
> the question in all cases was:
> - it may be possible sometimes, but any accetable solution MUST be 
> able to work with unchanged (legacy IPv6) CNs and offloading the nemo 
> RO processing to a proxy box topologically near.
> 
> requirements document? would it be in the next version? I think that 
> it is important to nail these requirements down, including all the 
> relevant informaiton there (in particular with respect to this issue 
> which seems very imporntat), cause, if not people working in solutions

> are not able to design properly
> 
> Regards, marcelo
> 
> 

____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Mon, 14 Apr 2008 14:49:52 -0500

I have the same understanding.  I believe the current draft implies this, but we
can easily make it explicit in the update.  Also, we need to be explicit about
the difference between PIES and ATS/AOS in this regard.

________________________________

From: [email-masked] on behalf of CERASI Eivan
Sent: Mon 4/14/2008 10:26 AM
To: [email-masked]
Subject: Re: [MEXT] Changes in the CNs (was Re: A ProposedSolutionfor AeronauticalRO

Regards,
Eivan Cerasi

-----Original Message-----

Regards,
Thierry.

____

---

From: marcelo bagnulo <[email-masked]>
Date: Tue, 15 Apr 2008 15:34:09 +0200

Hi Thierry,

I think we have a small difference on the level of the requirement.

I understood from comments of the aero community that in some cases it 
would simply be impossible to update the CNs (while there would some 
cases where it would be possible to do that)

So, afaiu, the requirement was that a solution for being suitable for 
the aero community must be possible to run it in a proxy for the CN, so, 
that unchanged CNs are supported.

This is not a nice to have feature to compare two solutions, but that a 
solution that doesn't have this is simply a non starter.

But i may have misunderstood what people expressed (BTW this is what i 
recall from the madrid interim, no disucssion on this particular itme in 
philly)

Regards, marcelo

Thierry Ernst escribió:
> meetings and didn't follow all the discussion, but to me, what we 
> stand on is:
>
> (RFC 3963): NEMO Basic Support has been designed so that CNs (and 
> MNNs, etc) are left unchanged so that even though the solution is not 
> optimal there is always a possibility to deal with legacy CNs. So, it 
> is acceptable to request changes for a RO solution (which MUST NOT 
> prevent the use of NEMO Basic Support)
>
> 2. We have always said that while leaving CNs unchanged is 
> recommended, it is acceptable to require extended features on the CNs 
> to perform RO
>
> 3. If there are 2 solutions of an acceptable quality and one of these 
> is  keeping the CNs unchanged, that one should be selected.
>
> Regards,
> Thierry.
>
> marcelo bagnulo wrote:
>> which seems very imporntat), cause, if not people working in 
>> solutions are not able to design properly
>>
>> Regards, marcelo
>>
>>

---

From: <[email-masked]>
Date: Thu, 24 Apr 2008 09:28:48 +0200

Dear Tony,

Having read through your proposal, I have some remarks.

1. "No Authentication SA"
You propose to provide a kind of "null AUTH" inside the IKE_AUTH message so that authentication of the Mobile Node can be omitted. However, to at least provide assurance that the HoA is valid, you suggest running the initial IKE exchanges with the HoA as source address and therefore over the Home Agent and switch to the CoA later on, based on MOBIKE.

In this case, the latency is not better than that in MIPv6 RR, that you say is not efficient: 2 RTTs for the IKE exchange over the HoA, one for updating the SA address with MOBIKE and an additional one for the RR procedure for validating the new CoA. This results in 4 RTTs - more than in MIPv6 with BU/BA exchange followed by RR and BU/BA, making it 3 RTTs.

2. "Authenticated SA"
I assume this is the first part of the mechanism the draft presents as the main solution, as opposed to the "Non Authenticated SA".

It is heavily worded on Mobile Hosts/Home Addresses instead of Mobile Routers/Mobile Network Prefixes.
You mention setting Traffic Selectors to routes (=prefix instead of a single address?) for the Mobile Router and, later on, that NAT traversal is implicitly possible. IIRC in the case of NAT traversal, the Traffic Selectors can only consist of a single IP address, and not of a range.

3. "Host to Subnet Transport Mode"
This is an evolution to the "No Protection SA", based on creating a new IKE Child SA alongside the existing AH/ESP options?

At this stage I started to wonder about the relationship of your proposal and MIPv6/NEMO.
If instead of using a Home Address Option/Type 2 Routing Header you introduce an arbitrary Type X and Y Routing Header and you stick to the "Authenticated SA with permission to use the HoA", this is completely independent of MIPv6/NEMO.

In addition you assume that the Mobile Router not just performs the mobility signalling but also the end2end IPsec management.

Your key idea is to modify IKEv2 so that instead of just setting up IPSec related SAs it becomes a more generic framework, independent of MEXT that can be used for mobility purposes.
I am wondering whether these modifications on IKEv2 (that extend its purpose) are within the scope of the working group?

Christian

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
> Tony Whyman
> Gesendet: Freitag, 4. April 2008 13:23
> An: [email-masked]
> Betreff: [MEXT] A Proposed Solution for Aeronautical RO
> 
> Dear all,
>