draft-ietf-mobileip-ipv6-pre22.txt		draft-ietf-mobileip-ipv6-pre22russ.txt
Skipping to change at page 10, line 22:
A link-layer identifier for an interface, such as IEEE 802		A link-layer identifier for an interface, such as IEEE 802
addresses on Ethernet links.		addresses on Ethernet links.
packet		packet
An IP header plus payload.		An IP header plus payload.
security association		security association
An IPsec security association is a simplex "connection" that		An IPsec security association is a cooperative relationship formed
affords security services to the traffic carried by it. Security		by the sharing of cryptographic keying material and associated
services are afforded to a security association by the use of the		context. Security associations are simplex. That is, two
AH and ESP protocols.		security associations are needed to protect bidirectional traffic
		between two nodes, one for each direction.
security policy database		security policy database
A database that specifies what security services are to be offered		A database that specifies what security services are to be offered
to IP packets and in what fashion.		to IP packets and in what fashion.
destination option		destination option
Destination options are carried by the IPv6 Destination Options		Destination options are carried by the IPv6 Destination Options
extension header. Destination options include optional		extension header. Destination options include optional
Skipping to change at page 20, line 27:
protected through the use of IPsec extension headers. Mechanisms		protected through the use of IPsec extension headers. Mechanisms
related to transporting payload packets - such as the Home Address		related to transporting payload packets - such as the Home Address
destination option and type 2 routing header - have been specified in		destination option and type 2 routing header - have been specified in
a manner which restricts their use in attacks.		a manner which restricts their use in attacks.
5.1 Binding Updates to Home Agents		5.1 Binding Updates to Home Agents
The mobile node and the home agent MUST use an IPsec security		The mobile node and the home agent MUST use an IPsec security
association to protect the integrity and authenticity of the Binding		association to protect the integrity and authenticity of the Binding
Updates and Acknowledgements. Both the mobile nodes and the home		Updates and Acknowledgements. Both the mobile nodes and the home
agents SHOULD use the Encapsulating Security Payload (ESP) [6] header		agents MUST support and SHOULD use the Encapsulating Security Payload
in transport mode and MUST use a non-NULL payload authentication		(ESP) [6] header in transport mode and MUST use a non-NULL payload
algorithm to provide data origin authentication, connectionless		authentication algorithm to provide data origin authentication,
integrity and optional anti-replay protection. Note that		connectionless integrity and optional anti-replay protection. Note
Authentication Header (AH) [5] is also possible but for brevity not		that Authentication Header (AH) [5] is also possible but for brevity
discussed in this specification.		not discussed in this specification.
In order to protect messages exchanged between the mobile node and		In order to protect messages exchanged between the mobile node and
the home agent with IPsec, appropriate security policy database		the home agent with IPsec, appropriate security policy database
entries must be created. A mobile node must be prevented from using		entries must be created. A mobile node must be prevented from using
its security association to send a Binding Update on behalf of		its security association to send a Binding Update on behalf of
another mobile node using the same home agent. This MUST be achieved		another mobile node using the same home agent. This MUST be achieved
by having the home agent check that the given home address has been		by having the home agent check that the given home address has been
used with the right security association. Such a check is provided		used with the right security association. Such a check is provided
in the IPsec processing, by having the security policy database		in the IPsec processing, by having the security policy database
entries unequivocally identify a single security association for		entries unequivocally identify a single security association for
Skipping to change at page 21, line 14:
and MUST be distributed off-line to the mobile nodes.		and MUST be distributed off-line to the mobile nodes.
Automatic key management with IKE [9] MAY be supported. When IKE is		Automatic key management with IKE [9] MAY be supported. When IKE is
used, either the security policy database entries or the MIPv6		used, either the security policy database entries or the MIPv6
processing MUST unequivocally identify the IKE phase 1 credentials		processing MUST unequivocally identify the IKE phase 1 credentials
which can be used to authorize the creation of security associations		which can be used to authorize the creation of security associations
for protecting Binding Updates for a particular home address. How		for protecting Binding Updates for a particular home address. How
these mappings are maintained is outside the scope of this		these mappings are maintained is outside the scope of this
specification, but they may be maintained, for instance, as a locally		specification, but they may be maintained, for instance, as a locally
administered table in the home agent. If the phase 1 identity is a		administered table in the home agent. If the phase 1 identity is a
FQDN, secure forms of DNS may also be used.		Fully Qualified Domain Name (FQDN), secure forms of DNS may also be
		used.
Section 11.3.2 discusses how IKE connections to the home agent need a		Section 11.3.2 discusses how IKE connections to the home agent need a
careful treatment of the addresses used for transporting IKE. This		careful treatment of the addresses used for transporting IKE. This
is necessary to ensure that a Binding Update is not needed before the		is necessary to ensure that a Binding Update is not needed before the
IKE exchange which is needed for securing the Binding Update.		IKE exchange which is needed for securing the Binding Update.
When IKE version 1 is used with preshared secret authentication		When IKE version 1 is used with preshared secret authentication
between the mobile node and the home agent, aggressive mode MUST be		between the mobile node and the home agent, aggressive mode MUST be
used. Similarly, the ID_IPV6_ADDR Identity Payload MUST NOT be used		used. Similarly, the ID_IPV6_ADDR Identity Payload MUST NOT be used
in IKEv1 phase 1.		in IKEv1 phase 1.
Skipping to change at page 31, line 32:
5.3 Dynamic Home Agent Address Discovery		5.3 Dynamic Home Agent Address Discovery
No security is required for dynamic home agent address discovery.		No security is required for dynamic home agent address discovery.
5.4 Prefix Discovery		5.4 Prefix Discovery
The mobile node and the home agent SHOULD use an IPsec security		The mobile node and the home agent SHOULD use an IPsec security
association to protect the integrity and authenticity of the Mobile		association to protect the integrity and authenticity of the Mobile
Prefix Solicitations and Advertisements. Both the mobile nodes and		Prefix Solicitations and Advertisements. Both the mobile nodes and
the home agents SHOULD use the Encapsulating Security Payload (ESP)		the home agents MUST support and SHOULD use the Encapsulating
header in transport mode with a non-NULL payload authentication		Security Payload (ESP) header in transport mode with a non-NULL
algorithm to provide data origin authentication, connectionless		payload authentication algorithm to provide data origin
integrity and optional anti-replay protection.		authentication, connectionless integrity and optional anti-replay
		protection.
5.5 Payload Packets		5.5 Payload Packets
Payload packets exchanged with mobile nodes can be protected in the		Payload packets exchanged with mobile nodes can be protected in the
usual manner, in the same way as stationary hosts can protect them.		usual manner, in the same way as stationary hosts can protect them.
However, Mobile IPv6 introduces the Home Address destination option,		However, Mobile IPv6 introduces the Home Address destination option,
a routing header, and tunneling headers in the payload packets. In		a routing header, and tunneling headers in the payload packets. In
the following we define the security measures taken to protect these,		the following we define the security measures taken to protect these,
and to prevent their use in attacks against other parties.		and to prevent their use in attacks against other parties.
Skipping to change at page 147, line 34:
limits the introduction of new addresses without either manual or		limits the introduction of new addresses without either manual or
automatic procedures to establish new certificates. Therefore, this		automatic procedures to establish new certificates. Therefore, this
specification restricts the generation of new home addresses (for any		specification restricts the generation of new home addresses (for any
reason) to those situations where there already exists a security		reason) to those situations where there already exists a security
association or certificate for the new address. (Appendix B.4 lists		association or certificate for the new address. (Appendix B.4 lists
the improvement of security for new addresses as one of the future		the improvement of security for new addresses as one of the future
developments for Mobile IPv6.)		developments for Mobile IPv6.)
15.4 Binding Updates to Correspondent Nodes		15.4 Binding Updates to Correspondent Nodes
15.4.1 Overview
The motivation for designing the return routability procedure was to		The motivation for designing the return routability procedure was to
have sufficient support for Mobile IPv6, without creating significant		have sufficient support for Mobile IPv6, without creating significant
new security problems. The goal for this procedure was not to		new security problems. The goal for this procedure was not to
protect against attacks that were already possible before the		protect against attacks that were already possible before the
introduction of Mobile IPv6.		introduction of Mobile IPv6.
		The next sections will describe the security properties of the used
		method, both from the point of view of possible on-path attackers who
		can see those cryptographic values that have been sent in the clear
		(Section 15.4.2 and Section 15.4.3) or from the point of view of
		other attackers (Section 15.4.6).
		15.4.1 Overview
The chosen infrastructureless method verifies that the mobile node is		The chosen infrastructureless method verifies that the mobile node is
"live" (that is, it responds to probes) at its home and care-of		"live" (that is, it responds to probes) at its home and care-of
addresses. Section 5.2 describes the return routability procedure in		addresses. Section 5.2 describes the return routability procedure in
detail. The procedure uses the following principles:		detail. The procedure uses the following principles:
o A message exchange verifies that the mobile node is reachable at		o A message exchange verifies that the mobile node is reachable at
its addresses i.e. is at least able to transmit and receive		its addresses i.e. is at least able to transmit and receive
traffic at both the home and care-of addresses.		traffic at both the home and care-of addresses.
o The eventual Binding Update is cryptographically bound to the		o The eventual Binding Update is cryptographically bound to the
Skipping to change at page 152, line 21:
to send to a peer. An implementation of this specification is not		to send to a peer. An implementation of this specification is not
required to make use of information from higher protocol layers, but		required to make use of information from higher protocol layers, but
some implementations are likely to be able to manage resources more		some implementations are likely to be able to manage resources more
effectively by making use of such information.		effectively by making use of such information.
We also require that all implementations be capable of		We also require that all implementations be capable of
administratively disabling route optimization.		administratively disabling route optimization.
15.4.6 Key Lengths		15.4.6 Key Lengths
		Attackers can try to break the return routability procedure in many
		ways. Section 15.4.2 discusses the situation where the attacker can
		see the cryptographic values sent in the clear, and Section 15.4.3
		discusses the impact this has on IPv6 communications. This section
		discusses whether attackers can guess the right values without seeing
		them.
While the return routability procedure is in progress, 64 bit cookies		While the return routability procedure is in progress, 64 bit cookies
are used to protect spoofed responses. This is believed to be		are used to protect spoofed responses. This is believed to be
sufficient, given that to blindly spoof a response a very large		sufficient, given that to blindly spoof a response a very large
number of messages would have to be sent before success would be		number of messages would have to be sent before success would be
probable.		probable.
The tokens used in the return routability procedure provide together		The tokens used in the return routability procedure provide together
128 bits of information. This information is used internally as an		128 bits of information. This information is used internally as an
input to a hash function to produce a 160 bit quantity suitable for		input to a hash function to produce a 160 bit quantity suitable for
producing the keyed hash in the Binding Update using the HMAC_SHA1		producing the keyed hash in the Binding Update using the HMAC_SHA1