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

[Alberto García <[e-mail]>]

Hi
Thanks for your review, Jari.

|  -----Mensaje original-----
|  De: Jari Arkko [mailto:[e-mail]]
|  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