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

below...

El 16/11/2004, a las 19:12, Mohan Parthasarathy escribió:

> Marcelo,
>
> Comments inline..
>
>>
>>> 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 ?
>>
>> 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)
>>
> I thought we have 3 different types of addresses now. The procedure to
> compute the hash is different depending on HBA or CGA  i.e include the
> public key or extended modifier depending on CGA or HBA. So, why does
> it matter if we can specify something different for HBA address ? Both 
> ends
> know they are operating on an HBA address. So, what is the 
> compatibility
> issue ? Could you elaborate on that ?
>

Well, the HBA is defined always (in the 3 cases) as an extension of the 
CGA.
i agree with you that we could define the HBA as an extension of the 
CGA when the CGA is also used (i.e. the HBA/CGA hybrid) and define the 
HBA in a different way when the CGA are not used (HBA only mode)
But i am not sure this is worthy, since i guess it would be more 
complex since you need to handle multiple generation algorithms, 
depending in the case. suppose the case when a a communication has a 
CGA/HBA and a HBA only in the other side, this would probably would be 
more complex either. I mean, having a different generation for the 
generation of the HBA only case would essentially provide that all the 
iids are the same in an HBA set, but with an additional complexity in 
the implementation, do you think that it is worthy?



>>>  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 ?
>>
>> 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
>>
>
> Agreed.
>
>>> there is not much we can do here i guess. Perhaps, this should be
>>> mentioned somewhere.
>>>
>>
>> Ok, i will mention this in the privacy consideration, thanks
>>
>>> 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 ?
>>
>> 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
>>
> Okay.
>
>
>>>
>>> 4)When the multi6 state is setup, i assume that the CGA parameter is
>>> exchanged between the
>>>   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)
>>
> Yes, that's what i meant. I assumed that whatever is not there in this
> draft is present in one of the other 5 drafts :-)
>
>>> 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 mean, you can generate the address and include it..but it is not 
> needed as
> you mention below..
>
>>>  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.
>>
>> 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
>>
> Agreed.  I was thinking in a slightly different direction which may not
> be needed i guess. Somebody in one of the multi6 meeting raised a 
> point about
> computing the hash and verifying it as expensive. First, the hash is 
> not computed
> always i guess. Only after the rehoming occurs. But once the rehoming 
> occurs, you
> have to recompute always as long as the locator does not match the 
> ULID. Is that right ?
> Then i was wondering whether it is a real problem because it affects 
> the fast path processing
> of the packet. Perhaps not because it can be pre-computed.

>  But it may not be necessary
> i guess. The first packet after rehoming will trigger the hash 
> computation, but that can
> be cached i guess. Hence the subsequent packets can be compared 
> directly
> with the cached value. Does that make sense ?
>

Yes,
I mean, i would do the following.
first the communication is set up, and at some moment in time the CGA 
parameters are exchanged. For now, no hash calculation.
Suddenly, an different locator needs to be used. So at this point, i 
would run the verification process, implying a hash calculation.
then as long this is the locator that is used, i don't think that 
additional verification are needed, you just need to remember that this 
locator is OK
So, i would say that for a HBA set with n prefixes, the maximum number 
of hash verifications needed is n (independently of the number of 
packets exchanged with each locator)


>>>   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.
>>
>> 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,
>>>
>>>       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).
>>
>> 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
>>
> That should be  sufficient.
>
>>>
>>>    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.
>>>
>>
>> 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.
>>>    As it is hard for the attacker to redirect packets to a victim, is
>>> it needed ? Can it be optional ?
>>
>> 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.
>>
> I am not sure i understood the above sentence.

well as it is stated it is impossible to understand (i am sorry for 
that)

What i wanted to say was:

HBAs are mainly used to prevent hijacking attacks.
We will need reachability tests to prevent flooding
attacks.


However, an additional consideration about this...
Note that if HBAs are used, flooding a specific target host is very 
difficult, since i would need to find an HBA set that contains an 
address with the attacker prefix and that the address of the victim is 
included in the HBA set, agree?

this is very difficult (O^(59+(16*Sec)) difficult

However, the flooding attack can be easily directed to the access link 
or access router of the victim, since the attacker only need to include 
the prefix of the victim's network in the prefix set.

This means that the resulting HBA set won't contain any address of a 
real host within the victim's network, but in any case the flood will 
be routed to the access router of the victim's network flooding the 
access link and the access router.

So even if the flooding attack is slightly different, i guess that it 
would still make sense to provide some protection from it, agree?

regards, marcelo


>  First you say that HBA can
> be used to prevent flooding attacks and then you say that we need
> reachaility tests to prevent flooding attacks.
>
> -mohan
>
>> 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 protected] is no longer in use
>> Please send mail to:
>> marcelo at it dot uc3m dot es
>> ------------------------------------------
>>
>
>
------------------------------------------
Please note that my former email address
[email protected] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------