[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-bagnulo-multi6dt-hba-00.txt
Hi Mohan,
thanks for the review
replies inline....
El 15/11/2004, a las 0:22, Mohan Parthasarathy escribió:
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)
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
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
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)
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
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
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
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.
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
mbagnulo@ing.uc3m.es is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------