[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-mobileip-mipv6-ha-ipsec-04.txt
Here's an initial text proposal to address the
issues raised by Bernard:
1. Care-of address source vs. use of HAO. Here I added first a new
paragraph to Section 3.2:
"Note that there are tradeoffs in using care-of addresses as the
gateway addresses versus using the home address and attaching an
additional Home Address destination option and/or Routing header
to the packets. The basis for requiring support for at least the
care-of address case has been discussed in Section 7."
And then in Section 7 the first paragraph has been expanded into
the following text:
"We have chosen to require an encapsulation format for return
routability and payload packet protection which can only be
realized if the destination of the IPsec packets sent from the
home agent can be changed as the mobile node moves. One of the
main reasons for choosing such a format is that it removes the
overhead of twenty four bytes when a home address option or
routing header is added to the tunneled packet. Such an overhead
would not be significant for the protection of the return
routability packets, but would create an additional overhead if
IPsec is used to protect the tunneling of payload packets to the
home agent. This overhead may be significant for real-time
traffic. Given that the use of the shorter packet formats for
any traffic requires the existence of suitable APIs, we have
chosen to use the shorter packet formats also for the protection
of the return routability packets. (Note that packet formats
and header ordering discussed in Section 3 must be supported,
but implementations may also support other formats. Some
implementations may therefore also support the protection of
payload packets using the home address as the gateway address.)
In order to support the care-of address as the gateway address
on the mobile node side, the home agent must act as if the
gateway address of a security association to the mobile node
would have changed upon movements. Implementations are free to
choose any particular method to make this change, such as using
an API to the IPsec implementation to change the parameters of
the security association, removing the security association and
installing a new one, or modification of the packet after it has
gone through IPsec processing. The only requirement is that
after registering a new binding at the home agent, the next
IPsec packets sent on this security association will be
addressed to the new care-of address."
2. The API and where it should be used. Here I added the following
text to the end of Section 4.3:
"Such gateway address changes can be implemented, for instance,
through an API from the Mobile IPv6 implementation to the IPsec
implementation. It should be noted that the use of such an API
and the gateway address changes MUST only be done based on the
Binding Updates received by the home agent and protected by the
use of IPsec. Address modifications based on other sources, such
as Binding Updates to the correspondent nodes protected by
return routability, or open access to an API from any
application may result in security vulnerabilities."
3. Tunnel source address discussion. I added the following to
Section 3.2:
"For a discussion of the role of source addresses in outer tunnel
headers, see Section 5.1.2.1 of [RFC 2401]. Note also that the
home agent requires the packets to be authenticated regardless
of the source address change, hence the "new" sender must
possess the same keys for the security association as the it had
in the previous location. This proves that the sender is the
same entity, regardless of the changes in the addresses."
4. Section 4.2 and single vs. multiple SAs and the "unequivocal"
requirement. I simply added "to protect the Binding Updates"
in the following text:
"In order to do this, the security policy database entries MUST
unequivocally identify a single security association for
protecting Binding Updates between any given home address and
home agent when manual keying is used. When dynamic keying is
used, the security policy database entries MUST unequivocally
identify the IKE phase 1 credentials which can be used to
authorize the creation of security associations for protecting
Binding Updates for a particular home address."
5. The SHOULD for RR tunnel mode protection and whether there's an
alternative. I added the following note to Section 1:
"Note that where this document indicates a feature MUST be
supported and SHOULD be used, this implies that all
implementations must be capable of using the specified feature,
but there may be cases where, for instance, a configuration
option disables to use of the feature in a particular
situation."
6. Main-mode preshared secret IKEv1 difficulties even when the
home address is static. I added this to Section 4.4:
"Note that the difficulties with main mode and preshared secrets
in IKE version 1 are well known for dynamic addresses. With
static addresses, there has not been a problem. With Mobile
IPv6, however, the use of the care-of addresses to run IKE
towards the home agent presents a problem even when the home
address stays stable."
7. Section 4.4 and IDci = HoA in Quick Mode. Here I reformulated
the text to the following:
"However, the IPsec security associations with the mobile node's
home agent use home addresses. That is, the IPsec security
associations MUST be requested from the key management protocol
using the home address of the mobile node as the client
identity."
8. IP-in-IP vs. tunnel mode. Still working on this.
These changes are also on the web at
http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.txt
http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.html
http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsecdiff.html
Bernard's comments have been filed as issue #284 at
http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html
Jari