diff options
Diffstat (limited to 'doc/rfc/rfc6860.txt')
| -rw-r--r-- | doc/rfc/rfc6860.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc6860.txt b/doc/rfc/rfc6860.txt new file mode 100644 index 0000000..80c4896 --- /dev/null +++ b/doc/rfc/rfc6860.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) Y. Yang +Request for Comments: 6860 A. Retana +Updates: 2328, 5340 A. Roy +Category: Standards Track Cisco Systems, Inc. +ISSN: 2070-1721 January 2013 + + + Hiding Transit-Only Networks in OSPF + +Abstract + + A transit-only network is defined as a network connecting routers + only. In OSPF, transit-only networks are usually configured with + routable IP addresses, which are advertised in Link State + Advertisements (LSAs) but are not needed for data traffic. In + addition, remote attacks can be launched against routers by sending + packets to these transit-only networks. This document presents a + mechanism to hide transit-only networks to speed up network + convergence and reduce vulnerability to remote attacks. + + In the context of this document, 'hiding' implies that the prefixes + are not installed in the routing tables on OSPF routers. In some + cases, IP addresses may still be visible when using OSPFv2. + + This document updates RFCs 2328 and 5340. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6860. + + + + + + + + + + + + +Yang, et al. Standards Track [Page 1] + +RFC 6860 Hiding Transit-Only Networks in OSPF January 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Requirements Notation ......................................3 + 2. Hiding IPv4 Transit-Only Networks in OSPFv2 .....................3 + 2.1. Point-to-Point Networks ....................................3 + 2.1.1. Advertising Point-to-Point Networks .................4 + 2.1.2. Hiding Point-to-Point Networks ......................4 + 2.2. Broadcast Networks .........................................5 + 2.2.1. Advertising Broadcast Networks ......................5 + 2.2.2. Hiding Broadcast Networks ...........................5 + 2.2.2.1. Sending Network-LSA ........................5 + 2.2.2.2. Receiving Network-LSA ......................6 + 2.2.2.2.1. Backward Compatibility ..........6 + 2.3. Non-Broadcast Networks .....................................7 + 2.3.1. NBMA ................................................7 + 2.3.2. Point-to-Multipoint .................................7 + 2.3.2.1. Advertising Point-to-Multipoint Networks ...7 + 2.3.2.2. Hiding Point-to-Multipoint Networks ........8 + 3. Hiding IPv6 Transit-Only Networks in OSPFv3 .....................9 + 3.1. Hiding AF-Enabled Transit-Only Networks in OSPFv3 ..........9 + 4. Operational Considerations ......................................9 + 4.1. Forwarding Address ........................................10 + 4.2. Virtual Links .............................................10 + 4.3. Unnumbered Interfaces .....................................10 + 5. Security Considerations ........................................11 + 6. Acknowledgments ................................................11 + 7. References .....................................................12 + 7.1. Normative References ......................................12 + 7.2. Informative References ....................................12 + + + + + + +Yang, et al. Standards Track [Page 2] + +RFC 6860 Hiding Transit-Only Networks in OSPF January 2013 + + +1. Introduction + + A transit-only network is defined as a network connecting routers + only. In OSPF, transit-only networks are usually configured with + routable IP addresses, which are advertised in LSAs but not needed + for data traffic. In addition, remote attacks can be launched + against routers by sending packets to these transit-only networks. + This document presents a mechanism to hide transit-only networks to + speed up network convergence and reduce vulnerability to remote + attacks. + + Hiding transit-only networks will not impact reachability to the end + hosts. + + In the context of this document, 'hiding' implies that the prefixes + are not installed in the routing tables on OSPF routers. In + [OSPFv2], the IPv4 interface addresses are still visible in the + Router-LSA links and the network-LSA Link-State ID (LSID). In + [OSPFv3], the router-LSAs and network-LSAs do not contain IPv6 + addresses and are not visible. + + This document updates [OSPFv2] and [OSPFv3] by specifying a mechanism + that can be used to hide transit-only networks. + +1.1. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [KEYWORD]. + +2. Hiding IPv4 Transit-Only Networks in OSPFv2 + + In [OSPFv2], networks are classified as point-to-point, broadcast, or + non-broadcast. In the following sections, we will review how these + OSPF networks are being advertised and discuss how to hide them. + +2.1. Point-to-Point Networks + + A point-to-point network joins a single pair of routers. Figure 1 + shows a point-to-point network connecting routers RT1 and RT2. + + +---+.1 198.51.100.0/30 .2+---+ + |RT1|---------------------------|RT2| + +---+ +---+ + + Figure 1. Physical Point-to-Point Network + + + + + +Yang, et al. Standards Track [Page 3] + +RFC 6860 Hiding Transit-Only Networks in OSPF January 2013 + + +2.1.1. Advertising Point-to-Point Networks + + For each numbered point-to-point network, a router has two link + descriptions in its router-LSA: one Type 1 link (point-to-point) + describing the neighboring router, and one Type 3 link (stub) + describing the assigned IPv4 subnet. + + An example of a router-LSA originated by RT1 would look like the + following: + + LS age = 0 ;newly (re-)originated + LS type = 1 ;router-LSA + Link State ID = 192.0.2.1 ;RT1's Router ID + Advertising Router = 192.0.2.1 ;RT1's Router ID + #links = 2 + Link ID = 192.0.2.2 ;RT2's Router ID + Link Data = 198.51.100.1 ;Interface IP address + Type = 1 ;connects to RT2 + Metric = 10 + + Link ID= 198.51.100.0 ;IP network/subnet number + Link Data = 255.255.255.252 ;Subnet's mask + Type = 3 ;Connects to stub network + Metric = 10 + + The Type 1 link will be used for SPF calculation, while the Type 3 + link will be used to install a route to the corresponding subnet in + the Routing Information Base (RIB). + +2.1.2. Hiding Point-to-Point Networks + + To hide a transit-only point-to-point network, the Type 3 link is + omitted from the router-LSA. + + An example of a router-LSA originated by RT1, hiding the point-to- + point network depicted in Figure 1, would look like the following: + + LS age = 0 ;newly (re-)originated + LS type = 1 ;router-LSA + Link State ID = 192.0.2.1 ;RT1's Router ID + Advertising Router = 192.0.2.1 ;RT1's Router ID + #links = 1 + Link ID = 192.0.2.2 ;RT2's Router ID + Link Data = 198.51.100.1 ;Interface IP address + Type = 1 ;connects to RT2 + Metric = 10 + + + + + +Yang, et al. Standards Track [Page 4] + +RFC 6860 Hiding Transit-Only Networks in OSPF January 2013 + + +2.2. Broadcast Networks + + A broadcast network joins many (more than two) routers and supports + the capability to address a single physical message to all of the + attached routers. Figure 2 shows a broadcast network connecting + routers RT3, RT4, and RT5. + + +---+ +---+ + |RT3| |RT4| + +---+ +---+ + |.3 198.51.100.0/24 .4| + +-----------------------------+ + |.5 + +---+ + |RT5| + +---+ + + Figure 2. Broadcast Network + +2.2.1. Advertising Broadcast Networks + + A Designated Router (DR) describes a broadcast network in a + network-LSA. Assuming that RT3 is elected as the DR in Figure 2, an + example of the network-LSA originated by RT3 would look like + + LS age = 0 ;newly (re)originated + LS type = 2 ;network-LSA + Link State ID = 198.51.100.3 ;IP address of the DR (RT3) + Advertising Router = 192.0.2.3 ;RT3's Router ID + Network Mask = 255.255.255.0 + Attached Router = 192.0.2.3 ;RT3's Router ID + Attached Router = 192.0.2.4 ;RT4's Router ID + Attached Router = 192.0.2.5 ;RT5's Router ID + + OSPF obtains the IP network number from the combination of the Link + State ID and the network mask. In addition, the Link State ID is + also being used for the two-way connectivity check. + +2.2.2. Hiding Broadcast Networks + +2.2.2.1. Sending Network-LSA + + A special subnet mask value of 255.255.255.255 MUST be used in the + network-LSA to hide a transit-only broadcast network. While a + broadcast network connects more than routers, using 255.255.255.255 + will not hide an access broadcast network accidentally. + + + + + +Yang, et al. Standards Track [Page 5] + +RFC 6860 Hiding Transit-Only Networks in OSPF January 2013 + + + As there is no change of the Link State ID, the two-way connectivity + check would proceed normally. + + An example of a network-LSA originated by RT3, hiding the broadcast + network depicted in Figure 2, would look like the following: + + LS age = 0 ;newly (re-)originated + LS type = 2 ;network-LSA + Link State ID = 198.51.100.3 ;IP address of the DR (RT3) + Advertising Router = 192.0.2.3 ;RT3's Router ID + Network Mask = 255.255.255.255 ;special subnet mask + Attached Router = 192.0.2.3 ;RT3's Router ID + Attached Router = 192.0.2.4 ;RT4's Router ID + Attached Router = 192.0.2.5 ;RT5's Router ID + +2.2.2.2. Receiving Network-LSA + + It is RECOMMENDED that all routers in an area be upgraded at the same + time to process the modified network-LSA correctly and consistently. + + When a router receives a network-LSA, it MUST calculate the routing + table normally [OSPFv2]. However, if the network mask in the + network-LSA is 255.255.255.255, the router MUST NOT install the route + in the RIB. + +2.2.2.2.1. Backward Compatibility + + When a router that has not yet been upgraded receives a modified + network-LSA, as specified in Section 2.2.2.1, a host route to the + originating DR will be installed. This is not ideal, but it is + better than the current result, which exposes the whole subnet. + + In a partial-deployment scenario, upgraded routers and routers that + have not yet been upgraded may coexist. The former do not install + the host route to the DR's interface, while the latter install it. + Such inconsistencies create routing black holes, which should + normally be avoided. In this case, however, as packets destined for + the transit-only networks are dropped somewhere in the network, the + black holes actually help the DRs defend themselves from remote + attacks. + + In summary, the modification of the network-LSA, as specified in + Section 2.2.2.1, is backward compatible with the current + specification of [OSPFv2], even in a partial-deployment scenario. + + + + + + + +Yang, et al. Standards Track [Page 6] + +RFC 6860 Hiding Transit-Only Networks in OSPF January 2013 + + +2.3. Non-Broadcast Networks + + A non-broadcast network joins many (more than two) routers but does + NOT support the capability to address a single physical message to + all of the attached routers. As mentioned in [OSPFv2], OSPF runs in + one of two modes over non-broadcast networks: Non-Broadcast Multi- + Access (NBMA) or point-to-multipoint. + +2.3.1. NBMA + + In NBMA mode, OSPF emulates operation over a broadcast network: a + Designated Router is elected for the NBMA network, and the Designated + Router originates an LSA for the network. + + To hide an NBMA transit-only network, OSPF adopts the same + modification as that used over the broadcast transit-only network + (see Section 2.2.2). + +2.3.2. Point-to-Multipoint + + In point-to-multipoint mode, OSPF treats the non-broadcast network as + a collection of point-to-point links. + + Figure 3 shows a non-broadcast network connecting routers RT6, RT7, + RT8, and RT9. In this network, all routers can communicate directly, + except for routers RT7 and RT8. + + +---+ +---+ + |RT6| |RT7| + +---+ +---+ + |.6 198.51.100.0/24 .7| + +----------------------------+ + |.8 .9| + +---+ +---+ + |RT8| |RT9| + +---+ +---+ + + Figure 3. Non-Broadcast Network + +2.3.2.1. Advertising Point-to-Multipoint Networks + + For a point-to-multipoint network, a router has multiple link + descriptions in its router-LSA, one Type 1 link (point-to-point) for + EACH directly communicable router, and one Type 3 link (stub) + advertising its interface IPv4 address with a subnet mask of + 255.255.255.255. + + + + + +Yang, et al. Standards Track [Page 7] + +RFC 6860 Hiding Transit-Only Networks in OSPF January 2013 + + + An example of a router-LSA originated by RT7 would look like the + following: + + LS age = 0 ;newly (re-)originated + LS type = 1 ;router-LSA + Link State ID = 192.0.2.7 ;RT7's Router ID + Advertising Router = 192.0.2.7 ;RT7's Router ID + #links = 3 + Link ID = 192.0.2.6 ;RT6's Router ID + Link Data = 198.51.100.7 ;Interface IP address + Type = 1 ;connects to RT6 + Metric = 10 + + Link ID = 192.0.2.9 ;RT9's Router ID + Link Data = 198.51.100.7 ;Interface IP address + Type = 1 ;connects to RT9 + Metric = 10 + + Link ID= 198.51.100.7 ;Interface IP address + Link Data = 255.255.255.255 ;Subnet's mask + Type = 3 ;Connects to stub network + Metric = 0 + +2.3.2.2. Hiding Point-to-Multipoint Networks + + To hide a transit-only point-to-multipoint network, the Type 3 link + is omitted from the router-LSA. + + An example of a router-LSA originated by RT7, hiding the point-to- + point network depicted in Figure 3, would look like the following: + + LS age = 0 ;newly (re-)originated + LS type = 1 ;router-LSA + Link State ID = 192.0.2.7 ;RT7's Router ID + Advertising Router = 192.0.2.7 ;RT7's Router ID + #links = 2 + Link ID = 192.0.2.6 ;RT6's Router ID + Link Data = 198.51.100.7 ;Interface IP address + Type = 1 ;connects to RT6 + Metric = 10 + + Link ID = 192.0.2.9 ;RT9's Router ID + Link Data = 198.51.100.7 ;Interface IP address + Type = 1 ;connects to RT9 + Metric = 10 + + + + + + +Yang, et al. Standards Track [Page 8] + +RFC 6860 Hiding Transit-Only Networks in OSPF January 2013 + + +3. Hiding IPv6 Transit-Only Networks in OSPFv3 + + In [OSPFv3], addressing semantics have been removed from the OSPF + protocol packets and the main LSA types, leaving a network-protocol- + independent core. + + More specifically, router-LSAs and network-LSAs no longer contain + network addresses but simply express topology information. Instead, + two new LSA types, link-LSA and intra-area-prefix-LSA, have been + introduced. A link-LSA associates a list of IPv6 addresses to a link + and has local-link flooding scope, and an intra-area-prefix-LSA + either associates a list of IPv6 addresses with a router by + referencing a router-LSA or associates a list of IPv6 addresses with + a broadcast/NBMA network by referencing a network-LSA. In the latter + case, the prefixes in the link-LSAs from adjacent neighbors are + copied into the intra-area-prefix-LSA by the Designated Router. + + To hide a transit-only network in [OSPFv3], the IPv6 address prefixes + are omitted from the router-LSA. Consequently, when a Designated + Router builds an intra-area-prefix-LSA referencing a network-LSA, + these IPv6 address prefixes will be omitted. + + In addition, when a router builds an intra-area-prefix-LSA that is + referencing a router-LSA, the associated IPv6 address prefixes from + the transit-only network MUST also be omitted from the intra-area- + prefix-LSA. + +3.1. Hiding AF-Enabled Transit-Only Networks in OSPFv3 + + [OSPF-AF] supports multiple Address Families (AFs) by mapping each AF + to a separate Instance ID and OSPFv3 instance. + + In the meantime, each prefix advertised in OSPFv3 has a prefix length + field [OSPFv3], which facilitates advertising prefixes of different + lengths in different AFs. The existing LSAs defined in [OSPFv3] are + used for prefix advertising, and there is no need to define new LSAs. + + In other words, as link-LSAs and intra-area-prefix-LSAs are still + being used, the same mechanism explained in Section 3 can be used to + hide those AF-enabled transit-only networks as well. + +4. Operational Considerations + + By eliminating the ability to reach transit-only networks, the + ability to manage these interfaces may be reduced. In order not to + reduce the functionality and capability of the overall network, it is + recommended that extensions such as [UNNUMBERED] also be implemented. + + + + +Yang, et al. Standards Track [Page 9] + +RFC 6860 Hiding Transit-Only Networks in OSPF January 2013 + + + Note that the extension defined in [UNNUMBERED] may provide the user + with the IP address of an interface. If that address was hidden, as + specified in this document, then even though the address is assigned + to the interface, it will not be reachable. + +4.1. Forwarding Address + + A non-zero forwarding address can be advertised in AS-external-LSAs + and Not-So-Stubby Area LSAs (NSSA-LSAs) [NSSA] to achieve optimal + routing to Autonomous System (AS) external routes. The matching + routing table entry for the forwarding address must exist to + facilitate the SPF calculation. + + In other words, when prefix-hiding is configured on the next-hop + interface, the next-hop address MUST NOT be advertised as a + forwarding address. + + Consequently, sub-optimal routing to these AS external routes may + exist when prefix-hiding is configured. + +4.2. Virtual Links + + Virtual links are used to connect physically separate components of + the backbone. The virtual link's viability is determined by the + existence of an intra-area path between two endpoints. The matching + routing table entries of the endpoints must exist to ensure the + virtual link's operation. + + In other words, if prefix-hiding is configured on an interface, the + virtual link endpoint MUST NOT use that interface's IP address as the + virtual interface's IP address. + +4.3. Unnumbered Interfaces + + Note that no host route is generated for, and no IP packets can be + addressed to, interfaces to unnumbered point-to-point networks + [OSPFv2]. In other words, these addresses are already hidden. + + However, for manageability purposes, it may be common practice to + manually include the numbered interface (for example, a loopback + interface to which the unnumbered interface points) in routing + updates. If needed, the numbered interface's address can be hidden + by using the mechanisms described in this document or by simply not + advertising it. + + + + + + + +Yang, et al. Standards Track [Page 10] + +RFC 6860 Hiding Transit-Only Networks in OSPF January 2013 + + + Before deciding to hide (or suppress the advertisement of) a numbered + interface, it is very important to consider other uses that interface + may have. Examples of common uses may include virtual link endpoint, + inter-domain routing peering point, etc. In other words, it may not + be possible to hide the address associated to an unnumbered interface + due to other applications in the network. + +5. Security Considerations + + One motivation for this document is to reduce vulnerability to remote + attacks by hiding transit-only networks. The result should then be + that fewer OSPF core networks will be exposed. + + The mechanisms described above result in reachability information + from transit-only networks not being installed in the routers' + forwarding tables. The effect is that even if the address of a + transit-only network is known, the forwarding information is not + present in the routers to reach the destination. Also, in some + cases, the address information is completely omitted from the LSA. + + Some information in the LSA (such as the OSPF Router ID) cannot be + omitted. Even though the Router ID may be taken from an IPv4 address + on the router, the configuration can be easily changed. Note again + that having an address doesn't guarantee reachability if the + information is hidden from the forwarding tables. + + While the steps described in this document are meant to be applied + only to transit-only networks, they could be used to hide other + networks as well. It is expected that the same care that users put + into the configuration of other routing protocol parameters is used + in the configuration of this extension. + +6. Acknowledgments + + The idea of using a special subnet mask to hide broadcast networks in + OSPF was originally introduced in the US patent "Apparatus and method + to hide transit only multi-access networks in OSPF" (patent number: + 7,929,524), by Yi Yang, Alvaro Retana, James Ng, Abhay Roy, Alfred + Lindem, Sina Mirtorabi, Timothy Gage, and Khalid Raza. + + The authors would like to thank Acee Lindem, Shraddha Hegde, Rajesh + Shetty, Marek Karasek, Michael Barnes, Paul Wells, Adrian Farrel, and + Stephen Farrell for their feedback on the document. + + + + + + + + +Yang, et al. Standards Track [Page 11] + +RFC 6860 Hiding Transit-Only Networks in OSPF January 2013 + + +7. References + +7.1. Normative References + + [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) + Option", RFC 3101, January 2003. + + [OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, + April 1998. + + [OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF + for IPv6", RFC 5340, July 2008. + + [OSPF-AF] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., + and R. Aggarwal, "Support of Address Families in + OSPFv3", RFC 5838, April 2010. + +7.2. Informative References + + [UNNUMBERED] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., + Shen, N., and JR. Rivers, "Extending ICMP for Interface + and Next-Hop Identification", RFC 5837, April 2010. + + + + + + + + + + + + + + + + + + + + + + + + + + +Yang, et al. Standards Track [Page 12] + +RFC 6860 Hiding Transit-Only Networks in OSPF January 2013 + + +Authors' Addresses + + Yi Yang + Cisco Systems, Inc. + 7025 Kit Creek Road + RTP, NC 27709 + USA + + EMail: yiya@cisco.com + + + Alvaro Retana + Cisco Systems, Inc. + 7025 Kit Creek Road + RTP, NC 27709 + USA + + EMail: aretana@cisco.com + + + Abhay Roy + Cisco Systems, Inc. + 225 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: akr@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + +Yang, et al. Standards Track [Page 13] + |