draft-ietf-v6ops-ra-guard-05.txt   draft-ietf-v6ops-ra-guard-06.txt 
v6ops Working Group E. Levy-Abegnoli v6ops Working Group E. Levy-Abegnoli
Internet-Draft G. Van de Velde Internet-Draft G. Van de Velde
Intended status: Informational C. Popoviciu Intended status: Informational C. Popoviciu
Expires: December 2, 2010 Cisco Systems Expires: December 19, 2010 Cisco Systems
J. Mohacsi J. Mohacsi
NIIF/Hungarnet NIIF/Hungarnet
May 31, 2010 June 17, 2010
IPv6 RA-Guard IPv6 RA-Guard
<draft-ietf-v6ops-ra-guard-05.txt> <draft-ietf-v6ops-ra-guard-06.txt>
Abstract Abstract
It is particularly easy to experience "rogue" routers on an unsecured It is particularly easy to experience "rogue" routers on an unsecured
link [reference4]. Devices acting as a rougue router may send link [reference4]. Devices acting as a rogue router may send
illegitimate RAs. Section 6 of SeND [RFC3971] provides a full illegitimate RAs. Section 6 of SeND [RFC3971] provides a full
solution to this problem, by enabling routers certification. This solution to this problem, by enabling routers certification. This
solution does, however, require all nodes on an L2 network segment to solution does, however, require all nodes on an L2 network segment to
support SeND, as well as it carries some deployment challenges. End- support SeND, as well as it carries some deployment challenges. End-
nodes must be provisioned with certificate anchors. The solution nodes must be provisioned with certificate anchors. The solution
works better when end-nodes have access to a Certificate Revocation works better when end-nodes have access to a Certificate Revocation
List server, and to a Network Time Protocol server, both typically List server, and to a Network Time Protocol server, both typically
off-link, which brings some bootstrap issues. off-link, which brings some bootstrap issues.
When using IPv6 within a single L2 network segment it is possible and When using IPv6 within a single L2 network segment it is possible and
sometimes desirable to enable layer 2 devices to drop rogue RAs sometimes desirable to enable layer 2 devices to drop rogue RAs
before they reach end-nodes. In order to distinguish valid from before they reach end-nodes. In order to distinguish valid from
rogue RAs, the L2 devices can use a spectrum of criterias, from a rogue RAs, the L2 devices can use a spectrum of criteria, from a
static scheme that blocks RAs received on un-trusted ports, or from static scheme that blocks RAs received on un-trusted ports, or from
un-trusted sources, to a more dynamic scheme that uses SeND to un-trusted sources, to a more dynamic scheme that uses SeND to
challenge RA sources. challenge RA sources.
This document reviews various techniques applicable on the L2 devices This document reviews various techniques applicable on the L2 devices
to reduce the threat of rogue RAs. to reduce the threat of rogue RAs.
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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 December 2, 2010. This Internet-Draft will expire on December 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 5, line 35 skipping to change at page 5, line 35
supported by all devices involved. It may take time until SeND is supported by all devices involved. It may take time until SeND is
ubiquitous in IPv6 networks and some of its large scale deployment ubiquitous in IPv6 networks and some of its large scale deployment
aspects are sorted out such as provisioning hosts with trust anchors. aspects are sorted out such as provisioning hosts with trust anchors.
It is also reasonable to expect that some devices might not consider It is also reasonable to expect that some devices might not consider
implementing SeND at all such as IPv6 enabled sensors. An RA-Guard implementing SeND at all such as IPv6 enabled sensors. An RA-Guard
implementation which SeND-validates RAs on behalf of hosts would implementation which SeND-validates RAs on behalf of hosts would
potentially simplify some of these challenges. potentially simplify some of these challenges.
RA-Guard can be seen as a superset of SEND with regard to router RA-Guard can be seen as a superset of SEND with regard to router
authorization. Its purpose is to filter Router Advertisements based authorization. Its purpose is to filter Router Advertisements based
on a set of criterias, from a simplistic "RA disallowed on a given on a set of criteria, from a simplistic "RA disallowed on a given
interface" to "RA allowed from pre-defined sources" and up to full interface" to "RA allowed from pre-defined sources" and up to full
fladge SeND "RA allowed from authorized sources only". fledge SeND "RA allowed from authorized sources only".
In addition to this granularity on the criteria for filtering out In addition to this granularity on the criteria for filtering out
Router Advertisements, RA-Guard introduces the concept of router Router Advertisements, RA-Guard introduces the concept of router
authorization proxy. Instead of each node on the link analyzing RAs authorization proxy. Instead of each node on the link analyzing RAs
and making an individual decision, a legitimate node-in-the-middle and making an individual decision, a legitimate node-in-the-middle
performs the analysis on behalf of all other nodes on the link. The performs the analysis on behalf of all other nodes on the link. The
analysis itself is not different from what each node would do: if analysis itself is not different from what each node would do: if
SeND is enabled, the RA is checked against X.509 certificates. If SeND is enabled, the RA is checked against X.509 certificates. If
any other criteria is in use, such as known L3 (addresses) or L2 any other criteria is in use, such as known L3 (addresses) or L2
(link-layer address, port number) legitimate sources of RAs, the (link-layer address, port number) legitimate sources of RAs, the
skipping to change at page 8, line 36 skipping to change at page 8, line 36
RA-Guard mechanisms do not offer protection in environments where RA-Guard mechanisms do not offer protection in environments where
IPv6 traffic is tunneled. IPv6 traffic is tunneled.
6. IANA Considerations 6. IANA Considerations
There are no extra IANA consideration for this document. There are no extra IANA consideration for this document.
7. Security Considerations 7. Security Considerations
Once RA-Guard has setup the proper criterias, for example, it Once RA-Guard has setup the proper criteria, for example, it
identified that a port is allowed to receive RAs, or it identified identified that a port is allowed to receive RAs, or it identified
legitimiate sources of RA, or certificate base, then there is no legitimate sources of RA, or certificate base, then there is no
possible instances of accidently filtered legitimate RA's assuming possible instances of accidentlly filtered legitimate RA's assuming
the RA-Guard filter enforcement follows strictly the RA-Guard the RA-Guard filter enforcement follows strictly the RA-Guard
criteria's. criteria's.
8. Acknowledgements 8. Acknowledgements
The authors dedicate this document to the memory of Jun-ichiro Hagino The authors dedicate this document to the memory of Jun-ichiro Hagino
(itojun) for his contributions to the development and deployment of (itojun) for his contributions to the development and deployment of
IPv6. IPv6.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
9.2. Informative References 9.2. Informative References
[reference1] [reference1]
LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol
Monitor (http://ndpmon.sourceforge.net/)", November 2007. Monitor (http://ndpmon.sourceforge.net/)", November 2007.
[reference2] [reference2]
KAME Project, "rafixd - developed at KAME - An active KAME Project, "rafixd - developed at KAME - An active
rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/ rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/
kame/kame/kame/rafixd/)", November 2007. kame/kame/kame/rafixd/)", November 2007.
 End of changes. 11 change blocks. 
15 lines changed or deleted 11 lines changed or added

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