draft-ietf-mipshop-cga-cba-00.txt		draft-ietf-mipshop-cga-cba-01.txt
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft Ericsson Research NomadicLab		Internet-Draft Ericsson Research NomadicLab
	Expires: February 14, 2007 C. Vogt		Expires: March 29, 2007 C. Vogt
	Universitaet Karlsruhe (TH)		Universitaet Karlsruhe (TH)
	W. Haddad		W. Haddad
	Ericsson Research		Ericsson Research
	August 13, 2006		September 25, 2006
	Applying Cryptographically Generated Addresses and Credit-Based		Applying Cryptographically Generated Addresses and Credit-Based
	Authorization to Mobile IPv6		Authorization to Mobile IPv6
	draft-ietf-mipshop-cga-cba-00.txt		draft-ietf-mipshop-cga-cba-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://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 February 14, 2007.		This Internet-Draft will expire on March 29, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document proposes an enhanced security mechanism for Mobile IPv6		This document proposes an enhanced security mechanism for Mobile IPv6
	route optimization, providing lower handoff delays, increased		route optimization, providing lower handoff delays, increased
	security, and reduced signaling overhead.		security, and reduced signaling overhead.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1 Handoff Latency . . . . . . . . . . . . . . . . . . . . . 4		2.1 Handoff Latency . . . . . . . . . . . . . . . . . . . . . 5
	2.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3 Signaling Overhead . . . . . . . . . . . . . . . . . . . . 6		2.3 Signaling Overhead . . . . . . . . . . . . . . . . . . . . 6
	3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 6		3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 7
	4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 9		4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 9
	4.1 Sending Binding Update messages . . . . . . . . . . . . . 9		4.1 Sending Binding Update Messages . . . . . . . . . . . . . 9
	4.2 Receiving Binding Update messages . . . . . . . . . . . . 12		4.2 Receiving Binding Update Messages . . . . . . . . . . . . 13
	4.3 Sending Binding Acknowledgment messages . . . . . . . . . 14		4.3 Sending Binding Acknowledgment messages . . . . . . . . . 15
	4.4 Receiving Binding Acknowledgment messages . . . . . . . . 15		4.4 Receiving Binding Acknowledgment Messages . . . . . . . . 16
	4.5 Sending CGA Parameters . . . . . . . . . . . . . . . . . . 15		4.5 Sending CGA Parameters . . . . . . . . . . . . . . . . . . 16
	4.6 Receiving CGA Parameters . . . . . . . . . . . . . . . . . 15		4.6 Receiving CGA Parameters . . . . . . . . . . . . . . . . . 18
	4.7 Renewing a Permanent Home Keygen Token . . . . . . . . . . 15		4.7 Sending Permanent Home Keygen Tokens . . . . . . . . . . . 19
	4.8 Handling Payload Packets . . . . . . . . . . . . . . . . . 16		4.8 Receiving Permanent Home Keygen Tokens . . . . . . . . . . 19
	4.9 Credit Aging . . . . . . . . . . . . . . . . . . . . . . . 17		4.9 Handling Payload Packets . . . . . . . . . . . . . . . . . 20
	4.10 Cryptographic Calculations . . . . . . . . . . . . . . . 18		4.10 Credit Aging . . . . . . . . . . . . . . . . . . . . . . 22
	4.11 Simultaneous Movements . . . . . . . . . . . . . . . . . 18		4.11 Simultaneous Movements . . . . . . . . . . . . . . . . . 22
	5. Option Formats and Status Codes . . . . . . . . . . . . . . 19		5. Option Formats and Status Codes . . . . . . . . . . . . . . 22
	5.1 CGA Parameters Option . . . . . . . . . . . . . . . . . . 19		5.1 CGA Parameters Option . . . . . . . . . . . . . . . . . . 23
	5.2 Permanent Home Keygen Token Option . . . . . . . . . . . . 20		5.2 Signature Option . . . . . . . . . . . . . . . . . . . . . 24
	5.3 Signature Option . . . . . . . . . . . . . . . . . . . . . 20		5.3 Permanent Home Keygen Token Option . . . . . . . . . . . . 24
	5.4 Care-of Test Init Option . . . . . . . . . . . . . . . . . 21		5.4 Care-of Test Init Option . . . . . . . . . . . . . . . . . 25
	5.5 Care-of Test Option . . . . . . . . . . . . . . . . . . . 22		5.5 Care-of Test Option . . . . . . . . . . . . . . . . . . . 26
	5.6 Status Codes . . . . . . . . . . . . . . . . . . . . . . . 22		5.6 Status Codes . . . . . . . . . . . . . . . . . . . . . . . 26
	6. Security Considerations . . . . . . . . . . . . . . . . . . 23		6. Security Considerations . . . . . . . . . . . . . . . . . . 27
	7. Performance Considerations . . . . . . . . . . . . . . . . . 24		6.1 Home Address Ownership . . . . . . . . . . . . . . . . . . 28
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25		6.2 Care-of Address Ownership . . . . . . . . . . . . . . . . 29
	9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 25		6.3 Time Shifting Attacks . . . . . . . . . . . . . . . . . . 31
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		6.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 32
	10.1 Normative References . . . . . . . . . . . . . . . . . . 26		6.5 Resource Exhaustion . . . . . . . . . . . . . . . . . . . 33
	10.2 Informative References . . . . . . . . . . . . . . . . . 26		6.6 IP Address Ownership of Correspondent Node . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28		7. Performance Considerations . . . . . . . . . . . . . . . . . 34
	A. Overview of CGA . . . . . . . . . . . . . . . . . . . . . . 28		8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 34
	B. Overview of Credit-Based Authorization . . . . . . . . . . . 30		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
	Intellectual Property and Copyright Statements . . . . . . . 32		10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 35
			11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
			11.1 Normative References . . . . . . . . . . . . . . . . . . 36
			11.2 Informative References . . . . . . . . . . . . . . . . . 36
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
			A. Overview of CGA . . . . . . . . . . . . . . . . . . . . . . 38
			B. Overview of Credit-Based Authorization . . . . . . . . . . . 40
			C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 41
			Intellectual Property and Copyright Statements . . . . . . . 44
	1. Introduction		1. Introduction
	Mobile IPv6 [1] includes a mode for route optimization that allows		Mobile IPv6 route optimization [1] allows mobile nodes to communicate
	nodes to communicate with reduced latency via a direct routing path.		with correspondent nodes via a direct path in spite of changes in IP
	Route optimization is protected through a "return routability		connectivity. Route optimization reduces the latency of packet
	procedure", which serves essentially two purposes:		propagation to a minimum, in opposition to the default approach of
			routing all packets via a stationary home agent. It was designed in
			an effort to accommodate real-time and interactive applications in
			the presence of IP mobility.
	o A correspondent node can (weakly) authenticate a mobile node based		Mobile and correspondent nodes use a stable "home address" in
	on a verification of the mobile node's reachability at its home		identifying the mobile node at stack layers above IP, while packets
	address.		are sent or received via a "care-of address" that routes to the
			mobile node's current network attachment. The Mobile IPv6 protocol
			swaps the IP addresses when a packet traverses the IP layer. Both
			end nodes maintain a binding between the home address and the care-of
			address. It is the mobile node's responsibility to update the
			binding at the correspondent node when it changes IP connectivity.
	o A correspondent node can verify that the mobile node is reachable		From a security perspective, the request for a binding update
	at the claimed care-of address.		requires a correspondent node to verify a mobile node's ownership of
			both the home and the care-of address. Unprecedented attack
			possibilities [8] would arise if correspondent nodes took liberties
			with respect to these obligations: An impersonator could claim a
			victim's IP address and request a correspondent node to bind this, as
			a home address, to its own care-of address. The impersonator could
			then communicate on behalf of the victim. A flooding attacker could
			use its own home address in combination with a care-of address that
			in fact would belong to a victim. This victim would receive packets
			that should actually be routed to the attacker.
	While authentication prevents impersonation threats, the reachability		A fundamental constraint for the security design of route
	verification for the care-of address protects against "redirection-		optimization is that it must do without a pre-existing relationship
	based flooding attacks" [8].		between a mobile node and a correspondent node. Reliance on a PKI is
			likewise assessed unsuitable given a number of intrinsic problems [9]
			that PKIs would entail in the context of mobility. The default
			mechanism to authorize a binding update for a correspondent node is
			instead based on a preceding return routability procedure. This
			allows the correspondent node to verify the mobile node's
			reachability at the home and care-of addresses in an ad-hoc, non-
			cryptographic manner. Reachability at both IP addresses indicates
			(though it does not guarantee) the mobile node's ownership of the IP
			addresses, and hence that binding these IP addresses is secure.
	Standard route optimization is limited by the capabilities of the		Unfortunately, the home and care-of address tests of the return
	return routability procedure. For one thing, the procedure does not		routability procedure are still vulnerable to those impersonators and
	protect against an impersonator on the path between the mobile node's		flooding attackers which can interpose in the respective test. This
	home agent and the correspondent node. This vulnerability may		may be considered acceptable for the care-of address test given that
	oftentimes be acceptable, given that it already exists in the non-		a flooding attacker capable of compromising the test would expose
	mobile Internet of today. But scenarios with higher security needs		itself to the same packet flood that also befalls the victim. Yet
	are also conceivable. Second, the return routability procedure		impersonation is a more intractable threat, which constitutes an
	consumes a significant of the overall handoff delay. Since route		obstacle for the deployment of route optimization. Besides security-
	optimization was orignally developed with an intent to improve		related drawbacks, performance-wise, both IP address tests have the
	support for interactive real-time applications, it is exactly those		disadvantage of increasing handoff delays.
	applications that suffer from prolonged handoff delays.
	This document amends the Mobile IPv6 base specification by two		The protocol defined in this document amends Mobile IPv6 route
	optional, interrelated, yet orthogonal optimizations to the return		optimization in two ways: A mobile node's home address is secured
	routability procedure. The first optimization enables unidirectional		against impersonation through an interface identifier that is
	or mutual authentication based on a cryptographically generated home		cryptographically and verifiably bound to the mobile node's public/
	address [9]. This replaces the weaker authentication through pure		private-key pair. The mobile node proves ownership of the home
	reachability verification at a home address. The second optimization		address by providing evidence that it knows the correct private key.
	allows a correspondent node to securely verify a mobile node's		An initial home address test confirms the home address prefix, but
	reachability at a new care-of address while it already sends data		subsequent tests can be spared. This alone would leave the latency
	packets to that care-of address [10]. The two optimizations can be		of the care-of address test, so in addition, correspondent nodes
	applied separately or, preferably, in conjunction.		allow this test to proceed in parallel with regular data traffic. To
			preclude the threat of redirection-based flooding until the test
			succeeds, the amount of data sent to the care-of address is bound by
			a dynamically determined limit. These two optional enhancements can
			be applied separately or, preferably, in conjunction.
	2. Objectives		2. Objectives
	The design of Mobile IPv6 route optimization is in may ways		The design of Mobile IPv6 route optimization is in may ways
	conservative, leaving room to optimize handoff delay, security, and		conservative, leaving room to optimize handoff delay, security, and
	signaling overhead. The protocol defined in this document tackles		signaling overhead. The protocol defined in this document tackles
	these issues and thus constitutes a more progressive variant of the		these issues and thus constitutes a more progressive variant of the
	base mobility protocol.		base mobility protocol.
	In spite of any improvements in the mobility protocol, it is		In spite of any improvements in the mobility protocol, it is
	skipping to change at page 4, line 44		skipping to change at page 5, line 28
	transmissions right after it has dispatched the Binding Update		transmissions right after it has dispatched the Binding Update
	message. But if it requests a Binding Acknowledgment message from		message. But if it requests a Binding Acknowledgment message from
	the correspondent node, communications are usually delayed until this		the correspondent node, communications are usually delayed until this
	is received.		is received.
	Handoff delays in Mobile IPv6 route optimization are additive to		Handoff delays in Mobile IPv6 route optimization are additive to
	other delays at IP layer or link layer. They can cause perceptible		other delays at IP layer or link layer. They can cause perceptible
	quality degradations for interactive and real-time applications. TCP		quality degradations for interactive and real-time applications. TCP
	bulk-data transfers are likewise affected since long handoff		bulk-data transfers are likewise affected since long handoff
	latencies may lead to successive retransmission timeouts and degraded		latencies may lead to successive retransmission timeouts and degraded
	throughput [11]. This protocol eliminates the additional handoff		throughput [10]. This protocol eliminates the additional handoff
	delay induced by Mobile IPv6 route optimization for packets that a		delay induced by Mobile IPv6 route optimization for packets that a
	mobile node sends, and it reduces the delay to 1 round-trip time		mobile node sends, and it reduces the delay to 1 round-trip time
	between the mobile node and the correspondent node for packets that		between the mobile node and the correspondent node for packets that
	the mobile node receives.		the mobile node receives.
	2.2 Security		2.2 Security
	Given that mobile and correspondent nodes with support for Mobile		Given that mobile and correspondent nodes with support for Mobile
	IPv6 route optimization form a true subset of all Internet nodes, the		IPv6 route optimization form a true subset of all Internet nodes, the
	security design of the mobility protocol cannot make the Internet any		security design of the mobility protocol cannot make the Internet any
	skipping to change at page 5, line 28		skipping to change at page 6, line 9
	o An attacker should not be able to redirect a third node's		o An attacker should not be able to redirect a third node's
	communication flow to itself or to another IP address, at least		communication flow to itself or to another IP address, at least
	not beyond what is already possible in plain IPv6. This		not beyond what is already possible in plain IPv6. This
	requirement applies both to ongoing and future communication		requirement applies both to ongoing and future communication
	flows.		flows.
	o An attacker should not be able to redirect its own communication		o An attacker should not be able to redirect its own communication
	flows to a third party, flooding the victim with unrequested		flows to a third party, flooding the victim with unrequested
	packets. Such redirection-based flooding attack would provide		packets. Such redirection-based flooding attack would provide
	substantial amplification that is today only possible through a		substantial amplification that is today only possible through a
	network of compromised nodes [12]. E.g., an attacker could		network of compromised nodes [11]. E.g., an attacker could
	accomplish the initial TCP handshake for a voluminous file		accomplish the initial TCP handshake for a voluminous file
	download through its own address (or home address, for that		download through its own address (or home address, for that
	matter), and then redirect the flow to the address of its victim.		matter), and then redirect the flow to the address of its victim.
	The attacker could spoof acknowledgments on behalf of the victim		The attacker could spoof acknowledgments on behalf of the victim
	based on the sequence numbers it learned from the initial		based on the sequence numbers it learned from the initial
	handshake, but those would be small compared to the full-sized		handshake, but those would be small compared to the full-sized
	segments that the correspondent node generates.		segments that the correspondent node generates.
	o Attackers should not be able to cause denial-of-service through		o Attackers should not be able to cause denial-of-service through
	potentially expensive computations involved in the mobility		potentially expensive computations involved in the mobility
	protocol.		protocol.
	Applications that require a higher security level than the return		Applications that require a higher security level than the return
	routability procedure can provide are generally advised to use end-		routability procedure can provide are generally advised to use end-
	to-end protection such as IPsec or TLS. But even then are they		to-end protection such as IPsec or TLS. But even then are they
	vulnerable to denial of service. Furthermore, these mechanisms		vulnerable to denial of service. Furthermore, these mechanisms
	either require end nodes to be preconfigured with credentials for		either require end nodes to be preconfigured with credentials for
	mutual authentication, or they depend on a public-key infrastructure.		mutual authentication, or they depend on a public-key infrastructure.
	Either approache impedes [13] wide deployment of Mobile IPv6 route		Either approache impedes [9] wide deployment of Mobile IPv6 route
	optimization. The protocol defined in this document permits end		optimization. The protocol defined in this document permits end
	nodes to authenticate each other by means of a cryptographic property		nodes to authenticate each other by means of a cryptographic property
	of their home addresses. It neither depends on preconfiguration nor		of their home addresses. It neither depends on preconfiguration nor
	on a public-key infrastructure, and yet it conforms to the key		on a public-key infrastructure, and yet it conforms to the key
	requirements listed above.		requirements listed above.
	2.3 Signaling Overhead		2.3 Signaling Overhead
	A complete correspondent registration involves 6 message		A complete correspondent registration involves 6 message
	transmissions at the mobile node, totaling about 376 bytes (cf.		transmissions at the mobile node, totaling about 376 bytes (cf.
	[14]). This signaling overhead may be acceptable if movements are		[12]). This signaling overhead may be acceptable if movements are
	infrequent. E.g., a mobile node that moves once every 30 minutes		infrequent. E.g., a mobile node that moves once every 30 minutes
	generates an average of 1.7 bits/second of signaling traffic. Higher		generates an average of 1.7 bits/second of signaling traffic. Higher
	mobility causes more serious overhead, however. A cell size of 100		mobility causes more serious overhead, however. A cell size of 100
	meters and a speed of 120 km/h yields 1 movement every 3 seconds and		meters and a speed of 120 km/h yields 1 movement every 3 seconds and
	about 1,000 bits/second of signaling traffic. This compares to a		about 1,000 bits/second of signaling traffic. This compares to a
	highly compressed voice stream with a typical data rate of 10,000 to		highly compressed voice stream with a typical data rate of 10,000 to
	30,000 bits/second. The protocol defined in this document introduces		30,000 bits/second. The protocol defined in this document introduces
	a new message exchange between mobile and correspondent nodes in		a new message exchange between mobile and correspondent nodes in
	order to accomplish the desired improvements in handoff delay. The		order to accomplish the desired improvements in handoff delay. The
	implied new signaling overhead is compensated for by verifying		implied new signaling overhead is compensated for by verifying
	reachability of the care-of address in-band, sparing a separate		reachability of the care-of address in-band, sparing a separate
	message exchange.		message exchange.
	Standard Mobile IPv6 requires mobile nodes to renew a binding at a		Standard Mobile IPv6 requires mobile nodes to renew a binding at a
	correspondent node at least every 7 minutes. The signaling overhead		correspondent node at least every 7 minutes. The signaling overhead
	amounts to 7.16 bits per second if the mobile node communicates with		amounts to 7.16 bits per second if the mobile node communicates with
	a stationary node [14]. It doubles if both peers are mobile. This		a stationary node [12]. It doubles if both peers are mobile. This
	overhead may be negligible when the nodes communicate, but it can be		overhead may be negligible when the nodes communicate, but it can be
	an issue for mobile nodes that are inactive and stay at the same		an issue for mobile nodes that are inactive and stay at the same
	location for a while. These nodes typically prefer to go to standby		location for a while. These nodes typically prefer to go to standby
	mode to conserve battery power. Also, the periodic refreshments		mode to conserve battery power. Also, the periodic refreshments
	consume a fraction of the wireless bandwidth that one could use more		consume a fraction of the wireless bandwidth that one could use more
	efficiently. The protocol defined in this document allows		efficiently. The protocol defined in this document allows
	correspondent nodes to specify a binding lifetime much larger than 7		correspondent nodes to specify a binding lifetime much larger than 7
	minutes. It thereby reduces the signaling overhead generated by		minutes. It thereby reduces the signaling overhead generated by
	mobile nodes that do not change their care-of address for a while.		mobile nodes that do not change their care-of address for a while.
	skipping to change at page 7, line 5		skipping to change at page 7, line 34
	Cryptographically generated home addresses		Cryptographically generated home addresses
	A Mobile IPv6 binding is conceptually a packet redirection from a		A Mobile IPv6 binding is conceptually a packet redirection from a
	home address to a care-of address. The home address is the source		home address to a care-of address. The home address is the source
	of the redirection, whereas the care-of address is the		of the redirection, whereas the care-of address is the
	destination. The packets to be redirected can hence be identified		destination. The packets to be redirected can hence be identified
	based on the home address. This motivates a strong, cryptographic		based on the home address. This motivates a strong, cryptographic
	ownership proof for the home address. The protocol defined in		ownership proof for the home address. The protocol defined in
	this document features this through the application of		this document features this through the application of
	cryptographically generated home addresses [15][16]. In general,		cryptographically generated home addresses [13][14]. In general,
	a cryptographically generated address [9] provides a strong,		a cryptographically generated address [15] provides a strong,
	cryptographic binding between the interface identifier of the		cryptographic binding between the interface identifier of the
	address and the address owner's public key. This enables other		address and the address owner's public key. This enables other
	nodes to securely authenticate the owner as such, modulo the		nodes to securely authenticate the owner as such, modulo the
	correctness of the address prefix. Cryptographically generated		correctness of the address prefix. Cryptographically generated
	home addresses can supersede home address tests with the exeption		home addresses can supersede home address tests with the exeption
	of an initial test for validating the home address prefix. This		of an initial test for validating the home address prefix. This
	facilitates lower handoff delays as well as longer binding		facilitates lower handoff delays as well as longer binding
	lifetimes and, consequently, reduced signaling overhead for nodes		lifetimes and, consequently, reduced signaling overhead for nodes
	which temporarily do not move.		which temporarily do not move.
	skipping to change at page 7, line 38		skipping to change at page 8, line 20
	Semi-permanent security associations		Semi-permanent security associations
	Cryptographically generated addresses involve public-key		Cryptographically generated addresses involve public-key
	cryptography and are computationally inefficient to validate.		cryptography and are computationally inefficient to validate.
	Further, the technique requires a significant amount of		Further, the technique requires a significant amount of
	supplementary data to be piggybacked onto protected messages. The		supplementary data to be piggybacked onto protected messages. The
	protocol defined in this document therefore leverages the		protocol defined in this document therefore leverages the
	cryptographic property of home addresses to securely exchange a		cryptographic property of home addresses to securely exchange a
	secret shared key between a mobile node and a correspondent node		secret shared key between a mobile node and a correspondent node
	[17]. This key is used to authenticate subsequent signaling		[16]. This key is used to authenticate subsequent signaling
	messages efficiently.		messages efficiently.
	Initial home address tests		Initial home address tests
	An initial home address test is necessary in order to prevent		An initial home address test is necessary in order to prevent
	redirection-based flooding attacks against an alleged home		redirection-based flooding attacks against an alleged home
	network. Specifically, in the absence of a home address test, a		network. Specifically, in the absence of a home address test, a
	malicious node can cryptographically generate a home address with		malicious node can cryptographically generate a home address with
	the prefix of a targeted victim network, and register a binding		the prefix of a targeted victim network, and register a binding
	between this spoofed home address and its own IP address at a		between this spoofed home address and its own IP address at a
	correspondent node. The attacker proceeds to request the		correspondent node. The attacker proceeds to request the
	correspondent node, which may be a public server, to send a stream		correspondent node, which may be a public server, to send a stream
	of packets to its current location. The attacker then de-		of packets to its current location. The attacker then de-
	registers the binding, or lets it expire, with the consequence of		registers the binding, or lets it expire, with the consequence of
	having the correspondent node redirect the packet stream "back" to		having the correspondent node redirect the packet stream "back" to
	the victim network. The result is a flooding attack against the		the victim network. The result is a flooding attack against the
	victim network. To avoid such misuse, the initial home address		victim network. To avoid such misuse, the initial home address
	test is executed at the same time as the semi-permanent security		test is executed at the same time as the semi-permanent security
	association is being established [17]. The test does not need to		association is being established [16]. The test does not need to
	be repeated upon subsequent movements, however.		be repeated upon subsequent movements, however.
	Concurrent care-of address tests		Concurrent care-of address tests
	The protocol defined in this document allows a correspondent node		The protocol defined in this document allows a correspondent node
	to send packets to a new care-of address already before a proof of		to send packets to a new care-of address already before a proof of
	reachability at that address has been received from the mobile		reachability at that address has been received from the mobile
	node. Specifically, when the mobile node moves to a different		node. Specifically, when the mobile node moves to a different
	link, it first registers its new care-of address without providing		link, it first registers its new care-of address without providing
	a proof of reachability. The correspondent node registers the		a proof of reachability. The correspondent node registers the
	skipping to change at page 8, line 33		skipping to change at page 9, line 15
	Credit-Based Authorization		Credit-Based Authorization
	Concurrent care-of address tests without additional protection		Concurrent care-of address tests without additional protection
	would enable an attacker to temporarily redirect its own		would enable an attacker to temporarily redirect its own
	communication flows to a spoofed, unverified care-of address.		communication flows to a spoofed, unverified care-of address.
	This introduces a vulnerability to redirection-based flooding		This introduces a vulnerability to redirection-based flooding
	attacks and is hence in conflict with the security requirements		attacks and is hence in conflict with the security requirements
	defined in Section 2.2. Recall that the appeal of redirection-		defined in Section 2.2. Recall that the appeal of redirection-
	based flooding attacks is the potential for significant		based flooding attacks is the potential for significant
	amplification. Credit-Based Authorization [10] guarantees that		amplification. Credit-Based Authorization [17] guarantees that
	malicious packet redirection cannot generate amplification. This		malicious packet redirection cannot generate amplification. This
	defeats the purpose of redirection-based flooding: Any attacker		defeats the purpose of redirection-based flooding: Any attacker
	could more effectively flood its victim by sending bogus packets		could more effectively flood its victim by sending bogus packets
	directly.		directly.
	Reduced reachability verification		Reduced reachability verification
	A cryptographically generated home address does not tell whether		A cryptographically generated home address does not tell whether
	its prefix is correct, so there is still need for a home address		its prefix is correct, so there is still need for a home address
	test. Reachability verification is also required for care-of		test. Reachability verification is also required for care-of
	skipping to change at page 9, line 11		skipping to change at page 9, line 41
	address, binding lifetimes can be much longer than in standard		address, binding lifetimes can be much longer than in standard
	Mobile IPv6 route optimization, and reachability tests may occur		Mobile IPv6 route optimization, and reachability tests may occur
	on a less frequent basis.		on a less frequent basis.
	4. Protocol Operation		4. Protocol Operation
	The protocol defined in this document features a variety of possible		The protocol defined in this document features a variety of possible
	message exchanges. These are described below, packaged by the type		message exchanges. These are described below, packaged by the type
	of message processing operation.		of message processing operation.
	4.1 Sending Binding Update messages		4.1 Sending Binding Update Messages
	A mobile node may initiate a correspondent registration for any of		A mobile node may initiate a correspondent registration for any of
	the following reasons:		the following reasons:
	o To establish a new binding at a correspondent node so that further		o To establish a new binding at a correspondent node so that further
	packets can be route-optimized and do no longer need to be routed		packets can be route-optimized and do no longer need to be routed
	through the mobile node's home agent.		through the mobile node's home agent.
	o To update an existing binding at the correspondent node while		o To update an existing binding at the correspondent node while
	moving from one point of IP attachment to another.		moving from one point of IP attachment to another.
	o To follow up an early Binding Update message with a complete		o To follow up an early Binding Update message with a complete
	Binding Update message after receiving a Binding Acknowledgment		Binding Update message after receiving a Binding Acknowledgment
	message with a Care-of Test option.		message with a Care-of Test option.
	o To refresh an existing binding at the correspondent node without		o To refresh an existing binding at the correspondent node without
	changing its point of IP attachment.		changing its point of IP attachment.
	o To request the correspondent node to renew an existing permanent		o To request the correspondent node to renew an existing permanent
	home keygen token shared between the mobile node and the		home keygen token shared between the mobile node and the
	correspondent node (cf. Section 4.7).		correspondent node (cf. Section 4.5).
	In any of these cases, the mobile node sends a Binding Update message		In any of these cases, the mobile node sends a Binding Update message
	to the correspondent node. The Binding Update message MUST be		to the correspondent node. The Binding Update message MUST be
	authenticated either through the CGA property of the mobile node's		authenticated either through the CGA property of the mobile node's
	home address, or through a proof of reachability at the home address.		home address, or through a proof of reachability at the home address.
	The appropriate authentication method is selected as follows:		The appropriate authentication method is selected as follows:
	o If the mobile node's home address is a CGA, and the mobile node		o If the mobile node's home address is a CGA, and the mobile node
	has a permanent home keygen token in its Binding Update List entry		has a permanent home keygen token in its Binding Update List entry
	for the correspondent node, the mobile node MUST authenticate the		for the correspondent node, the mobile node MUST authenticate the
	skipping to change at page 10, line 10		skipping to change at page 10, line 42
	does not have a permanent home keygen token in its Binding Update		does not have a permanent home keygen token in its Binding Update
	List entry for the correspondent node, the mobile node MUST		List entry for the correspondent node, the mobile node MUST
	authenticate the Binding Update message with a proof of		authenticate the Binding Update message with a proof of
	reachability at its home address.		reachability at its home address.
	o If the mobile node's home address is not a CGA, the mobile node		o If the mobile node's home address is not a CGA, the mobile node
	MUST authenticate the Binding Update message with a proof of		MUST authenticate the Binding Update message with a proof of
	reachability at its home address.		reachability at its home address.
	The mobile node SHOULD request the correspondent node to accept its		The mobile node SHOULD request the correspondent node to accept its
	CGA parameters for future CGA-based authentication if its home addess		CGA parameters for future CGA-based authentication if its home
	is a CGA, but it does not yet have a permanent home keygen token from		address is a CGA, but it does not yet have a permanent home keygen
	the correspondent node. The mobile node then includes its CGA		token from the correspondent node. The mobile node then includes its
	parameters in the Binding Update message by adding one or more CGA		CGA parameters in the Binding Update message by adding one or more
	Parameters options (cf. Section 5.1) followed by a Signature option		CGA Parameters options (cf. Section 5.1) followed by a Signature
	(cf. Section 5.3). Once a permanent home keygen token has been		option (cf. Section 5.2). Once a permanent home keygen token has
	obtained from the correspondent node, the mobile node MUST		been obtained from the correspondent node, the mobile node MUST
	authenticate all subsequent Binding Update messages with the CGA		authenticate all subsequent Binding Update messages with the CGA
	property of its home address until either the binding lifetime		property of its home address until either the binding lifetime
	expires, or the mobile node explicitly de-registers from the		expires, or the mobile node explicitly de-registers from the
	correspondent node. The mobile node MAY choose to ignore the CGA		correspondent node. The mobile node MAY choose to ignore the CGA
	property of its home address and continue authenticating Binding		property of its home address and continue authenticating Binding
	Update messages through a proof of reachability at the home address,		Update messages through a proof of reachability at the home address,
	but this behavior is NOT RECOMMENDED.		but this behavior is NOT RECOMMENDED.
	The mobile node also includes its CGA parameters in the Binding		The mobile node also includes its CGA parameters in the Binding
	Update message if it intends to renew an existing permanent home		Update message if it intends to renew an existing permanent home
	keygen token shared with the correspondent node (cf. Section 4.7).		keygen token shared with the correspondent node (cf. Section 4.5).
	This is accomplished, as before, by adding to the message one or more		This is accomplished, as before, by adding to the message one or more
	CGA Parameters options and a Signature option.		CGA Parameters options and a Signature option.
	The authenticator for the Binding Update message is calculated based		The authenticator for the Binding Update message is calculated based
	on a permanent or temporary home keygen token. Which type of home		on a permanent or temporary home keygen token. Which type of home
	keygen token the mobile node uses in calculating the authenticator		keygen token the mobile node uses in calculating the authenticator
	depends on the authentication method:		depends on the authentication method:
	o If the Binding Update message is to be authenticated through the		o If the Binding Update message is to be authenticated through the
	CGA property of the mobile node's home address, the mobile node		CGA property of the mobile node's home address, the mobile node
	skipping to change at page 12, line 12		skipping to change at page 12, line 44
	taken from the Home Test message with which the home keygen token		taken from the Home Test message with which the home keygen token
	was obtained.		was obtained.
	o The care-of nonce index is zero if the Binding Update message is		o The care-of nonce index is zero if the Binding Update message is
	early.		early.
	o If the Binding Update message is complete, the associated nonce		o If the Binding Update message is complete, the associated nonce
	index is taken from the Care-of Test message with which the		index is taken from the Care-of Test message with which the
	care-of keygen token was obtained.		care-of keygen token was obtained.
	The Nonce Indices options follows the CGA Parameters and Signature		The Nonce Indices option follows the CGA Parameters and Signature
	options, if any.		options, if any.
	The mobile node finally calculates an authenticator for the Binding		The mobile node finally calculates an authenticator for the Binding
	Update message based on the selected home and care-of keygen tokens,		Update message based on the selected home and care-of keygen tokens,
	following the rules described in [1]. The authenticator is placed		following the rules described in [1]. The authenticator is placed
	into a Binding Authorization Data option [1], which the mobile node		into a Binding Authorization Data option [1], which the mobile node
	adds to the Binding Update message as the last option.		adds to the Binding Update message as the last option.
	4.2 Receiving Binding Update messages		4.2 Receiving Binding Update Messages
	When the correspondent node receives a Binding Update message, it		When the correspondent node receives a Binding Update message, it
	must first verify whether the sending mobile node is the legitimate		must first verify whether the sending mobile node is the legitimate
	owner of the home address specified in the message. This is		owner of the home address specified in the message. This is
	accomplished either through the CGA property of the home address, or		accomplished either through the CGA property of the home address, or
	through verification of the mobile node's reachability at the home		through verification of the mobile node's reachability at the home
	address. The correspondent node selects the authentication method		address. The correspondent node selects the authentication method
	based on the home nonce index given in the Nonce Indices option of		based on the home nonce index given in the Nonce Indices option of
	the Binding Update message:		the Binding Update message:
	skipping to change at page 13, line 5		skipping to change at page 13, line 37
	keygen token the correspondent node uses in validating the		keygen token the correspondent node uses in validating the
	authenticator, and how to retrieve or recompute the home keygen		authenticator, and how to retrieve or recompute the home keygen
	token, depends on the authentication method:		token, depends on the authentication method:
	o If the Binding Update message is to be authenticated through the		o If the Binding Update message is to be authenticated through the
	CGA property of the mobile node's home address, the correspondent		CGA property of the mobile node's home address, the correspondent
	node should have a permanent home keygen token in its Binding		node should have a permanent home keygen token in its Binding
	Cache entry for the mobile node. If so, the correspondent node		Cache entry for the mobile node. If so, the correspondent node
	MUST use this permanent home keygen token in validating the		MUST use this permanent home keygen token in validating the
	authenticator of the Binding Update message. If the correspondent		authenticator of the Binding Update message. If the correspondent
	node does not have a permanent home keygen token for the mobile		node does not have a Binding Cache entry for the mobile node or
	node in its Binding Cache, the correspondent node MUST reject the		the existing Binding Cache entry for the mobile node does not
	Binding Update message.		include a permanent home keygen token, the correspondent node MUST
			reject the Binding Update message by sending a Binding
			Acknowledgment message with status code TBD ("Permanent Home
			Keygen Token Unavailable").
	o If the Binding Update message is to be authenticated through		o If the Binding Update message is to be authenticated through
	verification of the mobile node's reachability at the home		verification of the mobile node's reachability at the home
	address, the correspondent node MUST verify that it does not have		address, the correspondent node MUST verify that it does not have
	a permanent home keygen token in its Binding Cache entry for the		a permanent home keygen token in its Binding Cache entry for the
	mobile node. Provided that no permanent home keygen token is		mobile node. Provided that no permanent home keygen token is
	found, the correspondent node MUST recompute the temporary home		found, the correspondent node MUST recompute the temporary home
	keygen token defined by the (non-null) home nonce index in the		keygen token defined by the (non-null) home nonce index in the
	Nonce Indices option of the Binding Update message, and it MUST		Nonce Indices option of the Binding Update message, and it MUST
	use this recomputed token in validating the authenticator of the		use this recomputed token in validating the authenticator of the
	message. In case the correspondent node does have a permanent		message. On the other hand, in case the correspondent node does
	home keygen token in its Binding Cache entry for the mobile node,		have a permanent home keygen token in its Binding Cache entry for
	it MUST reject the Binding Update message. This is necessary to		the mobile node, further action depends on whether the Binding
	ensure that an attacker cannot bid down the authentication method		Update message includes a CGA Parameters option. If the message
	to hijack a mobile node's legitimate binding.		does not include a CGA Parameters option, the correspondent node
			MUST reject the message by sending a Binding Acknowledgment
			message with status code TBD ("Conflicting Permanent Home Keygen
			Token"). This is necessary to ensure that an attacker cannot bid
			down the authentication method to hijack a mobile node's
			legitimate binding. However, if a CGA Parameters option is
			included in the Binding Update message, the message is processed
			further. The sending mobile node is in this case requesting a new
			permanent home keygen token. Binding Update messages sent for the
			purpose of renewing an existing permanent home keygen token are
			usually authenticated through the CGA property of the mobile
			node's home address, based on the existing permanent home keygen
			token. However, a mobile node may authenticate the Binding Update
			message through verification of its reachability at the home
			address when it has lost the permanent home keygen token, for
			instance, due to a reboot. The correspondent node MUST then
			recompute the temporary home keygen token defined by the (non-
			null) home nonce index in the Nonce Indices option of the Binding
			Update message and use this recomputed token in validating the
			authenticator of the message. Note that the Binding Update
			message will still be rejected eventually should the
			authentication through the CGA property of the mobile node's home
			address fail during processing of the CGA Parameters option.
	The authenticator for the Binding Update message is further		The authenticator for the Binding Update message is further
	calculated based on a care-of keygen token. Which care-of keygen		calculated based on a care-of keygen token. Which care-of keygen
	token the correspondent node uses in validating the authenticator		token the correspondent node uses in validating the authenticator
	depends on whether the Binding Update message is complete or early:		depends on whether the Binding Update message is complete or early:
	o If the care-of nonce index in the Nonce Indices option of the		o If the care-of nonce index in the Nonce Indices option of the
	Binding Update message is set to a non-null value, the Binding		Binding Update message is set to a non-null value, the Binding
	Update message is complete. In this case, the correspondent node		Update message is complete. In this case, the correspondent node
	MUST recompute the care-of keygen token defined by the index, and		MUST recompute the care-of keygen token defined by the index, and
	it MUST use this recomputed token in validating the authenticator		it MUST use this recomputed token in validating the authenticator
	of the message.		of the message.
	o If the care-of nonce index is zero, the Binding Update message is		o If the care-of nonce index is zero, the Binding Update message is
	early. In this case, the correspondent node uses a value of zero		early. In this case, the correspondent node uses a value of zero
	in validating the authenticator of the Binding Update message.		in validating the authenticator of the Binding Update message.
	The correspondent node finally validates the authenticator in the		The correspondent node finally validates the authenticator in the
	Binding Update message based on the selected home and care-of keygen		Binding Update message based on the selected home and care-of keygen
	tokens, following the rules described in [1].		tokens, following the algorithm described in [1].
	If the validation fails, the correspondent node MUST discard the		If the validation fails, the correspondent node MUST discard the
	Binding Update message. The correspondent node may have to send a		Binding Update message. The correspondent node may have to send a
	Binding Acknowledgment message with a negative status code as		Binding Acknowledgment message with a negative status code as
	described in [1].		described in [1].
	Provided that the validation of the authenticator in the Binding		Provided that the validation of the authenticator in the Binding
	Update message succeeds, the correspondent node registers the mobile		Update message succeeds, the correspondent node registers the mobile
	node's new care-of address, either updating an existing Binding Cache		node's new care-of address, either updating an existing Binding Cache
	entry, if one exists, or creating a new Binding Cache entry. The		entry, if one exists, or creating a new Binding Cache entry. The
	skipping to change at page 14, line 30		skipping to change at page 15, line 39
	mobile node is requesting the correspondent node to accept the		mobile node is requesting the correspondent node to accept the
	included CGA parameters either for establishing a new, or for		included CGA parameters either for establishing a new, or for
	renewing an existing permanent home keygen token shared between the		renewing an existing permanent home keygen token shared between the
	mobile node and the correspondent node. The correspondent node MUST		mobile node and the correspondent node. The correspondent node MUST
	in this case check if the CGA Parameters option is directly followed		in this case check if the CGA Parameters option is directly followed
	by a Signature option and, if so, validate the signature included in		by a Signature option and, if so, validate the signature included in
	the latter. This is done as described in Section 4.6.		the latter. This is done as described in Section 4.6.
	If the CGA Parameters option is not directly followed by a Signature		If the CGA Parameters option is not directly followed by a Signature
	option, or the validation of the signature included in the Signature		option, or the validation of the signature included in the Signature
	option fails, the correspondent node MUST discard the Binding Update		option fails, the correspondent node MUST silently discard the
	message.		Binding Update message.
	Provided that the signature included in the Signature option is		Provided that the signature included in the Signature option is
	correct, the correspondent node generates a permanent home keygen		correct, the correspondent node generates a permanent home keygen
	token to be shared with the mobile node and stores it in its Binding		token to be shared with the mobile node and stores it in its Binding
	Cache entry for the mobile node. The permanent home keygen token is		Cache entry for the mobile node. The permanent home keygen token is
	sent to the mobile node within a Binding Acknowledgment message as		sent to the mobile node within a Binding Acknowledgment message as
	described in Section 4.3.		described in Section 4.3.
	4.3 Sending Binding Acknowledgment messages		4.3 Sending Binding Acknowledgment messages
	skipping to change at page 15, line 20		skipping to change at page 16, line 27
	message MUST contain a Care-of Test option with a pseudo-random value		message MUST contain a Care-of Test option with a pseudo-random value
	in the Care-of Keygen Token field.		in the Care-of Keygen Token field.
	If the Binding Update message contains a CGA Parameters option		If the Binding Update message contains a CGA Parameters option
	followed by a Signature option, and the signature included in the		followed by a Signature option, and the signature included in the
	latter was determined to be correct, the Binding Acknowledgment		latter was determined to be correct, the Binding Acknowledgment
	message MUST include a Permanent Home Keygen Token option with the		message MUST include a Permanent Home Keygen Token option with the
	permanent home keygen token stored in the correspondent node's		permanent home keygen token stored in the correspondent node's
	Binding Cache entry for the mobile node.		Binding Cache entry for the mobile node.
	4.4 Receiving Binding Acknowledgment messages		4.4 Receiving Binding Acknowledgment Messages
	A mobile node verifies a received Binding Acknowledgment message		A mobile node verifies a received Binding Acknowledgment message
	according to the rules specified in [1].		according to the rules specified in [1].
	If the Binding Acknowledgment message contains a Care-of Test option,		If the Binding Acknowledgment message contains a Care-of Test option,
	the mobile node extracts the care-of keygen token included in this		the mobile node extracts the care-of keygen token included in this
	option, stores this token in the appropriate entry of its Binding		option, stores this token in the appropriate entry of its Binding
	Update List, and sends the correspondent node a complete Binding		Update List, and sends the correspondent node a complete Binding
	Update message as defined in section Section 4.1.		Update message as defined in section Section 4.1.
	If the Binding Acknowledgment message contains a Permanent Home		If the Binding Acknowledgment message contains a Permanent Home
	Keygen Token option, the mobile node extracts the permanent home		Keygen Token option, the mobile node extracts the permanent home
	keygen token included in this option and stores it in the appropriate		keygen token included in this option and stores it in the appropriate
	entry of its Binding Update List. Future Binding Update messages		entry of its Binding Update List. Future Binding Update messages
	will then be authenticated based on the CGA property of the mobile		will then be authenticated based on the CGA property of the mobile
	node's home address.		node's home address.
	4.5 Sending CGA Parameters		4.5 Sending CGA Parameters
	TBD.		A mobile node SHOULD send its CGA parameters to the correspondent
			node in any of the following situations:
			o To acquire a permanent home keygen token if the mobile node's home
			address is a CGA, and the mobile node does not yet have a
			permanent home keygen token from the correspondent node.
			o To extent the lifetime of an existing binding if the mobile node
			already has a permanent home keygen token from the correspondent
			node, and the lifetime of the binding at the correspondent node is
			about to expire.
			o To reinitialize the available sequence number space if the mobile
			node already has a permanent home keygen token from the
			correspondent node, and a sequence number rollover is imminent.
			In addition, a mobile node that already has a permanent home keygen
			token from the correspondent node MAY renew this token at any time by
			sending its CGA parameters to the correspondent node. Periodic
			renewal of the permanent home keygen token provides increased
			protection against cryptanalysis.
			The mobile node sends its CGA parameters to the correspondent node
			within a Binding Update message in the format of the CGA Parameters
			data structure defined in [18]. The CGA Parameters data structure is
			split over one or more CGA Parameters options as described in
			Section 5.1. The last CGA Parameters option MUST be directly
			followed by a Signature option (see Section 5.2). The Nonce Indices
			and Binding Authorization Data options MUST appear after the
			Signature option.
			The mobile node calculates the value for the Signature field in the
			Signature option according to the signature generation algorithm
			defined in section 6 of [18]. The value is calculated with the
			mobile node's private CGA key over the following sequence of octets:
			mobility data =
			care-of address | correspondent node IP address | MH data
			where "|" denotes concatenation. "Care-of address" is the mobile
			node's care-of address, and "correspondent node IP address" is the IP
			address of the correspondent node that the mobile node uses. In case
			the correspondent node is mobile, "correspondent node IP address"
			refers to the correspondent node's home address. "MH data" is the
			content of the Binding Update message including the mobility header
			and all options up to the last CGA Parameters option. That is, "MH
			data" excludes the IPv6 header and any IPv6 extension headers other
			than the mobility header itself. The "mobility data" constitutes
			what is referred to as the "message" in section 6 of [18].
			The value for the Signature field is calculated as if the Checksum
			field in the mobility header was zero. The Checksum field in the
			transmitted packet is still calculated in the usual manner, with the
			calculated value in the Signature field being a part of the packet
			protected by the checksum.
	4.6 Receiving CGA Parameters		4.6 Receiving CGA Parameters
	TBD.		A correspondent node that receives a Binding Update message first
			processes the message as described in [1], even if the message
			includes CGA Parameters and Signature options. This includes a
			verification of the Authenticator value in the Binding Authorization
			Data option. If the Binding Update message is rejected due to an
			incorrect Authenticator value or for any other reason, the
			correspondent node does not process the message further.
	4.7 Renewing a Permanent Home Keygen Token		Otherwise, if the correspondent node accepts the Binding Update
			message and the message includes one or more CGA Parameters options
			directly followed by a Signature option, the correspondent node
			proceeds to verify the cryptographic properties of the mobile node's
			home address in the Binding Update message. It reassembles the CGA
			Parameters data structure from the CGA Parameters options included in
			the Binding Update message as described in Section 5.1, and executes
			the CGA verification algorithm defined in [18]. The CGA verification
			algorithm takes the home address and the reassembled CGA Parameters
			data structure as input. If the home address fails the CGA
			verification, the correspondent node skips the steps below and sends
			a Binding Acknowledgment message with status code TBD (CGA and
			signature verification failed) to the mobile node.
	A mobile node MAY request a correspondent node to renew an existing		If the cryptographic properties of the mobile node's home address are
	permanent home kegen token at any time, but it MUST do so in the		verified to be correct, the correspondent node performs the more
	imminent event of a sequence number rollover, or when the lifetime of		time-consuming check of the signature. It extracts the signature
	the binding at the correspondent node is about to expire.		from the Signature field in the Signature option and executes the
			signature verification algorithm defined in [18]. The signature
			verification algorithm takes as input the home address, the
			reassembled CGA Parameters data structure, the MH data as defined in
			Section 4.5, and the CGA Message Type tag for this protocol as
			defined in Section 8, and the signature itself. If the signature
			verification fails, the correspondent node skips the steps below and
			sends a Binding Acknowledgment message with status code TBD (CGA and
			signature verification failed) to the mobile node.
	4.8 Handling Payload Packets		The correspondent node does not accept the mobile node's home address
			as a CGA if either the CGA verification or the signature verification
			fails. However, in both cases, the correspondent node still accepts
			the contents of the Binding Update message excluding the CGA
			Parameters and Signature options, but does not provide a permanent
			home keygen token in the Binding Acknowledgment message. The
			correspondent node in particular follows the rules in [1] for sending
			a Binding Acknowledgment message to the mobile node.
	A correspondent node maintains a "credit counter" for each mobile		If both the CGA verification and the signature verification are
	nodes with which it uses the protocol specified in this document.		successful, the correspondent node sends a Binding Acknowledgment
	Whenever a packet arrives from one of these mobile nodes, the		message with an included Permanent Home Keygen Token option to the
	correspondent node SHOULD increase that mobile node's credit counter		mobile node as described in Section 4.7.
	by the size of the received packet. When the correspondent node has
	a packet to be sent to the mobile node, if the mobile node's care-of
	address is labeled UNVERIFIED, the correspondent node checks whether
	it can send the packet to the UNVERIFIED care-of address: The packet
	SHOULD be sent if the value of the credit counter is higher than the
	size of the outbound packet. If the credit counter is too low, the
	packet MUST be discarded or buffered until address verification
	succeeds. When a packet is sent to a mobile node at an UNVERIFIED
	care-of address, the mobile node's credit counter MUST be reduced by
	the size of the packet. The mobile node's credit counter is not
	affected by packets that the host sends to a VERIFIED care-of address
	of that mobile node.
	Figure 1 depicts the actions taken by the correspondent node when a		4.7 Sending Permanent Home Keygen Tokens
	packet is received. Figure 2 shows the decision chain in the event a
			A correspondent node assigns a mobile node a new permanent home
			keygen token after it has received from the mobile node a Binding
			Update message with included CGA Parameters and Signature options,
			and these options have been successfully validated as described in
			Section 4.6. The permanent home keygen token is a 64-bit value,
			randomly generated by the correspondent node. The correspondent node
			stores the permanent home keygen token in the binding cache entry
			that it maintains for the mobile node.
			The correspondent node sends the permanent home keygen token to the
			mobile node in encrypted form within a Permanent Home Keygen Token
			option in a Binding Acknowledgment message. It sends this message
			even if the Acknowledge flag in the Binding Update message was clear.
			The Binding Acknowlegment message is built according to the rules in
			[1], except that it includes the Permanent Home Keygen Token option.
			The correspondent node encrypts the permanent home keygen token with
			the mobile node's public key using the RSAES-PKCS1-v1_5 format [2],
			and places the ciphertext into the Permanent Home Keygen Token field
			of the Permanent Home Keygen Token option.
			The Binding Authorization Data option MUST be the last option in the
			Binding Acknowledgment message. That is, the Authenticator value in
			the Binding Authorization Data option covers the Permanent Home
			Keygen Token option.
			4.8 Receiving Permanent Home Keygen Tokens
			A mobile node that receives a Binding Acknowledgment message first
			processes the message as described in [1], even if the message
			includes a Permanent Home Keygen Token option. This includes a
			verification of the Authenticator value in the Binding Authorization
			Data option. If the Binding Acknowledgment message is rejected due
			to an incorrect Authenticator value or for any other reason, the
			mobile node does not process the message further.
			Otherwise, if the mobile node accepts the Binding Acknowledgment
			message and the message includes a Permanent Home Keygen Token
			option, the mobile node extracts the ciphertext from the Permanent
			Home Keygen Token field in this option and decrypts it with its
			private CGA key using the RSAES-PKCS1-v1_5 format [2]. The result of
			the encryption is the permanent home keygen token to be used in
			further registrations with the correspondent node. The mobile node
			stores the permanent home keygen token in the binding update list
			entry that it maintains for the correspondent node.
			4.9 Handling Payload Packets
			The immediate exchange of an early Binding Update message after a
			handoff on the mobile node side enables mobile and correspondent
			nodes to quickly reestablish route-optimized communications via the
			mobile node's new care-of address. The mobile node may send payload
			packets to the correspondent node from the new care-of address as
			soon as the early Binding Update message has been transmitted. Like
			all other route-optimized payload packets that originate from the
			mobile node, these packets have the new care-of address in the Source
			Address field of the IPv6 header and the home address in the Home
			Address option of the IPv6 Destination Options extension header. The
			correspondent node redirects outgoing payload packets for the mobile
			node to the new care-of address once it has received the early
			Binding Update message and registered the new care-of address. These
			payload packets have the new care-of address in the Destination
			Address field of the IPv6 header and the home address in the IPv6
			Routing extension header.
			The correspondent node limits the amount of data it sends to the
			mobile node while the new care-of address is UNVERIFIED to prevent
			amplified, redirection-based flooding attacks. This is specifically
			realized as follows: The correspondent node maintains a "credit
			counter" for each mobile nodes with which it uses the protocol
			specified in this document. Whenever a packet arrives from one of
			these mobile nodes, the correspondent node SHOULD increase that
			mobile node's credit counter by the size of the received packet.
			When the correspondent node has a packet to be sent to the mobile
			node, if the mobile node's care-of address is labeled UNVERIFIED, the
			correspondent node checks whether it can send the packet to the
			UNVERIFIED care-of address: The packet SHOULD be sent if the value
			of the credit counter is higher than the size of the outbound packet.
			If the credit counter is too low, the packet MUST be discarded or
			buffered until address verification succeeds. When a packet is sent
			to a mobile node at an UNVERIFIED care-of address, the mobile node's
			credit counter MUST be reduced by the size of the packet. The mobile
			node's credit counter is not affected by packets that the host sends
			to a VERIFIED care-of address of that mobile node.
			Figure 2 depicts the actions taken by the correspondent node when a
			packet is received. Figure 3 shows the decision chain in the event a
	packet is sent.		packet is sent.
	Inbound		Inbound
	packet		packet
	|		|
	| +-----------------+ +-----------------+		| +-----------------+ +-----------------+
	| | Increase the | | Deliver the |		| | Increase the | | Deliver the |
	+-----> | credit counter |---------------> | packet to the |		+-----> | credit counter |---------------> | packet to the |
	| by packet size | | application |		| by packet size | | application |
	+-----------------+ +-----------------+		+-----------------+ +-----------------+
	Figure 1: Receiving Packets with Credit-Based Authorization		Figure 2: Receiving Packets with Credit-Based Authorization
	Outbound		Outbound
	packet		packet
	| _________________		| _________________
	| / \ +-----------------+		| / \ +-----------------+
	| / Is the \ No | Send the packet |		| / Is the \ No | Send the packet |
	+-----> | care-of address |-------------> | to the care-of |		+-----> | care-of address |-------------> | to the care-of |
	\ UNVERIFIED? / | address |		\ UNVERIFIED? / | address |
	\_________________/ +-----------------+		\_________________/ +-----------------+
	|		|
	| Yes		| Yes
	skipping to change at page 17, line 32		skipping to change at page 21, line 49
	|		|
	| Yes		| Yes
	|		|
	v		v
	+-----------------+ +-----------------+		+-----------------+ +-----------------+
	| Reduce the | | Send the packet |		| Reduce the | | Send the packet |
	| credit counter |---------------> | to the care-of |		| credit counter |---------------> | to the care-of |
	| by packet size | | address |		| by packet size | | address |
	+-----------------+ +-----------------+		+-----------------+ +-----------------+
	Figure 2: Sending Packets with Credit-Based Authorization		Figure 3: Sending Packets with Credit-Based Authorization
	4.9 Credit Aging		4.10 Credit Aging
	A correspondent node ensures that the credit counters it maintains		A correspondent node ensures that the credit counters it maintains
	for its mobile nodes gradually decrease over time. Such "credit		for its mobile nodes gradually decrease over time. Such "credit
	aging" prevents a malicious node from building up credit at a very		aging" prevents a malicious node from building up credit at a very
	slow speed and using this, all at once, for a severe burst of		slow speed and using this, all at once, for a severe burst of
	redirected packets.		redirected packets.
	Credit aging SHOULD be implemented by multiplying credit counters		Credit aging SHOULD be implemented by multiplying credit counters
	with a factor, CreditAgingFactor, less than one in fixed time		with a factor, CreditAgingFactor, less than one in fixed time
	intervals of CreditAgingInterval length. Choosing appropriate values		intervals of CreditAgingInterval length. Choosing appropriate values
	skipping to change at page 18, line 18		skipping to change at page 22, line 34
	The following values are used for the credit-aging parameters defined		The following values are used for the credit-aging parameters defined
	in this document:		in this document:
	CreditAgingFactor 7/8		CreditAgingFactor 7/8
	CreditAgingInterval 5 seconds		CreditAgingInterval 5 seconds
	Note: These parameter values work well when the correspondent node		Note: These parameter values work well when the correspondent node
	transfers a file to the mobile node via a TCP connection and the end-		transfers a file to the mobile node via a TCP connection and the end-
	to-end round-trip time does not exeed 500 milliseconds.		to-end round-trip time does not exeed 500 milliseconds.
	4.10 Cryptographic Calculations
	The Signature option is calculated with the mobile node's private key
	over the following sequence of octets:
	Mobility Data = care-of address | correspondent | MH Data
	Where | denotes concatenation and "correspondent" is the
	correspondent node's IPv6 address. Note that in case the
	correspondent node is mobile, correspondent refers to the
	correspondent node's home address.
	MH Data is the content of the mobility message including the MH
	header. The Authenticator within the Binding Authorization Data
	option is zeroed for purposes of calculating the signature.
	The RSA signature is generated by using the RSASSA-PKCS1-v1_5 [2]
	signature algorithm with the SHA-1 hash algorithm.
	When the SKey option is used, the correspondent node MUST encrypt the
	Kbm with the MN's public key using the RSAES-PKCS1-v1_5 format [2].
	4.11 Simultaneous Movements		4.11 Simultaneous Movements
	As specified in RFC 3775 [1], Mobility Header messages are generally		As specified in RFC 3775 [1], Mobility Header messages are generally
	sent via the mobile node's home agent and to the peer's home address,		sent via the mobile node's home agent and to the peer's home address,
	if it is also mobile. This makes it possible for two mobile nodes to		if it is also mobile. This makes it possible for two mobile nodes to
	communicate even if they are moving simultaneously.		communicate even if they are moving simultaneously.
	5. Option Formats and Status Codes		5. Option Formats and Status Codes
			The protocol specified in this document introduces a set of new
			mobility options and status codes. These are described below.
	5.1 CGA Parameters Option		5.1 CGA Parameters Option
	Options of this type are used to carry the mobile node's public key		Options of this type are used to carry the mobile node's public key
	and the CGA parameters needed by the correspondent node to check the		and the parameters needed by the correspondent node to check the CGA
	validity of the mobile node's CGA. RFC 3775 [1] limits Mobility		property of the mobile node's home address. RFC 3775 [1] limits
	Header options to a maximum length of 255 bytes, excluding the Option		mobility header options to a maximum length of 255 bytes, excluding
	Type and Option Length fields. For this reason, multiple options of		the Option Type and Option Length fields. For this reason, multiple
	this type are used to carry the entire CGA information, which is		options of this type are used to carry the all parameters, which are
	likely to exceed the limit specified in RFC 3775.		likely to exceed the limit specified in RFC 3775.
	The format of the option is the following:		The format of the CGA Parameters option is the following:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option Type | Option Length |		| Option Type | Option Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		: :
	. CGA Parameters .		: CGA Parameters :
	. .		: :
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Option Type		Option Type
	<To Be Assigned By IANA>.		<To Be Assigned By IANA>
	Option Length		Option Length
	Length of the option.		Length of the option
	Option Data		CGA Parameters
	This field contains up to 255 bytes of the string holding the		This field contains up to 255 bytes of the string holding the
	mobile node's CGA public key and other CGA parameters in the		mobile node's CGA public key and other CGA parameters in the
	format defined in [18]. The concatenation of all options of this		format defined in [18]. The concatenation of all options of this
	type in the order they appear in the Binding Update message MUST		type in the order they appear in the Binding Update message MUST
	result in the string defined in [18]. All options of this type		result in the string defined in [18]. All options of this type
	carried in the Binding Update message except the last one MUST		carried in the Binding Update message except the last one MUST
	contain exactly 255 bytes in the Option Data field, and the Option		contain exactly 255 bytes in the Option Data field, and the Option
	Length field MUST be set to 255 accordingly. All options of this		Length field MUST be set to 255 accordingly. All options of this
	type MUST appear one after another, i.e., an option of a different		type MUST appear one after another, i.e., an option of a different
	type MUST NOT be placed in between two options of this type.		type MUST NOT be placed in between two options of this type.
	5.2 Permanent Home Keygen Token Option		5.2 Signature Option
	As it has been mentioned above, the correspondent node MUST send a		The mobile node MUST provide a signature generated with its private
	new Kbm each time it receives a Binding Update message containing the		CGA key if it includes a CGA Parameters option in a Binding Update
	CGA Parameter option. For this purpose, this proposal uses a new		message. The signature MUST be inserted into a Signature option that
	option called SKey option, which MUST be inserted in the Binding		follows the CGA Parameters option.
	Acknowledgment message.
	The format of the option is as follows:		The format of the Signature option is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option Type | Length = 16 |		| Option Type | Option Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		: :
	| |		: Signature :
	+ Semi-Permanent Key for Binding Management (Kbmperm) +		: :
	| |
	+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Option Type		Option Type
	<To Be Assigned By IANA>.		<To Be Assigned By IANA>
	Option Length		Option Length
	Length of the option.		Length of the option
	Option Data		Signature
	This field contains the Kbmperm value. Note that the content of		This field contains the signature generated as specified in
	this field MUST be encrypted with the mobile node's public key as		Section 4.5.
	defined in Section 4.10. The length of Kbmperm value is 20 octets
	(before encryption or padding possibly involved [2]).
	5.3 Signature Option		5.3 Permanent Home Keygen Token Option
	When the mobile node signs the Binding Update message with its CGA		A correspondent node MUST send a new permanent home keygen token to a
	private key, it MUST insert the signature in the SIG option. Such		mobile node each time it receives a Binding Update message containing
	scenario occurs when the mobile node sends its first Binding Update		the CGA Parameters option from the mobile node. The permanent home
	message to the correspondent node and if the mobile node reboots		keygen token is carried in a Permanent Home Keygen Token option,
	during an ongoing session.		which the correspondent node MUST insert in the Binding
			Acknowledgment message for the mobile node.
	The option format is as follows:		The format of the Permanent Home Keygen Token option is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option Type | Option Length |		| Option Type | Length = 16 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	. Signature .		| |
	. .		+ Permanent Home Keygen Token +
			| |
			+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Option Type		Option Type
	<To Be Assigned By IANA>.		<To Be Assigned By IANA>
	Option Length		Option Length
	Length of the option.		Length of the option
	Option Data		Permanent Home Keygen Token
	This field contains the signature of the MH message it is		This field contains the permanent home keygen token generated by
	contained within.		the correspondent node. The content of this field MUST be
			encrypted with the mobile node's public key as defined in
			Section 4.7. The length of the permanent home keygen token is 8
			octets (before encryption or padding possibly involved [2]).
	5.4 Care-of Test Init Option		5.4 Care-of Test Init Option
	A mobile node that wishes to employ the care-of address test		The Care-of Test Init option is included in a Binding Update message
	optimization MAY employ this option in Binding Update message sent to		to request the correspondent node to return a Care-of Test option
	a correspondent node in which it has previously established a Binding		with a fresh care-of keygen token in the Binding Acknowledgment
	Cache entry. When received by such a correspondent node, it SHOULD
	return a Care-of Keygen Token option in the Binding Acknowledgement
	message.		message.
	The option format is as follows:		The format of the Care-of Test Init option is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option Type | Option Length |		| Option Type | Option Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Option Type		Option Type
	<To Be Assigned By IANA>.		<To Be Assigned By IANA>
	Option Length		Option Length
	Length of the option = 0.		Length of the option
	5.5 Care-of Test Option		5.5 Care-of Test Option
	This option is returned by a correspondent node upon seeing a Care-of		A correspondent node sends a Binding Acknowledgment message with a
	Test Init option in a Binding Update.		Care-of Test option when it receives a valid Binding Update message
			that includes a Care-of Test Init message. The Care-of Test message
			contains a fresh care-of keygen token.
	The option format is as follows:		The format of the Care-of Test option is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option Type | Option Length |		| Option Type | Option Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Care-of Keygen Token +		+ Care-of Keygen Token +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Option Type		Option Type
	<To Be Assigned By IANA>.		<To Be Assigned By IANA>
	Option Length		Option Length
	Length of the option = 8.		Length of the option
	Care-of Keygen Token		Care-of Keygen Token
	A care-of keygen token, calculated as in RFC 3775.		A care-of keygen token, generated as defined in RFC 3775.
	5.6 Status Codes		5.6 Status Codes
	The following new Status codes are allocated:		The protocol defined in this document uses the following new status
			code for Binding Acknowledgment messages:
	Lost Kbmperm State (<To Be Allocated By IANA>)		Permanent Home Keygen Token Unavailable (<To Be Allocated By IANA>)
	This code is returned when the correspondent node does not have a		A correspondent node returns a Binding Acknowledgment message with
	Binding Cache Entry, Kbmperm, or has an invalid Binding		this status code to a mobile node if it has received from the
	Authorization Data option. The code MUST only be used in to		mobile node a Binding Update message that was authenticated
	respond to Binding Updates that contain one of the mobility		through the CGA property of the mobile node's home address, but
	options defined in this document.		the correspondent node either does not have a Binding Cache entry
			for the mobile node, or the existing Binding Cache entry for the
			mobile node does not include a permanent home keygen token. A
			Binding Acknowledgment message with this status code allows the
			mobile node to quickly request a new permanent home keygen token
			from the correspondent node in case of state loss at the
			correspondent node.
			Standard Mobile IPv6 does not allow a correspondent node to send a
			negative Binding Acknowledgment message when the authenticator of
			a received Binding Update message turns out to be incorrect. This
			is likely to cause additional handoff latency because the mobile
			node can detect the problem only after the expiration of a
			retransmission timer. The mobile node is furthermore likely to
			assume packet loss and resend the incorrectly authenticated
			Binding Update message additional times. A negative Binding
			Acknowledgment message with the status code helps the mobile node
			to identify the underlying problem much more efficiently.
			Conflicting Permanent Home Keygen Token (<To Be Allocated By IANA>)
			A correspondent node returns a Binding Acknowledgment message with
			this status code to a mobile node if it has received from the
			mobile node a Binding Update message that was authenticated
			through verification of the mobile node's reachability at the home
			address and does not include a CGA Parameters option, but the
			correspondent node has a permanent home keygen token in its
			Binding Cache entry for the mobile node. The Binding Update
			message is processed further if it includes a CGA Parameters
			option. This is necessary to enable a mobile node to obtain a new
			permanent home keygent token from the correspondent node in case
			it has lost the existing one, for instance, due to a reboot.
			Whether the correspondent node accepts the Binding Update message
			in this case depends on the verification of the signature provided
			for the CGA parameters included in the message.
	6. Security Considerations		6. Security Considerations
	This draft describes a method to exploit the CGA features in order to		The protocol defined in this document makes the following conceptual
	authenticate route optimization signaling. In fact, the CGA replaces		changes to the base protocol specified in RFC 3775:
	the authentication by providing a proof of ownership while the RR
	procedure replaces the authentication by a routing property.
	This proof of ownership ensures that only the mobile node will be		o RFC 3775 uses periodic tests of a mobile node's reachability at
	able to change the routing of packets destined to it, modulo		the home address as a proof of home address ownership. This
	exhaustive attacks on the CGA mechanism itself. The feasibility of		protocol uses an initial cryptographic home address ownership
	such attacks and the defenses against them have been discussed in		proof in combination with a verification of the mobile node's
	[18].		reachability at the home address in order to securely exchange a
			secret permanent home keygen token. The permanent home keygen
			token is used for cryptographic authentication of the mobile node
			during subsequent binding updates, so that these later binding
			updates can be securely bound to the initial home address
			ownership proof. No further, periodic reachability verification
			at the home address tests is performed.
	Note that, as specified, the proof of ownership protection applies		o RFC 3775 requires a mobile node to prove its reachability at a new
	only to the correspondent node believing the statements made by the		care-of address when updating a binding at a correspondent node.
	mobile node. There is no guarantee that the answers from the		This implies that the mobile node and the correspondent node must
	correspondent node truly come from that correspondent node and not		exchange Care-of Test Init and Care-of Test messages before the
	from someone who was on the path to the correspondent node during the		mobile node can initiate the binding update proper. This protocol
	initial contact phase. This is because we do not require		allows the mobile node to initiate the binding update first and
	correspondent nodes to have CGAs, and as a result, they can not make		then follow up with a proof of reachability at the care-of
	any statements that are authenticated in the strong sense. We chose		address. Mobile and correspondent nodes can so resume
	not to protect against this, because this attack is something that		communications early on after a handoff, while reachability
	already exists in plain IPv6, as is explained in the following. Lets		verification proceeds concurrently.
	assume that the correspondent node does not care about the IP address
	of the peers contacting it and that it does not protect its payload
	packets cryptographically. Then, a man-in-the-middle can always use
	its own address when communicating to the correspondent node, and the
	correspondent node's address when communicating to the mobile node.
	Philosophically, one can also argue that since the problem we attempt
	to solve here is routing modifications for the mobile node's address,
	it is sufficient to ensure that these modifications are protected.
	It should be mentioned that while the CGA can provide a protection		o The maximum binding lifetime for correspondent registrations is 7
	against unauthenticated Binding Update messages, it can expose the		minutes in RFC 3775. A mobile node must hence periodically
	involved nodes to denial-of-service attacks since it is		refresh a correspondent registration in cases where it does not
	computationally expensive. The draft limits the use of CGA to only		change IP connectivity for a while. This protocol increases the
	the first registration and if/when re-keying is needed. In addition,		maximum binding lifetime to 24 hours, eliminating the need for
	it is RECOMMENDED that nodes track the amount of resources spent to		periodic refreshes.
	the CGA processing, and disable the processing of new requests when
	these resources exceed a predefined limit.		The following subsections discuss the implications that these changes
			have on security. The discussion ought to be seen in context with
			the security considerations of [1], [18], and [8].
			6.1 Home Address Ownership
			The protocol defined in this document requires a mobile node to
			deliver a strong cryptographic proof that it is the owner of the home
			address it wishes to use. The proof requires knowledge of a private
			key for which the corresponding public key will, as an input to the
			CGA generation algorithm along with suitable other parameters, result
			in the desired home address. Spoofing another node's home or regular
			IPv6 address, so-called "IP address stealing" [8], hence requires an
			attacker to find a suitable public/private key pair in a brute-force
			manner. The effort for doing so successfully is very high [18].
			This makes the attack, which would otherwise permit impersonation and
			denial of service, extremely unlikely.
			While the CGA generation algorithm cryptographically ties the
			interface identifier of the CGA to the prefix, the algorithm accepts
			any prefix and hence does not prevent a node from generating a CGA
			from a different network. As a consequence, the cryptographic
			property of a CGA does not guarantee that the alledged CGA owner is
			indeed reachable at the IP address. An attacker could in fact use
			its own public key to generate a CGA-based home address with an
			incorrect prefix, request a correspondent node to bind this to the
			attacker's true care-of address, request a stream of packets via the
			care-of address, and then let the binding expire. The result would
			be a "return-to-home flooding" [8] attack against the victim network
			for which the home address was generated. The protocol defined in
			this document performs a reachability test for the home address at
			the time the home address is first registered with the correspondent
			node. This precludes return-to-home flooding.
			During the initial registration, the correspondent node assigns the
			mobile node a permanent home keygen token for use during subsequent
			binding updates. The permanent home keygen token is a symmetric
			secret key that allows for computationally more efficient
			authentication than a reapplied public-key-based home address
			ownership proof. Authentication of the mobile node allows the
			correspondent node to securely bind a subsequent binding update back
			to the home address ownership proof and reachability verification
			performed during the first registration. The permanent home keygen
			token is never sent in plain text; it is encrypted with the mobile
			node's public key when initially assigned, and irreversibly hashed
			during subsequent binding updates. Both mobile and correspondent
			nodes can therefore trust that the permanent home keygen token is
			known to only itself and the mobile node.
			6.2 Care-of Address Ownership
			A secure proof of home address ownership can mitigate the threat of
			IP address stealing, but a malicious node may still bind a correct
			home address to a false care-of address and thereby redirect packets,
			which would otherwise be delivered to the node itself, to a third
			party. Neglection to verify a given care-of address could therefore
			cause one or multiple correspondent nodes to unknowingly contribute
			to a "redirection-based flooding" [8] attack against a victim chosen
			by the attacker.
			A redirection-based flooding attack may target an entire network,
			rather than a single node, either by loading the network with
			packets, or by overwhelming a router or other critical network device
			further upstream. The attacker in this case directs the flooding
			packets against an arbitrary IP address matching a prefix of the
			victim network or, respectively, against the IP address of the
			network device in focus. An attack against a network potentially
			impacts a larger number of nodes than an attack against a specific
			node, although neighbors of a victim node on a broadcast link
			typically suffer the same damage as the victim itself.
			A common misconception is that a strong proof of home address
			ownership would mitigate the threat of redirection-based flooding and
			consequently eliminate the need for a verification of the care-of
			address. This notion may originate from the specification of a home
			registration in RFC 3775, which authenticates a mobile node based on
			an IPsec security association, but does not supplement this by an
			ownership proof of the care-of address. Yet the waiver for the
			care-of address test is in this case not justified by the fact that
			the home agent can securely verify the mobile node's home address
			ownership, or that the home registration is IPsec-protected. It is
			rather based a prerequired administrative relationship between the
			home agent and the mobile node that allows the home agent, first, to
			trust in the correctness of a mobile node's care-of address and,
			second, to quickly identify the mobile node should it still start
			behaving maliciously, e.g., due to compromise by malware. Section
			15.3 in [1] and section 1.3.2 in [8] explain these prerequisites.
			Assuming trust and an administrative relationship between the mobile
			node and its home agent is viable given that the home agent is an
			integral part of the mobility services which the mobile node's user
			typically has subscribed to, has set up her- or himself, or is
			receiving based on a business relationship. A Mobile IPv6 extension
			[19] that leverages a shared authentication key, pre-configured on
			the mobile node and the correspondent node, preassumes the same
			relationship between the mobile node and a correspondent node. While
			this assumption limits the applicability of the protocol (section 2
			of [19] acknowledges this), it permits omission of care-of address
			reachability verification as in the case of the home registration.
			The protocol defined in this document does not make assumptions on
			the relationship between mobile and correspondent nodes and thence
			applies to arbitrary scenarios. The implication of the lack of trust
			is that correspondent nodes must verify a mobile node's reachability
			at every new care-of address.
			Requiring mobile nodes to cryptographically generate care-of
			addresses would mitigate the threat of redirection-based flooding
			only marginally. While it would prevent an attacker from registering
			as its care-of address the IP address of a specific victim node, the
			attacker could still generate a new CGA-based care-of address with a
			prefix from the victim network. Directing a packet flood towards
			this care-of address would then not require any specific node to
			actually receive and process the packets, but it would impact an
			entire link or network and thus cause comparable damage. CGA-based
			care-of addresses are therefore little effective with respect to
			flooding protection, but would on the other hand require a
			computationally expensive, public-key-based ownership proof upon
			every binding update. The protocol described in this document uses
			regular IPv6 care-of addresses for these reasons.
			Concurrent verification of a mobile node's reachability at a new
			care-of address would in the absence of appropriate protection
			mechanisms re-introduce the threat of redirection-based flooding: An
			attacker could register a false care-of address, thereby trick its
			correspondent node into sending packets to a victim, delay the
			rechability verification process as much as possible, and finally
			register a different, possibly also spoofed care-of address. The
			attacker may in fact iterate through multiple incorrect care-of
			addresses which all route to the victim's link. Since even a
			legitimate mobile node may at times undergo two handoffs shortly
			after one another so that no time is left to finish reachability
			verification, it is in general impossible to decide at the
			correspondent node side whether a failed reachability verification is
			due to malicious intents or to other reasons.
			The protocol defined in this document uses Credit-Based Authorization
			to protect against misuse of concurrent reachability verification.
			Credit-Based Authorization does not prevent malicious packet
			redirection itself, but rather reduces the effectiveness of such an
			attack to that of a simple, direct flooding attack where the
			perpetrator itself sends packets to the victim. The ability to send
			unrequested packets is an inherent property of packet-oriented
			networks, and direct flooding is a threat that results from this.
			Since direct flooding exists with and without mobility support, it
			constitutes a reasonable measure in comparing the security provided
			by Credit-Based Authorization to the security of the non-mobile
			Internet. Through the use of Credit-Based Authorization, the
			protocol defined in this document hence satisfies the objective to
			provide a security level comparable to the non-mobile Internet.
			6.3 Time Shifting Attacks
			RFC 3775 limits the lifetime of a correspondent registration to 7
			minutes and so arranges that a mobile node's reachability at its home
			and care-of addresses is re-verified periodically. This ensures that
			the return routability procedure's vulnerability to eavesdropping
			cannot be exploited by an attacker which is only temporarily on the
			path between the correspondent node and the spoofed home or care-of
			address. Such "time shifting attacks" [8] could otherwise be misused
			for off-path IP address stealing, return-to-home flooding, or
			flooding of care-of addresses.
			The protocol defined in this document neither repeats the initial
			home address test nor any care-of address test in order to decrease
			handoff delays and signaling overhead. This does not limit the
			protocol's robustness to IP address stealing attacks because the
			protection of existing IP addresses solely rests on the required CGA-
			based ownership proof for home addresses, and it does not gain
			further strength through reachability testing. But the restriction
			to a single reachability test does facilitate time-shifted, off-path
			flooding attacks---either against home addresses with incorrect
			prefixes, or against spoofed care-of addresses---, if the perpetrator
			can interpose in the initial reachability test before it moves to a
			different location.
			The design choice against repeated IP address tests was made based on
			the observation that time shifting attacks are already an accepted
			threat in the non-mobile Internet of today. Specifically, an
			attacker can temporarily move onto the path between a victim and a
			correspondent node, request a stream of packets from the
			correspondent node on behalf of the victim, and then move to a
			different location. While a well-heeded responsibility of transport
			protocols and applications is to verify an initiator's IP address
			during connection establishment, subsequent verification typically
			takes place only by means of forgeable acknowledgments for received
			data. Participation in the initial handshake is then sufficient to
			spoof acknowledgments from an off-path position later on and thus
			feign continued presence at the victim's IP address. The threat of
			time shifting hence already applies to the non-mobile Internet.
			It should still be acknowledged that the time at which the mobility
			protocol verifies reachability of a home or care-of address may well
			antecede the establishment of any transport-layer connection. This
			gives an attacker more time to move away from the path between the
			correspondent node and the victim and so makes a time shifting attack
			more practicable. If the lack of periodic reachability verification
			is considered too risky, a correspondent node can enforce reruns of
			an home or care-of address test by limiting the registration lifetime
			or sending Binding Refresh Request messages to a mobile node.
			6.4 Replay Attacks
	The protocol specified in this document relies on standard 16-bit		The protocol specified in this document relies on standard 16-bit
	Mobile IPv6 sequence numbers and periodic rekeying to avoid replay		Mobile IPv6 sequence numbers and periodic rekeying to avoid replay
	attacks. Nodes rekey at least once every 24 hours. Nodes also rekey		attacks. Rekeying allows the nodes to reuse sequence numbers without
	whenever a rollover in the available sequence-number space becomes		exposing themselves to replay attacks. Mobile and correspondent
	imminent. Rekeying allows the nodes to reuse sequence numbers		nodes rekey at least once every 24 hours due to the maximum permitted
	without exposing themselves to replay attacks.		lifetime of a correspondent registration. The nodes also rekey
			whenever a rollover in sequence number space becomes imminent. This
			is unlikely to happen frequently, however, given that available
			sequence numbers are sufficient for up to 32768 binding updates, each
			consisting of an early and a full Binding Update message. The
			sequence number space thus permits an average rate of 22 binding
			updates per minute without exposing a need to rekey throughout the
			24-hour registration lifetime.
	This protocol is secure against flooding attacks due to the use of		6.5 Resource Exhaustion
	care-of-address tests, Credit-Based Authorization, and the use of an
	initial home address test.		While a CGA-based home address ownership proof provides protection
			against unauthenticated Binding Update messages, it can expose the
			involved nodes to denial-of-service attacks since it requires
			computationally expensive public-key cryptography. The protocol
			defined in this document limits the use of public-key cryptography to
			only the first registration and if/when re-keying is needed. It is
			RECOMMENDED that nodes in addition track the amount of processing
			resources they spend on CGA-based home address ownership
			verification, and that they reject new requests when these resources
			exceed a predefined limit. [18] discusses the feasibility of CGA-
			based resource exhaustion attacks in depth.
			6.6 IP Address Ownership of Correspondent Node
			The protocol defined in this document does not verify ownership of a
			correspondent node's IP address. A mobile node has hence no
			guarantee that a received permanent home keygen token indeed
			originates with the correspondent node. In particular, a man-in-the-
			middle attacker could interpose during the initial correspondent
			registration, pretend to be the correspondent node, and deliver its
			own permanent home keygen token to the mobile node. This attacker
			would have to be able to send both a Home Test message as well as a
			Binding Acknowledgment message on behalf of the correspondent node,
			and it may have to intercept the mobile node's Home Test Init and
			Binding Update messages. This potentially requires presence on
			separate paths. A successully spoofed inital registration would
			allow the attacker to impersonate the correspondent node also during
			subsequent binding updates of the mobile node, as long as it remains
			in a position to intercept and respond to the mobile node's Binding
			Update messages.
			The primary reason not to protect ownership of the correspondent
			node's IP address is that the threat emanating from a man in the
			middle on the path between two communicating nodes already exists in
			the non-mobile Internet. The threat can therefore more effectively
			be eliminated in a mobility-independent manner. This design choice
			also reduces the complexity of the protocol defined in this document
			and curtails the requirements imposed on the correspondent node.
	7. Performance Considerations		7. Performance Considerations
	Performance of our protocol depends on whether we look at the initial		Performance of our protocol depends on whether we look at the initial
	or subsequent runs. The number of messages in the initial run is one		or subsequent runs. The number of messages in the initial run is one
	less as in base Mobile IPv6, but the size of the messages is		less as in base Mobile IPv6, but the size of the messages is
	increased somewhat.		increased somewhat.
	On a mobile node that does not move that often, there is a		On a mobile node that does not move that often, there is a
	significant signaling reduction, as the lifetimes can be set higher		significant signaling reduction, as the lifetimes can be set higher
	than in return routability. For instance, a mobile node that stays		than in return routability. For instance, a mobile node that stays
	in the same address for a day will get a 99.52% signaling reduction.		in the same address for a day will get a 99.52% signaling reduction.
	Such long lifetimes can be achieved immediately, as opposed to		Such long lifetimes can be achieved immediately, as opposed to
	methods like [14] that grow them gradually.		methods like [12] that grow them gradually.
	On a mobile node that moves fast, the per-movement signaling is		On a mobile node that moves fast, the per-movement signaling is
	reduced by 33%.		reduced by 33%.
	Latency on the initial run is not affected, but on the subsequent		Latency on the initial run is not affected, but on the subsequent
	movements there's a significant impact. This is because the home		movements there's a significant impact. This is because the home
	address test is eliminated. The exact effect depends on network		address test is eliminated. The exact effect depends on network
	topology, but if the home agent is far away and the correspondent		topology, but if the home agent is far away and the correspondent
	node is on the same link, latency is almost completely eliminated.		node is on the same link, latency is almost completely eliminated.
	Additional latency and signaling improvements could be achieved		Additional latency and signaling improvements could be achieved
	through mechanisms that optimize the care-of address tests in some		through mechanisms that optimize the care-of address tests in some
	way. This is outside the scope of this document, however.		way. This is outside the scope of this document, however.
	8. IANA Considerations		8. Protocol Constants
	This document defines a new CGA Message Type name space for use as
	type tags in messages that may be signed using CGA signatures. The
	values in this name space are 128-bit unsigned integers. Values in
	this name space are allocated on a First Come First Served basis [3].
	IANA assigns new 128-bit values directly without a review.
	CGA Message Type values for private use MAY be generated with a		The CGA specification defines a CGA Message Type name space from
	strong random-number generator without IANA allocation.		which CGA applications draw CGA Message Type tags to be used in
			signature calculations. This protocol uses a CGA Message Type tag of
			0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13. The tag value has been
			generated randomly.
	This document defines a new 128-bit value under the CGA Message Type		9. IANA Considerations
	[18] namespace, 0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13.
	This document defines a set of new mobility options, which must be		This document defines a set of new mobility options, which must be
	assigned Option Type values within the mobility option numbering		assigned Option Type values within the mobility option numbering
	space of [1]. This document also allocates a new Status code value.		space of [1].
	9. Acknowledgment		This document allocates two new status codes, "Permanent Home Keygen
			Token Unavailable" and "Conflicting Permanent Home Keygen Token", for
			Binding Acknowledgment messages. The value to be assigned for both
			status codes must be greater than or equal to 128, indicating that
			the respective Binding Update message was rejected by the receiving
			correspondent node.
			This document also defines a new 128-bit value under the CGA Message
			Type name space [18].
			10. Acknowledgment
	The authors would like to thank Pekka Nikander, Tuomas Aura, Greg		The authors would like to thank Pekka Nikander, Tuomas Aura, Greg
	O'Shea, Mike Roe, Gabriel Montenegro, Vesa Torvinen for		O'Shea, Mike Roe, Gabriel Montenegro, Vesa Torvinen for
	interesting discussions around cryptographically generated addresses.		interesting discussions around cryptographically generated addresses.
	The authors would also like to thank Vidya Narayanan and Lakshminath		The authors would also like to thank Vidya Narayanan and Lakshminath
	Dondeti for their reviews of and comments on this document, as well		Dondeti for their reviews of and comments on this document, as well
	as Greg Daley, Samita Chakrabarti, Marcelo Bagnulo, Suresh Krishnan,		as Greg Daley, Samita Chakrabarti, Marcelo Bagnulo, Suresh Krishnan,
	Mohan Parthasarathy, Lila Madour, Francis Dupont, Roland Bless, Mark		Mohan Parthasarathy, Lila Madour, Francis Dupont, Roland Bless, Mark
	Doll, and Tobias Kuefner for their reviews of and comments on the		Doll, and Tobias Kuefner for their reviews of and comments on the
	predecessors of this document.		predecessors of this document.
	Finally, the authors would also like to emphasize that [19] pioneered		Finally, the authors would also like to emphasize that [20] pioneered
	the use of cryptographically generated addresses in the context of		the use of cryptographically generated addresses in the context of
	Mobile IPv6 route optimization, and that this document consists		Mobile IPv6 route optimization, and that this document consists
	largely of material from [20], [21], and [10] and the contributions		largely of material from [21], [22], and [17] and the contributions
	of their authors.		of their authors.
	10. References		11. References
	10.1 Normative References		11.1 Normative References
	[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in		[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	IPv6", RFC 3775, June 2004.		IPv6", RFC 3775, June 2004.
	[2] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards		[2] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
	(PKCS) #1: RSA Cryptography Specifications Version 2.1",		(PKCS) #1: RSA Cryptography Specifications Version 2.1",
	RFC 3447, February 2003.		RFC 3447, February 2003.
	[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[3] International Telecommunications Union, "Information Technology
	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
	[4] International Telecommunications Union, "Information Technology
	- ASN.1 encoding rules: Specification of Basic Encoding Rules		- ASN.1 encoding rules: Specification of Basic Encoding Rules
	(BER), Canonical Encoding Rules (CER) and Distinguished Encoding		(BER), Canonical Encoding Rules (CER) and Distinguished Encoding
	Rules (DER)", ITU-T Recommendation X.690, July 2002.		Rules (DER)", ITU-T Recommendation X.690, July 2002.
	[5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509		[4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
	Public Key Infrastructure Certificate and Certificate Revocation		Public Key Infrastructure Certificate and Certificate Revocation
	List (CRL) Profile", RFC 3280, April 2002.		List (CRL) Profile", RFC 3280, April 2002.
	[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
			[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
			Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
	[7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery		[7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
	for IP Version 6 (IPv6)", RFC 2461, December 1998.		for IP Version 6 (IPv6)", RFC 2461, December 1998.
	10.2 Informative References		11.2 Informative References
	[8] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.		[8] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
	Nordmark, "Mobile IP Version 6 Route Optimization Security		Nordmark, "Mobile IP Version 6 Route Optimization Security
	Design Background", IETF Request for Comments 4225,		Design Background", IETF Request for Comments 4225,
	December 2005.		December 2005.
	[9] Aura, T., "Cryptographically Generated Addresses (CGA)",		[9] Vogt, C. and J. Arkko, "Taxonomy and Analysis of Enhancements
	IETF Request for Comments 3972, March 2005.		to Mobile IPv6 Route Optimization", IETF Internet Draft
			draft-irtf-mobopts-ro-enhancements-08.txt (work in progress),
	[10] Vogt, C., "Credit-Based Authorization for Mobile IPv6 Early		May 2006.
	Binding Updates",
	draft-vogt-mipv6-credit-based-authorization-00 (work in
	progress), May 2004.
	[11] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in		[10] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in
	IPv6", Proceedings of the IEEE Wireless Communications and		IPv6", Proceedings of the IEEE Wireless Communications and
	Networking Conference, IEEE, April 2006.		Networking Conference, IEEE, April 2006.
	[12] Mirkovic, J. and P. Reiher, "A Taxonomy of DDoS Attack and DDoS		[11] Mirkovic, J. and P. Reiher, "A Taxonomy of DDoS Attack and DDoS
	Defense Mechanisms", ACM SIGCOMM Computer Communication Review,		Defense Mechanisms", ACM SIGCOMM Computer Communication Review,
	Vol. 34, No. 2, ACM Press, April 2004.		Vol. 34, No. 2, ACM Press, April 2004.
	[13] Vogt, C. and J. Arkko, "Taxonomy and Analysis of Enhancements		[12] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
	to Mobile IPv6 Route Optimization", IETF Internet Draft
	draft-irtf-mobopts-ro-enhancements-08.txt (work in progress),
	May 2006.
	[14] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
	Lifetime Extension",		Lifetime Extension",
	draft-arkko-mipv6-binding-lifetime-extension-00 (work in		draft-arkko-mipv6-binding-lifetime-extension-00 (work in
	progress), May 2004.		progress), May 2004.
	[15] O'Shea, G. and M. Roe, "Child-Proof Authentication for MIPv6		[13] O'Shea, G. and M. Roe, "Child-Proof Authentication for MIPv6
	(CAM)", ACM SIGCOMM Computer Communication Review, ACM Press,		(CAM)", ACM SIGCOMM Computer Communication Review, ACM Press,
	Vol. 31, No. 2, April 2001.		Vol. 31, No. 2, April 2001.
	[16] Nikander, P., "Denial-of-Service, Address Ownership, and Early		[14] Nikander, P., "Denial-of-Service, Address Ownership, and Early
	Authentication in the IPv6 World", Revised papers from the		Authentication in the IPv6 World", Revised papers from the
	International Workshop on Security Protocols, Springer-Verlag,		International Workshop on Security Protocols, Springer-Verlag,
	April 2002.		April 2002.
	[17] Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)",		[15] Aura, T., "Cryptographically Generated Addresses (CGA)",
			IETF Request for Comments 3972, March 2005.
			[16] Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)",
	draft-haddad-mipv6-omipv6-01 (work in progress), February 2004.		draft-haddad-mipv6-omipv6-01 (work in progress), February 2004.
			[17] Vogt, C., "Credit-Based Authorization for Mobile IPv6 Early
			Binding Updates",
			draft-vogt-mipv6-credit-based-authorization-00 (work in
			progress), May 2004.
	[18] Aura, T., "Cryptographically Generated Addresses (CGA)",		[18] Aura, T., "Cryptographically Generated Addresses (CGA)",
	draft-ietf-send-cga-06 (work in progress), April 2004.		draft-ietf-send-cga-06 (work in progress), April 2004.
	[19] Roe, M., "Authentication of Mobile IPv6 Binding Updates and		[19] Perkins, C., "Preconfigured Binding Management Keys for Mobile
			IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress),
			April 2004.
			[20] Roe, M., "Authentication of Mobile IPv6 Binding Updates and
	Acknowledgments", draft-roe-mobileip-updateauth-02 (work in		Acknowledgments", draft-roe-mobileip-updateauth-02 (work in
	progress), March 2002.		progress), March 2002.
	[20] Haddad, W., "Applying Cryptographically Generated Addresses to		[21] Haddad, W., "Applying Cryptographically Generated Addresses to
	Optimize MIPv6 (CGA-OMIPv6)", draft-haddad-mip6-cga-omipv6-04		Optimize MIPv6 (CGA-OMIPv6)", draft-haddad-mip6-cga-omipv6-04
	(work in progress), May 2005.		(work in progress), May 2005.
	[21] Vogt, C., "Early Binding Updates for Mobile IPv6",		[22] Vogt, C., "Early Binding Updates for Mobile IPv6",
	draft-vogt-mip6-early-binding-updates-00 (work in progress),		draft-vogt-mip6-early-binding-updates-00 (work in progress),
	February 2004.		February 2004.
	[22] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure		[23] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	[23] Nikander, P., "Mobile IP version 6 Route Optimization Security		[24] Nikander, P., "Mobile IP version 6 Route Optimization Security
	Design Background", draft-ietf-mip6-ro-sec-03 (work in		Design Background", draft-ietf-mip6-ro-sec-03 (work in
	progress), May 2005.		progress), May 2005.
	[24] Dupont, F. and J. Combes, "Using IPsec between Mobile and		[25] Dupont, F. and J. Combes, "Using IPsec between Mobile and
	Correspondent IPv6 Nodes", draft-dupont-mipv6-cn-ipsec-01 (work		Correspondent IPv6 Nodes", draft-dupont-mipv6-cn-ipsec-01 (work
	in progress), June 2004.		in progress), June 2004.
	[25] Perkins, C., "Preconfigured Binding Management Keys for Mobile
	IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress),
	April 2004.
	Authors' Addresses		Authors' Addresses
	Jari Arkko		Jari Arkko
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	FI-02420 Jorvas		FI-02420 Jorvas
	Finland		Finland
	Email: jari.arkko@ericsson.com		Email: jari.arkko@ericsson.com
	Christian Vogt		Christian Vogt
	skipping to change at page 29, line 25		skipping to change at page 39, line 24
	the real owner.		the real owner.
	CGA assures that the interface identifier part of the address is		CGA assures that the interface identifier part of the address is
	correct, but does little to ensure that the node is actually		correct, but does little to ensure that the node is actually
	reachable at that identifier and prefix. As a result, CGA needs to		reachable at that identifier and prefix. As a result, CGA needs to
	be employed together with a reachability test where redirection		be employed together with a reachability test where redirection
	denial-of-service attacks are a concern.		denial-of-service attacks are a concern.
	Each CGA is associated with a public key and auxiliary parameters.		Each CGA is associated with a public key and auxiliary parameters.
	In this protocol, the public key MUST be formatted as a DER-encoded		In this protocol, the public key MUST be formatted as a DER-encoded
	[4] ASN.1 structure of the type SubjectPublicKeyInfo defined in the		[3] ASN.1 structure of the type SubjectPublicKeyInfo defined in the
	Internet X.509 certificate profile [5].		Internet X.509 certificate profile [4].
	The CGA verification takes as input an IPv6 address and auxiliary		The CGA verification takes as input an IPv6 address and auxiliary
	parameters. These parameters are the following:		parameters. These parameters are the following:
	o a 128-bit modifier, which can be any value,		o a 128-bit modifier, which can be any value,
	o a 64-bit subnet prefix, which is equal to the subnet prefix of the		o a 64-bit subnet prefix, which is equal to the subnet prefix of the
	CGA,		CGA,
	o an 8-bit collision count, which can have values 0, 1 and 2.		o an 8-bit collision count, which can have values 0, 1 and 2.
	skipping to change at page 32, line 5		skipping to change at page 41, line 42
	verified |<-------------------------| don't change credit		verified |<-------------------------| don't change credit
	| |		| |
	Figure 10: Credit-Based Authorization		Figure 10: Credit-Based Authorization
	The correspondent node ensures that the mobile node's acquired credit		The correspondent node ensures that the mobile node's acquired credit
	gradually decrease over time. Such "credit aging" prevents a		gradually decrease over time. Such "credit aging" prevents a
	malicious node from building up credit at a very slow speed and using		malicious node from building up credit at a very slow speed and using
	this, all at once, for a severe burst of redirected packets.		this, all at once, for a severe burst of redirected packets.
			Appendix C. Change Log
			The following is a list of technical changes that were made from
			version 00 to version 01 of this document. Editorial revisions are
			not explicitly mentioned.
			o Revised Section 1 to reflect the comments from Vidya and
			Lakshminath. The text now makes it much clearer that there are
			two individual optimizations for home and care-of address
			verification.
			o Added Section 4.5 describing when the mobile node sends CGA
			parameters to the correspondent node and how the CGA Parameters
			and Signature options are used to accomplish this.
			o Added Section 4.6 describing the correspondent node's operation
			upon receiving a Binding Update message with included CGA
			Parameters and Signature options.
			o Added Section 4.7 describing how a correspondent node generates
			and encrypts a permanent home keygen token and sends the token in
			a Permanent Home Keygen Token option within a Binding
			Acknowledgment message to the mobile node.
			o Added Section 4.8 describing how a mobile node decrypts a
			permanent home keygen token received in a Binding Acknowledgment
			message with a Permanent Home Keygen Token option.
			o Removed Section "Renewing a Permanent Home Keygen Token" (formerly
			Section 4.7). The section described when the mobile node should
			renew an existing permanent home keygen token. This is now
			explained in Section 4.5.
			o Section 4.9 now also describes when mobile and correspondent nodes
			resume route-optimized payload transmission after handoff on the
			mobile node side.
			o Removed Section "Cryptographic Calculations" (formerly Section
			4.10). The section described how the signature in a Signature
			option and the contents of the former SKey option are calculated.
			The signature calculation is now described in Section 4.5. The
			SKey option was replaced by the Permanent Home Keygen Token
			option, and the contents of this are now described in Section 4.7.
			o Cleaned up section Section 5.
			o Replaced status code "Lost Kbmperm State" in Section 5.6 with a
			new status code, "Permanent Home Keygen Token Unavailable". Added
			a second status code "Conflicting Permanent Home Keygen Token".
			Section 4 ("Protocol Operation") and Section 9 ("IANA
			Considerations") were modified accordingly.
			o Revised Section 6 so that it now addresses the comments made by
			Vidya and Lakshminath. In particular, the text now explains why a
			care-of address test is required in spite of the more secure, CGA-
			based home address verification. The section also starts with an
			overview of the conceptual changes that the proposed protocol
			applies to RFC 3775.
			o Added Section 8 defining the CGA Message Type tag to be allocated
			for this protocol.
	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 Rights or other rights that might be claimed to		Intellectual Property Rights 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
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
End of changes. 119 change blocks.
	319 lines changed or deleted		869 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/