OSPF Working Group Y. Yang
Internet-Draft Cisco Systems
Updates: 2328, 5340 (if approved) A. Retana
Intended status: Standards Track Hewlett-Packard Co.
Expires: January 17, 2013 A. Roy
Cisco Systems
July 16, 2012
Hiding Transit-only Networks in OSPF
<draft-ietf-ospf-prefix-hiding-05.txt>
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 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
minimize remote attack vulnerability.
This document updates RFC 2328 and RFC 5340.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2013.
Yang, et al. Expires January 17, 2013 [Page 1]
Internet-Draft Hiding Transit-only Networks in OSPF July 16, 2012
Copyright Notice
Copyright (c) 2012 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.
Yang, et al. Expires January 17, 2013 [Page 2]
Internet-Draft Hiding Transit-only Networks in OSPF July 16, 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3
2. Hiding IPv4 Transit-only Networks in OSPFv2 . . . . . . . . . . 4
2.1. Point-to-Point Networks . . . . . . . . . . . . . . . . . . 4
2.1.1. Advertising Point-to-Point Networks . . . . . . . . . 4
2.1.2. Hiding Point-to-Point Networks . . . . . . . . . . . . 5
2.2. Broadcast Networks . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Advertising Broadcast Networks . . . . . . . . . . . . 5
2.2.2. Hiding Broadcast Networks . . . . . . . . . . . . . . 6
2.2.2.1. Sending Network-LSA . . . . . . . . . . . . . . . 6
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 . . . . 8
2.3.2.2. Hiding Point-to-MultiPoint Networks . . . . . . . 8
3. Hiding IPv6 Transit-only Networks in OSPFv3 . . . . . . . . . . 9
4. Hiding AF Enabled Transit-only Networks in OSPFv3 . . . . . . . 9
5. Forwarding Address . . . . . . . . . . . . . . . . . . . . . . 10
6. Virtual Links . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Operational Considerations . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 minimize remote attack
vulnerability.
Hiding transit-only networks will not impact reachability to the end
hosts.
1.1. Requirements notation
Yang, et al. Expires January 17, 2013 [Page 3]
Internet-Draft Hiding Transit-only Networks in OSPF July 16, 2012
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
2.1.1. Advertising Point-to-Point Networks
For each numbered point-to-point network, a router has 2 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 router-LSA originated by RT1 would look like
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
Yang, et al. Expires January 17, 2013 [Page 4]
Internet-Draft Hiding Transit-only Networks in OSPF July 16, 2012
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 MUST
be omitted from the router-LSA.
An example of router-LSA originated by RT1, hiding the point-to-point
network depicted in Figure 1, would look like
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
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
router 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
For each broadcast network, a designated router (DR) describes it in
its network-LSA. Assuming RT3 is elected as the DR in Figure 2, an
example of the network-LSA originated by RT3 would look like
Yang, et al. Expires January 17, 2013 [Page 5]
Internet-Draft Hiding Transit-only Networks in OSPF July 16, 2012
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 2-way connectivity check.
2.2.2. Hiding Broadcast Networks
2.2.2.1. Sending Network-LSA
To hide a transit-only broadcast network, a special network mask
value 255.255.255.255 MUST be used in the network-LSA. While a
broadcast network connects more than routers, using 255.255.255.255
will not hide an access broadcast network accidentally.
As there is no change of the Link State ID, the 2-way connectivity
check would proceed normally.
An example of network-LSA originated by RT3, hiding the broadcast
network depicted in Figure 2, 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.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's 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 check the 2-way
connectivity as normal. 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
Yang, et al. Expires January 17, 2013 [Page 6]
Internet-Draft Hiding Transit-only Networks in OSPF July 16, 2012
When a not-yet-upgraded router 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 better than the current result,
which exposes the whole subnet.
In a partial deployment scenario, upgraded routers and not-yet-
upgraded routers 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 the 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.
2.3. Non-Broadcast Networks
A non-broadcast networks 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 a NBMA transit-only network, OSPF adopts the same
modification over the broadcast transit-only network, as defined in
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 router RT6, RT7,
RT8, and RT9. In this network, all routers can communicate directly,
except for routers RT7 and RT8.
Yang, et al. Expires January 17, 2013 [Page 7]
Internet-Draft Hiding Transit-only Networks in OSPF July 16, 2012
+---+ +---+
|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.
An example of router-LSA originated by RT7 would look like
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 MUST be omitted from the router-LSA.
Yang, et al. Expires January 17, 2013 [Page 8]
Internet-Draft Hiding Transit-only Networks in OSPF July 16, 2012
An example of router-LSA originated by RT7, hiding the point-to-
point network depicted in Figure 3, would look like
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
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 address 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 associated IPv6
address prefixes MUST be omitted from the link-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.
4. Hiding AF Enabled Transit-only Networks in OSPFv3
Yang, et al. Expires January 17, 2013 [Page 9]
Internet-Draft Hiding Transit-only Networks in OSPF July 16, 2012
[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.
5. Forwarding Address
A non-zero forwarding address can be advertised in AS-external-LSAs
and NSSA-LSAs [NSSA] to achieve optimal routing to 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.
6. 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.
7. Operational Considerations
By eliminating the ability to reach transit-only networks, the
ability to manage these interfaces may be reduced. In order to not
reduce the functionality and capability of the overall network, it is
recommended that extensions such as [RFC5837] be also implemented.
Yang, et al. Expires January 17, 2013 [Page 10]
Internet-Draft Hiding Transit-only Networks in OSPF July 16, 2012
8. Security Considerations
One motivation for this document is to reduce remote attack
vulnerability by hiding transit-only networks. The result should
then be that fewer OSPF core networks will be exposed to un-
authorized access.
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 to
transit-only networks ONLY, they could be used to hide other networks
as well. It is expected that the same care that users put on the
configuration of other routing protocol parameters is used in the
configuration of this extension.
9. IANA Considerations
No actions are required from IANA as result of the publication of
this document.
10. Acknowledgments
The draft text was produced using Stefan Santesson's NroffEdit
application.
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, and Paul Wells, for their
feedback on the document.
Yang, et al. Expires January 17, 2013 [Page 11]
Internet-Draft Hiding Transit-only Networks in OSPF July 16, 2012
11. References
11.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", 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., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3",
RFC5838, April 2010.
11.2. Informative References
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR.
Rivers, "Extending ICMP for Interface and Next-Hop
Identification", RFC 5837, April 2010.
Authors' Addresses
Yi Yang
Cisco Systems
7025 Kit Creek Road
RTP, NC 27709
USA
Email: yiya@cisco.com
Alvaro Retana
Hewlett-Packard Co.
2610 Wycliff Road
Raleigh, NC 27607
USA
Email: alvaro.retana@hp.com
Abhay Roy
Cisco Systems
Yang, et al. Expires January 17, 2013 [Page 12]
Internet-Draft Hiding Transit-only Networks in OSPF July 16, 2012
225 West Tasman Drive
San Jose, CA 95134
USA
Email: akr@cisco.com
Yang, et al. Expires January 17, 2013 [Page 13]