draft-ietf-opsec-lla-only-02.txt   draft-ietf-opsec-lla-only-03.txt 
Operational Security Capabilities for M. Behringer Operational Security Capabilities for M. Behringer
IP Network Infrastructure E. Vyncke IP Network Infrastructure E. Vyncke
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational October 22, 2012 Intended status: Informational February 12, 2013
Expires: April 25, 2013 Expires: August 16, 2013
Using Only Link-Local Addressing Inside an IPv6 Network Using Only Link-Local Addressing Inside an IPv6 Network
draft-ietf-opsec-lla-only-02 draft-ietf-opsec-lla-only-03
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 34 skipping to change at page 1, line 34
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 April 25, 2013. This Internet-Draft will expire on August 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Using Link-Local Address on Infrastructure Links . . . . . . . 3 2. Using Link-Local Address on Infrastructure Links . . . . . . . 3
2.1. The Approach . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. The Approach . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Internet Exchange Points . . . . . . . . . . . . . . . . . 6 2.4. Internet Exchange Points . . . . . . . . . . . . . . . . . 6
2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
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
skipping to change at page 5, line 13 skipping to change at page 5, line 13
line cards are smaller but also because there are less prefixes in line cards are smaller but also because there are less prefixes in
the Routing Information Base hence accelerating the routing the Routing Information Base hence accelerating the routing
algorithm). Note: smaller routing tables can also be achieved by algorithm). Note: smaller routing tables can also be achieved by
putting interfaces in passive mode for the IGP. putting interfaces in passive mode for the IGP.
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, for example a TCP SYN flood, or he can traffic to that address, for example a TCP SYN flood, or he can
intent SSH brute force password attacks. If a network only uses intent SSH brute force password attacks. If a network only uses
loopback addresses for the routers, only those loopback addresses loopback addresses for the routers, only those loopback addresses
need to be protected from outside the network. This significantly need to be protected from outside the network. This may ease
eases protection measures, such as infrastructure access control protection measures, such as infrastructure access control lists. If
lists. See also [I-D.ietf-grow-private-ip-sp-cores] for further the addressing scheme is set up such that all link addresses and all
discussion on this topic. loopback addresses are aggregatable, and if the infrastructure access
list covers that entire aggregated space, then changing to link-local
addresses does not reduce the attack surface significantly. See also
[I-D.ietf-grow-private-ip-sp-cores] for further discussion on this
topic.
Lower configuration complexity: LLAs require no specific Lower configuration complexity: LLAs require no specific
configuration (except when they are statically configured), thereby configuration (except when they are statically configured), thereby
lowering the complexity and size of router configurations. This also lowering the complexity and size of router configurations. This also
reduces the likelihood of configuration mistakes. reduces the likelihood of configuration mistakes.
Simpler DNS: Less routable address space in use also means less DNS Simpler DNS: Less routable address space in use also means less DNS
mappings to maintain. mappings to maintain.
2.3. Caveats 2.3. Caveats
skipping to change at page 6, line 6 skipping to change at page 6, line 11
address. Today this does not display the specific interface the address. Today this does not display the specific interface the
packets came in on. Also here, RFC5837 [RFC5837] provides a packets came in on. Also here, RFC5837 [RFC5837] provides a
solution. solution.
Hardware dependency: LLAs are usually EUI-64 based, hence, they Hardware dependency: LLAs are usually 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. But, LLAs can the EUI-64 LLA and breaking the routing neighborship. But, LLAs can
be statically configured such as fe80::1 and fe80::2 which can be be statically configured such as fe80::1 and fe80::2 which can be
used to configure any required static routing neighborship. used to configure any required static routing neighborship. This
static configuration is similar in complexity to statically
configured greater than link-local addresses, however, it is only
required where routing peers are explicitly configured.
Network Management System (NMS) toolkits: If there is any NMS tool Network Management System (NMS) toolkits: If there is any NMS tool
that makes use of interface IP address of a router to carry out any that makes use of interface IP address of a router to carry out any
of NMS functions, then it would no longer work, if the interface is of NMS functions, then it would no longer work, if the interface is
missing routable address. A possible workaround for such tools is to missing routable address. A possible workaround for such tools is to
use the routable loopback address of the router instead. Most vendor use the routable loopback address of the router instead. Most vendor
implementations allow the specification of the loopback address for implementations allow the specification of the loopback address for
SYSLOG, IPfix, SNMP. LLDP (IEEE 802.1AB-2009) runs directly over SYSLOG, IPfix, SNMP. LLDP (IEEE 802.1AB-2009) runs directly over
Ethernet and does not require any IPv6 address so dynamic network Ethernet and does not require any IPv6 address so dynamic network
discovery is not hindered when using LLDP. But, network discovery discovery is not hindered when using LLDP. But, network discovery
skipping to change at page 8, line 18 skipping to change at page 8, line 29
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,
Benoit Claise, Simon Eng, Wes George, Janos Mohacsi, Alvaro Retana, Benoit Claise, Simon Eng, Wes George, Janos Mohacsi, Alvaro Retana,
Ivan Pepelnjak for their useful comments about this work. Ivan Pepelnjak, and Harald Michl for their useful comments about this
work.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References 6.2. Informative References
[I-D.ietf-grow-private-ip-sp-cores] [I-D.ietf-grow-private-ip-sp-cores]
Kirkham, A., "Issues with Private IP Addressing in the Kirkham, A., "Issues with Private IP Addressing in the
Internet", draft-ietf-grow-private-ip-sp-cores-07 (work in Internet", draft-ietf-grow-private-ip-sp-cores-07 (work in
progress), July 2012. progress), July 2012.
[I-D.ietf-ospf-prefix-hiding] [I-D.ietf-ospf-prefix-hiding]
Yang, Y., Retana, A., and A. Roy, "Hiding Transit-only Yang, Y., Retana, A., and A. Roy, "Hiding Transit-only
Networks in OSPF", draft-ietf-ospf-prefix-hiding-05 (work Networks in OSPF", draft-ietf-ospf-prefix-hiding-07 (work
in progress), July 2012. in progress), December 2012.
[I-D.jdurand-bgp-security] [I-D.jdurand-bgp-security]
Durand, J., Pepelnjak, I., and G. Doering, "BGP operations Durand, J., Pepelnjak, I., and G. Doering, "BGP operations
and security", draft-jdurand-bgp-security-02 (work in and security", draft-jdurand-bgp-security-02 (work in
progress), September 2012. progress), September 2012.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
skipping to change at page 9, line 23 skipping to change at page 9, line 35
Rivers, "Extending ICMP for Interface and Next-Hop Rivers, "Extending ICMP for Interface and Next-Hop
Identification", RFC 5837, April 2010. Identification", RFC 5837, April 2010.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, March 2011. Router Control Plane", RFC 6192, March 2011.
Authors' Addresses Authors' Addresses
Michael Behringer Michael Behringer
Cisco Cisco
400 Avenue Roumanille, Bat 3 Building D, 45 Allee des Ormes
Biot, 06410 Mougins, 06250
France France
Email: mbehring@cisco.com Email: mbehring@cisco.com
Eric Vyncke Eric Vyncke
Cisco Cisco
De Kleetlaan, 6A De Kleetlaan, 6A
Diegem, 1831 Diegem, 1831
Belgium Belgium
 End of changes. 10 change blocks. 
16 lines changed or deleted 24 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/