base.txt		issue47.txt
Secure Neighbor Discovery Working J. Arkko		Secure Neighbor Discovery Working J. Arkko
Group Ericsson		Group Ericsson
Internet-Draft J. Kempf		Internet-Draft J. Kempf
Expires: May 31, 2004 DoCoMo Communications Labs USA		Expires: July 15, 2004 DoCoMo Communications Labs USA
B. Sommerfeld		B. Sommerfeld
Sun Microsystems		Sun Microsystems
B. Zill		B. Zill
Microsoft		Microsoft
P. Nikander		P. Nikander
Ericsson		Ericsson
December 2003		January 15, 2004
SEcure Neighbor Discovery (SEND)		SEcure Neighbor Discovery (SEND)
draft-ietf-send-ndopt-01		draft-ietf-send-ndopt-02
Status of this Memo		Status of this Memo
This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as		other groups may also distribute working documents as
Internet-Drafts.		Internet-Drafts.
Skipping to change at page 1, line 39:
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."
The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 31, 2004.		This Internet-Draft will expire on July 15, 2004.
Copyright Notice		Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract		Abstract
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover		IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
other nodes on the link, to determine each the link-layer addresses		other nodes on the link, to determine each the link-layer addresses
of the nodes on the link, to find routers, and to maintain		of the nodes on the link, to find routers, and to maintain
reachability information about the paths to active neighbors. If not		reachability information about the paths to active neighbors. If not
secured, NDP is vulnerable to various attacks. This document		secured, NDP is vulnerable to various attacks. This document
specifies security mechanisms for NDP. Unlike to the original NDP		specifies security mechanisms for NDP. Unlike to the original NDP
specifications, these mechanisms do not make use of IPsec.		specifications, these mechanisms do not make use of IPsec.
Skipping to change at page 25, line 10:
ISP) that configured the original IP address space block for the		ISP) that configured the original IP address space block for the
router in question, or delegated the right to do so for someone. The		router in question, or delegated the right to do so for someone. The
certificates for intermediate delegating authorities MUST contain		certificates for intermediate delegating authorities MUST contain
X.509 IP address extension(s) for subdelegations. The router's		X.509 IP address extension(s) for subdelegations. The router's
certificate is signed by the delegating authority for the prefixes		certificate is signed by the delegating authority for the prefixes
the router is authorized to to advertise.		the router is authorized to to advertise.
The X.509 IP address extension MUST contain at least one		The X.509 IP address extension MUST contain at least one
addressesOrRanges element. This element MUST contain an		addressesOrRanges element. This element MUST contain an
addressPrefix element with an IPv6 address prefix for a prefix the		addressPrefix element with an IPv6 address prefix for a prefix the
router or the intermediate entity is authorized to advertise. If the		router or the intermediate entity is authorized to route. If the
entity is allowed to route any prefix, the used IPv6 address prefix		entity is allowed to route any prefix, the used IPv6 address prefix
is the null prefix, 0/0. The addressFamily element of the containing		is the null prefix, 0/0. The addressFamily element of the containing
IPAddrBlocks sequence element MUST contain the IPv6 Address Family		IPAddrBlocks sequence element MUST contain the IPv6 Address Family
Identifier (0002), as specified in [11] for IPv6 prefixes. Instead		Identifier (0002), as specified in [11] for IPv6 prefixes. Instead
of an addressPrefix element, the addressesOrRange element MAY contain		of an addressPrefix element, the addressesOrRange element MAY contain
an addressRange element for a range of prefixes, if more than one		an addressRange element for a range of prefixes, if more than one
prefix is authorized. The X.509 IP address extension MAY contain		prefix is authorized. The X.509 IP address extension MAY contain
additional IPv6 prefixes, expressed either as an addressPrefix or an		additional IPv6 prefixes, expressed either as an addressPrefix or an
addressRange.		addressRange.
Skipping to change at page 37, line 7:
an attacker, and the host MUST use a different advertising router as		an attacker, and the host MUST use a different advertising router as
its default router (if available). If the node is performing		its default router (if available). If the node is performing
stateful autoconfiguration, it SHOULD check the address provided by		stateful autoconfiguration, it SHOULD check the address provided by
the DHCP server against the certified prefixes and MUST NOT use the		the DHCP server against the certified prefixes and MUST NOT use the
address if the prefix is not certified.		address if the prefix is not certified.
In any case, the user should inform the network operator upon		In any case, the user should inform the network operator upon
receiving an address or prefix outside the certified range, since		receiving an address or prefix outside the certified range, since
this is either a misconfiguration or an attack.		this is either a misconfiguration or an attack.
If the network operator wants to constrain which routers support		If the network operator wants to constrain which routers are allowed
particular prefixes, routers SHOULD be configured with certificates		to route particular prefixes, routers SHOULD be configured with
having prefixes listed in the prefix extension. Routers so		certificates having prefixes listed in the prefix extension. Routers
configured MUST advertise exactly the prefixes for which they are		so configured MUST advertise the prefixes which they are certified to
certified.		route, or a subset thereof.
Network operators that do not want to constrain particular routers to		Network operators that do not want to constrain routers this way
specific prefixes SHOULD configure routers with certificates		SHOULD configure routers with certificates containing either the null
containing either the null prefix or no prefix extension at all.		prefix or no prefix extension at all.
7.4 Limitations		7.4 Limitations
This specification does not address the protection of NDP packets for		This specification does not address the protection of NDP packets for
nodes that are configured with a static address (e.g., PREFIX::1).		nodes that are configured with a static address (e.g., PREFIX::1).
Future certificate chain based authorization specifications are		Future certificate chain based authorization specifications are
needed for such nodes.		needed for such nodes.
It is outside the scope of this specification to describe the use of		It is outside the scope of this specification to describe the use of
trust anchor authorization between nodes with dynamically changing		trust anchor authorization between nodes with dynamically changing
Skipping to change at page 51, line 8:
EMail: Pekka.Nikander@nomadiclab.com		EMail: Pekka.Nikander@nomadiclab.com
Appendix A. Contributors		Appendix A. Contributors
Tuomas Aura contributed the transition mechanism specification in		Tuomas Aura contributed the transition mechanism specification in
Section 8.		Section 8.
Appendix B. Acknowledgments		Appendix B. Acknowledgments
The authors would like to thank Tuomas Aura, Erik Nordmark, Gabriel		The authors would like to thank Tuomas Aura, Erik Nordmark, Gabriel
Montenegro, Pasi Eronen, and Francis Dupont for interesting		Montenegro, Pasi Eronen, Greg Daley, and Francis Dupont for
discussions in this problem space.		interesting discussions in this problem space.
Appendix C. Cache Management		Appendix C. Cache Management
In this section we outline a cache management algorithm that allows a		In this section we outline a cache management algorithm that allows a
node to remain partially functional even under a cache filling DoS		node to remain partially functional even under a cache filling DoS
attack. This appendix is informational, and real implementations		attack. This appendix is informational, and real implementations
SHOULD use different algorithms in order to avoid he dangers of		SHOULD use different algorithms in order to avoid he dangers of
mono-cultural code.		mono-cultural code.
There are at least two distinct cache related attack scenarios:		There are at least two distinct cache related attack scenarios:
Skipping to change at page 53, line 34:
this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
Director.		Director.
The IETF has been notified of intellectual property rights claimed in		The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this		regard to some or all of the specification contained in this
document. For more information consult the online list of claimed		document. For more information consult the online list of claimed
rights.		rights.
Full Copyright Statement		Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes.
This html diff was produced by rfcdiff v0.42, available from http://www.levkowetz.com/ietf/tools/rfcdiff/