Subject: [Mip6] [issue88] Security Directorate (Pasi Eronen) reivew

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 25 Nov 2006 20:48:17 +0000

New submission from Vijay Devarapalli <[email-masked]>:

Some comments about draft-ietf-mip6-ikev2-ipsec-07:

1) Section 4 says "The home agent MAY use the Peer Authorization
   Database (PAD) [5] to store per-mobile node state."

   In RFC4301 the PAD is not some optional component of IPsec that may
   or may not be used; it is always present and always used (although
   in some cases it might not contain per-MN state).

2) Section 3 says "In case the mobile node reverse tunnels all traffic
   including Mobile IPv6 signaling messages exchanged between the
   mobile node and the home agent, then the Home Address Option is not
   required to be present in the messages sent to the home agent."
   (and continues to give an example of Binding Update without Home
   Address Option), but Section 4.2 says "The mobile node MUST use the
   Home Address destination option in Binding Updates and Mobile
   Prefix Solicitations". Is this a contradiction or just confusion?

3) Section 4.2 says "RFC 3776 required configuration of the security
   policies per interface in order to be able to differentiate between
   mobility header messages sent to the home agent and tunneled
   through the home agent to the correspondent node.  Since the
   Mobility Header message type is a selector, it is now easy to
   differentiate between HoTi and HoT messages from other mobility
   header messages.  Therefore per-interface configuration of security
   policies is not required."

   This is only partially true. RFC 3776 like virtual interfaces would
   probably still be required if link-layer addresses are used
   (e.g. for MLD or DHCPv6). If this is the case, it might be a good
   idea to explicitly mention that the mechanisms described in this
   document support payload data protection only for traffic
   originating/terminating at the home address.

4) Section 4.3, "The home agent and mobile node SHOULD support
   Mobility Header message type as an IPsec selector." and "The home
   agent and mobile node SHOULD support ICMPv6 message type as an
   IPsec selector."  If an implementation doesn't support them, it's
   not RFC4301 compliant anyway.

   Similarly, Section 5 says "IPsec implementations are compatible
   with this document even if they do not support fine grain selectors
   such as the Mobility Header message type and ICMPv6 message type."
   However, such implementations are not compliant with RFC4301; this
   should be said explicitly.

5) Section 4.3, "Similarly, the home agent starts to expect the new
   source address in the tunnel packets received from the mobile
   node."

   An RFC4301 IPsec implementation does not use the outer source
   address in tunnel mode packets for anything, so it doesn't "expect"
   anything. Similarly, Section 5 says "Typical IPsec processing does
   not check the outer source address.". More correctly, this is not
   part of IPsec processing as described in RFC 4301.

6) Section 7.1: These SPD entries do not follow anything in RFC4301;
   instead, they mix information that would be present in PAD as well.
   This section should also definitely consider PAD, as it is the 
   part of RFC4301 that prevents one MN for creating SAs for another 
   MN's home address.

7) Section 9: "The Home Agent should also include an
   INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node,
   the duration for which the dynamically allocated home address is
   valid." In RFC 4718 (IKEv2 clarifications) we strongly recommend 
   against using the INTERNAL_ADDRESS_EXPIRY attribute.

(Note: I'm not subscribed to the MIP6 list, so keep in in Cc line
of any replies  :-) 

Best regards,
Pasi

----------
category: Technical
draft: draft-ietf-mip6-ikev2-ipsec
messages: 284
nosy: vijay
priority: Must fix
status: Pending
title: Security Directorate (Pasi Eronen) reivew

_________________________________________________
Mip6 issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mip6/issue88>
_________________________________________________

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6