draft-ietf-opsec-lla-only-10.txt   draft-ietf-opsec-lla-only-11.txt 
OPsec Working Group M. Behringer OPsec Working Group M. Behringer
Internet-Draft E. Vyncke Internet-Draft E. Vyncke
Intended status: Informational Cisco Intended status: Informational Cisco
Expires: January 29, 2015 July 28, 2014 Expires: March 29, 2015 September 25, 2014
Using Only Link-Local Addressing Inside an IPv6 Network Using Only Link-Local Addressing Inside an IPv6 Network
draft-ietf-opsec-lla-only-10 draft-ietf-opsec-lla-only-11
Abstract Abstract
In an IPv6 network it is possible to use only link-local addresses on In an IPv6 network it is possible to use only link-local addresses on
infrastructure links between routers. This document discusses the infrastructure links between routers. This document discusses the
advantages and disadvantages of this approach to help the decision advantages and disadvantages of this approach to help the decision
process for a given network. process for a given network.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 29, 2015. This Internet-Draft will expire on March 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 2, line 29 skipping to change at page 2, line 29
1. Introduction 1. Introduction
An infrastructure link between a set of routers typically does not An infrastructure link between a set of routers typically does not
require global or unique local addresses [RFC4193]. Using only link- require global or unique local addresses [RFC4193]. Using only link-
local addressing on such links has a number of advantages. For local addressing on such links has a number of advantages. For
example, that routing tables do not need to carry link addressing, example, that routing tables do not need to carry link addressing,
and can therefore be significantly smaller. This helps to decrease and can therefore be significantly smaller. This helps to decrease
failover times in certain routing convergence events. An interface failover times in certain routing convergence events. An interface
of a router is also not reachable beyond the link boundaries, of a router is also not reachable beyond the link boundaries,
therefore reducing the attack horizon. therefore reducing the attack surface.
This document discusses the advantages and caveats of this approach. This document discusses the advantages and caveats of this approach.
Note that some traditionally used techniques to operate a network Note that some traditionally used techniques to operate a network
such as pinging interfaces, or seeing interface information in a such as pinging interfaces, or seeing interface information in a
traceroute do not work with this approach. Details are discussed traceroute do not work with this approach. Details are discussed
below. below.
During WG and IETF last call the technical correctness of the During WG and IETF last call the technical correctness of the
document has been reviewed, however debate exists as to whether to document has been reviewed, however debate exists as to whether to
skipping to change at page 4, line 39 skipping to change at page 4, line 39
router configurations. This also reduces the likelihood of router configurations. This also reduces the likelihood of
configuration mistakes. configuration mistakes.
Simpler DNS: Less routable address space in use also means less Simpler DNS: Less routable address space in use also means less
reverse and forward mapping DNS resource records to maintain. Of reverse and forward mapping DNS resource records to maintain. Of
course, if the operator selects not to enter any global interface course, if the operator selects not to enter any global interface
addresses in the DNS anyway, then this is less of an advantage. addresses in the DNS anyway, then this is less of an advantage.
Reduced attack surface: Every routable address on a router Reduced attack surface: Every routable address on a router
constitutes a potential attack point: a remote attacker can send constitutes a potential attack point: a remote attacker can send
traffic to that address. Examples are a TCP SYN flood (see traffic to that address, for example a TCP SYN flood (see [RFC4987]).
[RFC4987]) and SSH brute force password attacks. If a network only If a network only uses the addresses of the router loopback
uses the addresses of the router loopback interface(s), only those interface(s), only those addresses need to be protected from outside
addresses need to be protected from outside the network. This may the network. This may ease protection measures, such as
ease protection measures, such as infrastructure access control lists infrastructure access control lists (iACL). Without using link-local
(iACL). addresses, it is still possible to achieve the simple iACL if the
network addressing scheme is set up such that all link and loopback
Without using link-local addresses, it is still possible to achieve interfaces have greater than link-local addresses and are
the simple iACL if the network addressing scheme is set up such that aggregatable, and if the infrastructure access list covers that
all link and loopback interfaces have greater than link-local entire aggregated space. See also [RFC6752] for further discussion
addresses and are aggregatable, and if the infrastructure access list on this topic. [RFC6860] describes another approach to hide
covers that entire aggregated space. See also [RFC6752] for further addressing on infrastructure links for OSPFv2 and OSPFv3, by
discussion on this topic. modifying the existing protocols. This document does not modify any
protocol, however it works only for IPv6.
[RFC6860] describes another approach to hide addressing on
infrastructure links for OSPFv2 and OSPFv3, by modifying the existing
protocols. This document does not modify any protocol, however it
works only for IPv6.
2.3. Caveats 2.3. Caveats
The caveats listed in this section are in no particular order. The caveats listed in this section are in no particular order.
Interface ping: if an interface doesn't have a routable address, it Interface ping: if an interface doesn't have a routable address, it
can only be pinged from a node on the same link. Therefore, it is can only be pinged from a node on the same link. Therefore, it is
not possible to ping a specific link interface remotely. A possible not possible to ping a specific link interface remotely. A possible
workaround is to ping the loopback address of a router instead. In workaround is to ping the loopback address of a router instead. In
most cases today, it is not possible to see which link the packet was most cases today, it is not possible to see which link the packet was
skipping to change at page 5, line 33 skipping to change at page 5, line 28
router on the addresses of loopback interfaces, yet see which router on the addresses of loopback interfaces, yet see which
interface the packet was received on. To check liveliness of a interface the packet was received on. To check liveliness of a
specific interface, it may be necessary to use other methods, such as specific interface, it may be necessary to use other methods, such as
connecting to the router via SSH and checking locally or using SNMP. connecting to the router via SSH and checking locally or using SNMP.
Traceroute: similar to the ping case, a reply to a traceroute packet Traceroute: similar to the ping case, a reply to a traceroute packet
would come from the address of a loopback interface, and current would come from the address of a loopback interface, and current
implementations do not display the specific interface the packets implementations do not display the specific interface the packets
came in on. Also here, [RFC5837] provides a solution. As in the came in on. Also here, [RFC5837] provides a solution. As in the
ping case above, it is not possible to traceroute to a particular ping case above, it is not possible to traceroute to a particular
interface if it only has a link-local address. interface if it only has a link-local address. Conversely, this
approach may make network topology discovery from outside the network
simpler; because instead of responding with multiple different
interface IP addresses, which have to be correlated by the outsider,
a router will always respond with the same loopback address. If
reverse DNS mapping is used, the mapping is trivial in either case.
Hardware dependency: LLAs are usually EUI-64 based, hence, they Hardware dependency: LLAs have usually been EUI-64 based, hence, they
change when the MAC address is changed. This could pose problem in a change when the MAC address is changed. This could pose problem in a
case where the routing neighbor must be configured explicitly (e.g. case where the routing neighbor must be configured explicitly (e.g.
BGP) and a line card needs to be physically replaced hence changing BGP) and a line card needs to be physically replaced hence changing
the EUI-64 LLA and breaking the routing neighborship. LLAs can be the EUI-64 LLA and breaking the routing neighborship. LLAs can be
statically configured such as fe80::1 and fe80::2 which can be used statically configured such as fe80::1 and fe80::2 which can be used
to configure any required static routing neighborship. However, this to configure any required static routing neighborship. However, this
static LLA configuration may be more complex to operate than static LLA configuration may be more complex to operate than
statically configured greater than link-local scope addresses, statically configured greater than link-local scope addresses,
because LLAs are inherently ambiguous for a multi-link node such as a because LLAs are inherently ambiguous for a multi-link node such as a
router; to deal with the ambiguity, the link zone index must also be router; to deal with the ambiguity, the link zone index must also be
skipping to change at page 6, line 16 skipping to change at page 6, line 16
instead. Most vendor implementations allow the specification of instead. Most vendor implementations allow the specification of
loopback interface addresses for SYSLOG, IPfix, and SNMP. The loopback interface addresses for SYSLOG, IPfix, and SNMP. The
protocol LLDP (IEEE 802.1AB-2009) runs directly over Ethernet and protocol LLDP (IEEE 802.1AB-2009) runs directly over Ethernet and
does not require any IPv6 address, so dynamic network discovery is does not require any IPv6 address, so dynamic network discovery is
not hindered when using LLDP. But, network discovery based on NDP not hindered when using LLDP. But, network discovery based on NDP
cache content will only display the link-local addresses and not the cache content will only display the link-local addresses and not the
addresses of the loopback interfaces; therefore, network discovery addresses of the loopback interfaces; therefore, network discovery
should rather be based on the Route Information Base to detect should rather be based on the Route Information Base to detect
adjacent nodes. adjacent nodes.
MPLS and RSVP-TE [RFC3209] allow establishing a MPLS LSP on a path MPLS and RSVP-TE [RFC3209] allow establishing an MPLS LSP on a path
that is explicitly identified by a strict sequence of IP prefixes or that is explicitly identified by a strict sequence of IP prefixes or
addresses (each pertaining to an interface or a router on the path). addresses (each pertaining to an interface or a router on the path).
This is commonly used for Fast Re-Route (FRR). However, if an This is commonly used for Fast Re-Route (FRR). However, if an
interface uses only a link-local address, then such LSPs cannot be interface uses only a link-local address, then such LSPs cannot be
established. At the time of writing this document, there is no established. At the time of writing this document, there is no
workaround for this case; therefore, where RSVP-TE is being used, the workaround for this case; therefore, where RSVP-TE is being used, the
approach described in this document does not work. approach described in this document does not work.
2.4. Internet Exchange Points 2.4. Internet Exchange Points
skipping to change at page 6, line 47 skipping to change at page 6, line 47
Apart from general device security guidelines, there are generally Apart from general device security guidelines, there are generally
two additional ways to raise security (see also two additional ways to raise security (see also
[I-D.ietf-opsec-bgp-security]): [I-D.ietf-opsec-bgp-security]):
1. Not to announce the prefix in question, and 1. Not to announce the prefix in question, and
2. To drop all traffic from remote locations destined to the IXP 2. To drop all traffic from remote locations destined to the IXP
prefixes. prefixes.
Not announcing the prefix of the IXP would frequently result in Not announcing the prefix of the IXP would frequently result in
traceroute and similar packets (required for PMTUd) to be dropped due traceroute and similar packets (required for PMTUD) to be dropped due
to uRPF checks. Given that PMTUd is critical, this is generally not to unicast Reverse Path Forwarding (uRPF) checks. Given that PMTUD
acceptable. Dropping all external traffic to the IXP prefix is hard is critical, this is generally not acceptable. Dropping all external
to implement, because if only one service provider connected to an traffic to the IXP prefix is hard to implement, because if only one
IXP does not filter correctly, then all IXP routers are reachable service provider connected to an IXP does not filter correctly, then
from at least that service provider network. all IXP routers are reachable from at least that service provider
network.
As the prefix used in the IXP is usually longer than a /48, it is As the prefix used in the IXP is usually longer than a /48, it is
frequently dropped by route filters on the Internet having the same frequently dropped by route filters on the Internet having the same
net effect as not announcing the prefix. net effect as not announcing the prefix.
Using link-local addresses on the IXP may help in this scenario. In Using link-local addresses on the IXP may help in this scenario. In
this case, the generated ICMPv6 packets would be generated from this case, the generated ICMPv6 packets would be generated from
loopback interfaces or from any other interface with a globally loopback interfaces or from any other interface with a globally
routable address without any configuration. However in this case, routable address without any configuration. However in this case,
each service provider would use his own address space, making a each service provider would use his own address space, making a
skipping to change at page 7, line 44 skipping to change at page 7, line 44
Using exclusively link-local addressing on infrastructure links has a Using exclusively link-local addressing on infrastructure links has a
number of advantages and disadvantages, which are both described in number of advantages and disadvantages, which are both described in
detail in this document. A network operator can use this document to detail in this document. A network operator can use this document to
evaluate whether using link-local addressing on infrastructure links evaluate whether using link-local addressing on infrastructure links
is a good idea in the context of his/her network or not. This is a good idea in the context of his/her network or not. This
document makes no particular recommendation either in favour or document makes no particular recommendation either in favour or
against. against.
3. Security Considerations 3. Security Considerations
Using LLAs only on infrastructure links reduces the attack surface of Using only LLAs on infrastructure links reduces the attack surface of
a router: loopback interfaces with routed addresses are still a router: loopback interfaces with routed addresses are still
reachable and must be secured, but infrastructure links can only be reachable and must be secured, but infrastructure links can only be
attacked from the local link. This simplifies security of control attacked from the local link. This simplifies security of control
and management planes. The approach does not impact the security of and management planes. The approach does not impact the security of
the data plane. The link-local-only approach does not address the data plane. The link-local-only approach does not address
control plane [RFC6192] attacks generated by data plane packets (such control plane [RFC6192] attacks generated by data plane packets (such
as hop-limit expiration or packets containing a hop-by-hop extension as hop-limit expiration or packets containing a hop-by-hop extension
header). header).
For additional security considerations, as previously stated, see
also [RFC5837] and [I-D.ietf-opsec-bgp-security].
4. IANA Considerations 4. IANA Considerations
There are no IANA considerations or implications that arise from this There are no IANA considerations or implications that arise from this
document. document.
5. Acknowledgements 5. Acknowledgements
The authors would like to thank Salman Asadullah, Brian Carpenter, The authors would like to thank Salman Asadullah, Brian Carpenter,
Bill Cerveny, Benoit Claise, Rama Darbha, Simon Eng, Wes George, Bill Cerveny, Benoit Claise, Rama Darbha, Simon Eng, Wes George,
Fernando Gont, Jen Linkova, Harald Michl, Janos Mohacsi, Ivan Fernando Gont, Jen Linkova, Harald Michl, Janos Mohacsi, Ivan
Pepelnjak, Alvaro Retana, Jinmei Tatuya and Peter Yee for their Pepelnjak, Alvaro Retana, Jinmei Tatuya and Peter Yee for their
useful comments about this work. useful comments about this work.
6. Informative References 6. Informative References
[I-D.ietf-opsec-bgp-security] [I-D.ietf-opsec-bgp-security]
Durand, J., Pepelnjak, I., and G. Doering, "BGP operations Durand, J., Pepelnjak, I., and G. Doering, "BGP operations
and security", draft-ietf-opsec-bgp-security-03 (work in and security", draft-ietf-opsec-bgp-security-05 (work in
progress), April 2014. progress), August 2014.
[IS-IS] ISO/IEC 10589, , "Intermediate System to Intermediate [IS-IS] ISO/IEC 10589, , "Intermediate System to Intermediate
System Intra-Domain Routing Exchange Protocol for use in System Intra-Domain Routing Exchange Protocol for use in
Conjunction with the Protocol for Providing the Conjunction with the Protocol for Providing the
Connectionless-mode Network Service (ISO 8473)", June Connectionless-mode Network Service (ISO 8473)", June
1992. 1992.
[RFC0495] McKenzie, A., "Telnet Protocol specifications", RFC 495, [RFC0495] McKenzie, A., "Telnet Protocol specifications", RFC 495,
May 1973. May 1973.
 End of changes. 12 change blocks. 
34 lines changed or deleted 39 lines changed or added

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