Comments on draft-bagnulo-multi6dt-hba-00.txt

["Mohan Parthasarathy" <mohanp@sbcglobal.net>]

I had a few comments/questions on this draft. Sorry if some of them have already been
asked (i did not look closely at the archives).

1) In section 1,

   In addition, it should also be noted that it
   is not required that all interface identifiers of the addresses of an
   HBA set are equal, preserving some degree of privacy through changes
   in the addresses used during the communications.

To create all addresses (for various prefixes) with same interface identifiers, what is the
change that would be needed ? Does including the multi-prefix extension and removing the subnet-prefix
in the second hash calculation (Hash1 in CGA draft) sufficient ? It might be worth mentioning the procedure.

2) If HBA is used and the node wants RFC 3041 privacy addresses, it means that it needs to
periodically regnerate the HBA ? Though this is more expensive than RFC 3041 privacy addresses,
there is not much we can do here i guess. Perhaps, this should be mentioned somewhere.

3) In section 2,

      First, the current Secure Neighbor Discovery specification [2] uses
      the CGAs defined in [1] 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
      least the parts of SeND that require CGAs).  This would imply that
      nodes would have to choose between security (from SeND) and
      reliability (from multi6)

What do you mean by reliability here ?

4)When the multi6 state is setup, i assume that the CGA parameter is exchanged between the
  communicating parties. I was wondering whether it would make any difference between including
  the prefix Vs the whole address itself in the CGA parameter data structrure ? I am not able
  to see anything less secure by including the whole address itself. One possibility is that
  the peer can compute and validate the address ahead of time (which is of no use if rehoming
  will never occur) and hash verification becomes a simple comparison 
  when a packet with different locator comes in.  I am not saying we should do it this way.
  I was mainly trying to understand what it means  to include the address instead of prefix.


5) Security considerations need to be improved. It would be good to discuss what attacks it
   addresses with respect to the threats document. In the beginning of the document,

      This memo describes a tool that can be used to provide protection against some
      of the potential attacks, in particular against future/ premeditated
      attacks (a.k.a.  time shifting attacks in [6]).

   I hope the future version of the document would explain more on this. Is there a document
   that explains what threat needs to be addressed by multi6 solution ? (the threats document
   mentions this in a few places, but does not look like requirements to me).

   One of the inferences from the security consideration section is that the attacker cannot create an HBA
   set given a set of victim's addresses. It was not very obvious by reading the security consideration section.

   Also, how important is return routability for the locators  before they are used ? It is not discussed here.
   As it is hard for the attacker to redirect packets to a victim, is it needed ? Can it be optional ?

-mohan