Re: [Gen-art] Review: draft-garcia-shim6-applicability-03

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

Hi,
Thanks for your review, Joel, and to Brian for its comments.

First of all, I'm not generating a new version with the changes suggested below until Jari requested it, as recommended in the Gen-ART faq. Of course, if you prefer reading the -04-candidate-version file, let me know.

|  -----Mensaje original-----
|  De: Brian E Carpenter [mailto:[e-mail]]
|  Enviado el: domingo, 19 de febrero de 2012 2:10
|  Para: Joel M. Halpern
|  CC: [e-mail]; Jari Arkko; draft-garcia-shim6-
|  [e-mail]
|  Asunto: Re: [Gen-art] Review: draft-garcia-shim6-applicability-03
|  
|  Joel,
|  
|  Writing as an interested party, not a reviewer:
|  
|  
|  On 2012-02-19 09:12, Joel M. Halpern wrote:
|  > I am the assigned Gen-ART reviewer for this draft. For background on
|  > Gen-ART, please see the FAQ at
|  > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
|  >
|  > Please resolve these comments along with any other Last Call comments
|  > you may receive.
|  >
|  > Document: draft-garcia-shim6-applicability-03
|  >     Applicability Statement for the Level 3 Multihoming Shim Protocol
|  >                                 (Shim6)
|  > Reviewer: Joel M. Halpern
|  > Review Date: 18-Feb-2012
|  > IETF LC End Date: 14-March-2012
|  > IESG Telechat date: N/A
|  >
|  > Summary: This document is almost ready for publication as an
|  > information rfc
|  >
|  > Major issues:
|  >     The third paragraph of the introduction makes assertions about PI
|  > based multihoming being "not generally available to end sites due to a
|  > strict policy of route aggregation in the DFZ."  As far as I know,
|  > this is simply not the case.  RIRs sell IPv6 PI for reasonable fees.
|  > Most operators accept PI advertisements from customers.  And those
|  > advertisements are passed on to other ISP, and accepted.  I would
|  > recommend removal of the first sentence of this paragraph.  Instead,
|  > it needs to be noted that PI based multihoming can be done with IPv6,
|  > and then point to the scaling concerns.
|  
|  Yes, the point is that PI doesn't scale to ten million sites, but shim6 does.
|  That should be clarified.

I've made the following change, which I hope addresses the concerns raised:

OLD ---->
  In IPv6, site multihoming in the style of IPv4 is not generally
   available to end sites due to a strict policy of route aggregation in
   the DFZ.  Site multihoming for sites without provider-independent
   (PI) addresses is achieved by assigning multiple addresses to each
   host, one or more from each provider.  This multihoming approach
   provides no transport-layer stability across re-homing events.
<--- END OLD text

NEW text ---->
Site multihoming in IPv6 can be achieved as in IPv4, thus facing similar scalability concerns. However, the large address space of IPv6 enables a different solution for site multihoming in IPv6: to assign multiple addresses  to each host, one or more from each provider. Deploying site multihoming in this way does not impact in the routing system, so such a site multihoming strategy may be extended to a large number of sites, and may be applied to small sites which would not be eligible for site multihoming based on the injection of routes to PI prefixes. A drawback of this multihoming approach is that it does not provide transport-layer stability across re-homing events.
<--- END NEW text

|  
|  >
|  >
|  > Moderate Issues:
|  >     I am unable to understand the sentence "Shim6 has no means to
|  > enforce neither host nor network forwarding for a given locator to be
|  > used as source address."  I presume that what it is intended to
|  > communicate is simply a fact about shim6.  Please rewrite.

What I wanted to say was:
'When a locator has been selected by a host to be used as source address for a Shim6 session, Shim6 has no means to enforce an appropriate path for that source address neither in the host nor in the network.'

That is, there is no specific mechanism to do this in Shim6, so the solutions to this must be those of IPv6 (some solutions are commented in the same paragraph).

|  
|  It's a fact. In fact, it's a fact that seriously impacts shim6 deployability,
|  according to the experience of a student of mine.
|  Getting the appropriate locator pair out of a host, through the appropriate
|  edge router and ISP link, and through the firewall at the far end, and doing
|  the whole thing again in the reverse direction, is a significant configuration
|  challenge.

Yes. Most of the problem is common to IPv6 using multiple addresses. The possibility that the reverse path is different to the forward path, and the impact in the firewalls is commented in section 7.6 (Shim6 and firewalls).

|  
|     Brian
|  
|  >
|  >     If I am reading section 7.1.1 on MobileIPv6/Shim6 interaction, it
|  > looks like you are describing a scenario in which the mobile node uses
|  > multiple HOAs as locators with a correspondent node.  

Sure: 
" Two Shim6  entities will exchange their own available HoAs as locators. [...]The CoAs are not presented to the Shim6 layer and are not
   included in the local locator set in this case."
|  > I would suggest
|  > that this section would be clearer if the communicating parties were
|  > identified.  I suspect that the intended behavioral assumption is that
|  > the mobile node will register its CoA multiple times, once with each
|  > home address.  But this does not seem to be stated explicitly.
Well, it says 
" The CoAs are managed by the MIPv6 layer, which binds each HoA to a CoA."
To describe the most general case, we assume that they may be many CoAs for the MN, and it could bind
HoA1 to CoA3
HoA2 to CoA2
Etc. 
I can add the following text to the previous sentence: "For example, is a single CoA, CoA1, is available for the MN in the foreign link to which it is attached, every HoA should have a bind to CoA1."

However, regarding to the clarity... For me it is very clear - and I must say I was not the writer of this part of the text, so I'm not taking it personally :-)
Besides, just to understand your comment, when you say that 'it be clearer if the communicating parties were identified'... to which communication parties are you referring?

|  >
|  >
|  > Minor issues:
|  >     In th long comparative paragraph in the introduction, "The Shim6
|  > approach is thought to have better scaling properties with respect to
|  > the state held in the DFZ than the IPv approach." Could "IPv 4
|  > approach be replaced with "PI approach"?

Sure, changed.

|  >
|  >     In section 7.7 on the interaction with NPT66, I think it would be
|  > helped by a bit more discussion of when certain shim6 messages are
|  > exchanged, and which fields are validated.  Specifically, I can not
|  > tell if it is ever possible to get a shim6 ULID-pair option through an
|  > NPT66 which is rewriting the one of the addresses prefixes in the
|  > packet.  I suspect not.  If indeed it just won't work, this needs to
|  > be stated MUCH more clearly.

Definitely, after reading this part again, it needs to be MUCH more clear, as you say. Therefore, I've rewritten almost completely. I have gave up from trying to be exhaustive in the possible cases, since there are too many cases (R1bis, I2bis, options that may or may not appear...). Covering all the cases would be unfeasible, unreadable, and also useless. So the section is a warning of the kind of things that may appear.
Do you think the new text is ok?

"7.7.  Shim6 and IPv6 NAT

   Address translation techniques such as Network Prefix Translation
   [RFC6296] may be used until workable solutions to avoid renumbering
   or facilitate multihoming are developed [RFC5902].  We now consider
   the impact of IPv6 NATs in Shim6 operation.

   The main purpose of Shim6 is to provide locator agility below
   transport protocols.  To prevent the risk of redirection attacks by
   abusing on the locator exchange facilities provided by Shim6, the
   protocol is built upon the cryptographic properties of CGA and HBA
   addresses.  When a CGA address of a node is used as the local ULID,
   the locators configured in the node can be signed with the private
   key associated to the CGA.  A peer receiving a Shim6 message performs
   a hash of the CGA Parameter Data Structure information received,
   including a public key, to assure that this key is bound to the CGA
   address, and then checks the signature protecting the locators.  When
   an HBA address of a node is used as the local ULID, the HBA address
   securely chains the ULID and other locators of the node by means of a
   hash.  For both the CGA and the HBA, the locators can be exchanged at
   the four-way handshake used to establish the Shim6 context, or once
   the context has been established by means of an Update Request
   message.

   When a node behind an IPv6 NAT communicates, the NAT device
   translates the address assigned to this internal node to an address
   of its address pool.  This operation results in a mismatch between
   the address seen by external hosts and the address configured in the
   internal node, which is the locator that would be conveyed in a Shim6
   locator exchange and is also the address for which the security
   defined in the CGA and HBA specifications are provided.  Then, the
   validation processes performed by an external node may prevent the
   creation of the Shim6 context, or may allow the context to be created
   but render the alternative locator of the internal host unusable.

   However, note that the failure in creating a Shim6 context, or in
   using the alternative locators, does not impact in the communication
   between the nodes as long as the path between them defined by the
   initial locator pair remains available.  Data packets flow between
   the communicating nodes as for any non-Shim6 communication.  Not
   creating the Shim6 context or not being able to convey the local
   locators to the peer node affect to the added value provided by
   Shim6, i.e. to the ability of preserving the communication in case
   any of the locators fail.  Therefore, using Shim6 with IPv6 NAT does
   not provide less functionality than using IPv6 in the same scenario.

   We now illustrate some cases that may occur when combining Shim6 and
   IPv6 NAT.  The following discussion does not aim to be exhaustive in
   the cases that may arise, but just aims to provide some examples of
   possible situations.  We assume a scenario in which host A is located
   behind a NAT for its locator IP_A1, but it is connected to the public
   IPv6 internet for its locator IP_A2.  Once translated, locator IP_A1
   appears to external nodes as IP_T. Node A communicates with node B,
   with public addresses IP_B1 and IP_B2.


                 +-----+
                 |  A  |
                 +-----+
            IP_A1 |  | IP_A2
                  |  |
                  |  +-----+
                  |        |
               +------+    |
               | NAT  |    |
               +------+    |
             IP_T |        |
                  |        |
         +--------------------------+
         |         Internet         |
         +--------------------------+
                   |  |
             IP_B1 |  | IP_B2
                 +-----+
                 |  B  |
                 +-----+

                                 Figure 4

   We first discuss some issues related with the four-way handshake used
   to establish the Shim6 context.  When the locator information is
   included in the Shim6 exchange, either in the I2 or R2 messages, the
   receiver is required to validate the ULID of the peer node by
   performing the CGA or HBA address validation procedure.  In case the
   validation fails, the message containing the information is silently
   discarded.  In the scenario depicted in Figure 4, some of the cases
   which may occur are:
   o  Node A initiates the exchange, with IP_B1 as destination address
      and IP_A1 as source address, which is a CGA.  Node A includes
      IP_A2 as an alternative locator in the I2 message.  Node B sees
      IP_T as the ULID for A, so when it validates the CGA with the
      information contained in I2, the validation fails because the CGA
      Parameter Data Structure contains information bound to IP_A1.
      Therefore, B silently discards the received I2 message.  Without
      receiving a valid I2 message, B does not create the Shim6 context.
      Without receiving the R2 message, A does not create either the
      Shim6 context.  However, data communication can proceed as long as
      the path between IP_A1 and IP_B1 is valid.  A similar case occur
      if IP_A1 and IP_A2 form a HBA, instead of using CGAs for securing
      the communication.
   o  Node A initiates the exchange with IP_B1 as destination address
      and IP_A2, its public address, as source address, which is a CGA.
      Node A includes IP_A1 as an alternative locator in the I2 message.
      In this case, B can successfully validate IP_A2 as a CGA.
      Regarding to the validation of IP_A1 as an alternative locator for
      A, the Shim6 specification [RFC5533] indicates that it should
      perform this check when the I2 message is received, but it may
      perform it later on, provided that the check is performed before
      using it as a locator.  In case the validation is performed when
      I2 is received, the I2 message would be silently discarded, with
      the same result as for the previous case.  In case the validation
      is performed later, the Shim6 context would be established in both
      nodes A and B, but B could not send to IP_A1, and packets sent by
      A from IP_A1 will not be received by B. Note that in this case
      both IP_B1 and IP_B2 could be used by A and B, as long as the
      locator for A is IP_A2, so limited locator agility may be
      achieved.
   o  Node B initiates the exchange with IP_B1 as source address, and
      IP_A2 as destination address, which is a CGA.  This case is
      similar to the previous one, although it is the R2 message sent by
      A the one that cannot be validated.  While A can create a context
      with B, B cannot do the same for A. Data communication using IP_B1
      and IP_A2 can proceed.  However, A may try to use IP_B2 as
      alternative locator but the data packets sent, carrying the Shim6
      Extension Header, will not be associated by B to any established
      context, so they will be discarded.  The same occurs for packets
      sent by A with IP_A1 as source address.

   We can also consider the case in which node A do not exchange its own
   locators in the Shim6 establishment exchange.  For example, a Shim6
   context can be established between CGA IP_A2, and IP_B1.  B can
   convey locator IP_B2 in the four-way handshake without, and
   validation will be correctly done by A. Later on, A may send an
   Update Request message to inform B about its locator IP_A1.
   Validation for this message will fail in B, and B will send a Shim6
   Error message to A. Neither A nor B will use IP_A1 as locator.
   However, in IP_A2, IP_B1 and IP_B2 can still be used as valid
   locators for the communication.

   Finally, note that an Application Level Gateway designed to modify
   the Shim6 control packets would not be able to generate a valid
   signature, in case a CGA is being used, or a Parameter Data Structure
   binding the translated locator to the other locators of a node, in
   case a HBA is being used.  Therefore, the same failure cases
   described before would remain."


|  >
|  > Yours,
|  > Joel M. Halpern
|  >
|  >
|  > Nits/editorial comments:

Don't know if you have any comment here, or this is just part of the template

Regards,
Alberto

|  > _______________________________________________
|  > Gen-art mailing list
|  > [e-mail]
|  > https://www.ietf.org/mailman/listinfo/gen-art
|  >