[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: flow label demultiplexing
El 18/04/2005, a las 22:27, Pekka Savola escribió:
On Mon, 18 Apr 2005, marcelo bagnulo braun wrote:
Note that HBA+CGA in one doesn't help (AFAICS) because otherwise
you'd be trusting anyone you have a public key with to not hijack
any of your sessions?
Well, i guess not.
In the CGA case, the address being used as the ULID for the
communication is a CGA that contains a hash of the publich key in the
iid. In this case, you will only trust a public key whose hash
matches the iid of the ulid.
Sure.
So, when you use CGA capabilities of the address, the CGA parameter
data structure is exchanged upfront and it contains the public key.
Next, the node can use a new address (that was not included in the
CGA parameter data structure) because it can authorize it by signing
it with the private key corresponding to the CGA. Moreover, such
signature could even be included in a packet that contains the new
address as source address (i think)
I mean, with CGA there is no need to know the addresses before hand.
OK, I guess you'll assume that
1) the CGA implementations would check the prefix, i.e., that anyone
who claims to be of prefix A::/64 has a certificate to use that
prefix, and can present that?
No, i am not assuming this.
Otherwise you trusting me would allow me to say I'm in control of a
third party's prefix, right?
Not a prefix, but just an address of that prefix, right?
I mean, through this message, the mh node is saying that this new
address (of a different previously unknow prefix) is his current
locator. but see below, becuase i guess we may be misunderstanding each
other...
2) delegation path discovery works across the internet so you can
actually find a common trust anchor, and
I am certainly not assuming this...
3) you sign the whole [shim6 exchange, and in this case everything,
if it's piggybacked] packet. But CGA is only defined for neighbor
discovery options...
I am certainly assuming that we are signing the alternative locator
information carried in a SHIM message using the private key of the CGA.
Agree that this is not a usage that is currently defined for CGAs, but
i guess that could be defined within the SHIM protocol
As such, embedding the public key in the CGA/HBA address protects
against the third parties trying to spoof another person's identity,
but does not protect against the responder lying.
Right.
Now, my understanding of this is the following:
We need to prevent basically two types of redirection attacks:
hijacking and flooding (this is basically what the threat analysis
says)
Now, using CGAs (or HBAs) basically, hijacking protection is achieved.
In order to prevent flooding, i guess that the easiest way if to
preform a reachability test to the address, in order to find out if the
target is willing to receive packets.
At this point, an interesting question is raised: do we need to perform
the reachability test in order to receive packets or is it enough to
perform the reachability test before sending packets to the new
locator?
As far as i understand, it would be safe enough to accept packets
perfoming only the CGA (or HBA) verification and delaying the
reachability test untli there is a need to send packets. This is so
becuase, the reachability test is used to prevent flooding attacks,
i.e. we need to do it before sending packets to that locator.
Such configuration would allow to receive packets from previously
unknown locators, delaying the rechability verification until we need
to send packets to those locators.
make sense?
Regards, marcelo
(This is really bad if one would use something like opportunistic
encryption rather than real "he's my very good friend, he won't try
tricks" trust.) We need to deal with that as well. The above three
mitigate this to a great extent, I think, but to a significant cost..
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings