Subject: RE: tsv-dir review of draft-garcia-shim6-applicability-03

From: "Dan Wing" <[email-masked]>
Date: Tue, 6 Mar 2012 09:25:07 -0800

> -----Original Message-----
> From: Alberto García [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2012 9:07 AM
> To: 'Dan Wing'; 'IETF discussion list'
> Cc: 'Transport Directorate'; [email-masked]; [email-masked];
> 'marcelo bagnulo braun'
> Subject: RE: tsv-dir review of draft-garcia-shim6-applicability-03
> 
> Hi Dan,
> Thank you very much for your review
> 
> |  -----Mensaje original-----
> |  De: Dan Wing [mailto:[email-masked]]
> |  Enviado el: jueves, 01 de marzo de 2012 3:56
> |  Para: 'IETF discussion list'
> |  CC: 'Transport Directorate'; [email-masked]; [email-masked];
> |  'marcelo bagnulo braun'; [email-masked]
> |  Asunto: tsv-dir review of draft-garcia-shim6-applicability-03
> |
> |  I have reviewed this document as part of the transport area
> directorate's
> |  ongoing effort to review key IETF documents. These comments were
> written
> |  primarily for the transport area directors, but are copied to the
> document's
> |  authors for their information and to allow them to address any
> issues
> |  raised. When done at the time of IETF Last Call, the authors should
> consider
> |  this review together with any other last-call comments they receive.
> Please
> |  always CC [email-masked] if you reply to or forward this review.
> |
> |  This draft is basically ready for publication, but has nits that
> should
> be fixed
> |  before publication.
> |
> |
> |
> |  Nits:
> |
> |  Section 1:
> |
> |     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
> the
> |     providers.
> |
> |  It might be useful to add a non-normative reference to RFC5220 at
> the end
> |  of that sentence.
> Ok
> 
> |
> |
> |  Section 3.4:
> |
> |     The use of HBA is more efficient in the sense that addresses
> require
> |     less computation than CGA, involving only hash operations for
> both
> |     the generation and the verification of locator sets.  However,
> the
> |     locators of an HBA set are determined during the generation
> process,
> |     and cannot be subsequently changed; the addition of new locators
> to
> |     that initial set is not supported, except by re-generation of the
> |     entire set which will in turn cause all addresses to change.
> |
> |  I think that paragraph is too harsh, as it implies the old addresses
> have
> to be
> |  invalidated immediately.  I expect existing connections could
> continue
> with
> |  the old addresses, and, if the host wanted to, could even have new
> |  connections use the old addresses.  If that is not possible, the
> draft
> should
> |  explain why.  If that is possible, the draft should probably explain
> it
> is
> |  possible.
> |
> 
> I have rewritten the paragraph:
> 
>    "The use of HBA is more efficient in the sense that addresses
> require
>    less computation than CGA, involving only hash operations for both
>    the generation and the verification of locator sets.  However, the
>    locators of an HBA set are determined during the generation process,
>    and cannot be subsequently changed; the addition of new locators to
>    that initial set is not supported.  Therefore, a node using an HBA
> as
>    ULID for a Shim6 session can only use the locators associated to
> that
>    HBA for the considered Shim6 session.  If the node wants to use a
> new
>    set of locators, it has to generate a new HBA including the prefixes
>    of the new locators (which will result with very high probability in
>    different addresses to those of the previous set).  New sessions
>    initiated with a ULID belonging to the new HBA address set could use
>    the new locators."
> 
> Do you think it is now more clear?

Yes, thanks.

> |
> |  Section 4:
> |
> |     In order to configure source and destination address selection,
> tools
> |     such as DHCPv6 can be used to disseminate a [RFC3484] policy
> table to
> |     a host.
> |
> |  It might be useful to add a non-normative reference to draft-ietf-
> 6man-
> |  addr-select-opt.
> Sure
> 
> |
> |
> |  Section 4:
> |
> |  The sentence ending with "properties exhibited by REAP." needs a
> reference
> |  to RFC5544, which seems to be the RFC defining REAP.
> Ok
> 
> |
> |
> |
> |  Section 7.7, "Shim6 and IPv6 NAT", the problem could be overcome by
> the
> |  Shim6 node knowing its IPv6 address after NPTv6 translation.
> Probably
> not
> |  worth adjusting the document, though, as NPTv6 is experimental.
> 
> Well, this would not work for HBA, since in this case the addresses are
> fixed once generated.

NPTv6 does not change the host portion of the address (it only changes
the network portion -- the IPv6 prefix), so HBA should work with NPTv6.

> It could work for the CGA, since the Shim6 host could sign dynamically
> the
> translated address. But in this case a protocol would be needed to
> convey
> the translated address to the Shim6 node which has to sign it. A threat
> analysis of this operation should be performed, in order not to
> introduce
> new vulnerabilities in the process...
> As you suggest, I think this is not worth.

I agree, it can be discussed in a later document, should someone 
find it useful to have Shim6 work with NPTv6.

> |
> |
> |  Section 7.7:
> |
> |     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.
> |
> |  Applications are layer 7, Shim6 is layer 3, so an "Application Layer
> Gateway"
> |  that modifies Shim6 control packets seems an abuse of terminology.
> |  Suggest:
> |
> |  OLD:
> |     Note that an Application Level Gateway designed to modify the
> Shim6
> |     control packets would not be able to generate a valid signature,
> in
> |  NEW:
> |     Note that modification of the Shim6 control packets by the IPv6
> NAT
> |
> .............^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |  ^
> |     would not be able to generate a valid signature, in
> 
> Changed.

Thanks.
-d

> Thanks again,
> Alberto
> |
> |  -d
> |
> |
> |
> |
> |
> |
> |

---

From: Alberto García <[email-masked]>
Date: Tue, 6 Mar 2012 18:06:38 +0100

Hi Dan,

|  -----Mensaje original-----
|  De: Dan Wing [mailto:[email-masked]]
|  Enviado el: jueves, 01 de marzo de 2012 3:56
|  Para: 'IETF discussion list'
|  CC: 'Transport Directorate'; [email-masked]; [email-masked];
|  'marcelo bagnulo braun'; [email-masked]
|  Asunto: tsv-dir review of draft-garcia-shim6-applicability-03
|  
|  I have reviewed this document as part of the transport area directorate's
|  ongoing effort to review key IETF documents. These comments were written
|  primarily for the transport area directors, but are copied to the
document's
|  authors for their information and to allow them to address any issues
|  raised. When done at the time of IETF Last Call, the authors should
consider
|  this review together with any other last-call comments they receive.
Please
|  always CC [email-masked] if you reply to or forward this review.
|  
|  This draft is basically ready for publication, but has nits that should
be fixed
|  before publication.
|  
|  
|  
|  Nits:
|  
|  Section 1:
|  
|     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 the
|     providers.
|  
|  It might be useful to add a non-normative reference to RFC5220 at the end
|  of that sentence.
Ok

|  
|  
|  Section 3.4:
|  
|     The use of HBA is more efficient in the sense that addresses require
|     less computation than CGA, involving only hash operations for both
|     the generation and the verification of locator sets.  However, the
|     locators of an HBA set are determined during the generation process,
|     and cannot be subsequently changed; the addition of new locators to
|     that initial set is not supported, except by re-generation of the
|     entire set which will in turn cause all addresses to change.
|  
|  I think that paragraph is too harsh, as it implies the old addresses have
to be
|  invalidated immediately.  I expect existing connections could continue
with
|  the old addresses, and, if the host wanted to, could even have new
|  connections use the old addresses.  If that is not possible, the draft
should
|  explain why.  If that is possible, the draft should probably explain it
is
|  possible.
|  

   "The use of HBA is more efficient in the sense that addresses require
   less computation than CGA, involving only hash operations for both
   the generation and the verification of locator sets.  However, the
   locators of an HBA set are determined during the generation process,
   and cannot be subsequently changed; the addition of new locators to
   that initial set is not supported.  Therefore, a node using an HBA as
   ULID for a Shim6 session can only use the locators associated to that
   HBA for the considered Shim6 session.  If the node wants to use a new
   set of locators, it has to generate a new HBA including the prefixes
   of the new locators (which will result with very high probability in
   different addresses to those of the previous set).  New sessions
   initiated with a ULID belonging to the new HBA address set could use
   the new locators."

|  
|  Section 4:
|  
|     In order to configure source and destination address selection, tools
|     such as DHCPv6 can be used to disseminate a [RFC3484] policy table to
|     a host.
|  
|  It might be useful to add a non-normative reference to draft-ietf-6man-
|  addr-select-opt.
Sure

|  
|  
|  Section 4:
|  

|  
|  
|  
|  Section 7.7, "Shim6 and IPv6 NAT", the problem could be overcome by the
|  Shim6 node knowing its IPv6 address after NPTv6 translation.  Probably
not
|  worth adjusting the document, though, as NPTv6 is experimental.

Well, this would not work for HBA, since in this case the addresses are
fixed once generated. 
It could work for the CGA, since the Shim6 host could sign dynamically the
translated address. But in this case a protocol would be needed to convey
the translated address to the Shim6 node which has to sign it. A threat
analysis of this operation should be performed, in order not to introduce
new vulnerabilities in the process... 
As you suggest, I think this is not worth.

|  
|  
|  Section 7.7:
|  
|     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.
|  
|  Applications are layer 7, Shim6 is layer 3, so an "Application Layer
Gateway"
|  that modifies Shim6 control packets seems an abuse of terminology.
|  Suggest:
|  
|  OLD:
|     Note that an Application Level Gateway designed to modify the Shim6
|     control packets would not be able to generate a valid signature, in
|  NEW:
|     Note that modification of the Shim6 control packets by the IPv6 NAT
|  .............^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|  ^
|     would not be able to generate a valid signature, in

Changed.

Thanks again,
Alberto

|  
|  -d
|  
|  
|  
|  
|  
|  
|

---

From: Alberto García <[email-masked]>
Date: Wed, 7 Mar 2012 11:02:21 +0100

Hi Dan,

|  > |  Section 7.7, "Shim6 and IPv6 NAT", the problem could be overcome by
|  > the
|  > |  Shim6 node knowing its IPv6 address after NPTv6 translation.
|  > Probably
|  > not
|  > |  worth adjusting the document, though, as NPTv6 is experimental.
|  >
|  > Well, this would not work for HBA, since in this case the addresses
|  > are fixed once generated.
|  
|  NPTv6 does not change the host portion of the address (it only changes
the
|  network portion -- the IPv6 prefix), so HBA should work with NPTv6.
|  

Well, HBAs are built as a hash of many things, including the different
prefixes for which you want to generate an address. Different interface
identifiers are generated by changing the order in which the hash is
performed. 
The issue with NPTv6 is that, in order to verify that the locator is a valid
HBA, the receiver checks that the prefix of the locator is included in the
HBA Parameter Data Structure, and then that the appropriate hash of the
Parameter Data Structure corresponds to the interface identifier. If the
NPTv6 changes the prefix, the first validation, the one regarding to the
prefix, will fail, and HBAs will not work.

Regards,
Alberto