[Mip6] Re: AD review of draft-ietf-mip6-ikev2-ipsec

[Jari Arkko <[e-mail]>]

Vijay Devarapalli wrote:
>>
>>  >    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.  The packet format
>>  >    for the binding update when sent in the tunnel mode looks as
>> follows.
>>
>> ...
>>
>>  >    o  ESP encapsulation for Binding Updates and Binding
>> Acknowledgements
>>  >       MUST be supported and used.
>>
>>  >    o  When securing Binding Updates, Binding Acknowledgements, and
>>  >       prefix discovery, both the mobile nodes and the home agents
>> MUST
>>  >       support and SHOULD use the Encapsulating Security Payload (ESP)
>>  >       [6] header in transport mode and MUST use a non-null payload
>>  >       authentication algorithm to provide data origin authentication,
>>  >       connectionless integrity and optional anti-replay protection.
>>
>> The latter requirements are copied from RFC 3776 but they do not seem
>> to say anything about the new, alternate, tunnel mode BU encapsulation.
>> Please specify whether the new encapsulation is a MUST/MAY implement
>> or not.
>
> modified the above paragraph to
>
>    o  When securing Binding Updates, Binding Acknowledgements, and
>       Mobile Prefix Discovery messages, both the mobile node and the
>       home agent MUST support the use of Encapsulating Security Payload
>       (ESP) [6] header in transport mode and MUST use a non-null payload
>       authentication algorithm to provide data origin authentication,
>       connectionless integrity and optional anti-replay protection.
>       Support for protecting these messages using ESP in tunnel mode is
>       optional.
Ok.
>>
>>  >       With dynamic keying, it
>>  >       should be possible for the home agent to verify that the
>> identity
>>  >       presented in the IKE_AUTH exchange is allowed to create
>> security
>>  >       associations for a particular home address.
>>
>> This is weaker than I would like it to be. This check is not optional.
>> Say "... the home agent MUST ..." or something to that effect.
>
> changed it to
>
>       With dynamic keying, the
>       home agent MUST be able to verify that the identity presented in
>       the IKE_AUTH exchange is allowed to create security associations
>       for a particular home address.
Ok.
>>
>>  >    o  The home agent and mobile node SHOULD support Mobility Header
>>  >       message type as an IPsec selector.
>>  >
>>  >    o  The home agent and mobile node SHOULD support ICMPv6 message
>> type
>>  >       as an IPsec selector.
>>
>>  > 5.  Selector Granularity Considerations
>>  >
>>  >    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.
>>
>> For this spec it would seem that a MUST requirement for the
>> finer granularity would be better. This would also reduce
>> the number of variant configuration styles that implementations
>> must support, reduce configuration related problems, and
>> enhance interoperability.
>>
>> I am quite concerned about interoperability in the mobility
>> space. We have multiple protocols, they have multiple
>> ways to set up security, multiple operation modes, different
>> configuration options, etc. One of the main reasons we
>> work in organizations like the IETF is that we agree on
>> a standard way to do things (see also RFC 1958).
>>
>> I can see situations where we have to have options and
>> alternate ways. But for that we need a very good reason.
>> Is there such a reason for this? For instance, do we have
>> implementors who have stated they have a problem with
>> the granularity?
>
> this was discussed extensively on the mailing list. version
> 02 of this draft had a MUST against mobility header as a
> selector. see
> http://tools.ietf.org/wg/mip6/draft-ietf-mip6-ikev2-ipsec/draft-ietf-mip6-ikev2-ipsec-02.txt
>
>
> Francis and (I don't remember who else) objected to this.
> it was changed to SHOULD in version 03.

>
>>  >    In the examples shown above, the home address of the mobile node
>>  >    might not be available all the time.  For instance, the mobile
>> node
>>  >    might have not configured a home address yet.  When the mobile
>> node
>>  >    acquires a new home address, it must either add the address to the
>>  >    corresponding SPD entries or create the SPD entries for the home
>>  >    address.
>>
>> Has this procedure been reviewed by IKEv2 experts?
>
> this is not different from regular IPsec VPN process.
> the client acquires an IPsec remote IP address only after
> the configuration payload is received in the last IKE_AUTH
> message. any SPD entry that affects the traffic sent using
> the IPsec remote IP address must be modified after the IPsec
> remote IP address is configured, correct? I didn't see text
> in RFC 4306 which addresses this. I could have missed it....
Ok. I guess we will get additional secdir review for this
anyway.
>>
>>  >    A possible mechanism used for
>>  >    mutual authentication is a shared secret between the mobile
>> node and
>>  >    the home agent.  The home agent uses the identity of the mobile
>> node
>>  >    to identify the corresponding shared secret.  When a public key
>> based
>>  >    mechanism is available, it should be the preferred mechanism for
>>  >    mutual authentication: private keys are used to generate the AUTH
>>  >    payload and identities are verified with certificate information
>>  >    transmitted by CERT payloads.
>>
>> This text fragment has several issues:
>>
>> 1) I am not sure why we are making recommendations about the
>>     mechanism used.
>> 2) Using the identity to identify a shared secret: if this is the usual
>>     IKEv2 procedure, then maybe it is not worth repeating here. If
>>     it is something else, please clarify.
>> 3) Why are we explaining some (but not all) details of the
>>     public key authentication process in IKEv2? The same
>>     issue continues further down in the next paragraph.
>
> IMHO, we should have some text on how the MN is actually
> authenticated by the HA. thats what the 2nd paragraph in
> section 7.2 trying to do. we could refer to RFC 4306 for
> more details at the end of the paragraph.
My issue was precisely the part about "some text".
It is not clear why some details but not all is chosen.
You can explain the high level things as an introductory
explanation, though.
>>  >    The mobile node should always include its identity in the IDi
>> payload
>>  >    in the IKE_AUTH exchange.  The mobile node could use the following
>>  >    different types of identities to identity itself to the home
>> agent.
>>  >
>>  >    o  Home Address - The mobile node could use its statically
>> configured
>>  >       home address as its identity.  In this case the ID Type
>> field is
>>  >       set to ID_IPV6_ADDR.
>>  >    o  FQDN - The mobile node can use a Fully Qualified Domain Name as
>>  >       the identifier and set the ID Type field to ID_FQDN.
>>  >    o  RFC 822 identifier - If the mobile node uses a RFC 822
>> identifier
>>  >       [9], it sets the ID Type field to ID_RFC822_ADDR.
>>
>> It is good that you list the specific identities that devices
>> conformant to this spec need to employ. However, it
>> seems that you are missing one case. When EAP is used
>> within IKEv2, it is possible that the identity provided in the
>> IDi payload is not the final, true identity. See Sections 3.4
>> and 3.5 in draft-eronen-ipsec-ikev2-clarifications-09.txt.
>> I wouldn't bring this up otherwise but I think EAP usage
>> in this application is likely.
>
> good point. we can fix this by adding one sentence at the
> end of above paragraph.
>
>        The above list of identities is not exhaustive.
>
> and in section 8 that talks about the use of EAP, add the
> following.
>
>    When EAP is used, the identity presented by the mobile node in the
>    IDi field may not be the actual identity of the mobile node.  It
>    could be set to an identity that is used only for AAA routing
>    purposes and selecting the right EAP method.  The actual identity is
>    carried inside EAP payloads that is not visible to the home agent.
>    The home agent MUST acquire the mobile node's identity from the
>    corresponding AAA server.  More details can be found in [13].
>
>    [13]  Hoffman, P. and P. Eronen, "IKEv2 Clarifications and
>          Implementation Guidelines",
>          draft-eronen-ipsec-ikev2-clarifications-09 (work in progress),
>          May 2006.
Ok.
>>
>>  >    If the mobile node or the home agent does
>>  >    not support this capability, then an IKEv2 exchange MUST be
>> initiated
>>  >    to re-establish a new IKE SA.
>>
>> This seems too strict. If the K bit functionality is not there,
>> it is still possible that the peers happen to support MOBIKE.
>> The MUST prevents using it. I would phrase this as "If the
>> mobile node or the home agent does not support this capability
>> and has no other means to update the addresses (such as
>> MOBIKE [ref]), then a new IKEv2 exchange MUST be initiated
>> to re-establish another IKE SA."
>
> see http://www.mip4.org/issues/tracker/mip6/issue68. I don't
> believe MOBIKE and MIP6 can be run between the same end
> points simultaneously.
>
> how about
>
>    If the mobile node or the home agent does
>    not support this capability, and has no other means to update the
>    addresses, then an IKEv2 exchange MUST be initiated to re-establish a
>    new IKE SA.
My text but no reference? Ok.
>> > 9.  Dynamic Home Address Configuration
>>
>> This section does not say anything about the use of multiple
>> home addresses for the same mobile node. 
>
> from the same home agent or a different home agent? if its
> the same agent, then I think you can only configure one
> address at a time using the INTERNAL_IP6_ATTRIBUTE. 
Really? RFC 4306 say that "Multiple internal addresses
MAY be requested by requesting multiple internal address
attributes.  The responder MAY only send up to
the number of addresses requested."
> if you
> want multiple addresses, you would have to setup up a
> separate IKE SA and IKE_AUTH with CP request for each
> address.
>
>> I believe this
>> should be allowed. Perhaps you could explicitly mention
>> that it is allowed.
>>
>>  > 7.1.  Security Policy Database Entries
>>
>> The style of presentation in this section is taken from
>> RFC 3776. With the new IPsec architecture, it seems that
>> it would be more appropriate to state the configuration
>> in terms of the PAD and the SPD, rather than in SPD only.
>> I would also like you to go through the examples in both
>> the dynamic and manual keying sections with an RFC 4301
>> expert, to ensure that they are generally written in the
>> way that is in alignment with the current specs.
>
> that would be nice, yes.
>
> but IMO, the SPD description in section 7.1 can be easily
> mapped to whatever is needed in 4301.
> BTW the "SPD-S" comes from 4301.
One expert that I attempted to recruit to help you
indicated that there indeed was a problem. So this
may still be an issue.

Is there a possibility that you could add a discussion
of how the PAD needs to be configured for Mobile IPv6
usage?

--Jari


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