draft-ietf-v6ops-ra-guard-implementation-05.txt   draft-ietf-v6ops-ra-guard-implementation-06.txt 
IPv6 Operations Working Group (v6ops) F. Gont IPv6 Operations Working Group (v6ops) F. Gont
Internet-Draft UK CPNI Internet-Draft UK CPNI
Updates: 6105 (if approved) October 26, 2012 Updates: 6105 (if approved) November 14, 2012
Intended status: BCP Intended status: Informational
Expires: April 29, 2013 Expires: May 18, 2013
Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
draft-ietf-v6ops-ra-guard-implementation-05 draft-ietf-v6ops-ra-guard-implementation-06
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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 29, 2013. This Internet-Draft will expire on May 18, 2013.
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 26 skipping to change at page 2, line 26
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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Assessment tools . . . . . . . . . . . . . . . . . . 17 Appendix A. Assessment tools . . . . . . . . . . . . . . . . . . 17
Appendix B. Advice and guidance to vendors . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 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 8, line 7 skipping to change at page 8, line 7
The second fragment presents the same challenges as the second The second fragment presents the same challenges as the second
fragment of the previous variant. That is, it would be impossible fragment of the previous variant. That is, it would be impossible
for a device processing only the second fragment to locate the second for a device processing only the second fragment to locate the second
Destination Options header (and hence the ICMPv6 header), since the Destination Options header (and hence the ICMPv6 header), since the
"Hdr Ext Len" field of the first Destination Options header is "Hdr Ext Len" field of the first Destination Options header is
present in the first fragment (rather than the second). present in the first fragment (rather than the second).
3. RA-Guard implementation advice 3. RA-Guard implementation advice
The following filtering rules MUST be implemented as part of an "RA- The following filtering rules must be implemented as part of an "RA-
Guard" implementation on those ports that are not allowed to send Guard" implementation on those ports that are not allowed to send
ICMPv6 Router Advertisement messages, such that the vulnerabilities ICMPv6 Router Advertisement messages, such that the vulnerabilities
discussed in this document are eliminated: discussed in this document are eliminated:
1. If the IPv6 Source Address of the packet is not a link-local 1. If the IPv6 Source Address of the packet is not a link-local
address (fe80::/10), RA-Guard MUST pass the packet. address (fe80::/10), RA-Guard must pass the packet.
RATIONALE: Section 6.1.2 of [RFC4861] requires nodes to RATIONALE: Section 6.1.2 of [RFC4861] requires nodes to
discard Router Advertisement messages if their IPv6 Source discard Router Advertisement messages if their IPv6 Source
Address is not a link-local address. Address is not a link-local address.
2. If the Hop Limit is not 255, RA-Guard MUST pass the packet. 2. If the Hop Limit is not 255, RA-Guard must pass the packet.
RATIONALE: Section 6.1.2 of [RFC4861] requires nodes to RATIONALE: Section 6.1.2 of [RFC4861] requires nodes to
discard Router Advertisement messages if their Hop Limit is discard Router Advertisement messages if their Hop Limit is
not 255. not 255.
3. RA-Guard MUST parse the IPv6 entire header chain present in the 3. RA-Guard must parse the IPv6 entire header chain present in the
packet, to identify whether the packet is a Router Advertisement packet, to identify whether the packet is a Router Advertisement
message. message.
RATIONALE: [RFC6564] specifies a uniform format for IPv6 RATIONALE: [RFC6564] specifies a uniform format for IPv6
Extension Header, thus meaning that an IPv6 node can parse an Extension Header, thus meaning that an IPv6 node can parse an
IPv6 header chain even if it contains Extension Headers that IPv6 header chain even if it contains Extension Headers that
are not currently supported by that node. Additionally, are not currently supported by that node. Additionally,
[I-D.ietf-6man-oversized-header-chain] requires that if a [I-D.ietf-6man-oversized-header-chain] requires that if a
packet is fragmented, the first fragment contains the entire packet is fragmented, the first fragment contains the entire
IPv6 header chain. IPv6 header chain.
RA-Guard implementations MUST NOT enforce a limit on the RA-Guard implementations must not enforce a limit on the
number of bytes they can inspect (starting from the beginning number of bytes they can inspect (starting from the beginning
of the IPv6 packet), since this could introduce false- of the IPv6 packet), since this could introduce false-
positives: legitimate packets could be dropped simply because positives: legitimate packets could be dropped simply because
the RA-Guard device does not parse the entire IPv6 header the RA-Guard device does not parse the entire IPv6 header
chain present in the packet. An implementation that has such chain present in the packet. An implementation that has such
an implementation-specific limit MUST NOT claim compliance an implementation-specific limit must not claim compliance
with this specification, and MUST pass the packet when such with this specification, and must pass the packet when such
implementation-specific limit is reached. implementation-specific limit is reached.
4. When parsing the IPv6 header chain, if the packet is a first- 4. When parsing the IPv6 header chain, if the packet is a first-
fragment (i.e., a packet containing a Fragment Header with the fragment (i.e., a packet containing a Fragment Header with the
Fragment Offset set to 0) and it fails to contain the entire IPv6 Fragment Offset set to 0) and it fails to contain the entire IPv6
header chain (i.e., all the headers starting from the IPv6 header header chain (i.e., all the headers starting from the IPv6 header
up to, and including, the upper-layer header), RA-Guard MUST drop up to, and including, the upper-layer header), RA-Guard must drop
the packet, and SHOULD log the packet drop event in an the packet, and should log the packet drop event in an
implementation-specific manner as a security fault. implementation-specific manner as a security fault.
RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies
that the first-fragment (i.e., the fragment with the Fragment that the first-fragment (i.e., the fragment with the Fragment
Offset set to 0) MUST contain the entire IPv6 header chain, Offset set to 0) MUST contain the entire IPv6 header chain,
and allows intermmediate systems such as routers to drop those and allows intermmediate systems such as routers to drop those
packets that fail to comply with this requirement. packets that fail to comply with this requirement.
NOTE: This rule should only be applied to IPv6 fragments with NOTE: This rule should only be applied to IPv6 fragments with
a Fragment Offset of 0 (non-first fragments can be safely a Fragment Offset of 0 (non-first fragments can be safely
passed, since they will never reassemble into a complete passed, since they will never reassemble into a complete
datagram if they are part of a Router Advertisement received datagram if they are part of a Router Advertisement received
on a port where such packets are not allowed). on a port where such packets are not allowed).
5. When parsing the IPv6 header chain, if the packet is identified 5. When parsing the IPv6 header chain, if the packet is identified
to be an ICMPv6 Router Advertisement message, RA-Guard MUST drop to be an ICMPv6 Router Advertisement message, RA-Guard must drop
the packet, and SHOULD log the packet drop event in an the packet, and should log the packet drop event in an
implementation-specific manner as a security fault. implementation-specific manner as a security fault.
RATIONALE: By definition, Router Advertisement messages MUST RATIONALE: By definition, Router Advertisement messages MUST
originate on-link, MUST have a link-local IPv6 Source Address, originate on-link, MUST have a link-local IPv6 Source Address,
and MUST have a Hop Limit value of 255. [RFC4861]. and MUST have a Hop Limit value of 255. [RFC4861].
6. In all other cases, RA-Guard MUST pass the packet as usual. 6. In all other cases, RA-Guard must pass the packet as usual.
NOTE: For the purpose of enforcing the RA-Guard filtering policy, NOTE: For the purpose of enforcing the RA-Guard filtering policy,
an ESP header [RFC4303] should be considered to be an "upper-layer an ESP header [RFC4303] should be considered to be an "upper-layer
protocol" (that is, it should be considered the last header in the protocol" (that is, it should be considered the last header in the
IPv6 header chain). This means that packets employing ESP would IPv6 header chain). This means that packets employing ESP would
be passed by the RA-Guard device to the intended destination. If be passed by the RA-Guard device to the intended destination. If
the destination host does not have a security association with the the destination host does not have a security association with the
sender of the aforementioned IPv6 packet, the packet would be sender of the aforementioned IPv6 packet, the packet would be
dropped. Otherwise, if the packet is considered valid by the dropped. Otherwise, if the packet is considered valid by the
IPsec implementation at the receiving host and encapsulates a IPsec implementation at the receiving host and encapsulates a
Router Advertisement message, it is up to the receiving host what Router Advertisement message, it is up to the receiving host what
to do with such packet. to do with such packet.
If a packet is dropped due to this filtering policy, then the packet If a packet is dropped due to this filtering policy, then the packet
drop event SHOULD be logged in an implementation-specific manner as a drop event should be logged in an implementation-specific manner as a
security fault. The logging mechanism SHOULD include a drop counter security fault. The logging mechanism should include a drop counter
dedicated to RA-Guard packet drops. dedicated to RA-Guard packet drops.
In order to protect current end-node IPv6 implementations, Rule #4 In order to protect current end-node IPv6 implementations, Rule #4
has been defined as a default rule to drop packets that cannot be has been defined as a default rule to drop packets that cannot be
positively identified as not being Router Advertisement (RA) messages positively identified as not being Router Advertisement (RA) messages
(because the packet is a fragment that fails to include the entire (because the packet is a fragment that fails to include the entire
IPv6 header chain). This means that, at least in theory, RA-Guard IPv6 header chain). This means that, at least in theory, RA-Guard
could result in false-positive blocking of some legitimate non-RA could result in false-positive blocking of some legitimate non-RA
packets that could not be positively identified as being non-RA. In packets that could not be positively identified as being non-RA. In
order to reduce the likelihood of false positives, Rule #1 and Rule order to reduce the likelihood of false positives, Rule #1 and Rule
skipping to change at page 15, line 22 skipping to change at page 15, line 22
[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.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011.
[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.
[I-D.ietf-6man-oversized-header-chain] [I-D.ietf-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-ietf-6man-oversized-header-chain-01 (work in draft-ietf-6man-oversized-header-chain-02 (work in
progress), July 2012. progress), November 2012.
[I-D.ietf-6man-nd-extension-headers] [I-D.ietf-6man-nd-extension-headers]
Gont, F., "Security Implications of the Use of IPv6 Gont, F., "Security Implications of IPv6 Fragmentation
Extension Headers with IPv6 Neighbor Discovery", with IPv6 Neighbor Discovery",
draft-ietf-6man-nd-extension-headers-00 (work in draft-ietf-6man-nd-extension-headers-01 (work in
progress), June 2012. progress), November 2012.
8.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.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011.
[DHCPv6-Shield] [DHCPv6-Shield]
Gont, F., "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Gont, F., "DHCPv6-Shield: Protecting Against Rogue DHCPv6
Servers", IETF Internet Draft, Servers", IETF Internet Draft,
draft-gont-opsec-dhcpv6-shield, work in progress, draft-gont-opsec-dhcpv6-shield, work in progress,
May 2012. 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).
skipping to change at page 18, line 5 skipping to change at page 18, line 5
<http://www.thc.org/thc-ipv6/>. <http://www.thc.org/thc-ipv6/>.
Appendix A. Assessment tools Appendix A. Assessment tools
[SI6-IPv6] is a publicly-available set of tools (for Linux, *BSD, and [SI6-IPv6] is a publicly-available set of tools (for Linux, *BSD, and
Mac OS) that implements the techniques described in this document. Mac OS) that implements the techniques described in this document.
[THC-IPV6] is a publicly-available set of tools (for Linux) that [THC-IPV6] is a publicly-available set of tools (for Linux) that
implements some of the techniques described in this document. implements some of the techniques described in this document.
Appendix B. Advice and guidance to vendors
Vendors are urged to contact CSIRTUK (csirt@cpni.gsi.gov.uk) if they
think they may be affected by the issues described in this document.
As the lead coordination centre for these issues, CPNI is well placed
to give advice and guidance as required.
CPNI works extensively with government departments and agencies,
commercial organisations and the academic community to research
vulnerabilities and potential threats to IT systems especially where
they may have an impact on Critical National Infrastructure's (CNI).
Other ways to contact CPNI, plus CPNI's PGP public key, are available
at http://www.cpni.gov.uk.
Author's Address Author's Address
Fernando Gont Fernando Gont
Centre for the Protection of National Infrastructure Centre for the Protection of National Infrastructure
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.cpni.gov.uk URI: http://www.cpni.gov.uk
 End of changes. 19 change blocks. 
46 lines changed or deleted 30 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/