draft-ietf-v6ops-ra-guard-implementation-03.txt   draft-ietf-v6ops-ra-guard-implementation-04.txt 
IPv6 Operations Working Group (v6ops) F. Gont IPv6 Operations Working Group (v6ops) F. Gont
Internet-Draft UK CPNI Internet-Draft UK CPNI
Intended status: BCP May 11, 2012 Updates: 6105 (if approved) May 22, 2012
Expires: November 12, 2012 Intended status: BCP
Expires: November 23, 2012
Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
draft-ietf-v6ops-ra-guard-implementation-03 draft-ietf-v6ops-ra-guard-implementation-04
Abstract Abstract
The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly
employed to mitigate attack vectors based on forged ICMPv6 Router employed to mitigate attack vectors based on forged ICMPv6 Router
Advertisement messages. Many existing IPv6 deployments rely on RA- Advertisement messages. Many existing IPv6 deployments rely on RA-
Guard as the first line of defense against the aforementioned attack Guard as the first line of defense against the aforementioned attack
vectors. However, some implementations of RA-Guard have been found vectors. However, some implementations of RA-Guard have been found
to be prone to circumvention by employing IPv6 Extension Headers. to be prone to circumvention by employing IPv6 Extension Headers.
This document describes the evasion techniques that affect the This document describes the evasion techniques that affect the
aforementioned implementations, and provides advice on the aforementioned implementations, and formally updates RFC 6105, such
implementation of RA-Guard, such that the RA-Guard evasion vectors that the aforementioned RA-Guard evasion vectors are eliminated.
are eliminated.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 12, 2012. This Internet-Draft will expire on November 23, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Evasion techniques for some Router Advertisement Guard (RA 2. Evasion techniques for some Router Advertisement Guard (RA
Guard) implementations . . . . . . . . . . . . . . . . . . . . 4 Guard) implementations . . . . . . . . . . . . . . . . . . . . 4
2.1. Attack Vector based on IPv6 Extension Headers . . . . . . 4 2.1. Attack Vector based on IPv6 Extension Headers . . . . . . 4
2.2. Attack vector based on IPv6 fragmentation . . . . . . . . 4 2.2. Attack vector based on IPv6 fragmentation . . . . . . . . 4
3. RA-Guard implementation advice . . . . . . . . . . . . . . . . 8 3. RA-Guard implementation advice . . . . . . . . . . . . . . . . 8
4. Other Implications . . . . . . . . . . . . . . . . . . . . . . 11 4. Other Implications . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
Appendix A. Assessment tools . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix B. Advice and guidance to vendors . . . . . . . . . . . 17 Appendix A. Assessment tools . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Advice and guidance to vendors . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique
for attack vectors based on ICMPv6 Router Advertisement messages. for attack vectors based on ICMPv6 Router Advertisement messages.
[RFC6104] describes the problem statement of "Rogue IPv6 Router [RFC6104] describes the problem statement of "Rogue IPv6 Router
Advertisements", and [RFC6105] specifies the "IPv6 Router Advertisements", and [RFC6105] specifies the "IPv6 Router
Advertisement Guard" functionality. Advertisement Guard" functionality.
The concept behind RA-Guard is that a layer-2 device filters ICMPv6 The concept behind RA-Guard is that a layer-2 device filters ICMPv6
skipping to change at page 12, line 5 skipping to change at page 11, line 13
with [RFC5722]. with [RFC5722].
4. Other Implications 4. Other Implications
A similar concept to that of "RA-Guard" has been implemented for A similar concept to that of "RA-Guard" has been implemented for
protecting against forged DHCPv6 messages. Such protection can be protecting against forged DHCPv6 messages. Such protection can be
circumvented with the same techniques discussed in this document, and circumvented with the same techniques discussed in this document, and
the counter-measures for such evasion attack are analogous to those the counter-measures for such evasion attack are analogous to those
described in Section 3 of this document. described in Section 3 of this document.
5. Security Considerations [DHCPv6-Shield] specifies a mechanism to protect against rogue
DHCPv6 servers, while taking into consideration the evasion
techniques discussed in this document.
5. IANA Considerations
This document has no actions for IANA.
6. Security Considerations
This document describes a number of techniques that have been found This document describes a number of techniques that have been found
to be effective to circumvent popular RA-Guard implementations, and to be effective to circumvent popular RA-Guard implementations, and
provides advice to RA-Guard implementations such that those evasion provides advice to RA-Guard implementations such that those evasion
vulnerabilities are eliminated. vulnerabilities are eliminated.
As noted in Section 3, IPv6 implementations that allow overlapping As noted in Section 3, IPv6 implementations that allow overlapping
fragments (i.e. that do not comply with [RFC5722]) might still be fragments (i.e. that do not comply with [RFC5722]) might still be
subject of RA-based attacks. However, most current subject of RA-based attacks. However, most current
implementations seem to comply with [RFC5722]. implementations seem to comply with [RFC5722].
skipping to change at page 12, line 32 skipping to change at page 13, line 32
complete datagram. If a large number of such packets were sent by an complete datagram. If a large number of such packets were sent by an
attacker, and the victim node failed to implement proper resource attacker, and the victim node failed to implement proper resource
management for the fragment reassembly buffer, this could lead to a management for the fragment reassembly buffer, this could lead to a
Denial of Service (DoS). However, this does not really introduce a Denial of Service (DoS). However, this does not really introduce a
new attack vector, since an attacker could always perform the same new attack vector, since an attacker could always perform the same
attack by sending forged fragmented datagram in which at least one of attack by sending forged fragmented datagram in which at least one of
the fragments is missing. [CPNI-IPv6] discusses some resource the fragments is missing. [CPNI-IPv6] discusses some resource
management strategies that could be implemented for the fragment management strategies that could be implemented for the fragment
reassembly buffer. reassembly buffer.
Finally, we note that most effective and efficient mitigation for We note that most effective and efficient mitigation for these
these attacks would be to prohibit the use of IPv6 fragmentation with attacks would be to prohibit the use of IPv6 fragmentation with
Router Advertisement messages (as proposed by Router Advertisement messages (as proposed by
[I-D.gont-6man-nd-extension-headers]), such that the RA-Guard [I-D.gont-6man-nd-extension-headers]), such that the RA-Guard
functionality is easier to implement. However, since such mitigation functionality is easier to implement. However, since such mitigation
would require an update to existing implementations, it cannot be would require an update to existing implementations, it cannot be
relied upon in the short or near term. relied upon in the short or near term.
6. Acknowledgements Finally, we note that RA-Guard only mitigates attack vectors based on
ICMPv6 Router advertisement messages. Protection against similar
attacks based on other messages (such as DCHPv6) is considered out of
the scope of this document, and left for other documents(e.g.
[DHCPv6-Shield]).
7. Acknowledgements
The author would like to thank Ran Atkinson, Karl Auer, Robert The author would like to thank Ran Atkinson, Karl Auer, Robert
Downie, Washam Fan, David Farmer, Marc Heuse, Nick Hilliard, Ray Downie, Washam Fan, David Farmer, Marc Heuse, Nick Hilliard, Ray
Hunter, Simon Perreault, Arturo Servin, Gunter van de Velde, James Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter van de
Woodyatt, and Bjoern A. Zeeb, for providing valuable comments on Velde, James Woodyatt, and Bjoern A. Zeeb, for providing valuable
earlier versions of this document. comments on earlier versions of this document.
The author would like to thank Arturo Servin, who presented this The author would like to thank Arturo Servin, who presented this
document at IETF 81. document at IETF 81.
This document resulted from the project "Security Assessment of the This document resulted from the project "Security Assessment of the
Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by
Fernando Gont on behalf of the UK Centre for the Protection of Fernando Gont on behalf of the UK Centre for the Protection of
National Infrastructure (CPNI). The author would like to thank the National Infrastructure (CPNI). The author would like to thank the
UK CPNI, for their continued support. UK CPNI, for their continued support.
7. References 8. References
7.1. Normative References 8.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.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, December 2009. RFC 5722, December 2009.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers", M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, April 2012. RFC 6564, April 2012.
7.2. Informative References 8.2. Informative References
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", RFC 6104, February 2011. Problem Statement", RFC 6104, February 2011.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011. February 2011.
[I-D.gont-6man-oversized-header-chain] [I-D.gont-6man-oversized-header-chain]
Gont, F. and V. Manral, "Security and Interoperability Gont, F. and V. Manral, "Security and Interoperability
Implications of Oversized IPv6 Header Chains", Implications of Oversized IPv6 Header Chains",
draft-gont-6man-oversized-header-chain-01 (work in draft-gont-6man-oversized-header-chain-01 (work in
progress), April 2012. progress), April 2012.
[I-D.gont-6man-nd-extension-headers] [I-D.gont-6man-nd-extension-headers]
Gont, F., "Security Implications of the Use of IPv6 Gont, F., "Security Implications of the Use of IPv6
Extension Headers with IPv6 Neighbor Discovery", Extension Headers with IPv6 Neighbor Discovery",
draft-gont-6man-nd-extension-headers-02 (work in draft-gont-6man-nd-extension-headers-02 (work in
progress), January 2012. progress), January 2012.
[DHCPv6-Shield]
Gont, F., "DHCPv6-Shield: Protecting Against Rogue DHCPv6
Servers", IETF Internet Draft,
draft-gont-opsec-dhcpv6-shield, work in progress,
May 2012.
[CPNI-IPv6] [CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request). National Infrastructure, (available on request).
[NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", [NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor",
<http://ndpmon.sourceforge.net/>. <http://ndpmon.sourceforge.net/>.
[rafixd] "rafixd", <http://www.kame.net/dev/cvsweb2.cgi/kame/kame/ [rafixd] "rafixd", <http://www.kame.net/dev/cvsweb2.cgi/kame/kame/
kame/rafixd/>. kame/rafixd/>.
 End of changes. 13 change blocks. 
25 lines changed or deleted 46 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/