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

Alberto García <alberto@it.uc3m.es> Thu, 22 December 2011 17:36 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 91D9121F8B0C for <shim6@ietfa.amsl.com>; Thu, 22 Dec 2011 09:36:45 -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.000, 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 rNhQ6TKRfQSG for <shim6@ietfa.amsl.com>; Thu, 22 Dec 2011 09:36:44 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id E5BE421F8B02 for <shim6@ietf.org>; Thu, 22 Dec 2011 09:36:43 -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 ACCF19C5F14; Thu, 22 Dec 2011 18:36:42 +0100 (CET)
From: Alberto García <alberto@it.uc3m.es>
To: 'Jari Arkko' <jari.arkko@piuha.net>
References: <4EF089CF.5070300@piuha.net> <00d901ccc0a3$c68c7dc0$53a57940$@it.uc3m.es> <4EF33EDB.5010806@piuha.net>
In-Reply-To: <4EF33EDB.5010806@piuha.net>
Date: Thu, 22 Dec 2011 18:36:45 +0100
Message-ID: <011901ccc0d0$467030f0$d35092d0$@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
thread-index: AQGDOZmzRYcIB0SkvRGwi/BNWMGwMgCBFVc7AUaz2k6WbMtNEA==
Content-Language: es
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18600.000
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 17:36:45 -0000

Hi Jari,

[Trimming out all the issues already agreed]

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

OK. I undo the position change of the 'address' section.

I have added some text to the 4th paragraph of the 'introduction':

"   Shim6 provides layer-3 support for making re-homing events
   transparent to the transport layer by means of a shim approach.  
NEW TEXT ---->
   Once
   a Shim6 session has been established, the failure detection mechanism
   defined for Shim6 allows finding new valid locator combinations in
   case of failure, and using these locators to continue the
   communication.  However, Shim6 does not provide failure protection to
   the communication establishment, so if a host within a multihomed
   site attempts to establish a communication with a remote host and
   selects an address which corresponds to a failed transit path, the
   communication will fail.  
<--- END OF NEW TEXT
   State information relating to the
   multihoming of two endpoints exchanging unicast traffic is retained
   on the endpoints themselves, rather than in the network.
   Communications between Shim6-capable hosts and Shim6-incapable hosts
   proceed as normal, but without the benefit of transport-layer
   stability.  The Shim6 approach is thought to have better scaling
   properties with respect to the state held in the DFZ than the IPv4
   approach.  
NEW TEXT ---->
In order to successfully deploy Shim6 in a multihomed site, additional
mechanism may be required to solve issues such as selecting the source
address appropriate to the destination and to the outgoing provider, or to
allow the network manager to perform traffic engineering. Such problems are
not specific of Shim6, but are suffered by the hosts of any site which is
connected to multiple transit providers, and which receives an IPv6 prefix
from each of them. Some of these mechanisms are not defined today.
<--- END OF NEW TEXT"

Do you think this is enough?
|  
|  >
|  > |
|  > |  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 ...")

Sure. Changed.

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

Ummm. The problem related above is common to IPv6 nodes connecting to
multiple providers. We have a section for this, 'Shim6 in Multihomed Nodes',
in which we comment (following
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat) that RFC3484-related
configuration should be defined, the possibility of using Extensions to
Router Advertisements through Default Router Preference and More-Specific
Routes to specify the next hop router to use for a given set of
destinations, etc. 
I think your comment is addressed in this section.

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

One piece of text added to the introduction, included in a comment above,
included this idea:

"In order to successfully deploy Shim6 in a multihomed site, additional
mechanism may be required to solve issues such as selecting the source
address appropriate to the destination and to the outgoing provider, or to
allow the network manager to perform traffic engineering. Such problems are
not specific of Shim6, but are suffered by the hosts of any site which is
connected to multiple transit providers, and which receives an IPv6 prefix
from each of them. Some of these mechanisms are not defined today."

|  >
|  > |
|  > |  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 think there are two different cases for this. Some combinations are NOT
RECOMMENDED by the draft. These are 
- shim6 and SCTP. 
- shim6 and HIP. 
- shim6 and NATs: since shim6 security is end-to-end, NATs break Shim6 as
currently defined.
Although it would be nice to have some experimental proof of this... I think
it is easier to accept that, if the analysis is ok, no further experiment is
required.

The rest combinations are assumed to work. However, since IFAIK there is no
production deployment of Shim6, most of them have not been tested. And even
those tested, have not been tested in 'real' conditions. For this, we have 
- shim6 and IPsec and shim6 and MIPv6 (and the three of them). Barre's
implementation to check
- shim6 and SEND. It seems there should be no problem in the interaction,
since both protocols deal with different issues. I'm not aware of any
combined test for them.
- shim6 and NEMO. I'm not aware of any implementation/test of NEMO with
Shim6
- shim6 and firewalls. There is an implementation (a modification to Linux
netfilter) developed for a Master Thesis from U. of Lovaina:
http://inl.info.ucl.ac.be/system/files/memoire_0.pdf. They analyze several
possible issues that may arise with firewalling shim6 traffic, although all
of them seem to be solved without requiring any protocol modification. The
main problem seems to be the large amount of state that the firewall is
required to store (the locators, context tag, etc. for each shim6 session).
Of course, there is lack of real-world experience, so this conclusions may
not be close to reality.

So, it is very likely that we could not find info for real tests on many of
these combinations. Would it suffice to write a disclaimer for this section
saying that there is a lack of real experience with most of these
combinations?.

Regards,
Alberto

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