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

I have finally performed my AD review of this document.
Sorry for taking so long time.

Overall, the document is in relatively good shape. I
do have some issues, however. Addressing these
issues requires a new revision of the spec, and
probably some help from RFC 4301 experts.

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.

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

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

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

Note also that folks who do not support full RFC 4301 granularity
could keep on using RFC 3776.

(Note: I was similarly concerned about the continued support
for manual keying and the introduction of the tunnel mode
packet formats. And the consensus for tunnel mode was decided
based on a tiny number of opinions. But maybe these two
features can be justified by the need to ease the manual
configuration process for some current implementions.)

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

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

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

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

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

> 9.  Dynamic Home Address Configuration

This section does not say anything about the use of multiple
home addresses for the same mobile node. 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.

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

--Jari

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6