Subject: [MEXT] changes in the CNs

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

Hi,

People have pointed out ot me offline what are the constraints expressed 
during the interim meeting by the aero people.

The limitation is not related with software update for the CNs, but with 
establishing trust with all of them.

This is already covered by the current draft, which states:

   It is also reasonable to assume trust relationshiops between each MR
   and a number of mobility anchor points topologically near to its CNs
   (these anchor points may be owned by the service providers), but it
   is not reasonable to assume that trust relationships can be
   established between an MR and any given CN itself.

So, at this point, i think that the requirements w.r.t. the changes in the CNs is as Thierry nicely 
expressed in his email, but there is the other constrain, which is the one i have pointed out above.

Regards, marcelo

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Tony Whyman <[email-masked]>
Date: Tue, 15 Apr 2008 17:21:50 +0100

Marcelo,

Seems an odd assumption to me. The one thing that you can usually assume 
in ATC is that there is a trust relationship between an aircraft (MR) 
and the ATC Centre (CN).

Regards

Tony

marcelo bagnulo wrote:
> Hi,
>
> People have pointed out ot me offline what are the constraints 
> expressed during the interim meeting by the aero people.
>
> The limitation is not related with software update for the CNs, but 
> with establishing trust with all of them.
>
> So, at this point, i think that the requirements w.r.t. the changes in 
> the CNs is as Thierry nicely expressed in his email, but there is the 
> other constrain, which is the one i have pointed out above.
>
> Regards, marcelo
>
>
>
>

---

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

FWIW, i am just repeating what people have expressed in the meeting.

below...

Tony Whyman escribió:
> Marcelo,
>
> Seems an odd assumption to me. The one thing that you can usually 
> assume in ATC is that there is a trust relationship between an 
> aircraft (MR) and the ATC Centre (CN).
>
right, there is trust between the MR and the ATC center, but not with 
every CN within the network, since it seemed that the provision of trust 
(like provisioning of certificates) would be hard for every CN. It is 
acceptable though t provision a certificate for a single node within a 
given network that acts like a proxy for the CNs topologically close, 
makes sense?

regards, marcelo

>> So, at this point, i think that the requirements w.r.t. the changes 
>> in the CNs is as Thierry nicely expressed in his email, but there is 
>> the other constrain, which is the one i have pointed out above.
>>
>> Regards, marcelo
>>
>>
>>
>>
>

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Tue, 15 Apr 2008 11:41:19 -0500

>-----Original Message-----
>From: marcelo bagnulo [mailto:[email-masked]] 
>Sent: Tuesday, April 15, 2008 12:28 PM
>

I think the consensus was that in the long-term, what Tony says will
be the case, but in the nearer-term (next several years), the PKI
will not yet be deployed and it is unclear how long it will take to
get it rolled out globally to all ANSPs and equipment.

This is a parallel/supporting effort whose website and minutes may be
of interest:
https://www.jcg.aero/index.php
Hugh Mote, who has been participating in MEXT meetings is active there.
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Apr 2008 10:29:32 -0700

Wesley, 

>get it rolled out globally to all ANSPs and equipment.

I don't have much knowledge in this space, but I am wondering
about the PKI. Would it be feasible to deploy pre-placed keys
even before a PKI becomes generally available?

Thanks - Fred
[email-masked]
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Tony Whyman <[email-masked]>
Date: Tue, 15 Apr 2008 19:14:08 +0100

Wesley,

Thanks for clarifying that.

The moto of the ATC Business is "if it ain't broke don't fix it" and I 
would expect any deployment of ATN-IP to respect this and follow the 
same roll out pattern as ATN-OSI - after all if it worked once...

That model started with years of prototypes and trials, followed by a 
deployment programme that recruited a core set of pioneer airlines in 
Europe around a single ATC Centre, in order to help prove the system and 
give the vendors a chance to develop stable products. Only now has the 
full roll out programme begun, backed by a mandate that will apply to 
all aircraft flying above FL280. Start to finish was around 16 years.

Expect the same to happen with an ATN-IP. There will be several years of 
trials and prototypes before some pioneer airlines start to use it. Only 
once the system is proven and demonstrated to be at least as safe as the 
current system, would full roll out begin. Hopefully the experience 
gained first time around would be used to speed the process up - but how 
much is another matter.

During the trials and prototypes phase only a local PKI is required and 
expect it to be refined several times during the learning process. Even 
during the pioneer phase, only a local PKI would be required, but its 
implementation should anticipate the later roll out to first regional 
use and then global.

So, you can see why I have a relaxed view about PKI deployment.

Regards

Tony

---

From: marcelo bagnulo <[email-masked]>
Date: Wed, 16 Apr 2008 10:47:05 +0200

I see your point. However, it does sounds like a reasonable feature to 
ask to be able to run whatever mechanism we define in proxy mode, 
doesn't it?

Tony Whyman escribió:
> Europe around a single ATC Centre, in order to help prove the system 
> and give the vendors a chance to develop stable products. Only now has 
> the full roll out programme begun, backed by a mandate that will apply 
> to all aircraft flying above FL280. Start to finish was around 16 years.
>
> Expect the same to happen with an ATN-IP. There will be several years 
> of trials and prototypes before some pioneer airlines start to use it. 
> Only once the system is proven and demonstrated to be at least as safe 
> as the current system, would full roll out begin. Hopefully the 
> experience gained first time around would be used to speed the process 
> up - but how much is another matter.
>
> During the trials and prototypes phase only a local PKI is required 
> and expect it to be refined several times during the learning process. 
> Even during the pioneer phase, only a local PKI would be required, but 
> its implementation should anticipate the later roll out to first 
> regional use and then global.
>
>>> From: marcelo bagnulo [mailto:[email-masked]] Sent: Tuesday, 
>>> April 15, 2008 12:28 PM
>>>

---

From: Tony Whyman <[email-masked]>
Date: Wed, 16 Apr 2008 09:52:13 +0100

Dear all,

 From some off list discussions that have taken place, I get the feeling 
that different people focus on different issues when the term "global 
PKI" is mentioned. There is thus a need to agree on the interpretation 
of the term "global PKI".

Firstly, there is a clear need to separate out discussion on the 
technology used (certificate formats, digital signature algorithms, 
etc.) from the process of issuing certificates (politics).

In my paper and posts, I have assumed an evolutionary approach to both, 
with a single global PKI being the logical outcome of this process. On 
the other hand, I have no problem in conceding that the move from 
regional to a single global PKI may have political issues associated 
with it, in the sense that one CA may have problems recognising the 
validity and integrity of the process performed by another CA. It may 
thus be a very long evolutionary process.

My proposal is thus that the requirement for an aviation global PKI is 
interpreted as a need for a core common PKI technology supporting a 
number of regional PKIs, with a long term objective of evolving into a 
single global PKI.

My assumption here is that the main problem in establishing a regional 
PKI is technology, while joining the regions together to form a single 
global PKI is a political problem. A region is thus self-defining.

The practical implication is that an aircraft will need a certificate 
for each region in which it operates and will need to be able to 
validate certificates presented to it issued by the CAs responsible for 
those regions. Implementations will have to be able to work with 
multiple certificates and CAs. Only when CAs start issuing 
cross-certificates for each other, will the number of certificates that 
an aircraft needs, be reduced.

The issuing of the cross-certificate is where the political issue arises 
as will only be done when a given regional  CA is fully satisfied as to 
the validity and integrity of the process performed by another regional CA.

Regards

Tony Whyman

---

From: <[email-masked]>
Date: Wed, 16 Apr 2008 12:31:37 +0200

Hi,

the idea of the related sentence in Section 3.8.1. in the requirements document is to reduce the set of nodes to whom the MR has a trust relationship with (wrt certificates) to one where it is guaranteed that it will work and the certificates are stable and reliable.

Extending it to the CNs involves problems and assuming a distributed PKI with numerous CAs for the future in aviation has its own problems, like the complex building of certification paths in case of bridges, using the correct certificate or problems with certain local policies. Given a certificate is not accepted at the CN (for whathever reasons) there must still be a way communication can take place, and having RO is necessary for this purpose.
Fact is no one knows when an "end2end" PKI is available and how reliably it will work. Basing the *primary* RO solution on such an assumption seems dangerous and as the requirements document says "anchor points may be owned by the service providers" it seems reasonable to take advantage of airlines and communication service providers having contracts with each other for the purpose of RO.

Christian

-----Ursprüngliche Nachricht-----
Von: [email-masked] im Auftrag von Tony Whyman
Gesendet: Mi 16.04.2008 10:52
An: [email-masked]
Betreff: [MEXT] Global PKIs ( was Re:  changes in the CNs)
 
Dear all,

Regards

Tony Whyman

---

From: Tony Whyman <[email-masked]>
Date: Wed, 16 Apr 2008 15:51:31 +0100

Christian,

Your comment "Given a certificate is not accepted at the CN (for 
whatever reason) there must still be a way communication can take 
place..." reminds me of a now deleted requirement in the original ATN 
SARPs. This was titled "Emergency use of a Mobile Subnetwork" and 
basically said that if an aircraft calls within 5 mins of comms being 
rejected, it must be accepted - at least for emergency use (knock twice 
and you're in). Without qualifying what "an emergency" was, this 
requirement was aimed at ensuring comms would be available. I was 
certainly present at the meeting that agreed this, and the requirement 
reads as if I wrote it - but I can't remember that degree of detail. The 
point is, it was later deleted once the operational people got involved.

The comms group that wrote the original SARPs thought like you do (like 
I did), that there must always be a way for data link communication to 
take place. The operational people beg to differ. If you look at the way 
the European system works today, data link equipped aircraft must 
explicitly identify themselves to the ATC Provider and, unless they are 
on a list of approved aircraft, they will be rejected for data link service.

The reason for this is air safety. The ATC Provider needs to be sure 
that the aircraft's data link implementation has been properly certified 
and approved for use. Data link is supplementary to a general 
certificate of air-worthiness and hence must be separately verified An 
aircraft that does not have certified equipment on board, or is from an 
airline whose pilot procedures for use of data link have not been 
approved, may be a hazard to other airspace users. Hence service denied.

What happens to the aircraft? It must have a working VHF radio and hence 
can still be offered voice based ATC services. At present, ATC for that 
aircraft is simply less efficient than it should be. In the future, this 
will mean that the aircraft will be limited in its choice of airspaces 
and will probably have to bump around at 20,000 feet.

However, there is another problem lurking here and that is that the 
current ATN-OSI was designed around the open access principle. The 
current system cannot provide a proof of identity. This is acceptable 
for the present, partly because the ATN-OSI protocols are not part of 
every Linux distribution and hence there is a technical barrier to 
overcome for any attacker, and partly because of high quality 
Surveillance from SSR Mode S radars. Controllers can readily spot any 
discrepancy between data comms, voice comms and the Airspace picture.

A move to ATN-IP potentially removes one of those props and simply by 
using industry standard protocols without any mitigation, weakens the 
system. It also makes it difficult to realise any cost savings by 
reducing dependency on SSR Mode S.

An important Operational Requirement was missed first time around and it 
seems to me fairly obviously that now the requirement is known, any 
ATN-IP must respect it. That is identity of aircraft must be visible to 
the ATC Provider, and credentials offered that support that identity. 
This is so that Data Link ATC Service is not given to unapproved aircraft.

There is a validated ATN-OSI specification (PKI based) to add a proof to 
the identity. The business case for this enhancement is not there yet - 
but one day it will be - if only because having a signed certificate 
will be easier to manage than an ever growing list of approved aircraft. 
It would be nice if you can put the case: rather than investing more in 
the old system, why not put the money into deploying ATN-IP.

You may argue that a Service Provider could still be a proxy and check 
the identity on behalf of the ATC Provider. But think of the liability 
issues. I doubt whether the risk of getting this wrong is insurable.

Hence my own view that any ATN-IP has to start from the assumption that 
there is a direct trust relationship between the ATC Provider and the 
aircraft it serves. IPsec supported by an appropriate PKI appears to be 
the correct way of realising this.

Regards

Tony