Re: Gen-ART Last Call review of draft-ietf-shim6-hba-04

[marcelo bagnulo braun <marcelo at it.uc3m.es>]

Hi Spencer,

thanks for the review

see comments below...


El 24/11/2007, a las 3:59, Spencer Dawkins escribió:

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

they are bound to each other, os i have put that i.e. that are  
inherently bound to each other
> 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/

ok

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

done

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

ok

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

ok

i have substituted shim6 by


  and fault tolerance (from IPv6 multihoming support provided by the
  Shim6 protocol <xref target="shimproto" />)

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

ok

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

right
i used the strcilty, because even if it is not needed, you can use  
it, resulting in hybrid HBA/CGA addresses, but i can also remove it  
from the sentence and the sense it is ok too.

I have removed the strcitly from next version of the draft

>   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, ..."?

right

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

i replaced it with:

"is set to zero"

>   6. For i=1 to n do
>
> Spencer (nit) just for clarity, suggest s/n/n (number of prefixes)/?

done

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

this is actually take literally from RFC3972 (CGA spec) and it is  
consequence of RFC3971 SeND

The point is that DAD can be used to launch a DoS attack so a node  
can discard DAD responses and even not consder responses from non  
send nodes in order to prevent such attack

from rfc3971

9.2.3.  Duplicate Address Detection DoS Attack

   This attack is described in Section 4.1.3 of [22].  SEND counters
   this attack by requiring that the Neighbor Advertisements sent as
   responses to DAD include an RSA Signature option and proof of
   authorization to use the interface identifier in the address being
   tested.  If these prerequisites are not met, the node performing DAD
   discards the responses.

   When a SEND node performs DAD, it may listen for address collisions
   from non-SEND nodes for the first address it generates, but not for
   new attempts.  This protects the SEND node from DAD DoS attacks by
   non-SEND nodes or attackers simulating non-SEND nodes, at the  
cost of
   a potential address collision between a SEND node and a non-SEND
   node.  The probability and effects of such an address collision are
   discussed in [11].

so, i would like to keep that text, so this is fully compatibl with  
rfc3971 and rfc3972, ok?

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

ok

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

ok, i have changes it is needed to verify bu we need to verify,  
resulting in the following text:

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, we need to verify if a given HBA belongs to the HBA set
defined by a CGA Parameter Data Structure. It should be noted that we  
may
 need to verify if an HBA belongs to the HBA set defined by the CGA  
Parameter
Data Structure of another HBA of the set

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

your understanding is correct. i have substituted the text for the  
one you have suggested above

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

ok

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

ok

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


ok, i have removed it from the spec

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

right

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

i have removed this section

thanks again, marcelo


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


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf