[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: soft state (was Re: shim6 and bit errors in data packet headers
marcelo bagnulo braun wrote:
- Flooding attacks once the shim context is established: in this case,
an attacker creates a context with a server and starts downloading a
heavy flow (i know you know this story, but just to make sure we are
sync), then the attackers rehomes the flow towards an alternative
address that belongs to the victim, so the victim is flooded. In this
case, the server has context state and the packets involved in the
flooding are the data flow (not only reachability test packets) Imho, if
we are going to use a reachability test exchange to prevent this attack,
then the reachability test exchange requires additional information than
the one is included in the reachability test exchange that you describe
FWIW I've been assuming that the purpose of the locator pair test
protocol is merely to test which locator pairs are working.
Shim6 does need a way to prevent this kind of 3rd party flooding
attacks, by verifying that A is indeed present at locator A2, but I
don't see why this needs to be done at the same time as searching for a
working locator pair.
Conceptually there is a big difference between searching for a working
locator pair and verifying whether one of the locators that A says it
has, does indeed reach ULID A.
This is because for preventing this attack, the victim needs to
know what is the context that is associated with the reachability test
that it is replying to, in order to verify that the future incoming flow
corresponds to an existent context.
You still don't need to check the context tag. It is sufficient to
verify that the ULID A1 is acceptable by whoever responds at locator A2.
- reachability test request for exploring alternative address pairs for
rehoming an established communication require context information in
order to prevent flooding attacks
To prevent the 3rd party flooding attack this verification just needs
OTOH, i think that both reachability test exchange will be similar in
all the other aspects ( i mean, i don't think that two different
reachability tests are required for this two situations, only that in
one case it will be required to carry context information and in the
other one it won't. However, such context information can be useful to
detect loss of context, i think
I still have to work out some details to figure out if this really helps
in detecting a lost context.
and perhaps also trigger its own exploration of the B->A direction
(since it knows that Ai,Bj works for the A->B direction).
at this point i wonder if this exploration may not result in
Perhaps. But any damage can be limited by this being (in addition to
applying to existing contexts) limited to a few and rate limited tests.
here is the part that i am concerned, since B would generate 6 packets
as reply to one packet, right?
Yep, but they need to be spaced out according to whatever congestion
control constraints we have in any case.
I think this test protocol is ok for initial contact, but that we need
additional protectio from flooding attacks in the case of a rehoming of
an existing context, as i described above. for this, context information
is to be included in the exchange
Yes. But to me that is a conceptually different protocol mechanism.