Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6)
draft-garcia-shim6-applicability-05

[Ballot comment]
The first two paragraphs of the Security section reads oddly.

Suggest:
OLD
  This section considers the applicability of the Shim6 protocol from a
  security perspective, i.e. which security features can expect
  applications and users of the Shim6 protocol.

  First of all, it should be noted that the Shim6 protocol is not a
  security protocol, like for instance HIP.
NEW
  This section considers the applicability of the Shim6 protocol from a
  security perspective, i.e. which security features can be expected by
  applications and users of the Shim6 protocol.

  First of all, it should be noted that the Shim6 protocol is not a
  security protocol, unlike for instance HIP.
END

[Ballot discuss]

  The Gen-ART Review by Joel Halpern on 18-Feb-2012 raised several
  concerns, and there seems to be agreement on the nature of the
  changes to the document that are needed.  Yet, the changes have not
  been made yet.

[Ballot comment]


- I wondered how IPsec was affected by or affects shim6.  Figure 3
didn't really tell me.

- Section 3.3 seems a bit odd - why do you want to control CGA
parameters via DHCP? (That's also the subject of a discuss on
ietf-csi-dhcpv6-cga-ps.) Its also not the case (is it?) that private
key information is ever exchanged like this. Similarly with 3.4.
Could both these sections not actually just be deleted?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6)) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Applicability Statement for the Level 3 Multihoming Shim Protocol
  (Shim6)'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-03-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document discusses the applicability of the Shim6 IPv6 protocol
  and associated support protocols and mechanisms to provide site
  multihoming capabilities in IPv6.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-garcia-shim6-applicability/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-garcia-shim6-applicability/


No IPR declarations have been submitted directly on this I-D.

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