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

From: Sam Hartman <[email-masked]>
Date: Mon, 06 Nov 2006 19:55:01 -0500

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

Make absolutely sure that your document gets SPD and PAD entries right
in a manner consistent with RFC 4301 or one of the security ADs will
hold a discuss.

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

---

From: <[email-masked]>
Date: Tue, 7 Nov 2006 02:09:53 +0200

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 26 Nov 2006 14:59:05 -0800

hi Pasi,

thanks for the review.

I will create a separate issue for the PAD and
how the SPD entries are represented in this draft.
I will respond to the rest of your comments on
this email.

>    Prefix Solicitations". Is this a contradiction or just confusion?

the text in section 4.2 needs to be fixed.

    o  The mobile node MUST use the Home Address destination option in
       Binding Updates and Mobile Prefix Solicitations when transport
       mode IPsec protection is used, so that the home address is visible
       when the IPsec policy checks are made.
>    (e.g. for MLD or DHCPv6). 

agreed.

If this is the case, it might be a good
>    originating/terminating at the home address.

what if I just modify the last sentence of the above
paragraph? new text

    o  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 for protecting mobility header messages.

>    should be said explicitly.

this text was added to address some concerns that
not all IPsec implementations support all selectors.
this was true in 2401 case at least. don't know
about 4301 IPsec implementations. but we can add the
note.

    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.  Note that such IPsec
    implementations are not compliant to RFC 4301 [5].

>    part of IPsec processing as described in RFC 4301.

that is correct. however, this check is mandated by
RFC 3775. section 15.7 of RFC 3775

    When receiving
    tunneled traffic, the home agent verifies that the outer IP address
    corresponds to the current location of the mobile node.  This acts as
    a weak form of protection against spoofing packets that appear to
    come from the mobile node.  This is particularly useful, if no end-
    to-end security is being applied between the mobile and correspondent
    nodes.  The outer IP address check prevents attacks where the
    attacker is controlled by ingress filtering.

>    against using the INTERNAL_ADDRESS_EXPIRY attribute.

Tero also had this comment. I agree the
INTERNAL_ADDRESS_EXPIRY does not make sense in IKEv2
context. this is what I had written in response to
Tero's comment.

if we tie the home address lifetime to the IKE SA
lifetime, then I am afraid that home address
assignment through IKEv2 is not going to be popular.
folks would use other mechanisms to assign the home
address to the mobile node. a Mobile IP home address
by definition is supposed to be a long lived address
that does not change very often.

if there is no restriction that the lifetime in
INTERNAL_ADDRESS_EXPIRY attribute should always be
less than the IKEv2 SA lifetime, perhaps MIPv6 could
use the INTERNAL_ADDRESS_EXPIRY attribute. maybe we
have found a use for the attribute. ;)

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Nov 2006 07:54:55 -0800

[email-masked] wrote:
> Vijay Devarapalli wrote:
>>>    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). 
>> agreed.
>>
>>        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 for protecting mobility 
>>        header messages.
> 
> I don't think the average reader can infer from this text that 
> payload packet protection will not work the same way without 
> per-virtual-interface SPDs... so IMHO it would be worthwhile to
> say so explicitly: something along the lines "Without per-interface
> security policies, payload packet protection is limited to
> packets originating/terminating at the home address, and 
> e.g. link-local traffic is not supported".

ok. here is the new text.

    o  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 for protecting mobility header messages.  Note that
       without per-interface security policies. payload packet protection
       is limited to packets originating/terminating at the home address.
       Traffic using link local address within the Mobile IP tunnel
       cannot be provided IPsec protection without per-interface security
       policies.

>> Tero also had this comment. I agree the INTERNAL_ADDRESS_EXPIRY does
>> not make sense in IKEv2 context. this is what I had written in
>> response to Tero's comment.
>>
>> if we tie the home address lifetime to the IKE SA lifetime, then I
>> am afraid that home address assignment through IKEv2 is not going to
>> be popular.  folks would use other mechanisms to assign the home
>> address to the mobile node. a Mobile IP home address by definition
>> is supposed to be a long lived address that does not change very
>> often.
> 
> Nothing prevents us from keeping the same home address through several
> IKE_SAs: when the client connects again, it can request the same
> home address it had previously. In other words: the lifetime
> is not a single IKE_SA, but at home agents discreption, through
> all IKE_SAs between the MN and home agent,.
> 
>> INTERNAL_ADDRESS_EXPIRY attribute should always be less than the
>> IKEv2 SA lifetime, perhaps MIPv6 could use the
>> INTERNAL_ADDRESS_EXPIRY attribute. maybe we have found a use for the
>> attribute. ;)
> 
> Such a restriction does exist: RFC4306 says that "the requested
> address is valid until the expiry time defined with the
> INTERNAL_ADDRESS EXPIRY attribute or there are no IKE_SAs between the
> peers." So even if INTERNAL_ADDRESS_EXPIRY value is very large, the
> address is not valid after all the IKE_SAs are gone (it can become
> again valid when new IKE_SA is established, though).

ok. removed the INTERNAL_ADDRESS_EXPIRY attribute.
the new text would be

    When the home agent receives a configuration payload with a
    CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home
    address for the mobile node.  The INTERNAL_IP6_ADDRESS attribute in
    the CFG_REPLY contains the prefix length of the home prefix in
    addition to a 128 bit home address.  The home agent could use a local
    database or contact a DHCPv6 server on the home link to allocate a
    home address.  The duration for which the home address is allocated
    to the mobile node is the same as the IKEv2 security association
    lifetime.

there is text already in the following paragraph
to say that the mobile node can request the same
home address again.

    The mobile node could suggest a home address that it wants to use in
    the CFG_REQUEST.  For example, this could be a home address that it
    was allocated before or could be an address the mobile node auto-
    configured from the IPv6 prefix on the home link.  The Home Agent
    could let the mobile node use the same home address by setting the
    INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same
    home address.

Vijay

---

From: <[email-masked]>
Date: Mon, 27 Nov 2006 10:31:17 +0200

<snip>

Best regards,
Pasi