Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-shim6-hba-04

From: Spencer Dawkins <[email-masked]>
Date: Fri, 23 Nov 2007 20:59:54 -0600

Hi, Marcelo,

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-shim6-hba-04
Reviewer: Spencer Dawkins
Review Date:
IETF LC End Date: 2007-11-23

Summary: This document is on the right track, but in some places is just not 
clear enough for publication yet. I'll call Russ's attention to my comments 
about "Perform duplicate address detection if required" and in the security 
considerations section (both below). Almost everything else is (nit)s.

Comments:

Abstract

   This memo describes a mechanism to provide a secure binding between
   the multiple addresses with different prefixes available to a host
   within a multihomed site.  The main idea is that information about
   the multiple prefixes is included within the addresses themselves.
   This is achieved by generating the interface identifiers of the
   addresses of a host as hashes of the available prefixes and a random
   number.  Then, the multiple addresses are generated by prepending the
   different prefixes to the generated interface identifiers.  The
   result is a set of addresses, called Hash Based Addresses (HBAs),
   that are inherently bound.

Spencer (nit): s/bound/bound to a host/?

3.3.  Motivations for the HBA design

   Fourth, performance considerations as described in [17] motivated the
   usage of a hash based approach as oposed to a public key based
   approach based on pure Cryptographic Generated Addresses (CGA), in
   order to avoid imposing the performance of public key operations for
   every communication in multihomed environments.  The HBA appraoch

Spencer (nit): s/appraoch/approach/

   presented in this document presents a cheaper alternative that is
   attractive to many common usage cases.  Note that the HBA approach
   and the CGA approaches are not mutually exclusive and that it is
   possible to generate addresses that are both CGA and HBA providing

Spencer (nit): "both CGA and HBA" is correct but difficult to parse. Suggest
"that are both valid CGA and HBA addresses" for ease of comprehension.

   the benefits of both approaches if needed.

4.  Cryptographic Generated Addresses (CGA) compatibility considerations

   First, the current Secure Neighbor Discovery specification [3] uses
   the CGAs defined in [2] to prove address ownership.  If HBAs are not
   compatible with CGAs, then nodes using HBAs for multihoming wouldn't
   be able to do Secure Neighbor Discovery using the same addresses (at

Spencer (nit): s/Discovery/Discovery (SeND)/

   least the parts of SeND that require CGAs).  This would imply that
   nodes would have to choose between security (from SeND) and fault
   tolerance (from shim6).  In addition to SeND, there are other

Spencer (nit): shim6 has not been introduced previously in this document -
need at least a reference here, and probably need to spell shim6 out at
least once.

   protocols that are considering to benefit from the advantages offered
   by the CGA scheme, such as mobility support protocols [13].  Those
   protocols would also become incompatible with HBAs if HBAs are not

Spencer (nit): difficult to parse - suggest something like "Those protocols
could not be used with HBAs if HBAs are not compatible with CGAs".

   compatible with CGAs.

   Even though a CGA compatible approach is adopted, it should be noted
   that HBAs and CGAs are different concepts.  In particular, the CGA is
   inherently bound to a public key, while a HBA is inherently bound to
   a prefix set.  This means that a public key is not strictly required

Spencer (nit): why "strictly"? the context seems to say "not required", no
adverb needed... unless you mean "a public key is not required to generate 
an HBA"?

   to generate an HBA.  Because of that, we define three different types
   of addresses:

   - HBA-only addresses:  These addresses are bound to a prefix set but
      they are not bound to a public key.  Because CGA compatibility,

Spencer (nit): I can't parse "Because CGA compatibility". Is the sentence 
saying "Because HBAs are compatible with CGA, ..."?

      the CGA Parameter Data Structure will be used for their
      generation, but a random nonce will be included in the Public Key
      field instead of a public key.  These addresses can be used for
      HBA based multihoming protocols, but they cannot be used for SeND.

6.  HBA-Set Generation

   1. Multi-Prefix Extension generation.  Generate the Multi-Prefix
      Extension with the format defined in section 3.  Include the
      vector of n 64-bit prefixes in the Prefix[1...n] fields.  The Ext
      Len field value is (n*8 + 4).  If a public key is provided, then
      the P flag is set.  Otherwise, the P flag is reset.

Spencer (nit): "is reset" - I don't actually know what this means. s/is 
reset/is cleared/?

   6. For i=1 to n do

Spencer (nit) just for clarity, suggest s/n/n (number of prefixes)/?

      6.4.  Perform duplicate address detection if required.  If an

Spencer: not sure why "if required" is here. Can you give explicit guidance 
on when duplicate address detection can safely be bypassed? (and I am 
concerned about people who take code targeted for environments where DAD can 
be bypassed and porting it into environments where DAD is required, but 
let's ignore that for now).

         address collision is detected, increment the collision count by
         one and go back to step (6).  However, after three collisions,
         stop and report the error.

7.2.  Verification that a particular HBA address belongs tto the HBA set

Spencer (nit): s/tto/to/

      associated to a given CGA Parameter Data Structure

   For multihoming applications, it is also relevant to verify if a
   given HBA address belongs to a certain HBA set.  An HBA set is
   identified by a CGA Parameter Data structure that contains a Multi-
   Prefix Extension.  So, it is then needed to verify if an HBA belongs

Spencer: "needed to verify" appears twice in two sentences, and I don't 
understand what it means. I'm guessing this is saying something like "needed 
to verify", but I'm really in the weeds here (I'm not sure who is doing the 
verification, either - I can guess, but I can't figure that out from the 
text)

   to the HBA set defined by a CGA Parameter Data Structure.  It should
   be noted that it may be needed to verify if an HBA belongs to the HBA
   set defined by the CGA Parameter Data Structure of another HBA of the
   set.  If this is the case, the CGA verification process as defined in
   [2] will fail, because the prefix included in the Subnet Prefix field
   of the CGA Parameter Data Structure will not match with the one of
   the HBA that is being verified.  However, this doesn't mean that this
   HBA does not belong to the HBA set.  In order to address this issue,

Spencer: the last few sentences are difficult to parse, at least for me. I 
think the text is saying "HBAs will fail to pass the CGA verification 
process defined in [2], because the prefix included in the Subnet Prefix 
field of the CGA Parameter Data Structure will not match the prefix of the 
HBA that is being verified. To verify if an HBA belongs to an HBA set 
associated with another HBA, verify that the HBA prefix is included in the 
prefix set defined in the Multi-Prefix Extension, and if this is the case, 
then substitute the prefix included in the Subnet Prefix field by the prefix 
of the HBA, and then perform the CGA verification process defined in [2]". 
If this isn't what you meant, that's a problem, too :-)

      2.2.  Check that the subnet prefix in the CGA Parameters Data
         Structure is equal to the subnet prefix (i.e., the leftmost 64
         bits) of the address.  The CGA verification fails if the prefix
         values differ.  [Note: This step is trivially successful
         because step 1]

Spencer (nit): s/is trivially successful because/always succeeds because of 
the action taken in/

8.  Example of HBA application to a multihoming scenario

   Host2 in not located in a multihomed site, so there is no need for it

Spencer (nit): s/in/is/

   to create HBAs (it must be able to verify them though, in order to
   support the shim6 protocol, as we will describe next.)

   Eventually, the communication will end and the associated shim6
   context information will be discarded.

Spencer: this sentence probably doesn't belong in this spec (it's not about 
HBAs, it's about shim6 context management), but if it stays here, it should 
probably point to a specific section of a SHIM6 protocol specification...

8.1.  Dynamic Address Set Support

   In order to verify this new address, CGA capabilities of PA:LA:iidA
   are used.  Note that the same address is used, only that the
   verification mechanism is different.  So, if Host1 wants to use PC:
   LC:addC to exchange packets in the established communication, it will
   use message of the shim6 protocol, conveying the new address, PC:LC:

Spencer: is this "use the Update message of the shim6 protocol"? If so, a 
pointer to section 5.10 of the protocol draft would be helpful.

   addC, and this message will be signed using the private key
   corresponding to the public key contained in CGA_PDS_A. When Host2
   receives the message, it will verify the signature using the public
   key contained in the CGA Parameter Data Structure associated with the
   address used for establishing the communication i.e.  CGA_PDS_A and
   PA:LA:iidA respectively.  Once that the signature is verified, the
   new address (PC:LC:addC) can be used in the communication.

11.3.  Interaction with IPSec.

   In the case that both IPSec and CGA/HBA address are used
   simultaneously, it is possible that two public keys are available in
   a node, one for IPSec and another one for the CGA/HBA operation.  In
   this case, an improved security can be achieved by verifying that the
   keys are related somehow, (in particular if the same key is used for

Spencer: this is over my head, but did SECDIR go for recommended key sharing 
here? If they're good, I'm good...

   both purposes).  The actual verification procedure is outside the
   scope of this specification. 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art