Comments on draft-ietf-mobileip-mipv6-ha-ipsec-04.txt

[Bernard Aboba <aboba@internaut.com>]

Section 3.2

Presumably the CoA is required as the Source Address for the HOTI message
with no Home Address Option (HAO) since if HOTI/HOT is sent after
movement, no binding cache entry exists binding the CoA to the HoA.
However, it also seems possible for the HOTI/HOT messsage to be sent
*before* movement (this gets HOTI/HOT out of the critical path), in which
case a valid binding cache entry might exist. Is there another reason that the HAO is
precluded? I mention this because it appears that the RR messages are the only
ones in Section 3 that do not include a HAO or RH Type 2.

In Section 7 it says:

"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".

Would it be possible to add some text clarifying this?

Section 3.2

"The home agent accepts packets sent like this, as the outer source
address in tunnel packets is not checked".

You might cite Section 5.1.2.1 of RFC 2401:

"NOTE: In principle, the encapsulating IP source address can
be any of the encapsulator's interface addresses or even an
address different from any of the encapsulator's IP
addresses, (e.g., if it's acting as a NAT box) so long as the
address is reachable through the encapsulator from the
environment into which the packet is sent.  This does not
cause a problem because IPsec does not currently have any
INBOUND processing requirement that involves the Source
Address of the encapsulating IP header.  So while the
receiving tunnel endpoint looks at the Destination Address in
the encapsulating IP header, it only looks at the Source
Address in the inner (encapsulated) IP header."

Steve Kent describes some of the security issues arising from this in the
following post:

[AuthSource]
          Kent, S., "Authenticated Source Addresses", IPsec WG Archive (
          ftp://ftp.ans.net/pub/archive/IPsec ), Message-Id:
          <v02130517ad121773c8ed@[128.89.0.110]>, January 5, 1996.

Section 4.2

"When IPsec is used to protect return routability signaling or payload
packets, the security policy database entries SHOULD be defined
specifically for the tunnel interface between the mobile node and the
home agent. That is, the policy entries are not generally applied on
all traffic on the physical interface of the nodes but rather only
on the traffic that enters this tunnel."

Maybe I'm not understanding what you mean here, but this looks to me like
special case IPsec processing. My understanding is that the processing
described above is somewhat more akin to what occurs with transport mode
IP-IP encapsulation than with tunnel mode. See the following draft for more details:

http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-04.txt

Note also that in various places in the document, tunnel mode is required
in preference to transport mode IP-IP, even where manual keying is used.
Since the two are identical on the wire (the difference is in how they are
negotiated within IKE), I am not sure how such a preference can be
enforced.

Section 4.2

"In order to do this, the security policy database entries MUST
unequivocally identify a single security association for any given home
address and home agent when manual keying is used."

This seems to contradict Section 5, which seems to imply that multiple SAs
will exist between the MN and HA. Can you clarify?

Section 4.3

"Tunnel mode IPsec ESP MUST be supported and SHOULD be used for protection
of packets belong to the return routability procedure"

Since this is only a SHOULD, is there an alternative? Does it matter
whether dynamic or manual keying is used?

Section 4.4

"Therefore if preshared secret authentication is used in IKEv1 between the
mobile node and the home agent then aggressive mode MUST be used."

This says that it is not possible to use IKEv1 Main Mode with pre-shared
keys alongside MIPv6. This by itself is not all that surprising since the
difficulties with use of Main Mode/pre-shared keys along with dynamic IP
addresses are well known. But what is unique here is that the difficulties
occur even when the home address is static. That is, SAs such as the
tunnel mode RR SA are set up from the CoA, which is dynamic, without an HAO.
This means that even if the HoA is static, that IKE MM cannot be
used with pre-shared keys. The problem is fixed in IKEv2, but since some
implementors will no doubt try to integrate IKEv1 with MIPv6, some
additional explanation is required in places, I think. At a minimum, I'd
like to understand why the HOTI/HOT messages can't have an HAO even if
HOTI/HOT is done prior to movement.

Section 4.4

"Conversely, the IPsec security associations with the mobile node's home
agent MUST be requested from the key management protocol with the home
address as the mobile node's address."

One could read this as contradicting the previous paragraph. What I think
you mean here is that IDci = HoA in Quick Mode.