[address-policy-wg] RE: Question - Aviation

Jim

As I said, I remain 100% opposed to NAT and certainly don't intend to implement it in any way or cause it to be furthered.  A global "closed" network to me, means it requires both authentication to join and IPSec communication.

To me, it is simply easier to build, secure, and route a "closed" network if it is all made from a single global allocation rather than built from a collage of individual networks.

Take care
Terry

> -----Original Message-----
> From: Bound, Jim [mailto:Jim.Bound at hp.com]
> Sent: Tuesday, April 11, 2006 7:19 AM
> To: Davis, Terry L; CERASI Eivan; Tony Hain; PPML; address-policy-
> wg at ripe.net
> Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on IPv6");
> ROBERT Ollivier; narten at us.ibm.com; Brig, Michael P CIV DISA GES-E;
> Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI; Bound, Jim
> Subject: RE: [address-policy-wg] RE: Question - Aviation
> 
> Terry,
> 
> I respectfully disagree closed networks can interfere with true end-to-end
> and end-to-end security, if not done very carefully with IPv6.  Back at
> Digital we ran with global addresses (ok we had a Class A net 16) and
> implemented secure VPNs before they were popular in the late 80's and a
> form of IPsec with encryption.  We had all the benefits of Firewalls just
> no "ADDRESS TRANSLATION".  Your view of closed networks is far more
> dangerous than "potential" renumbering.  Any network with globally
> routable addresses can be firewalled and protected it is not rocket
> science. But at the same time permits the end-to-end secure IP layer 3
> model via IPsec as an option, which is the strongest security model we
> know of today from any cryptographer and black ops security analysts I
> speak with and quite often. This is also my position as SME (not HP) to
> the DOD per those furturistic networks for the GIG as one point of input
> to them .  The only way to have global end-to-end which all enties should
> want is to have a pool of globally routable addresses and never use NAT
> again on the planet.  That being said my view of Tony's proposal for PI
> space will not cause NAT but I want to be sure it is NAT bullet proof.
> Next to over abusive egoes/selfishness, elistism, and liars I think NAT is
> another great evil on the planet earth :--) (thats a joke ok).
> 
> /jim
> 
> > -----Original Message-----
> > From: Davis, Terry L [mailto:terry.l.davis at boeing.com]
> > Sent: Tuesday, April 11, 2006 10:02 AM
> > To: CERASI Eivan; Bound, Jim; Tony Hain; PPML;
> > address-policy-wg at ripe.net
> > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based
> > on IPv6"); ROBERT Ollivier; narten at us.ibm.com; Brig, Michael
> > P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM
> > CERDEC STCD SRI
> > Subject: RE: [address-policy-wg] RE: Question - Aviation
> >
> > Eivan
> >
> > I don't think that I suggested changing anything that would
> > really impact you all.  I just suggested the possibility of
> > formalizing the use of "closed networks" in my closing, I
> > would not expect it to impact you at all.
> >
> > Take care
> > Terry
> >
> > > -----Original Message-----
> > > From: CERASI Eivan [mailto:eivan.cerasi at eurocontrol.int]
> > > Sent: Tuesday, April 11, 2006 5:34 AM
> > > To: Davis, Terry L; Bound, Jim; Tony Hain; PPML; address-policy-
> > > wg at ripe.net
> > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based
> > on IPv6");
> > > ROBERT Ollivier; narten at us.ibm.com; Brig, Michael P CIV DISA GES-E;
> > > Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI
> > > Subject: RE: [address-policy-wg] RE: Question - Aviation
> > >
> > > Hello just to give you some status/complement on what we
> > are doing in
> > > Europe for air traffic management.
> > >
> > > EUROCONTROL (a European organization dealing with the safety of air
> > > navigation) has become LIR to obtain a /32.
> > >
> > > We have started using this address space for ground air traffic
> > > control unicast applications but take-up is slow due to the
> > nature of
> > > our environment.
> > >
> > > With regard to air-ground applications, we have launched
> > studies for a
> > > more global approach vis-à-vis air/ground applications and this is
> > > being performed in collaboration with ICAO working groups.
> > >
> > > Of course our primary goal is to enable an IP service for
> > air traffic
> > > control communications, not passenger nor airline
> > communications. As
> > > our environment is highly conservative, technology changes are very
> > > slow especially if they have to be global. Our European strategy is
> > > that IPv6 is our final target for all communications but
> > our X.25 will
> > > still be around for another few years and our IPv4 for even more.
> > >
> > > It is correct to state that our safety critical
> > applications operate
> > > in a closed environment as opposed to the use of classical
> > internet services.
> > > However we do have exchanges with internet customers (airlines) via
> > > dedicated means. Clearly, both IP routing environments are isolated
> > > from each other.
> > >
> > > To come back on one of the points that was raised below, I
> > do not see
> > > the benefit of creating a dedicated address space for such type of
> > > applications (just as  RFC1918 provides private address
> > space for IPv4).
> > > For me, it would just increase the end-user perceived
> > complexity of IPv6.
> > > In doing so, you would already cause us a problem of having
> > to change
> > > something we have already put into operations !
> > >
> > >
> > > Best regards
> > > Eivan Cerasi
> > >
> > > -----Original Message-----
> > > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-
> > > admin at ripe.net] On Behalf Of Davis, Terry L
> > > Sent: Monday 10 April 2006 22:13
> > > To: Bound, Jim; Tony Hain; PPML; address-policy-wg at ripe.net
> > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based
> > on IPv6");
> > > ROBERT Ollivier; narten at us.ibm.com; Brig, Michael P CIV DISA GES-E;
> > > Pouffary, Yanick; Green, David B RDECOM CERDEC STCD SRI
> > > Subject: [address-policy-wg] RE: Question - Aviation
> > >
> > >
> > > Jim/All
> > >
> > > I am going to respond in two parts here on PI issues; one
> > in terms of
> > > aviation and one in terms of corporate.  This one is on aviation.
> > >
> > > The next two paragraphs are from an original response to Thomas
> > > Narten, that I didn't see make the list.
> > >
> > > ----
> > > I view systems that run "critical infrastructure" entirely
> > different
> > > from those used to run anything else; especially systems that can
> > > directly impact the safety of the people using or relying on them.
> > >
> > > Safety engineering is just like security engineering; both
> > depend on
> > > our ability to build in layers of defense and reliability trying to
> > > never rely entirely on a single system.  By forcing an
> > industry like
> > > aviation to accept the potential of address changing in a global
> > > fleet, an element of extreme risk is added as the system's
> > overall reliability is decreased.
> > > ----
> > >
> > > We know that in the next decade that there will be development
> > > initiated for a new air traffic control system.  It will likely be
> > > built upon IP and if so, likely IP-v6.  And ICAO currently has a
> > > working group studying this and the committee is leaning
> > towards IP-v6
> > > although there is a strong component that is pushing for
> > IP-v4 and a
> > > continuation the NAT type usage currently required in the aviation
> > > industry by Arinc 664. And I do definitely agree with Jim here, the
> > > use IP-v4 and NAT would create huge risks; if in nothing else, the
> > > potential for mis-addressing through one of the hundreds of
> > NAT gateways that would be required.
> > >
> > > I'll respectfully disagree with Jim in that I believe
> > address change
> > > in a complex global system like air traffic control can create a
> > > hazard. Keep in mind, that the air traffic control system spans
> > > virtually every nation on globe and most everything manmade that
> > > flies.  Likewise the technical and operational capabilities
> > vary from
> > > extraordinary to very minimal; like the 30 or so aviation operators
> > > that the EU just banned from flying into EU countries
> > because of their
> > > poor safety and maintenance performance record.
> > >
> > > Coordinating an address change across this type of
> > infrastructure with
> > > aircraft and ground infrastructure in almost every nation on the
> > > globe, is simply beyond my ability comprehend.  Assuming the
> > > technology would work flawlessly (discussed below), the politics of
> > > when and how to implement the change would likely end up on
> > the floor of the UN for debate.
> > > Likewise, if a decision was made to implement a change, we would be
> > > dealing with such different levels of expertise around the
> > world that
> > > no amount of pre-planning could ensure that implementation failures
> > > would not occur.
> > >
> > > Now just a bit about where ATC systems are likely going and
> > why their
> > > criticality will likely grow over the next couple decades.
> > Unless we
> > > suddenly develop anti-gravity capabilities to allow slow vertical
> > > takeoffs, we are stuck with the airports we have and only minimal
> > > abilities to expand them (cost, environmental, noise, etc).
> >  The only
> > > real way we can expand their capacity is with bigger airplanes and
> > > more flights.  The "more flights" part is where this gets
> > complicated
> > > and critical.  To handle more flights, we have to decrease
> > landing and
> > > takeoff separations and speed up aircraft ground movements so an
> > > airport can handle more aircraft per hour.  We are about to human
> > > capacity with the current systems which means that these
> > improvements
> > > will need to move more and more to relying on precise
> > control systems;
> > > a minutes interruption here will be a really big deal.
> > >
> > > Also we as an industry are just beginning to migrate from bus data
> > > communications on the aircraft to networks.  The commercial
> > aircraft
> > > flying today are already largely computer controlled and as I
> > > mentioned above we try very hard not design the aircraft to be
> > > critically reliant on any one system.  In almost all cases, it
> > > requires a cascading series of failures to present an
> > aircraft with a
> > > catastrophic hazard.  Now as I said, we are starting to put
> > networks
> > > on the aircraft and as Arinc 664 shows; we are not the world's
> > > greatest network engineers (at least not yet..).  In a
> > decade or so, we will have hundreds of networked systems on
> > an aircraft.
> > > I think the risk here in re-addressing is clear; how well will they
> > > all react.  And yes we can probably take most of the risk down in
> > > certification testing but keep in mind variation in technical
> > > competence of the operators around the world and that we are
> > > continually accepting upgraded systems from our vendors as
> > replacement
> > > parts and this could also inject potential failures in
> > re-addressing.
> > >
> > > If we were to use 3178 without a single global address
> > space, I still
> > > don't think this would scale as we then would be using
> > probably in the
> > > neighborhood of 50 or more ISP's (you don't always get to pick your
> > > ISP's and while a country might accept addressing from an industry
> > > block, they'd probably insist on using theirs otherwise) around the
> > > world for the service.  And the way I read it, I would
> > still have lots
> > > of unnecessary backhauling to the other side of the planet and some
> > > very complicated policy routing to set up.  Besides and
> > then with mix
> > > of address spaces, I would probably be perpetually leaking with the
> > > global Internet in what should be a closed network.
> > >
> > > Finally at the moment with our existing certification
> > processes, I'm
> > > not sure that we would even be permitted to change the aircraft
> > > addresses without re-issuing all the affected software with
> > new part
> > > numbers. (I'll bet you assumed we used DHCP to address the current
> > > aircraft; nope we hard code address everything, remember "bus
> > > engineering" 101 ;-) With today's current rules, we haven't put any
> > > "critical systems" on anything but a closed onboard
> > network.  We are
> > > just discussing the ability upload new IP_tables/firewall-rules and
> > > authentication certs/passwords to the non- critical networks and I
> > > believe that this will be solved in the next couple years.  And now
> > > also keep in mind that every aviation rule-making body around the
> > > world would also have to approve of the address change for
> > an ATC network and define how they were going to certify the change.
> > >
> > >
> > ======================================================================
> > > Finally now having said all this Jim, I think it is possible for
> > > aviation to remain conforming.
> > >
> > > We have probably only two primary needs for stable IP addressed
> > > networks; one for Air Traffic Control and one for Airline
> > Operations.
> > > These are industry traffic type designations that have
> > safety related
> > > functions that are carried out over them.  As we have discussed
> > > before, I expect both of them to be run as "closed networks" and
> > > should never
> > > (IMHO) be seen in the global routing tables; a closed network will
> > > provide them with a layer of security, better routing
> > performance, the
> > > multi- homing that an aircraft needs, and more options for
> > mobility solutions.
> > >
> > > Further, two organizations already exist that could
> > legitimately hold
> > > the addresses; ICAO for the ATC network as they already
> > govern it and
> > > the AEEC for "airline operations" whose members already
> > essentially own "Arinc"
> > > which is an ISP already.  If it were possible to convince
> > these orgs,
> > > to apply for space and the registries to grant them, that
> > would seem
> > > to be a solution.
> > >
> > > Take care
> > > Terry
> > >
> > > PS: Apologies for the length..
> > >
> > > PSS: Back to "critical infrastructure" networks a moment,
> > I'd say that
> > > any network that wanted to declare itself "critical infrastructure"
> > > could obtain PI space, BUT to me this type of network
> > should always be
> > > run as a "closed network" with exchanges to the Internet
> > only through
> > > "mediation gateways" operating at the application level,
> > not at the routing level.
> > > Just food for thought but perhaps there is a class of IP-v6
> > networks
> > > for "critical infrastructure" that have their own PI space, but are
> > > prohibited from the participating in "Internet routing". Such a
> > > concept might solve lots of problems.
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Bound, Jim [mailto:Jim.Bound at hp.com]
> > > > Sent: Saturday, April 08, 2006 5:52 AM
> > > > To: Tony Hain; PPML; address-policy-wg at ripe.net
> > > > Cc: Richard Jimmerson; Latif Ladid ("The New Internet based on
> > > > IPv6"); Davis, Terry L; ollivier.robert at eurocontrol.fr;
> > > > narten at us.ibm.com;
> > > Brig,
> > > > Michael P CIV DISA GES-E; Pouffary, Yanick; Green, David B RDECOM
> > > CERDEC
> > > > STCD SRI; Bound, Jim
> > > > Subject: RE: Question
> > > >
> > > > Tony,
> > > >
> > > > Excellent response and educational for sure.  It is my
> > belief that
> > > > the corporate business model today for operating networks may be
> > > > broken
> > > and
> > > > I think you supported that below?  If not my apologies for bad
> > > parsing?
> > > >
> > > >
> > > > Their models were fine for an IPv4 world where NAT was
> > required and
> > > some
> > > > even confuse NAT with securing ones network (and some programs in
> > > > the U.S. Government) and that is simply bad policy and view.
> > > >
> > > > In the interim can this be resolved by RIRs creating some kind of
> > > > additional wording that address reclaim will be done in
> > manner that
> > > > is negotiable, and do no harm to corporate or government business
> > > > operations?  This would buy us time to work on the issue and stop
> > > > the FUD around this topic?
> > > >
> > > > Also I am willing to sponsor a world wide IPv6 Forum BOF
> > on PI and
> > > > addressing you can lead as ajunct to one of our regular
> > meetings you
> > > can
> > > > lead for an entire day and we get the right players in
> > the room.  So
> > > > think about that as another option too.
> > > >
> > > > But do enjoy the beach this thread does not have to be
> > resolved this
> > > > week :--)
> > > >
> > > > Really want to hear from all of you and discussion Terry
> > D., Latif,
> > > > Yanick, Dave G. Mike B. etc.
> > > >
> > > > Thanks
> > > > /jim
> > > >
> > > > > -----Original Message-----
> > > > > From: Tony Hain [mailto:alh-ietf at tndh.net]
> > > > > Sent: Friday, April 07, 2006 7:57 PM
> > > > > To: 'PPML'; address-policy-wg at ripe.net
> > > > > Cc: 'Richard Jimmerson'; Bound, Jim; 'Latif Ladid ("The New
> > > > > Internet based on IPv6")'; 'Davis, Terry L';
> > > > > ollivier.robert at eurocontrol.fr; narten at us.ibm.com;
> > 'Brig, Michael
> > > > > P CIV DISA GES-E'; Pouffary, Yanick; 'Green, David B
> > RDECOM CERDEC STCD SRI'
> > > > > Subject: RE: Question
> > > > >
> > > > > A public answer to a private question as I have been
> > sitting on a
> > > > > beach for awhile without the laptop and missed some related
> > > > > conversations ... :)
> > > > >
> > > > > > Is the outcome really open for discussion on the PI issue?
> > > > > It doesn't
> > > > > > sound like it is.
> > > > >
> > > > > In the minds of some the route scaling issue outweighs any
> > > > > argument for PI. When taken to its extreme, there is a
> > valid point
> > > > > that a broken routing system serves no one. At the same
> > time the
> > > > > dogmatic stance by the ISPs enforcing lock-in is just as broken
> > > > > both for large organizations with financial or legal
> > requirements
> > > > > for operational stability, and the individual consumer/small
> > > > > business with limited budgets looking for true competition. The
> > > > > hard part is finding the middle ground in a way that limits the
> > > > > exposure to a potential routing collapse.
> > > > >
> > > > > I personally refuse to declare some needs legitimate and others
> > > > > not, as the only point of such differentiation is to
> > establish a
> > > > > power broker. When all uses are legitimate, the problem
> > boils down
> > > > > to the technical approach that can be scaled as necessary to
> > > > > contain growth in the routing system. This is the logic
> > that leads
> > > > > me to the bit-interleaved geo that can be aggregated in varying
> > > > > size pockets as necessary using existing BGP
> > deployments. We can
> > > > > start flat and implement aggregation over time when a region
> > > > > becomes too large to handle. One nice side effect of this geo
> > > > > approach is that it mitigates the continuing political
> > demands for
> > > > > sovereign rights to IPv6 space.
> > > > >
> > > > > Any aggregation approach will force the business models
> > to change
> > > > > from current practice. That is not as bad a thing as
> > the alarmists
> > > > > will make it out to be, because their accountants are
> > claiming the
> > > > > current model is a broken money looser as it is (which
> > if so means
> > > > > they will eventually change anyway). The primary difference is
> > > > > that there will need to be aggregation intermediaries
> > between the
> > > > > last-mile and transit providers. The current model eliminates
> > > > > these middle-men by trading off their routing
> > mitigation service
> > > > > against a larger routing table (actually they already
> > exist in the
> > > > > right places but are currently limited to layer2 media
> > > > > aggregators). The anti-PI bunch is trying to use social
> > > > > engineering to directly counter the bottom line
> > business reality
> > > > > that the customer will always win in the end.
> > > > > Rather than accept this situation and constructively
> > work on the
> > > > > necessary business model and technology developments, they
> > > > > effectively stall progress by staunchly claiming there is no
> > > > > acceptable technical approach that works within the current
> > > > > business structure.
> > > > >
> > > > > Making the RIRs be the police deciding who qualifies for PI and
> > > > > who does not just adds to their workload and raises costs. The
> > > > > beneficiaries of this gatekeeper approach are the ISPs
> > that claim
> > > > > they need full routing knowledge everywhere, while the
> > cost burden
> > > > > for supporting the waste-of-time
> > qualification/evaluation work is
> > > > > borne by the applicant. Given that the most vocal and organized
> > > > > membership in the RIR community are the ISPs it is easy to
> > > > > understand why it would seem like the PI issue is
> > already decided
> > > > > as closed. I tend to believe it will just drag out
> > until enough of
> > > > > the corporate world becomes aware of the IPv4
> > exhaustion in light
> > > > > of their growth needs that they collectively appear at
> > their RIR
> > > > > and demand an immediate solution. Unfortunately this 'wait till
> > > > > the last minute' tactic will likely result in a reactionary
> > > > > quickie with its own set of long term side effects.
> > > > >
> > > > > A while back I tried to hold a BOF on geo PI in the
> > IETF, but was
> > > > > told that shim6 was the anointed solution. Now that at
> > least nanog
> > > > > has told the IAB where to put shim6 it might be possible to get
> > > > > the current IESG to reconsider. In any case the result
> > would be a
> > > > > technical approach that would still require RIRs to establish
> > > > > policies around. As long as they are dominated by the
> > ISPs it will
> > > > > be difficult to get real PI.
> > > > >
> > > > > Tony
> > > > >
> > > > >
> > >
> > > ____
> > >
> > > 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.
> > >
> >
> >