Re: [shim6] AD review of draft-garcia-shim6-applicability-00.txt
Alberto García <alberto@it.uc3m.es> Thu, 22 December 2011 12:18 UTC
Return-Path: <alberto@it.uc3m.es>
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 36C5321F8A56 for <shim6@ietfa.amsl.com>; Thu, 22 Dec 2011 04:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 W3aWTd0W5x-b for <shim6@ietfa.amsl.com>; Thu, 22 Dec 2011 04:18:16 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id BBA6C21F853B for <shim6@ietf.org>; Thu, 22 Dec 2011 04:18:15 -0800 (PST)
X-uc3m-safe: yes
Received: from BOMBO (unknown [163.117.139.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id E562E9C650D; Thu, 22 Dec 2011 13:18:11 +0100 (CET)
From: Alberto García <alberto@it.uc3m.es>
To: 'Jari Arkko' <jari.arkko@piuha.net>, 'shim6' <shim6@ietf.org>, 'marcelo bagnulo braun' <marcelo@bagnulo.net>, 'Joe Abley' <joe.abley@icann.org>
References: <4EF089CF.5070300@piuha.net>
In-Reply-To: <4EF089CF.5070300@piuha.net>
Date: Thu, 22 Dec 2011 13:18:12 +0100
Message-ID: <00d901ccc0a3$c68c7dc0$53a57940$@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
thread-index: AQGDOZmzRYcIB0SkvRGwi/BNWMGwMpZ5LT0A
Content-Language: es
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18598.007
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 12:18:17 -0000
Hi Thanks for your review, Jari. | -----Mensaje original----- | De: Jari Arkko [mailto:jari.arkko@piuha.net] | Enviado el: martes, 20 de diciembre de 2011 14:13 | Para: shim6; Alberto García; marcelo bagnulo braun; Joe Abley | Asunto: AD review of draft-garcia-shim6-applicability-00.txt | | 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. Well, actually the last version submitted is -02, expiring on April 2012. Although you refer in the subject of this email to -00, I see by your comments that you refer to text that was included in version 01 and 02... so it seems that regarding to the text we are synchronized. | | 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,. | 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.' | | 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? | | 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." | | 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. 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. | | > 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]." | | 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? 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. Regards, Alberto | | Jari
- [shim6] AD review of draft-garcia-shim6-applicabi… Jari Arkko
- Re: [shim6] AD review of draft-garcia-shim6-appli… Alberto García
- Re: [shim6] AD review of draft-garcia-shim6-appli… Jari Arkko
- Re: [shim6] AD review of draft-garcia-shim6-appli… Alberto García
- Re: [shim6] AD review of draft-garcia-shim6-appli… Brian E Carpenter
- Re: [shim6] AD review of draft-garcia-shim6-appli… Jari Arkko
- Re: [shim6] AD review of draft-garcia-shim6-appli… Alberto García
- Re: [shim6] AD review of draft-garcia-shim6-appli… Jari Arkko