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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 14 Nov 2004 15:22:19 -0800

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Nov 2004 13:27:18 +0100

Mohan Parthasarathy wrote:
...
> Is there a document

We have no plan to produce a security requirements document. Obviously, the
solution architecture will need to contain an analysis of how it deals with
all the identified threats. HBA is not a total solution, so it doesn't
need to do that.

     Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Nov 2004 15:10:18 +0100

Hi Mohan,

thanks for the review
replies inline....

El 15/11/2004, a las 0:22, Mohan Parthasarathy escribió:

> in the second hash calculation (Hash1 in CGA draft) sufficient ?

Yes, but this imply not to be compliant with CGA spec.
in other words, if we are compliant with CGAs, the iid will be 
different and it wouldn't be possible to have equal iids

we felt that cga compatibility was more important than supporting equal 
iids in the HBAs of a given set (note that we do see some value in 
having equal iids, for instance for simplified management, but this 
cannot be provided in the CGA format)

>  It might be worth mentioning the procedure.
>
> periodically regnerate the HBA ?

i think so

>  Though this is more expensive than RFC 3041 privacy addresses,

I guess that it depends in the Sec value...
If Sec =0 then i guess than generating an HBA is similar to generate a 
random number. I mean, you only need to add 1 to the modifier and 
perform a hash operation (probably generating random addresses requires 
a similar effort)
If Sec>0 then i agree

> there is not much we can do here i guess. Perhaps, this should be 

Ok, i will mention this in the privacy consideration, thanks

> What do you mean by reliability here ?

fault tolerance i.e. the fault tolerance and other features provided by 
the  multi6 protocol based on the usage of HBAs

i will try to reword this in the draft

>   communicating parties.

if you mean the CGA parameter data structure including the multiprefix 
extension, then yes
(BTW i need to state this explicitly in the draft)

> 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 following you here.
The CGA parameter data structure is used to generate the iid of the 
addresses, so how can you include the complete address in it if you 
still haven't generate it yet.... i am probably missing your point here

>  I am not able
>   when a packet with different locator comes in.

but this can be done with the current CGA parameter data structure, 
right?
i mean, the HBA set generation only uses the info contained in the CGA 
parameter data structure, so once the peer has the CGA parameter data 
structure, it can regenerate the whole HBA set before the rehoming, as 
you suggest.

i mean, i think you can do this that you suggest already

>   I am not saying we should do it this way.
> 5) Security considerations need to be improved.

agree

>  It would be good to discuss what attacks it
>    addresses with respect to the threats document.

agree, but note that HBAs are not a complete multihoming solution, and 
are useful to prevent certain attacks, not all the threats described in 
the threats drafts

> In the beginning of the document,
>

well, i guess that the arch document that we are suppose to write next 
should at least specify the security goals that the designed solution 
is trying to achieve

>    set given a set of victim's addresses. It was not very obvious by 
> reading the security consideration section.
>

agree, i will include an example of usage and possible attempts of 
attacks, and see if this improves this point

>    Also, how important is return routability for the locators  before 
> they are used ? It is not discussed here.

very good point
HBAs are mainly used to prevent hijacking attacks and to prevent 
flooding attacks. We will need reachability tests to prevent flooding 
attacks. I will include this also in the doc.

Thank you very much for your constructive comments
I hope i can address them in a satisfactory manner in the next version. 
Please let me know if i wasn't successful

regards, marcelo

> -mohan
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Mon, 15 Nov 2004 16:25:05 +0100

In your previous mail you wrote:

=> I agree. In fact, to get the same IID for all prefixes is not
a good property IMHO.

   
   
=> you should because HBAs are compatible with CGAs...   

   
=> the CGA draft is pretty clear about this.

   
=> in fact this is clearer in the CGA document: this problem is to the
good parameters which will hash to the given 59+16*sec bits (note
the number of prefixes don't really matter, i.e., it doesn't add or
remove bits to the problem to solve for attackers).

Thanks

[email-masked]

PS: BTW CGA IPR holders provide royalty-free licenses only for SEND,
can they update their IPR texts on the IETF web for HBAs too?

---

From: Jari Arkko <[email-masked]>
Date: Mon, 15 Nov 2004 17:50:50 +0200

> can they update their IPR texts on the IETF web for HBAs too?

FYI: I have asked the Ericsson IPR department to inform the
IETF about their licensing conditions regarding the HBA draft
and usage in MULTI6.

--Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Nov 2004 16:55:24 +0100

Francis Dupont wrote:
...
> can they update their IPR texts on the IETF web for HBAs too?

We could leave this issue until we have a WG chartered and
an item intended for the standards track. But it would be nice.

     Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 18 Nov 2004 16:23:03 +0100

> IETF about their licensing conditions regarding the HBA draft

Shouldn't we try to determine whether the patent even applies in the 
first place?

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Nov 2004 16:50:18 +0100

=> as the HBA idea is an extension of the CGA one, I can't see how the
patent can apply to CGA but not to HBA... No, the problem is real,
but it should very easy to fix with a better wording in the IPR note.

Thanks

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 18 Nov 2004 17:09:47 +0100

El 18/11/2004, a las 16:50, Francis Dupont escribió:

> => as the HBA idea is an extension of the CGA one,

I disagree

The HBA uses the format of CGA in order to provide simoultaneous 
support of SeND and CGA
We could prefectly define HBA with a different format, so that it is 
not extension of CGA (this would cause problems when using multi6 and 
send of course, which is bad)

But the point is that HBA are defined as a CGA extension just to allow 
Send and multi6 run together

regards, marcelo

> I can't see how the