AERONAUTICAL COMMUNICATIONS PANEL (ACP)
3rd MEETING OF WORKING GROUP I
Aarhus, Denmark 6-12 August 2007
Agenda Item : 4 / Guidance MaterialATN IPS Manual on Implementation
(Presented by Kelly Kitchens)
SUMMARYThis working paper reorganizes the guidance document to align with the Technical Manual and adds VoIP material
4
TABLE OF CONTENTS
1 Introduction 4
1.1 Background 4
2 Reference Documents 4
3 Abbreviations and Definitions 4
4 ATN Deployment Guidance 4
4.1 Network Layer Guidance 4
4.1.1 Network Layer Addressing 5
4.1.2 Basic IPV6 Address Space Assignments and BGP as Numbers 6
4.1.3 Transit Traffic 7
4.1.4 ATN/IPS QoS 8
4.1.5 QoS Management 9
4.2 Transport layer Guidance 13
4.2.1 General 13
4.2.2 Connection oriented and connectionless transmission 13
4.2.3 Transport layer addressing 14
4.2.4 Congestion Avoidance 14
4.2.5 Error Detection and Recovery 14
4.3 Application Layer Guidance 15
4.3.1 Application interface to the transport layer 15
4.3.2 Application interface to the network layer 15
4.4 IPS Security Guidance Material 15
4.4.1 IPsec Authentication Header and Encapsulating Security Payload 15
4.4.2 Authentication Header 16
4.4.3 Encapsulating Security Payload 17
4.4.4 IPsec Transport and Tunnel Modes 18
4.4.5 IPsec Key Management 18
4.4.6 Alternatives to IPv6 Security 19
4.4.7 Alternatives/Compliments to IPsec 21
4.4.8 Need for Security at Multiple Levels in Aviation Environment 21
5 VoIP Guidance 21
Annex 1 Example Implementation Guide 22
Annex 2 Implementation of Voice over Internet Protocol (VoIP) Handbook 59
FOREWORD
The material contained in this document supplements Standards and Recommended Practices (SARPs). This document is to be used to assist in the deployment of IPS systems for the ICAO Aeronautical Telecommunication Network (ATN) as defined in Annex 10 — Aeronautical Telecommunications, Volume III — Communication Systems and Part I — Digital Data Communication Systems. The purpose of this document is to support the deployment of ATN network components in ICAO Regions.
This document consists of nine Sub-Chapters
Section 1 — Introduction
Section 2 — Reference Documents
Section 3 — Abbreviations and Definitions
Section 4 — ATN Deployment Guidance
Section 5 — VoIP Guidance
Annex 1 — Example Implementation Guide
Annex 2 — Implementation of Voice over Internet Protocol Handbook
In line with the agreement by the ANC that the document should be updated on a as needed basis.
1 Introduction
The ATN/IPS Guidance Document contains information to assist member states in the deployment of a harmonized IPS network infrastructure to support the delivery of Air Traffic Management (ATM) services. The following minimum core services should be provided by ATN/IPS:
· Interface registry
· Directory and naming
· Flight Information
· Security
· Infrastructure management
· Global information exchange
These core services enable applications to exchange voice and data with appropriate priority and security over an underlying transport networks with QoS and CoS technology.
1.1 Background
The ICAO/ATN has established specific goals for modernizing global ATM systems. ATN/IPS [1] is a new concept based upon an open, flexible, modular, manageable, and secure architecture that is transparent to the stakeholders. This approach provides value by reducing costs and risks, enabling new capabilities and enhancing legacy services.
2 Reference Documents
3 Abbreviations and Definitions
Allocation
This is the address space that is set aside by a Regional Internet Registry (RIPE) for an LIR.
Sub-allocation
This is the address space that is set aside by a Local Internet Registry (EUROCONTROL Agency) for an LIR's downstream customer or organisation.
Assignment
Address space taken from the LIR allocation and given to the End User or to the LIR’s infrastructure.
4 ATN Deployment Guidance
4.1 Network Layer Guidance
The IPS ATN addressing is performed using IPv6. The network layer provides the functionality that allows different types of networks to be joined and share a common addressing scheme.
4.1.1 Network Layer Addressing
The IPv6 addressing scheme builds on the RIPE allocation in order to provide /48 assignments.
The IPv6 addressing scheme had been developed within the context of the former EUROCONTROL iPAX Task Force which is illustrated in Figure 4-1. This is the scheme that is being deployed.
Figure 4-1 Address Assignment
The iPAX addressing scheme is structured according to following principles:
The first 32 bits are fixed to 2001:4b50 (RIPE allocation);
The 3 bits of Field F1 are assigned as follows;
F1 Assignment / Binary / Hex / Network Name1 / 000 / 0 / National/Regional Entities
2 / 001 / 1 / Pan-European Organisations and Entities
Figure 4-2 F1 Field Assignment
· The 7 bits of the fixed “Net. Prefix” field are used to number each ANSP, organisation or infrastructure that can be considered as a single entity; the high order bit of the “Net. Prefix” is set to 0 for national entities and 1 for regional entities;
· The 1 bit of the v4/v6 field is a toggle bit to indicate if IP address translation is required at the network border.
· The 5 bits of F2 field are assigned sequentially to provide multiple /48 per network prefix, the bit assignment follows RFC 3531 (A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block).
F2 Assignment / Binary / Hex / Network Name1 / 00000 / 0 / First Operational
2 / 10000 / 10 / First Pre-Operational
3 / 01000 / 8 / Second Operational
4 / 11000 / 18 / Second Pre-Operational
5 / 00100 / 4 / Third Operational
6 / 10100 / 14 / Third Pre-Operational
7 / 01100 / C / ….
8 / 11100 / 1C / ….
9 / 00010 / 2 / ….
…. / ….
…. / ….
32 / 11111 / 1F / ….
Figure 4-3 F2 Field Assignment
Stakeholders assign the remaining 80 bits of the address based on their own policies but should note the advice provided in RFC 3531 (A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block); typically the first 16 bits (SLA ID) are used to represent location related information.
In order to address direct interconnections between stakeholders, the future PEN backbone or regional networks, additional address space has been planned.
4.1.2 Basic IPV6 Address Space Assignments and BGP as Numbers
Each stakeholder is initially assigned with a network prefix. On the basis of this network prefix, each organisation can advertise the associated /42 IPv6 address prefix at their network border.
EUROCONTROL enters this information into the RIPE database and indicate the address space as being “sub-allocated”.
Then two /48 prefixes (one for real v6 nodes and the other to represent virtual v4 nodes) for operational networks and another two for pre-operational networks will be assigned. This will correspond to 2 values of the F2 field complemented by the v4/v6 toggle bit.
EUROCONTROL will enter this information into the RIPE database on behalf of the organisation. These 4 assignments are referred to as the “basic assignment”.
This process will provide the same address space to all organisations irrespective of their size. In reality, some organisations may be operating multiple, very large or regional networks. As a consequence, the basic assignment may be insufficient or inappropriate. In such cases an alternative assignment can be made within the organisations range as long as it remains within the RIPE policy and does not compromise the overall addressing scheme.
Private BGP AS numbers within the range [64512 to 65535] are defined on the basis of the first IPv6 address assignment (v4/v6 bit and F2 set to 0). More precisely, an algorithm based on 4 hexadecimal values (nibbles) that immediately follow the /32 assignment:
· when the first nibble equals zero, the AS number is equal to the sum of decimal value 64600 and the decimal value of the following two nibbles; assignments with such values correspond to national/local networks and entities.
· when the first nibble equals one, the AS number is equal to the sum of decimal value 65100 and the decimal value of the following two nibbles; assignments with such values correspond to regional networks and entities.
· when the first nibble equals two, the AS number is equal to the sum of decimal value 65200 and the decimal value of the following two nibbles; assignments with such values correspond to pan-European networks and entities.
4.1.2.1 Example
ROMATSA has been assigned with the Network Prefix of binary value 0100101 As a result, they have been sub-allocated with IPv6 network prefix 2001:4B50:0940::/42 which they can advertise at their border.
ROMATSA has been assigned with the following /48 network prefixes to number their systems. These addresses are indicated as being maintained by the EUROCONTROL Agency.
inet6num: 2001:4B50:0940::/48netname: RO-ROMATSA-OR-1
descr: Assignment for site RO-ROMATSA-OR-1
country: RO
admin-c: CA1732-RIPE
tech-c: CD1668-RIPE
status: ASSIGNED
mnt-by: EURO-HQ-MNT
source: RIPE # Filtered / Inet6num: 2001:4B50:0960::/48
netname: RO-ROMATSA-OV-1
descr: Assignment for site RO-ROMATSA-OV-1
country: RO
admin-c: CA1732-RIPE
tech-c: CD1668-RIPE
status: ASSIGNED
mnt-by: EURO-HQ-MNT
source: RIPE # Filtered
inet6num: 2001:4B50:0950::/48
netname: RO-ROMATSA-PR-1
descr: Assignment for site RO-ROMATSA-PR-1
country: RO
admin-c: CA1732-RIPE
tech-c: CD1668-RIPE
status: ASSIGNED
mnt-by: EURO-HQ-MNT
source: RIPE # Filtered / Inet6num: 2001:4B50:0970::/48
netname: RO-ROMATSA-PV-1
descr: Assignment for site RO-ROMATSA-PV-1
country: RO
admin-c: CA1732-RIPE
tech-c: CD1668-RIPE
status: ASSIGNED
mnt-by: EURO-HQ-MNT
source: RIPE # Filtered
The associated BGP AS number is 64748 (64600 + decimal (94h) ). Inter-domain Routing
4.1.2.2 Traffic type segregation
BGP-4 does not natively allow setting up different set of routes for different traffic to the same destination.
ATN IPS requirement on traffic type segregation may be fulfilled by appropriate provisions in the ATN addressing plan: if the ATN address incorporates an indication of the traffic type, BGP-4 will transparently flood segregated route information for the various traffics.
4.1.2.3 AS Numbering Plan
TBD
4.1.3 Transit Traffic
The purpose of this section is to raise the issue of transit traffic within the ATN IPS network service.
The ATN IPS Manual describes the notion of autonomous administrative domains (ADs) that interact by exchanging routing information through static routes or dynamic routes by making use of the Border Gateway Protocol (BGP).
4.1.3.1 Issues
The ATN IPS manual does not specify which routes are to be advertised between ATN IPS routers nor basic traffic management policies for a dynamically routed environment.
It can be assumed that ATN IPS routers will exchange information about network prefixes within its AD to neighbour routers. In BGP, this implies that the AD network administrators populate the ATN IPS BGP routers with this information and seek some form of aggregation. By default, BGP routers will also forward routing information about other prefixes learned from other BGP neighbours.
In the absence of traffic management or fully meshed topology between Administrative Domains, traffic between two ADs may be relayed over a third intermediate AD. Such traffic being carried on behalf of two others is termed transit traffic.
The ATN IPS manual should define policies in the management of such traffic as it can lead to various concerns such as:
· Unplanned resource use of network resources;
· Compatibility with security measures (a given AD security policy may prevent traffic not destined to pass its firewall but still advertise via BGP the destination network);
· Compatibility with QoS measures applied within an intermediate AD;
· Obligation for Administrative Domains to relay such traffic.
Cost sharing approach requirement, a country must pay for increased traffic costs.
Need to develop general framework for backbone.
4.1.3.2 Transition between IPv4 and IPv6
Current ground communications are generally handled through appropriate profiles based on IPv4. For technical, economical and strategic reasons, transition to IPv6 will be made gradually and appropriate transition path need to be defined:
RFC 4213 - Basic Transition Mechanisms for IPv6 Hosts and Routers
This RFC discusses dual stack approaches as well as tunnelling IPv6 traffic through existing IPv4 networks.
In the ATN context, a symmetrical issue exists: the core network is IPv6 while some application (e.g. AMHS) only supports IPv4 profiles. This case may be handled through the “IPv4-compatible IPv6 address” and “IPv4-mapped IPv6 address” as stated in:
RFC 3513 - Basic Transition Mechanisms for IPv6 Hosts and Routers.
An alternate solution consists in making appropriate provisions for supporting IPv4 systems when specifying the ATN addressing plan. This solution improves consistency between all categories of ATN systems addresses.
4.1.4 ATN/IPS QoS
The ATN/IPS QoS/CoS objectives and architecture are influenced by proper selection of the following functions:
· Applications and Traffic Classes
· Transport layer protocols
· Security algorithms
· Flow and congestion Control
· Buffering and queue management – drop policies
· Multicasting protocols
· Routing and addressing schemes
· Media Access Control Protocols
· Bandwidth allocation and bandwidth-on-demand algorithms
· G-G and future A-G interfaces
· Network control and management
· Interoperability among network domains
· Internal and External Policy control
Differentiated Service
Differentiated Service (RFC 2474) provides a mean for specifying and implementing Qos handling consistently in IPS network. This specification is made on a per node basis, specifying behaviour of individual nodes concerning Qos (Per Hop behaviour).
The general framework / current practices is depicted in details in: RFC 2475 - Architecture for Differentiated Services
Traffic Priority
Historically, network layer priority was selected explicitly by the sending application through the TOS field. Although Differentiated Service (RFC 2474) preserves the IP precedence semantic of the TOS field, this approach is now deprecated. This is partly because the IP precedence has been superseded by the Per-Hop-Behaviour strategy inside Differentiated service, but also because network administrators usually don’t trust QOS specification coming from the application.
ATN application traffics can be identified / prioritised according to the destination port of datagrams when they enter the network:
· This provides transparent and safe identification of traffics, because the destination port is always a trusted information (otherwise the traffic will never reach its destination).