Subject: Re: [Mip6] Last call comments for draft-ietf-mip6-ikev2-ipsec-07

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Dec 2006 20:58:13 +0100

In your previous mail you wrote:

   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).
   
=> as your parenthesis suggests there can be another place to put
this state (BTW in IKEv1 this state was needed and there was no PAD :-).

   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?
   
=> partial quote: "when transport mode" (BTW please signal any missing
context, I can't find one in 4.2 but nobody is perfect...).

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

=> the link-local case is cited at the top of page 6.

      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.
   
=> I agree but it has been already done. 

   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.
   
=> I can't see where RFC 4301 makes fine granulary selectors mandatory
(even I like them and I don't believe we shan't get them in the context
of MN/HA).

      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.
   
=> it is at the end of page 9.

   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.
   
=> it is in RFC 3775 so I've proposed to explain why the check is not needed
(I was talking about the proper wording with Vijay some minutes ago).

   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.
   
=> I let Vijay answer about his SPD format.

   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.
   
=> fixed
   
   (Note: I'm not subscribed to the MIP6 list, so keep in in Cc line
   of any replies :-)
   
=> now I understand why you have missed all the recent fixes...
Please look at the pre version 8 at:
http://dvijay.com/ietf/internet-drafts/mip6/mip6_ikev2.txt

Thanks

[email-masked]

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Dec 2006 21:02:17 +0100

Oops, I replied to an old message... Of course, it is about things
which have been fixed (at least I expect!).