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

[Vijay Devarapalli <[e-mail]>]

hi Jari,

thanks. sorry for the delayed response.

Jari Arkko wrote:

> Technical:
> 
>  >    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.

> There are probably other occurrences of this problem elsewhere
> in the document.

this seems to be only one....

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

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

> 
>  >    The home agent should have named SPD entries per mobile node, based
>  >    on the identity of the mobile node.  The identity of the mobile node
>  >    is stored in the "Name" selector in the SPD [5].  The home address
>  >    presented by the mobile node during the IKE negotiation is stored as
>  >    the remote IP address in the resultant IPsec security associations.
> 
> Assuming a likely deployment arrangement is authentication
> through EAP and AAA, this seems hard to achieve. Overall, the text
> in this section follows the RFC 3776 model which may not be all
> that great for a dynamic operation.

I will address this separately

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

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

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

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

> 
> Editorial:
> 
>  >    The mobile node should always include its identity in the IDi payload
>  >    in the IKE_AUTH exchange.
> 
> I think this should be "always includes" instead of "should always
> include". The payload is mandatory.
> 
>  >    implementations are required to match the source address in the outer
>  >    most IP header with the IP address in the IDi field [8].  This
> 
> s/outer most/outermost/
> 
>  > The author would like to thank
> 
> authors

fixed.

Vijay

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