base.txt		issue95.txt
	skipping to change at page 2, line 11		skipping to change at page 2, line 11
	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 the original NDP		specifies security mechanisms for NDP. Unlike the original NDP
	specifications, these mechanisms do not make use of IPsec.		specifications, these mechanisms do not make use of IPsec.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Specification of Requirements . . . . . . . . . . . . 5		1.1 Specification of Requirements . . . . . . . . . . . . 5
	2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Neighbor and Router Discovery Overview . . . . . . . . . . . 8		3. Neighbor and Router Discovery Overview . . . . . . . . . . . 9
	4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 10		4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 11
	5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 12		5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 13
	5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . . 12		5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . . 13
	5.1.1 Processing Rules for Senders . . . . . . . . . . 13		5.1.1 Processing Rules for Senders . . . . . . . . . . 14
	5.1.2 Processing Rules for Receivers . . . . . . . . . 14		5.1.2 Processing Rules for Receivers . . . . . . . . . 15
	5.1.3 Configuration . . . . . . . . . . . . . . . . . 15		5.1.3 Configuration . . . . . . . . . . . . . . . . . 16
	5.2 RSA Signature Option . . . . . . . . . . . . . . . . . 15		5.2 RSA Signature Option . . . . . . . . . . . . . . . . . 16
	5.2.1 Processing Rules for Senders . . . . . . . . . . 17		5.2.1 Processing Rules for Senders . . . . . . . . . . 18
	5.2.2 Processing Rules for Receivers . . . . . . . . . 18		5.2.2 Processing Rules for Receivers . . . . . . . . . 19
	5.2.3 Configuration . . . . . . . . . . . . . . . . . 19		5.2.3 Configuration . . . . . . . . . . . . . . . . . 20
	5.2.4 Performance Considerations . . . . . . . . . . . 20		5.2.4 Performance Considerations . . . . . . . . . . . 21
	5.3 Timestamp and Nonce options . . . . . . . . . . . . . 20		5.3 Timestamp and Nonce options . . . . . . . . . . . . . 21
	5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 20		5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 21
	5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 21		5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 22
	5.3.3 Processing rules for senders . . . . . . . . . . 22		5.3.3 Processing rules for senders . . . . . . . . . . 23
	5.3.4 Processing rules for receivers . . . . . . . . . 23		5.3.4 Processing rules for receivers . . . . . . . . . 24
	6. Authorization Delegation Discovery . . . . . . . . . . . . . 26		6. Authorization Delegation Discovery . . . . . . . . . . . . . 27
	6.1 Authorization Model . . . . . . . . . . . . . . . . . 26		6.1 Authorization Model . . . . . . . . . . . . . . . . . 27
	6.2 Deployment Model . . . . . . . . . . . . . . . . . . . 27		6.2 Deployment Model . . . . . . . . . . . . . . . . . . . 28
	6.3 Certificate Format . . . . . . . . . . . . . . . . . . 28		6.3 Certificate Format . . . . . . . . . . . . . . . . . . 29
	6.3.1 Router Authorization Certificate Profile . . . . 28		6.3.1 Router Authorization Certificate Profile . . . . 29
	6.3.2 Suitability of Standard Identity Certificates . 30		6.3.2 Suitability of Standard Identity Certificates . 31
	6.4 Certificate Transport . . . . . . . . . . . . . . . . 31		6.4 Certificate Transport . . . . . . . . . . . . . . . . 32
	6.4.1 Certification Path Solicitation Message Format . 31		6.4.1 Certification Path Solicitation Message Format . 32
	6.4.2 Certification Path Advertisement Message Format 33		6.4.2 Certification Path Advertisement Message Format 34
	6.4.3 Trust Anchor Option . . . . . . . . . . . . . . 35		6.4.3 Trust Anchor Option . . . . . . . . . . . . . . 36
	6.4.4 Certificate Option . . . . . . . . . . . . . . . 37		6.4.4 Certificate Option . . . . . . . . . . . . . . . 38
	6.4.5 Processing Rules for Routers . . . . . . . . . . 38		6.4.5 Processing Rules for Routers . . . . . . . . . . 39
	6.4.6 Processing Rules for Hosts . . . . . . . . . . . 39		6.4.6 Processing Rules for Hosts . . . . . . . . . . . 40
	6.5 Configuration . . . . . . . . . . . . . . . . . . . . 40		6.5 Configuration . . . . . . . . . . . . . . . . . . . . 41
	7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 42		7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 43
	7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 42		7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 43
	7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 42		7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 43
	7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 42		7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 43
	7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 43		7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 44
	8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 45		8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 46
	9. Security Considerations . . . . . . . . . . . . . . . . . . 47		9. Security Considerations . . . . . . . . . . . . . . . . . . 48
	9.1 Threats to the Local Link Not Covered by SEND . . . . 47		9.1 Threats to the Local Link Not Covered by SEND . . . . 48
	9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 47		9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 48
	9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 48		9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 49
	9.2.2 Neighbor Unreachability Detection Failure . . . 48		9.2.2 Neighbor Unreachability Detection Failure . . . 49
	9.2.3 Duplicate Address Detection DoS Attack . . . . . 48		9.2.3 Duplicate Address Detection DoS Attack . . . . . 49
	9.2.4 Router Solicitation and Advertisement Attacks . 49		9.2.4 Router Solicitation and Advertisement Attacks . 50
	9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 49		9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 50
	9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 50		9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 51
	9.3 Attacks against SEND Itself . . . . . . . . . . . . . 50		9.3 Attacks against SEND Itself . . . . . . . . . . . . . 51
	10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . 52		10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . 53
	10.1 Constants . . . . . . . . . . . . . . . . . . . . . . 52		10.1 Constants . . . . . . . . . . . . . . . . . . . . . . 53
	10.2 Variables . . . . . . . . . . . . . . . . . . . . . . 52		10.2 Variables . . . . . . . . . . . . . . . . . . . . . . 53
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 53		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 54
	Normative References . . . . . . . . . . . . . . . . . . . . 54		Normative References . . . . . . . . . . . . . . . . . . . . 55
	Informative References . . . . . . . . . . . . . . . . . . . 56		Informative References . . . . . . . . . . . . . . . . . . . 57
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 57
	A. Contributors and Acknowledgments . . . . . . . . . . . . . . 58		A. Contributors and Acknowledgments . . . . . . . . . . . . . . 59
	B. Cache Management . . . . . . . . . . . . . . . . . . . . . . 59		B. Cache Management . . . . . . . . . . . . . . . . . . . . . . 60
	C. Message Size When Carrying Certificates . . . . . . . . . . 60		C. Message Size When Carrying Certificates . . . . . . . . . . 61
	Intellectual Property and Copyright Statements . . . . . . . 61		Intellectual Property and Copyright Statements . . . . . . . 62
	1. Introduction		1. Introduction
	IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]		IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]
	and 2462 [8]. Nodes on the same link use NDP to discover each		and 2462 [8]. Nodes on the same link use NDP to discover each
	other's presence, to determine each other's link-layer addresses, to		other's presence, to determine each other's link-layer addresses, to
	find routers, and to maintain reachability information about the		find routers, and to maintain reachability information about the
	paths to active neighbors. NDP is used both by hosts and routers.		paths to active neighbors. NDP is used both by hosts and routers.
	Its functions include Neighbor Discovery (ND), Router Discovery (RD),		Its functions include Neighbor Discovery (ND), Router Discovery (RD),
	Address Autoconfiguration, Address Resolution, Neighbor		Address Autoconfiguration, Address Resolution, Neighbor
	skipping to change at page 7, line 50		skipping to change at page 7, line 50
	Router Discovery (RD)		Router Discovery (RD)
	Router Discovery allows the hosts to discover what routers exist		Router Discovery allows the hosts to discover what routers exist
	on the link, and what prefixes are available. Router Discovery is		on the link, and what prefixes are available. Router Discovery is
	a part of the Neighbor Discovery Protocol.		a part of the Neighbor Discovery Protocol.
	Trust Anchor		Trust Anchor
	Hosts are configured with a set of trust anchors for the purposes		Hosts are configured with a set of trust anchors for the purposes
	of protecting Router Discovery. A trust anchor is an entity that		of protecting Router Discovery. A trust anchor is an entity that
	the host trusts to authorize routers to act as routers.		the host trusts to authorize routers to act as routers. A trust
			anchor configuration consists of a public key and some associated
			parameters (see Section 6.5 for a detailed explanation of these
			parameters).
	3. Neighbor and Router Discovery Overview		3. Neighbor and Router Discovery Overview
	The Neighbor Discovery Protocol has several functions. Many of these		The Neighbor Discovery Protocol has several functions. Many of these
	functions are overloaded on a few central message types, such as the		functions are overloaded on a few central message types, such as the
	ICMPv6 Neighbor Advertisement message. In this section we review		ICMPv6 Neighbor Advertisement message. In this section we review
	some of these tasks and their effects in order to understand better		some of these tasks and their effects in order to understand better
	how the messages should be treated. This section is not normative,		how the messages should be treated. This section is not normative,
	and if this section and the original Neighbor Discovery RFCs are in		and if this section and the original Neighbor Discovery RFCs are in
	conflict, the original RFCs take precedence.		conflict, the original RFCs take precedence.
	skipping to change at page 27, line 12		skipping to change at page 28, line 12
	also a number of other parameters beyond the above. For instance,		also a number of other parameters beyond the above. For instance,
	routers have their own IP addresses, prefixes have lifetimes, routers		routers have their own IP addresses, prefixes have lifetimes, routers
	control the use of stateless and stateful address autoconfiguration,		control the use of stateless and stateful address autoconfiguration,
	and so on. However, the ability to be a router and the prefixes are		and so on. However, the ability to be a router and the prefixes are
	the most fundamental parameters to authorize. This is because the		the most fundamental parameters to authorize. This is because the
	host needs to choose a router that it uses as its defaulr router, and		host needs to choose a router that it uses as its defaulr router, and
	because the advertised prefixes have an impact on the addresses the		because the advertised prefixes have an impact on the addresses the
	host uses. In addition, the prefixes also represent a claim about the		host uses. In addition, the prefixes also represent a claim about the
	topological location in the network.		topological location in the network.
	Care should be taken if the certificates used in SEND are re-used to		Care should be taken if the certificates used in SEND are also used
	provide authorization in other circumstances, for example with		to provide authorization in other circumstances, for example with
	routing protocols. It is necessary to ensure that the authorization		routing protocols. It is necessary to ensure that the authorization
	information is appropriate for all applications. SEND certificates		information is appropriate for all applications. SEND certificates
	may authorize a larger set of prefixes than the router is really		may authorize a larger set of prefixes than the router is really
	authorized to advertise on a given interface. For instance, SEND		authorized to advertise on a given interface. For instance, SEND
	allows the use of the null prefix. This prefix might cause		allows the use of the null prefix. This prefix might cause
	verification or routing problems in other applications. It is		verification or routing problems in other applications. It is
	RECOMMENDED that SEND certificates containing the null prefix are		RECOMMENDED that SEND certificates containing the null prefix are
	only used for SEND.		only used for SEND.
	Note that end hosts need not be provisioned with their own certified		Note that end hosts need not be provisioned with their own certified
	skipping to change at page 27, line 40		skipping to change at page 28, line 40
	The deployment model for trust anchors can be either a globally		The deployment model for trust anchors can be either a globally
	rooted public key infrastructure, or a more local, decentralized		rooted public key infrastructure, or a more local, decentralized
	deployment model similar to the current model used for TLS in Web		deployment model similar to the current model used for TLS in Web
	servers. The centralized model assumes a global root capable of		servers. The centralized model assumes a global root capable of
	authorizing routers and, optionally, the address space they		authorizing routers and, optionally, the address space they
	advertise. The end hosts are configured with the public keys of the		advertise. The end hosts are configured with the public keys of the
	global root. The global root could operate, for instance, under the		global root. The global root could operate, for instance, under the
	Internet Assigned Numbers Authority (IANA) or as a co-operation among		Internet Assigned Numbers Authority (IANA) or as a co-operation among
	Regional Internet Registries (RIRs). However, no such global root		Regional Internet Registries (RIRs). However, no such global root
	currently exists or is even being planned.		currently exists.
	In the decentralized model, end hosts are configured with a		In the decentralized model, end hosts are configured with a
	collection of trusted public keys that form the trust anchors. The		collection of trusted public keys that form the trust anchors. The
	public keys could be issued from a variety of places, for example: a)		public keys could be issued from a variety of places, for example: a)
	a public key for the end host's own organization, b) a public key for		a public key for the end host's own organization, b) a public key for
	the end host's home ISP and for ISPs with which the home ISP has a		the end host's home ISP and for ISPs with which the home ISP has a
	roaming agreement, or c) public keys for roaming brokers that act as		roaming agreement, or c) public keys for roaming brokers that act as
	intermediaries for ISPs that don't want to run their own		intermediaries for ISPs that don't want to run their own
	certification authority.		certification authority.
	skipping to change at page 31, line 7		skipping to change at page 32, line 7
	is authorized to route the prefixes R1,...,Rs.		is authorized to route the prefixes R1,...,Rs.
	6.3.2 Suitability of Standard Identity Certificates		6.3.2 Suitability of Standard Identity Certificates
	Since deployment of the IP address extension is, itself, not common,		Since deployment of the IP address extension is, itself, not common,
	a network service provider MAY choose to deploy standard identity		a network service provider MAY choose to deploy standard identity
	certificates on the router to supply the router's public key for		certificates on the router to supply the router's public key for
	signed Router Advertisements.		signed Router Advertisements.
	If there is no prefix information further up in the certification		If there is no prefix information further up in the certification
	chain, a host interprets a standard identity certificate as allowing		path, a host interprets a standard identity certificate as allowing
	unconstrained prefix advertisements.		unconstrained prefix advertisements.
	If the other certificates do contain prefix information, a standard		If the other certificates do contain prefix information, a standard
	identity certificate is interpreted as allowing those prefixes.		identity certificate is interpreted as allowing those prefixes.
	6.4 Certificate Transport		6.4 Certificate Transport
	The Certification Path Solicitation (CPS) message is sent by a host		The Certification Path Solicitation (CPS) message is sent by a host
	when it wishes to request a certification path between a router and		when it wishes to request a certification path between a router and
	one of the host's trust anchors. The Certification Path		one of the host's trust anchors. The Certification Path
	skipping to change at page 60, line 7		skipping to change at page 61, line 7
	node may be more intelligent in keeping its cache entries, and not		node may be more intelligent in keeping its cache entries, and not
	just have a black/white old/new boundary.		just have a black/white old/new boundary.
	It also looks like a good idea to consider the Sec parameter when		It also looks like a good idea to consider the Sec parameter when
	forcing cache entries out, and let those entries with a larger Sec a		forcing cache entries out, and let those entries with a larger Sec a
	higher chance of staying in.		higher chance of staying in.
	Appendix C. Message Size When Carrying Certificates		Appendix C. Message Size When Carrying Certificates
	In one example scenario using SEND, an Authorization Delegation		In one example scenario using SEND, an Authorization Delegation
	Discovery test run was made using a certification chain length four.		Discovery test run was made using a certification path length four.
	This results in having to send three certificates using the		This results in having to send three certificates using the
	Certification Chain Advertisement messages as the trust anchor's		Certification Path Advertisement messages as the trust anchor's
	certificate is already known by both parties. Using a key length of		certificate is already known by both parties. Using a key length of
	XXX bits, the implementation used in the test run used certificates		XXX bits, the implementation used in the test run used certificates
	ranging from 864 to 888 bytes long; the variation is due to the		ranging from 864 to 888 bytes long; the variation is due to the
	differences in the certificate issuer names and prefix extensions in		differences in the certificate issuer names and prefix extensions in
	the certificates. The different certificates had one to four prefix		the certificates. The different certificates had one to four prefix
	extensions.		extensions.
	The three Certification Chain Advertisement messages ranged from 1050		The three Certification Path Advertisement messages ranged from 1050
	to 1066 bytes on an Ethernet link layer. The certificate itself		to 1066 bytes on an Ethernet link layer. The certificate itself
	accounts for the bulk of the packet. The rest is the trust anchor		accounts for the bulk of the packet. The rest is the trust anchor
	option, ICMP header, IPv6 header, and link layer header.		option, ICMP header, IPv6 header, and link layer header.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/