< draft-ietf-rtgwg-atn-bgp-08.txt   draft-ietf-rtgwg-atn-bgp-09.txt >
Network Working Group F. Templin, Ed. Network Working Group F. Templin, Ed.
Internet-Draft G. Saccone Internet-Draft G. Saccone
Intended status: Informational Boeing Research & Technology Intended status: Informational Boeing Research & Technology
Expires: June 21, 2021 G. Dawra Expires: June 24, 2021 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
December 18, 2020 December 21, 2020
A Simple BGP-based Mobile Routing System for the Aeronautical A Simple BGP-based Mobile Routing System for the Aeronautical
Telecommunications Network Telecommunications Network
draft-ietf-rtgwg-atn-bgp-08 draft-ietf-rtgwg-atn-bgp-09
Abstract Abstract
The International Civil Aviation Organization (ICAO) is investigating The International Civil Aviation Organization (ICAO) is investigating
mobile routing solutions for a worldwide Aeronautical mobile routing solutions for a worldwide Aeronautical
Telecommunications Network with Internet Protocol Services (ATN/IPS). Telecommunications Network with Internet Protocol Services (ATN/IPS).
The ATN/IPS will eventually replace existing communication services The ATN/IPS will eventually replace existing communication services
with an IPv6-based service supporting pervasive Air Traffic with an IPv6-based service supporting pervasive Air Traffic
Management (ATM) for Air Traffic Controllers (ATC), Airline Management (ATM) for Air Traffic Controllers (ATC), Airline
Operations Controllers (AOC), and all commercial aircraft worldwide. Operations Controllers (AOC), and all commercial aircraft worldwide.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2021. This Internet-Draft will expire on June 24, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 20 skipping to change at page 8, line 20
3. ATN/IPS Routing System 3. ATN/IPS Routing System
The ATN/IPS routing system comprises a private BGP instance The ATN/IPS routing system comprises a private BGP instance
coordinated in an overlay network via tunnels between neighboring coordinated in an overlay network via tunnels between neighboring
ASBRs over one or more underlying INETs. The overlay does not ASBRs over one or more underlying INETs. The overlay does not
interact with the underlying INET BGP routing systems, and only a interact with the underlying INET BGP routing systems, and only a
small and unchanging set of MSPs are advertised externally instead of small and unchanging set of MSPs are advertised externally instead of
the full dynamically changing set of MNPs. the full dynamically changing set of MNPs.
Within each INET partition, one or more s-ASBRs connect each stub AS Within each INET partition, each s-ASBRs connects a stub AS to the
to the INET partition core using a shared stub AS Number (ASN). Each INET partition core using a distinct stub AS Number (ASN). Each
s-ASBR further uses eBGP to peer with one or more c-ASBRs. All s-ASBR further uses eBGP to peer with one or more c-ASBRs. All
c-ASBRs are members of the INET partition core AS, and use a shared c-ASBRs are members of the INET partition core AS, and use a shared
core ASN. Unique ASNs are assigned according to the standard 16-bit core ASN. Unique ASNs are assigned according to the standard 32-bit
ASN format [RFC4271], where each ASBR assigns an ASN that matches its ASN format [RFC4271][RFC6793]. Since the BGP instance does not
ADM-ULA suffix. connect with any INET BGP routing systems, the ASNs assigned need not
be coordinated with IANA and can in fact coincide with values that
are assigned in other domains. The only requirement is that ASNs
must not be duplicated within the ATN/IPS routing system itself.
The c-ASBRs use iBGP to maintain a synchronized consistent view of The c-ASBRs use iBGP to maintain a synchronized consistent view of
all active MNP-ULAs currently in service within the INET partition. all active MNP-ULAs currently in service within the INET partition.
Figure 1 below represents the reference INET partition deployment. Figure 1 below represents the reference INET partition deployment.
(Note that the figure shows details for only two s-ASBRs (s-ASBR1 and (Note that the figure shows details for only two s-ASBRs (s-ASBR1 and
s-ASBR2) due to space constraints, but the other s-ASBRs should be s-ASBR2) due to space constraints, but the other s-ASBRs should be
understood to have similar Stub AS, MNP and eBGP peering understood to have similar Stub AS, MNP and eBGP peering
arrangements.) The solution described in this document is flexible arrangements.) The solution described in this document is flexible
enough to extend to these topologies. enough to extend to these topologies.
skipping to change at page 17, line 48 skipping to change at page 17, line 48
routing domains. From a conceptual and operational standpoint, the routing domains. From a conceptual and operational standpoint, the
implementation should provide isolation between the two BGP routing implementation should provide isolation between the two BGP routing
domains (e.g., separate BGP instances). domains (e.g., separate BGP instances).
ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random
40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit 40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit
OMNI link identifier '*' to form the prefix [ULA*]::/64. Each OMNI link identifier '*' to form the prefix [ULA*]::/64. Each
individual address taken from [ULA*]::/64 includes additional routing individual address taken from [ULA*]::/64 includes additional routing
information in the interface identifier. For example, for the MNP information in the interface identifier. For example, for the MNP
2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120, 2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120,
and for the administrative address 1001/8 the ADM-ULA is and for the administrative address 1001:2002/16 the ADM-ULA is
[ULA*]::1001/120 (see: [I-D.templin-6man-omni-interface] for further [ULA*]::1001:2002/112 (see: [I-D.templin-6man-omni-interface] for
details). This gives rise to a BGP routing system that must further details). This gives rise to a BGP routing system that must
accommodate large numbers of long and non-aggregatable MNP-ULA accommodate large numbers of long and non-aggregatable MNP-ULA
prefixes as well as moderate numbers of long and semi-aggregatable prefixes as well as moderate numbers of long and semi-aggregatable
ADM-ULA prefixes. The system is kept stable and scalable through the ADM-ULA prefixes. The system is kept stable and scalable through the
s-ASBR / c-ASBR hub-and-spokes topology which ensures that mobility- s-ASBR / c-ASBR hub-and-spokes topology which ensures that mobility-
related churn is not exposed to the core. related churn is not exposed to the core.
7. Stub AS Mobile Routing Services 7. Stub AS Mobile Routing Services
Stub ASes maintain intradomain routing information for mobile node Stub ASes maintain intradomain routing information for mobile node
clients, and are responsible for all localized mobility signaling clients, and are responsible for all localized mobility signaling
skipping to change at page 18, line 36 skipping to change at page 18, line 36
9. IANA Considerations 9. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
10. Security Considerations 10. Security Considerations
ATN/IPS ASBRs on the open Internet are susceptible to the same attack ATN/IPS ASBRs on the open Internet are susceptible to the same attack
profiles as for any Internet nodes. For this reason, ASBRs should profiles as for any Internet nodes. For this reason, ASBRs should
employ physical security and/or IP securing mechanisms such as IPsec employ physical security and/or IP securing mechanisms such as IPsec
[RFC4301], TLS [RFC5246], etc. [RFC4301], TLS [RFC5246], WireGuard, etc.
ATN/IPS ASBRs present targets for Distributed Denial of Service ATN/IPS ASBRs present targets for Distributed Denial of Service
(DDoS) attacks. This concern is no different than for any node on (DDoS) attacks. This concern is no different than for any node on
the open Internet, where attackers could send spoofed packets to the the open Internet, where attackers could send spoofed packets to the
node at high data rates. This can be mitigated by connecting ATN/IPS node at high data rates. This can be mitigated by connecting ATN/IPS
ASBRs over dedicated links with no connections to the Internet and/or ASBRs over dedicated links with no connections to the Internet and/or
when ASBR connections to the Internet are only permitted through when ASBR connections to the Internet are only permitted through
well-managed firewalls. well-managed firewalls.
ATN/IPS s-ASBRs should institute rate limits to protect low data rate ATN/IPS s-ASBRs should institute rate limits to protect low data rate
skipping to change at page 20, line 51 skipping to change at page 20, line 51
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress),
November 2020. November 2020.
[I-D.templin-6man-omni-interface] [I-D.templin-6man-omni-interface]
Templin, F. and T. Whyman, "Transmission of IP Packets Templin, F. and T. Whyman, "Transmission of IP Packets
over Overlay Multilink Network (OMNI) Interfaces", draft- over Overlay Multilink Network (OMNI) Interfaces", draft-
templin-6man-omni-interface-61 (work in progress), templin-6man-omni-interface-62 (work in progress),
December 2020. December 2020.
[I-D.templin-intarea-6706bis] [I-D.templin-intarea-6706bis]
Templin, F., "Asymmetric Extended Route Optimization Templin, F., "Asymmetric Extended Route Optimization
(AERO)", draft-templin-intarea-6706bis-80 (work in (AERO)", draft-templin-intarea-6706bis-81 (work in
progress), December 2020. progress), December 2020.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
 End of changes. 10 change blocks. 
15 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/