2/12/2016
SGN1 WP-604
Draft
ICAO/ATN
Internet Communication Service
For
Internet Protocol Suite Version 6 (IPS v6)
Prepared by: SGN-1
2/12/2016
SGN1 WP-XXX
FOREWORD
This standard defines the recommended data communications protocols and services to
be used for developing ground to ground portion of the data communications networks
for the ICAO Aeronautical Telecommunications Network (ATN). The standards defined
in this document provide support ATN application and services over the Internet Protocol
Suite (IPS). This standard uses terminology based on the Open System Interconnection
(OSI) Model for the protocols and layers.
i
2/12/2016
SGN1 WP-XXX
TABLE of CONTENTS
1
INTRODUCTION..................................................................................................... 1
1.1
1.2
2
GENERAL OVERVIEW ........................................................................................... 1
PURPOSE .............................................................................................................. 1
APPLICABLE DOCUMENTS ................................................................................ 3
2.1
IETF STANDARDS ................................................................................................ 3
2.2
ICAO PUBLICATIONS ........................................................................................... 5
2.3
DOCUMENT SOURCES ........................................................................................... 5
3.0 ACRONYMS ............................................................................................................... 6
3.1 DEFINITIONS .............................................................................................................. 7
4
GENERAL RECOMMENDATIONS ..................................................................... 8
4.1
4.2
4.3
4.4
5
LINK LAYER SUBPROFILE ..................................................................................... 9
NETWORK LAYER SUBPROFILE ............................................................................. 9
TRANSPORT LAYER SUBPROFILE .......................................................................... 9
APPLICATION LAYER SUBPROFILE ...................................................................... 10
DETAILED RECOMMENDATIONS .................................................................. 11
5.1
LINK LAYER ....................................................................................................... 11
5.2
NETWORK SUBPROFILE ...................................................................................... 12
5.2.1
Internet Protocol (IP) ................................................................................ 12
5.2.2
Routing...................................................................................................... 12
5.2.3
Multi-Protocol Label Switching (MPLS) ..Error! Bookmark not defined.
5.2.4
Error detection and reporting .................................................................... 12
5.2.5
Neighbor Discovery .................................................................................. 13
Neighbor discovery shall be used in accordance RFC -2461. .................................. 13
5.2.6
Mobile IP G-G .......................................................................................... 13
5.2.7
Network Layer Security (IPsec)................................................................ 13
5.2.8
Quality of Services (QoS) ......................................................................... 13
5.2.9
Transport subprofile .................................................................................. 13
5.2.9.1 Transmission Control Protocol (TCP) ........................................................ 14
5.2.10
Transport Layer Security (SSL/TLS) PROTOCOL ................................. 15
5.3
APPLICATION SUBPROFILE ................................................................................. 15
5.3.1
Support services ........................................................................................ 15
5.3.2
Network management ............................................................................... 15
5.3.3
Application Layer Security ....................................................................... 16
5.4
NAMING AND ADDRESSING ................................................................................ 17
6
NOTES ................................................................................................................... 18
6.1
SOCKETS ............................................................................................................ 18
ii
2/12/2016
SGN1 WP-XXX
Table of Figures
Figure 1 Transfer of information using IPS protocol architecture ...................................... 1
Figure 2 IPS Protocol Suite................................................................................................. 8
Figure 3 Subprofile layers ................................................................................................. 11
iii
2/12/2016
SGN1 WP-XXX
1 Introduction (Robert Witzen to review and make
recommendations)
1.1 GENERAL OVERVIEW
This standard defines the protocols, features, and layered services that should be
supported in an ICAO internet protocol suite (IPS) by implementing Internet Protocol
version 6 (IPv6) environments within the ATN. The standard will focus on documenting
the required internet protocol standards for communication services as shown
in Figure 1 for ATN users.
FTP protocol
Application
Application
TCP/UDP protocol
TCP/UDP
TCP/UDP
router
IP protocol
IP protocol
IP
Ethernet
driver
IP
token ring Ethernet
protocol
driver
IP
MPLS
token ring
protocol
802.X
token ring
Ethernet
BGP-4
Figure 1 Transfer of information using IPS Architecture
Specified in this sub-volume are the minimum protocols and services that may be
implemented by mutual agreement between ICAO member states for ATN connectivity.
The minimum set defined herein may be exceeded by additional requirements if required
for a particular service or if mutually agreed to by all service participants. The
supplemental requirements shall be documented and distributed to all participants.
1.2 PURPOSE
The purpose of this document is to provide a standardized set of IPS protocols, reference
the appropriate ATN service elements that are available for implementation within the
ATN based ground-to-ground networks. Additionally, the implementation of the
1
2/12/2016
SGN1 WP-XXX
specified protocols and services will enable aeronautical systems to be compatible with
the ATN and enable support for current and future ATN services.
2
2/12/2016
SGN1 WP-XXX
2 APPLICABLE DOCUMENTS
2.1 IETF STANDARDS
The following documents form a part of this standard to the extent specified herein. In the
event of conflict between the documents referenced herein and the contents of this
standard, the contents of this standard shall be considered the superseding document.
Internet Standards (IETF)
RFC-768
RFC-793
RFC-1055
RFC-1101
RFC-1122
RFC-1123
RFC-1155
RFC-1156
RFC-1183
RFC-1213
RFC-1633
RFC-1706
RFC-1887
RFC-1918
RFC-1998
RFC-2005
RFC-2212
RFC-2273
RFC-2373
RFC-2375
RFC-2401
(check)
RFC-2402
RFC-2406
RFC-2460
RFC-2461
RFC-2462
RFC-2463
User Datagram Protocol, August 1980
Transmission Protocol, September 1981
Nonstandard for transmission of IP Datagrams over serial Lines:
SLIP, June 1988
DNS Encoding of Network Names and Other Types, April 1989
Requirements for Internet Host-Communications Layers, October
1989
Requirements for Internet Host-Application and Support, October
1989
Structure and Identification of Management Information for IPSbased Internets, May1990
Management Information Base for Network Management of IPSbased internets, May 1990
New DNS RR Definitions, October 1990
Management Information Base for Network Management of IPSbased internets: MIB-II, March 1991
Integrated Services in the Internet Architecture: an Overview, June
1994
DNS NSAP Resource Records, October 1994
An Architecture for IPv6 Unicast address Allocation,
December1995
Address Allocation for Private Internets, February 1996
An Application of the BGP Community Attribute in Multi-home
Routing, August 1996
Applicability Statement for IP Mobility Support, October 1996
Specification of Guaranteed Quality of Service, September 1997
SNMPv3 Applications, January 1998
IP Version 6 Addressing Architecture, July 1998
IPv6 Multicast Address Assignments, July 1998
Security Architecture for the Internet Protocol, November 1998
IP Authentication Header, November 1998
IP Encapsulating Security Payload (ESP), November 1998
Internet Protocol, Version 6 (IPv6) Specification, December 1998
Neighbor Discovery for IPv6, December 1998
IPv6 Stateless Address Auto configuration, December 1998
ICMPv6 for the IPv6 Specification, December 1998
3
2/12/2016
SGN1 WP-XXX
RFC-2470
Transmission of IPv6 Packets over Token Ring Networks,
December 1998
Definition of the Differentiated Services Field (DS Field)
in the IPv4 and IPv6 Headers, December 1998
Internet X.509 Public Key Infrastructure Certificate Management
Protocols, March 1999
Domain Name System Security Extensions, March 1999
Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain
Routing, March 1999
IP VPN, December 2005
Internet X.509 Public Key Infrastructure Operational Protocols:
FTP and HTTP, May 1999
Requirements for Traffic Engineering over MPLS, September
1999
Format for Literal IPv6 Addresses in URL's, December 1999
OSPF for IPv6, December 1999
Encryption using KEA and SKIPJACK, February 2000
Simple Mail Transfer Protocol, April 2001
MPLS Architecture, January 2001
MPLS Label Stack Encoding, January 2001
The Addition of Explicit Congestion Notification (ECN) to IP,
September 2001
Assigned Numbers, October 2003
An Expedited Forwarding PHB (Per-Hop Behavior), March 2002
New Terminology and Clarifications for Diffserv, April 2002
Internet Official Protocol Standards, November 2002
Dynamic Host Configuration Protocol for IPv6, July 2003
Internet Group Management Protocol, Version 3, October 2002
An Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks, December 2002
User-based Security Model (USM) for version 3 of the Simple
Network Management Protocol (SNMPv3), December 2002
The Classless Static Route Option for Dynamic Host Configuration
Protocol (DHCP) version 4, December 2002
IPv6 Addressing Architecture for Unicast, Anycast, Multicast, and
an IPv6 node’s required Addresses
Transport Layer Security (TLS) Extensions, June 2003
DNS Extensions to Support IP Version 6, October 2003
DNS Configuration options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6), December 2003
IPv6 Flow Label Specification, March 2004
Mobility Support in IPv6, June 2004
Fast Handovers for Mobile IPv6, July 2005
Hierarchical Mobile IPv6 Mobility Management (HMIPv6), August
2005
RFC-2474
RFC-2510
RFC-2535
RFC-2545
RFC-2547bis
RFC-2585
RFC-2702
RFC-2732
RFC-2740
RFC-2773
RFC-2821
RFC-3031
RFC-3032
RFC-3168
RFC-3232
RFC-3246
RFC-3260
RFC-3300
RFC-3315
RFC-3376
RFC-3422
RFC-3414
RFC-3442
RFC-3513
RFC-3546
RFC-3596
RFC-3646
RFC-3697
RFC-3775
RFC-4068
RFC-4140
4
2/12/2016
RFC-4283
2.2
SGN1 WP-XXX
Mobile Node Identifier Option for Mobile IPv6 (MIPv6),
November 2005
ICAO PUBLICATIONS
ICAO ATN Doc. 9705 Edition 3 Profile Requirement List ISO-8571-5: File Transfer,
Access, and Management – Part: Protocol Implementation Conformance Statement
(PICS) Proforma
ICAO Doc. 9739 Comprehensive Aeronautical Telecommunication Network (ATN)
Manual
2.3 DOCUMENT SOURCES
Obtain copies of the applicable documents or standards by contacting the appropriate
organizations.
Request for Comments (RFCs)
Copies of RFC may be obtained from DS.INTERNIC.NET via File Transfer Protocol
(FTP), Wide Area Information Service (WAIS), and electronic mail.
If FTP is used, RFCs are stored as rfc/rfcnnnn.txt or rfc/rfcnnnn.ps where "nnnn" is the
RFC number. Login as "anonymous" and provide your E-Mail address as the password.
If WAIS is used, the local WAIS client or Telnet to DS.INTERNIC.NET can be used.
Login as "wais" (no password is required) to access a WAIS client; help information and
a tutorial for using WAIS are available online. Search the "rfcs" database to locate the
desired rfc.
If electronic mail is used, send a mail message to mailserv@ds.internic.net and include
any of the following commands in the message body:
document-by-name rfcnnnn
where "nnnn" is the RFC number; the text
version is sent
file/ftp/rfc/rfcnnnn.yyy
where "nnnn" is the RFC number and "yyy" is
"txt" or "ps"
ICAO Document
Copies of ICAO documents can be obtained by contacting ICAO and requesting the
appropriate documents.
5
2/12/2016
SGN1 WP-XXX
3.0 ACRONYMS
The acronyms used in this standard are defined as follows:
API
ATM
ATN
ARP
BGP
CL
CMIP
CO
DGRAM
DNS
ECN
EGP
FTP
G-G
GUI
ICAO
ICMP
IETF
IGMP
IGP
I/O
IP
IPCP
IPSec
ISO
LAN
MPLS
MTU
OSI
OSPF
RARP
RFC
RIP
SNMP
SSH
SSL
TCP
TLS
UDP
WAIS
WAN
Application Programming Interface
Asynchronous Transfer Mode
Aeronautical Telecommunication Network
Address Resolution Protocol
Border Gateway Protocol
Connection-less
Common Management Information Protocol
Connection-oriented
Datagram
Domain Name System
Explicate Congestion Notification
Exterior Gateway Protocol
File Transfer Protocol
Ground- to- Ground
Graphical User Interface
International Civil Aviation Organization
Internet Control Message Protocol
Internet Engineering Task Force
Internet Group Management Protocol
Interior Gateway Protocol
Input/Output
Internet Protocol
Internet Protocol Control Protocol
Internet Protocol Security
International Standards for Organization
Local Area Network
Multi-Protocol Label Switch
Maximum Transmission Unit
Open System Interconnection
Open Shortest Path First
Reverse Address Resolution Protocol
Request for Comments
Routing Information Protocol
Simple Network Management Protocol
Secure Shell
Secure Socket Layer
Transmission Control Protocol
Transport Layer Security
User Datagram Protocol
Wide Area Information Service
Wide Area Network
6
2/12/2016
SGN1 WP-XXX
3.1 DEFINITIONS
Internet
A three-level hierarchy composed of backbone networks (e.g.
Advanced Research Projects Net [ARPAnet], National Science
Foundation Net [NSFNet], Military Network [MILNET]) and
Mid-level network stub networks. These include commercial
(.com or .co), university (.ac or .edu), other research networks
(.org or .net), and military (.mil) networks. It spans many different
physical networks around the world with various protocols
including the IP.
Network
Hardware and software data communication systems.
Profile
Defines implementation conformance constrain on a set of
reference specifications.
Protocol
A set of rules and formats (semantic and syntactic) which
determines the communication behavior between peer entities in
the performance of functions at that layer.
Socket
A socket is defined as "the endpoint in a connection." Sockets are
created and used with a set of programming requests or "function
calls" sometimes called the sockets application programming
interface (API). The most common sockets API is the Berkeley
Unix C interface for sockets. Sockets can also be used for
communication between processes within the same computer.
Subnetwork
An actual implementation of data network that employs a
homogeneous protocol and addressing plan and is under control of
a single authority.
Subprofile
A subset of a profile that supports a specific protocol layer in a
network application.
World Wide Web
An internet client-server distributed information retrieval system
which originated in the CERN High-Energy Physics laboratories
in Geneva, Switzerland.
7
2/12/2016
SGN1 WP-XXX
4 GENERAL RECOMMENDATIONS
This section specifies general recommendations for implementing the IPS protocols
within a network. The IPS allows computers of all sizes, using different operating
systems, to exchange air traffic data information’s by using layer protocols that perform
different functions at different layers of the data exchange. The complete set of protocols
necessary for this communication is referred to as a protocol suite. Depicted in Figure 2 is
a typical protocol suite; the suite will vary for each application and is dependent upon the
implemented network services.
Doc 9705
FTP
DNS
SNMP v3
XML
TFTP
TCP
BOOTP
Transport
Layer
UDP
Network
Layer
IPv6
ICMPv6
BGP4
Application
Layer
MPLS
802.X
Link Layer
Network Access Links
Figure 2 IPS Protocol Suite
Each layer of the protocol suite supports the implementation of a different function
within a communication network. The lower layer will typically provide transmission
services to the upper layer. In order to implement the desired network functions, a layer
can consist of more than one protocol. The grouping of protocols that support the
functional requirements of a protocol layer is referred to as a subprofile.
The link subprofile, also referred to as the network access layer, provides the physical
interface to the network. This layer is where the electrical and mechanical characteristics
are defined for the network and is not subject to this document.
The network subprofile, also know as the internet layer, provides for the movement of
data packets around the network. This layer handles packet routing, addressing, packet
fragmentation, QoS, reassembly and security.
8
2/12/2016
SGN1 WP-XXX
The transport subprofile provides end-to-end communications between two end systems.
This layer is used to provide both reliable and unreliable services for an application
depend on the requirements and specifications.
The application subprofile provides the functions and services to an end-user. A few of
the services provided are security (remote login), file transfer over the network, and
electronic mail delivery.


Implementation of IPS systems that will connect to the Internet systems should be
in accordance with RFC-3300, Internet Official Protocol Standards.
Implementation of the network management system in an IPS network should be
in accordance with Systems Management.
Subnetworks that will interface and support communications with the OSI/ISO-based
international Aeronautical Telecommunication Network (ATN), shall implement the
practices and standards contained in the following document:

International Civil Aviation Organization (ICAO) Doc 9705, Edition 3.
4.1 LINK LAYER SUBPROFILE
The link layer, or media access layer, normally includes the device drivers for the
operating system and the corresponding network access in the computer. General
recommendations for implementation of the link layer should be done in accordance with
applicable project or program requirements. Detailed recommendations for the network
layer are contained in Section 5.1 Network subprofile of this document
4.2 NETWORK LAYER SUBPROFILE
The network layer handles the movement of packets around the network. This layer
performs address conversion between internet protocol addresses and Ethernet addresses
in local area network (LAN) environments. This layer also defines the gateway interface,
multicast specifications, and low-level network management.
General recommendations for implementation of the network layer should be done in
accordance with RFC-1122, Requirements for Internet Hosts-Communication Layer.
Detailed recommendations for the network layer are contained in Section 5.2 Network
subprofile of this document.
4.3 TRANSPORT LAYER SUBPROFILE
The transport layer provides a flow of data between two hosts for the application layer
above it. In the IPS, there are two vastly different transport protocols: one for reliable
connection-oriented service, and the other for unreliable connectionless service. General
recommendations for implementation of the transport layer should be done in accordance
with RFC-1122, Requirements for Internet Hosts-Communication Layer. Detailed
recommendations for the transport layer are contained in Section 5.3, Transport
subprofile, of this document.
9
2/12/2016
SGN1 WP-XXX
4.4 APPLICATION LAYER SUBPROFILE
The application layer handles the details of specific application programs. General
recommendations for implementation of the application layer should be done in
accordance with RFC-1123, Requirements for Internet Hosts-Application and Support.
Detailed recommendations for the application layer are contained in Section 5.4, User
extended subprofile, of this document.
10
2/12/2016
SGN1 WP-XXX
5 DETAILED RECOMMENDATIONS
This section specifies the detailed recommendations necessary to implement IPS
protocols within and between an ATN subnetwork. Contained in the following sections
are the RFC’s recommendations that network implementers should follow in order to
provide a consistent and uniform data transmission environment between ATN users.
The protocols used and the number of layers in the protocol hierarchy are dependent upon
the type of services the network will provide to the end user. The individual layer of a
protocol stack is referred to as a subprofile. Each subprofile consists of identifying the
protocols for a specific layer that will allow the network to provide the desired services.
The IPS subprofile layers are shown in Figure 3.
User
Process
User
Process
User
Process
TCP
User
Process
UDP
application
transport
ICMP
IP
IGMP
network
MPLS
Hardware
Interface
802.x
link
media
Figure 3 Subprofile layers
5.1 LINK LAYER
The link subprofile often specifies the protocols that provide services corresponding to
the physical and data link layers. Users may be directly connected to either the ATN
backbone Wide Area Network (WAN) or to an ATN access LAN. Backbone WAN endsystems adhere to the backbone WAN subprofile, which are typically based on Frame
Relay (FR), Ethernet, Token Ring or any desired WAN technology. The link protocols
should be implemented in accordance with the specification applicable to the physical
11
2/12/2016
SGN1 WP-XXX
interface. This is a local matter and should be implemented as specified by the member
state.
5.2 NETWORK SUBPROFILE
The network subprofile specifies the protocols that provide services corresponding to the
network layer. The protocol used in the IPS networks is IPv6. IPv6 is designed for use in
interconnected packet-switched computer communication networks and provides
addressing and fragmentation services.
5.2.1
Internet Protocol (IP)
IPv6 support shall be in accordance with RFC-2460, Internet Protocol. In addition to
congestion notification must conform to RFC-3168, RFC-3260, and RFC-3697.
5.2.1.1
Network addressing
Network addressing requirements shall be in accordance ICAO Doc. 9705 and map to
IPv6 addressing by using the following RFC’s:








RFC-1887, An architecture for IPv6 Unicast address allocation
RFC-1998, Address allocation for private internet
RFC-2373, IPv6 addressing structure
RFC-2375, IPv6 Multicast address assignments
RFC-3232, Assigned Numbers
RFC-3513, IPv6 addressing architecture for Unicast, Multicast, Anycast, and an
IPv6 node’s required address
RFC-3596, DNS extension to support IPv6
ATNP/WGB-1/WP/304, Mapping between ATN NSAP and IPv6 Addresses
5.2.2
Routing
The process of delivering a message across a network or networks via the most
appropriate path is done using routing protocols. The following protocols are the most
commonly used protocols in networks: OSPFv3, BGPv4+, RIP and IS-IS. The following
RFC’s shall be used for interior and exterior routing in ATN environments.



RFC-2470, OSPF for IPv6 (Delete)kelly
RFC-2545, Boarder gateway protocol (BGP) version 4+
Draft RFC for IS-IS using IPv6 address, www.ietf.org/internet-draft-ietf-isis-wgmulti-topology-06.txt
5.2.3
Error detection and reporting
Error detection and reporting (check on title and content of RFC) Kelly should be
accomplished using RFC-2463, ICMPv6.
12
2/12/2016
5.2.4
SGN1 WP-XXX
Neighbor Discovery
Neighbor discovery shall be used in accordance RFC -2461.
5.2.5
Mobile IP G-G
Mobile IP protocol is designed network support for wireless LANs. Mobile IP should be
implemented in accordance with RFC 2005, Applicability Statement for IP Mobility
Support, accompanied with RFC-3775, RFC-4068, RFC-4140, and RFC-4283 (optional).
(Move to Guidance Materiel Kelly)
5.2.6
Network Layer Security (IPsec)
The goal of the architecture is to provide various security services for ATM traffic. The
set of security services offered includes access control, connectionless integrity, data
origin authentication, protection against replays (a form of partial sequence integrity),
confidentiality (encryption), and limited traffic flow confidentiality. These services are
provided at the IPv6 specifications. Security shall be implemented in accordance with
the following RFCs: 2401, 2402, 2406, 2535, 2732, and 3697.
5.2.7
Quality of Services (QoS)
QoS encompasses the capability of a network to provide prioritized communications
services in a quantifiable manner for defined network traffic classes [note: traffic at the
class level is classified by the Class of Services (CoS)], over various underlying
communication technologies, in accordance with stakeholder needs. Relevant metrics for
QoS include:





Service Availability – Reliability of users’ connection to the network
Delay – time taken by a packet to traverse the network from end to end
Delay jitter – Variation of delay encountered by similar packets following the
same route through the network
Throughput – Rate at which packets go through the network
Packet Loss Rate – Rate at which packets are dropped, get lost, or become
corrupted while going through the network
QoS for ATN shall be in accordance with RFCs -1633, 2212, 2474, 2702, 2547, 3031,
3168, 3246, and 3260.
Some of the RFCs are too generic, need to add information on QOS signaling and flow
labels. Focus on IPv6 support, cover header information (Kelly to add information)
5.2.8
Transport subprofile
13
2/12/2016
SGN1 WP-XXX
The transport subprofile specifies the protocols that provide services for the transport
layer of the IPS protocol stack. Transport protocols regulate flow, detect and correct
errors, and multiplex data, on an end-to-end basis.
The IPS transport layer will support two transport subprofiles connection-oriented (CO)
and connection-less (CL) transport subprofile.
CO service is provided using the TCP, which is the primary virtual-circuit transport
protocol for IPS. TCP provides reliable, in-sequence delivery of a full-duplex data stream
and is used by applications requiring reliable, CO service (i.e., single mail transfer
protocol [SMTP], FTP, Telnet).
CL service is provided using the UDP, which offers minimal transport service and does
not provide guaranteed delivery. This protocol gives applications direct access to the
datagram service of the IP layer. The only services this protocol provides over IP are
checksumming of the data and multiplexing by port number. Therefore, applications
running over UDP should deal directly with end-to-end communication problems that a
CO protocol would have handled (i.e., transmission for reliable delivery, packetization
and reassembly, flow control, etc.). UDP is used by applications that do not require the
level of service that TCP provides or if communications services that TCP does not
provide (i.e., broadcast, multicast) are to be used.
Implementation of the Transport subprofile should be done in accordance with RFC1122, Requirements for Internet Hosts-Communication Layers.
5.2.9.1 Transmission Control Protocol (TCP)
The reliable, connection oriented communication protocol used in IPS networks should
be TCP. The protocol shall be implemented in accordance with RFC-793, Transmission
Control Protocol. In addition, RFC-793 shall be accompanied by RFC-3168, The
Addition of Explicit Congestion Notification (ECN) to IP.
5.2.8.2
User Datagram protocol (UDP)
For unreliable, connection-less oriented communication protocol used in IPS networks
shall be UDP. The protocol shall be implemented in accordance with RFC-768, User
Datagram Protocol.
5.2.9
Convergence Service for Non-IPS Applications
RFC1006 (Andy Colon)
5.2.10 Transport Layer Security
14
2/12/2016
SGN1 WP-XXX
5.2.10.1 Secure Socket Layer/Transport Layer Security (SSL/TLS)
PROTOCOL
SSL creates a secure connection between a client and a server, over which any amount of
data can be sent securely. The implementation of the SSL/TLS protocol should be in
accordance with RFC-2246 and RFC-3546. (Vic Patel and Tom McParland to validate
and add information if necessary)
5.3
APPLICATION SUBPROFILE (MOVE TO SEPARATE
DOCUMENT)
The application subprofile provides services corresponding to the application layer.
The Application Layer allows for functions and services required by particular userdesigned application processes. Functions satisfying particular user requirements are
contained in this layer. Transfer of information necessary to communicate between
applications is the responsibility of the lower layers. The applications available are
dependent upon the implemented transport layer and end-user requirements.
The application subprofile is transport layer specific and cannot be interchanged between
the transport subprofiles. Therefore, exercise caution when implementing an application
subprofile. Prior to implementing an application subprofile verify that the applicable
transport layer is supported by the network.
5.3.1
Support services
The following sections cover the protocols necessary to supply support services. The
standard support services are domain name system, host initialization, and network
management. Implementation of these services should be in accordance with RFC-1123,
Requirements for Internet Hosts-Application and Support.
5.3.1.1
Domain name system (DNS)
A host must implement a resolver to convert host names to IP addresses and vice-versa.
Implementation of a domain name system should be in accordance with the following
RFCs:
 RFC-2821, Mail Routing and the Domain System,
 RFC-1101, DNS Encoding of Network Names and Other Types,
 RFC-1183, New DNS RR Definitions,
 RFC-1706, DNS NSAP Resource Records.
Need to define DNS structure, check with IATA and EUROCONTROL
5.3.2
Network management
15
2/12/2016
SGN1 WP-XXX
Current network management framework for IPS-based internets consists of Structure
and Identification of Management Information for IPS-based internets, RFC 1155, and
Management Information Base for Network Management of IPS-based internets: MIB-II,
RFC-1213, and the Simple Network Management Protocol, RFC 3411. The RFC-1155
describes how managed objects contained in the Management Information Base (MIB)
are defined. While, RFC-1155 describes the managed objects contained in the MIB (and
supercedes RFC-1156), RFC-3411 defines the protocol used to manage these objects.
RFC-1213, along with RFC-1155, provide a simple, workable architecture and system for
managing IPS-based internets.
RFC-1213 should be accompanied by RFC-2011, SNMPv2 Management Information
Base for the Internet Protocol using SMIv2, RFC-2012, SNMPv2 Management
Information Base for the Transmission Control Protocol using SMIv2, and RFC-2013,
SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2.
Network management should be implemented using either simple network management
protocol (SNMP) over UDP or common management information protocol (CMIP) over
TCP. Therefore, in order to allow management to be performed by either protocol, a host
should implement an appropriate management agent for both SNMP and CMIP.
Implementation of network management should be in accordance with FAA-HDBK-002,
Systems Management. (DELETE)
5.3.2.1
Simple Network Management Protocol (SNMP)
SNMPv3 should be done in accordance to RFC-3411, An Architecture for Describing
SNMP Management Frameworks, RFC-3412, Message Processing and Dispatching for
the Simple Network Management Protocol (SNMP), RFC-3413, SNMP Applications,
RFC-3414, User-based Security Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3), and RFC-3415, View-based Access Control Model
(VACM) for the Simple Network Management Protocol (SNMP).
SNMP version 2 should be done in accordance with RFC-2578, Structure of Management
Information Version 2 (SMIv2), RFC-2579, Textual Conventions for SMIv2, and RFC2580, Conformance Statements for SMIv2.
5.3.3
Application Layer Security
Security services provided by the following protocols are implemented in the lover levels
as well as in the application layer.
5.3.3.1.1
5.3.3.2
LDAP
Public Key Infrastructure (PKI)
Systems implementing Public Key Infrastructure (PKI) for IPS based systems should be
implemented according to RFC-2510, Internet X.509 Public Key Infrastructure
16
2/12/2016
SGN1 WP-XXX
Certificate Management Protocols, and RFC-2585, Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP, Internet X.509 Public Key
Infrastructure Certificate and CRL Profile.
5.4 NAMING AND ADDRESSING
System naming and addressing should be in accordance with ICAO Doc.9705 edition 3.
(Check with Bolek from EUROCONTROL for their info as stated in Chiang Mai Check
with IATA for naming plan)
17
2/12/2016
6
SGN1 WP-XXX
NOTES
6.1
SOCKETS (MOVE TO GUIDANCE MATERIAL)
A socket is one end of a two-way communications link between two programs running on
a network. Sockets are used to implement the connection between a client program and a
server program. Mail, FTP, Telnet, name, and finger are all examples of services
provided by computers on a network. Typically, each service is provided on a dedicated,
well-known port. A program can access a specific service by connecting to the port
dedicated to that service. In addition to the ports that are dedicated to specific services,
computers also have other ports that let programmers create their own services. Typically
ports are numbered and a program connects to a port by specifying the port number of the
service. Each service or port recognizes a certain protocol, so requests should be
formulated in a manner specific to the desired service. This ensures that a request is
understood and a response is received. Port assignments should be in accordance with
RFC-3232, Assigned Numbers: RFC 1700 is replaced by an On-line Database.
Typically UNIX systems use Berkeley Sockets, System V Transport Layer Interface
(TLI), and Remote Procedure Call (RPC) API. Berkeley Sockets and System V TLI
provide the same functionality, which is access to TCP and UDP, and are mutually
exclusive. However, it is possible to write conditionally-compiled software to support
either API. RPC supports network subroutines using Sun's RPC protocol. Microsoft has a
sockets-like programming interface, but emphasizes event-based non-blocking to provide
constant handling of graphical user interface (GUI) events.
UDP communications requires DGRAM sockets. Once created, a DGRAM socket can
immediately be used to transmit UDP packets. TCP requires STREAM sockets; a
STREAM socket cannot send or receive data until a connection has been established.
Therefore, prior to implementing an application, the applicable socket must be available
to support end-to-end communications.
18