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

Jari Arkko <jari.arkko@piuha.net> Thu, 22 December 2011 14:29 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: shim6@ietfa.amsl.com
Delivered-To: shim6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3613621F8B23 for <shim6@ietfa.amsl.com>; Thu, 22 Dec 2011 06:29:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.462
X-Spam-Level:
X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfDlmDjtIOZJ for <shim6@ietfa.amsl.com>; Thu, 22 Dec 2011 06:29:53 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id CE92521F8AFB for <shim6@ietf.org>; Thu, 22 Dec 2011 06:29:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 265922CC4D; Thu, 22 Dec 2011 16:29:52 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHYzC6lhBZKR; Thu, 22 Dec 2011 16:29:47 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id AA4D82CC31; Thu, 22 Dec 2011 16:29:47 +0200 (EET)
Message-ID: <4EF33EDB.5010806@piuha.net>
Date: Thu, 22 Dec 2011 16:29:47 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
References: <4EF089CF.5070300@piuha.net> <00d901ccc0a3$c68c7dc0$53a57940$@it.uc3m.es>
In-Reply-To: <00d901ccc0a3$c68c7dc0$53a57940$@it.uc3m.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'marcelo bagnulo braun' <marcelo@bagnulo.net>, 'shim6' <shim6@ietf.org>, 'Joe Abley' <joe.abley@icann.org>
Subject: Re: [shim6] AD review of draft-garcia-shim6-applicability-00.txt
X-BeenThere: shim6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SHIM6 Working Group Mailing List <shim6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/shim6>, <mailto:shim6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shim6>
List-Post: <mailto:shim6@ietf.org>
List-Help: <mailto:shim6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2011 14:29:54 -0000

Alberto,

> |
> |  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?
>
> Very soon. I would wait for finishing this discussion to generate a new
> version,.

OK

>
> |  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.
>
> Agreed
>
> |
> |>  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.
>
> Well, do you think it could be improved by updating the text if changed
> to...
> '[...]  which would be problematic considering the current situation in
> which IPv4 address space has been exhausted.'

OK

>
> |
> |  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.
>
> To address this, I suggest moving the current section '3.  Addresses and
> Shim6' after 'Shim6 capabilities'. The result would be:
> 1.  Introduction
> 2.  Deployment Scenarios<- this is a short section which define the
> topology... which is convenient before discussing all the problems related
> with the attachment to different providers.
> 3.  Shim6 in Multihomed Nodes<- source address problem
> 4.  Shim6 Capabilities<-- initial contact issue
> 5. Addresses and Shim6
>
> The 'addresses and Shim6' section does not include problematic issues, so I
> think there is no problem in placing it later.
> Do you think this solves the issue?

Perhaps you could solve it in a simpler way, without this much surgery to the structure of the document. Just mention the things we need to highlight in the introduction, and you should be fine.

>
> |
> |  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.
>
> OK. I add a paragraph at the end of 5.2 saying:
> "It is worth to note that the use of transport-layer solutions enhanced with
> mechanisms to allow the use of multiple paths for a transport session are
> more amenable for achieving load-balancing. One such solution is being
> developed at the MP-TCP Working Group."

OK. (Maybe "It is worth noting that ...")

>
> |
> |  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.
>
> To address this, I have added the following text:
> At the end of the 5th paragraph of section '2 Deployment Scenarios':
> " As discussed in
>     Section 4, the site should deliver outgoing packets having a source
>     address derived from the prefix of ISP[i] to that particular
>     provider, in order to prevent those packets to be filtered due to
>     Ingress Filtering [RFC2827] being applied by the providers.  It is
>     worth to note that in an scenario such as the one depicted in
>     Figure 1, the paths followed by inbound and outbound traffic are
>     determined to a large extent by the locators in use for the
>     communication.  This is not a particular issue of Shim6, but it is
>     common to any deployment in which hosts are configured with addresses
>     received from different providers.  Traffic Engineering in such sites
>     will likely involve proper configuration of address selection
>     policies in the hosts, by means of mechanisms such as the ones
>     discussed in Section 4."
> I think the previous text is early enough to provide a clear indication of
> the limitations of Shim6 regarding to this.

The text above is fine, but I'm hoping that you do have somewhere other text that explains that in Shim6, operator control of hosts does require extra mechanisms that do not currently exist.

>
> At the end of section '3.4.  Use of CGA vs. HBA'
> "  There is no current mechanism designed to allow an administrator to
>     enforce the configuration of a CGA or an HBA in a host."
>
> Regarding to your comment specific for section 5.3, I have rewritten it to:
>
> "5.3.  Traffic Engineering
>
>     For sites with prefixes obtained from different providers, the paths
>     followed by inbound and outbound traffic are determined to a large
>     extent by the locators selected for each communication.  This is not
>     a particular issue of Shim6, but it is common to any deployment in
>     which hosts are configured with addresses received from different
>     providers.  Traffic Engineering in such sites will likely involve
>     proper configuration of the address selection policies defined by
>     [RFC3484].
>
>     Besides, the Shim6 protocol provides some lightweight traffic
>     engineering capabilities in the form of the Locator Preferences
>     option, which allows a host to inform a remote host of local
>     preferences for locator selection.  In this way, the host can
>     influence in the incoming path for the communication.  This mechanism
>     is only available after a Shim6 context has been established, and it
>     is a host-based capability rather than a site-based capability.
>     There is no defined mechanism which would allow use of the Locator
>     Preferences option amongst a site full of hosts to be managed
>     centrally by the administrator of the site."
>
> I've checked the rest of the document with 'site admin' hat on, but I did
> not find a clear target to add more comments.

See above. If all else fails, you could add this somewhere in the introduction:

"Also, Shim6 is inherently a host-centric approach. In situations where there is a need for the network manager to control the multihoming behavior for traffic engineering reasons, additional mechanisms are needed to implement such control from the network manager to the hosts. No such mechanisms are defined today."

Or words to that effect.

>
> |
> |>      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.
>
> I've added a new sentence at the beginning of the first paragraph of the
> section:
> "[OLD:]Shim6 multihomed nodes are likely to suffer problems related to the
> attachment to different provision domains.
> [NEW:] Note that these problems are not specific 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.
>
> I have shortened the DNS paragraph. Now it says:
> "For some particular configurations, i.e. for a walled-garden or closed
> service, the node may need to identify the most appropriate DNS server to
> resolve a particular query. For an analysis of this problem, the reader is
> referred to [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]."

OK

>
> |
> |  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.
>
> I assume you are referring specifically to discuss deployment experience for
> the 'Shim6 and Mobile IPv6' subsection, aren't you?

No, I was thinking of all the combinations listed in Section 7.

> I will ask Sebastien Barre, which had a MipShim6 implementation, with which
> I think he successfully tested some of the configurations discussed in the
> draft, although I'm not sure if IPsec was involved in the tests.
>
OK

Jari