Re: soft state (was Re: shim6 and bit errors in data packet headers

[Erik Nordmark <erik.nordmark@sun.com>]

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 
> below.

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 
the ULID.

> 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 
> amplification attacks?

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.

  Erik