www.information.aero dac 7 progress report: b2b applications april 19, 2005 geneva

www.information.aero

DAC 7Progress report: B2B

applications

April 19, 2005

Geneva

DAC 7 Progress report: B2B applications| Slide 2 www.information.aero

“To create a structured, open and constantly evolving Internet naming architecture which helps the aviation

community to integrate systems and services, and streamline communications within the community and with

its partners“

Mission of .aero


A short note before we start …

• Parts of this presentation were developed in close co-operation with airlines, many examples refer to airlines or airline systems

• The concepts discussed here are relevant to other sectors of the air transport community, particularly areas where industry codes or community standards exist like

– Airport operators– FBOs– Aerospace manufacturers– Etc.


What’s happening in the industry?

• Paradigm shift from ticketing to e-ticketing– E-ticked stored in the database of the validating carrier

– Intensive system to system communications needed

• Possible paradigm shift in baggage processing

• Alliances, changes in alliances, many business partners– Time to market depends on the speed in setting up connections with business partners

• Convergence, shift to Internet, increasing importance of DNS– Some airlines already require business partners to publish service locations in DNS


Why change ?

• Air transport companies traditionally had rigid standards for inter-system communications pinned to the underlying centralized network

• The network has become a commoditised service with elements of the service being provided by disparate third parties

• IP comms over the Internet are becoming the de facto standard for business to business transactions

• In the absence of well defined standards, the airlines are establishing bilateral or multilateral mechanisms to connect their systems over IP networks and increasingly rely on a small number of hubs to gateway between their systems.

• This complexity restricts the flexibility and scalability and will affect time to market for new relationships and functionality


What will happen anyway ?

• Moving forward there will be a number of different solutions to each communications requirement

• Many air transport companies will end up solving the same problems in similar ways independently

• Issues for scalability will be service / application location and communications protocol standards

• Move to internet communications is inevitable in the longer term

• There is an opportunity to leverage existing open standards as part of a next generation solution for airline inter-connectivity


How .aero fits in ?

• The use of DNS is growing exponentially

– Globally accessible distributed database, distributed management– Allows to map names to “anything on the Net”– New security protocol addresses many security concerns

• .aero can be the uniting factor for the community

– Names can be allocated in a structured manner, matching codes– Standards can be agreed and deployed

InternetHostnames

Intranet names

Windows 2000services

IETFAnti-SPAM

RFIDtags

1988 2003199819931983 2008

SPAM,viruses

Table: The growth of domain names in use Source: Presentation by Dr. Mockapetris to CENT, Fenruary, 2005


Distributed database, distributed management

• Hierarchical, globally distributed database

• Management distributed–Once node is delegated, the “owner” can manage all below independently

• Robust, fast

• “Everyone” has it already

• Most Internet applications use it–Each email needs 3+ lookups

–Each web page viewed needs it

–Directory applications rely on it

“”

UK IL AERO ARPA

AIRLINES SITA ISI

EDU

IN-ADDR

KLM BAW Venera Aloha A

GVA


Global system to give names to “things”

• Same domain name can be used as pointer to many different “things” at once– Host name for a web site– Mail server– Individual email address– Instant messaging address– VoIP service location (SIP, H323 record)– Web service location– Public cryptography key

• Domain owner has full control over the configuration of all pointers

• User can obtain automatically pointers to locations of different services, depending on the protocol used, without having to maintain all this information for each protocol himself


Example

• make a voice over IP call to hear recorded weather forecast;

• find a normal phone number to call via PSTN to listen to airport weather forecast;

• send an email to inquire about the weather at airport AAAA;

• send a message to get instant weather update;

• encrypt his communications sent us the airport (for example flight plan);

• access a weather service using protocol X;• download notams using protocol Y.

• If you are calling via VoIP, here is our VoIP service address…

• If you need to call via PSTN, use this phone number…

• If you are sending an email, send it here…• For instant messages, use this address..• To encrypt communications for sent us, here

is our public key…• To access our superb weather service via

protocol X use this URI…• To read notams via protocol Y use this

URI…

weather.AAAA.airport.aero

The airport prepares a reply in DNS…The user asks the airport how to …

The airport does not provide all these services, “just” configures an authoritative pointer in AAAA.airport.aero zone to the appointed service provider.


New security protocol (DNSSec)

• Security is and will remain a challenge for any solution– Current authentication mechanisms at “higher levels” and protocol-specific– DNS Sec adds authentication on lower layer and is independent on other methods

• Allows to authenticate response received from DNS– In our example above, the user can verify that the airport response is authentic

and no-one poses as an airport authority to provide this pointer

• Governments recently stepped up effort to implement globally– US Dpt of Homeland security funding global implementation project lead by ICANN– Sweden requires the registry operator to implement this year; banks, media and

government institutions committed to deploy


What others are doing with all this?

• ENUM – mapping phone numbers to domain names– Callers can dial over VoIP using traditional phone numbers– Users can receive calls, emails, IMs, faxes over IP under their phone number– Austria live, Germany close to launch, UK expects launch this year, major telcos and cable

operators in the US expected to roll out next year

• RFID value processing in the supply chain– DNS based solution deployed as a standard technology to locate systems in supply chain– Questions about “devolution” of the original standard– Experts expect “break” along the industry lines but using the same underlying technology

• ICANN expects to implement DNSSec this year in the root of the Internet– New anti-spam standards will benefit from DNSSec– Liberty alliance (XML related security) – Trials took place to implement dynamic virtual private networks


Opportunities for air transport

• Create a deterministic framework for locating services and applications within the air transport community without needing to hard-code

• If I know who I want to talk to and what I want to do, I need to be able to determine:

– What system to talk to and where that system is located in the IP worldWhat is its IP address

– How that system is capable of being communicated with– How to obtain the correct certification in order to validate the authenticity of the information I

am being provided

• Remote systems need to be able to obtain the same information about me, it must be possible to dynamically update location information.


Applications to benefit

• VoIP integration, convergence – Domain name is a dial code to call airports, airlines, suppliers (weather.APcode.airport.aero)– Users don’t need to maintain and update list of key phone numbers, dial code stays the same, owners

configure how they wish to be reached (I.e. the real phone number, email, etc.)

• Interline e-ticketing, integration of GSAs– Domain name serves as an authoritative pointer to URI where the service is located (MATIP, MQ, web

service)– Users do not have to make any changes when the service location moves– Shorter time to market, faster and less complex implementation of new business relationships– Easy to share a public key to encrypt communications

• RFID for baggage management, spare parts,under/over age passengers– RFID value processed directly via DNS to locate system with added value information – The standard already employs DNS technology, this would be an industry-specific implementation

• Flight information– each airline/airport manages and publishes its own data, all act together as “one database”

– Generic FLIFO public service – Collaborative decision making

• Publication of tariffs by routes if and when required by regulators


Summary

• We have identified problems well worth solving – Reducing the complexity of communications within the industry and facilitating convergence to

IP could be a major efficiency and flexibility boost

• We have the right technical tools and community oversight to solve them– IT experts agree the technology is available to address the issue on hand

– .aero naming structure and policies can serve as the uniting factor

– Dot Aero Council has wide industry representation

• Next steps in this direction are “bigger” than .aero and success not certain– major industry standards impacted (MATIP, MQ)

– significant engineering effort to design the framework

• SITA currently reviewing its approach– Likely next step - workshop and/or survey within the industry to determine level of interest,

commitment, priorities


Impact on future .aero policy

• Most domain names on the second level (anyname.aero) will continue to be used for branding, access to web sites, emails by people

• Sub-domains to evolve into strict coding structures for individual segments of air transport community and form the backbone of industry applications

• To ensure interoperability, the .aero policies may need to include by reference other industry standards and policies


Supporting slides

IP Comms technologies

Name of presentation | Slide 18 www.information.aero

Internet / Private IP Networks

MESSAGINGEmail

Web services/SOAP/XMLMATIP

EDIFACTMQ

BATAPIM

Other bespoke solutions

FILE TRANSFERFTP

XCOMXFB


VOICE/MULTIMEDIASIP

H.323

TERMINAL ACCESSTN3270

TELNET/SSHX-Windows

CitrixWeb/HTTP



What needs to be in place

Locator service

Lowest common

denominator standards

Transport security

• Set of open, free, common standards for file transfer, messaging and terminal access which individual participants agree to adopt as a lowest common denominator

• Agreed algorithm for determining what mechanisms the remote end supports (!!!key to migration)

• Airlines may continue to use different solutions by bilateral / multilateral agreement

• DNS (Domain Name System) is the well-established mechanism for resource location in IP networks

• Airlines are already using DNS internally and for business-to-business communications, but there is a lack of consistent standards across the air transport industry

• DNSSEC standard will increase confidence in using DNS as a trusted “telephone directory” • Over the internet, IPSEC for non-web and

SSL for web traffic are well-established• Still a role in the short-to-medium term for

private IP services (where guarantees of service availability are a key concern)

• Scalable encryption solutions need PKI capability; DNSSEC may well become the standard mechanism for public key distribution [other solutions also possible]


Key culture change

• Knowing my “phone number” isn’t the security risk.– Appropriate network perimeter and application security mechanisms mean that

only those parties I want to permit can “dial” me.

• The internet is too unstable / insecure to use for critical applications– Appropriate design addresses security concerns– Redundancy of connectivity can be implemented– Increase confidence by using Internet as avenue of first resort with private network

connectivity available as a fallback if carriers want it in the short term

• Common standards don’t mean that the product cannot be differentiated

www.information.aero dac 7 progress report: b2b applications april 19, 2005 geneva

Documents