[shim6] AD review of draft-garcia-shim6-applicability-00.txt

[Jari Arkko <[e-mail]>]

This document has been revived from an expired status, and I was told that it should be ready enough to be published. I have therefore reviewed it.

The document is in relatively good shape and can progress forward, but first we have to make sure that it properly highlights the major issues with Shim6 usage (ingress filtering, lack of initial contact support, lack of firewall implementations with Shim6 support, on/off vs. load balanced multihoming) as well as talk about the needs for site network admins to control the behaviour of Shim6.

I'm expecting a revised draft. How soon can you make one, Alberto?

My detailed comments follow.

>     The Shim6 protocol is defined only for IPv6.  However, there is no
>     fundamental reason why a Shim6-like approach could not support IPv4
>     addresses as locators, either to provide multihoming support to IPv4-
>     numbered sites, or as part of an IPv4/IPv6 transition strategy.  Some
>     extensions to the Shim6 protocol for supporting IPv4 locators have
>     been proposed in [I-D.nordmark-shim6-esd  <http://tools.ietf.org/html/draft-garcia-shim6-applicability-02#ref-I-D.nordmark-shim6-esd>].
>
>     The Shim6 protocol, as specified for IPv6, incorporates cryptographic
>     elements in the construction of locators (see [RFC3972  <http://tools.ietf.org/html/rfc3972>], [RFC5535  <http://tools.ietf.org/html/rfc5535>]).
>     Since IPv4 addresses are insufficiently large to contain addresses
>     constructed in this fashion, direct implementation of Shim6 as
>     specified for IPv6 for use with IPv4 addresses might require protocol
>     modifications.

I think this is too optimistic. The devil is in the details, and I'm not sure how the security would actually work in this case.

Suggested edit:

    The Shim6 protocol is defined only for IPv6.  While some Shim6-like
    approaches have been suggested to support IPv4 addresses as locator
    [I-D.nordmark-shim6-esd], at this time it is not clear if such extensions
    are feasible.
    The Shim6 protocol, as specified for IPv6, incorporates cryptographic
    elements in the construction of locators (see [RFC3972], [RFC5535]).
    Since IPv4 addresses are insufficiently large to contain addresses
    constructed in this fashion, direct implementation of Shim6 as
    specified for IPv6 for use with IPv4 addresses is not possible.

> which with the current rate of IPv4 addresses
>     would be problematic.

which would obviously be problematic given that IPv4 addresses are not easily available any more.

The source address problem discussed in one paragraph in Section 4 should be highlighted much earlier. It is a key missing pieces for Shim6 to work, and it would be honest to tell this to the reader. Similarly, the initial contact issue from Section 5.1.1 should also be highlighted up front.

Section 5.2 should highlight the fact that transport-layer solutions are much more amenable for load balancing solutions, and that work for such solutions is already ongoing at MP-TCP WG.

Section 5.3 should highlight that it is the hosts, not the site admin that get to set these bits. In general, the document should highlight more of the issues from the perspective of a site admin. Not that that is the only relevant viewpoint, but the reader should get a balanced view of the benefits and disadvantages of Shim6.

>     In order to identify the DNS server most appropriate to resolve a
>     particular query, nodes can be configured with policy information.
>     [RFC3484  <http://tools.ietf.org/html/rfc3484>] policy information needs be configured in such way that
>     only source addresses of the node could be used by Shim6 to establish
>     the communication with the DNS if Shim6 could be used for accessing
>     to the DNS.

The "mif" style issues take perhaps a too big of a role here. You should indicate that these issues exist and that they exist independent of Shim6. Also, only certain configurations exhibit the above problems, e.g., walled garden situations. Normal Internet access through ISP would not be affected, and it would not be a problem to use just a regular DNS.

Section 7 should indicate if there is any implementation of deployment experience with these combinations. I'm doubtful on whether all the ipsec layering mechanisms and so on would actually work in real implementations without someone having tested such combinations.

Jari