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

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 14/05/2005, a las 1:56, Erik Nordmark escribió:

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

agree with the point that conceptually these are different things.
However, i think that both verifications require a packet exchange, 
that needs to be performed before sending packets using the involved 
addresses.
I mean, for path exploration we need to verify that packets sent using 
the address pair get to the destiantion
For flooding attack prevention, we need to verify that the node that is 
located in the proposed target address is willing to receive the 
packets of the existing communication. The only way to do this AFAICS, 
is to send a packet to the new locator and see if the node receiving 
packets sent to that address is willing to receive packets of the 
communication. Can you think of alternative mechanisms to perform 
flooding prevention that does not involve a packet exchange to the new 
address?

I mean, if we need to perform a packet exchange to explore alternative 
paths and we also need a packet exchange in order to prevent flooding, 
i guess it would be reasonable to do it in the same packet exchange, in 
order to reduce the number of packets, agree?

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

So, the alternative would be to include the ULID in the reachability 
test request instead of the context identifier?

I think this could be an option to prevent flooding attacks, but i am 
not sure what are the benefits of such approach.

Let me write down how this would look like in order to make sure that 
we are on the same page:

node A with IPA1 and IPA2, node B with IPB1 and IPB2

node A is communicating with node B and a shim context is established 
with ULIDs IPA1 and IPB1.

Node B includes IPB2 in the locator set available for that 
communication.

Now, node A detects a failure and performs a reachability test to 
explore alternative paths and perform flooding prevention.

The packet sent from A to B is a reachability test request that 
contains the following information:

IP src: IPA1
IP dst: IPB2
Packet type: reachability test request
Additional info: IPB1 as ULID associated with IPB2

Now, when node B receives such packet, it can reply because it has 
received it (the path is working) and both IPB1 and IPB2 belong to him 
(no flooding threat)

Is something like this what you had in mind?

I think such scheme would work, but i am not sure about the benefits of 
such approach w.r.t. to the case where the full context information is 
carried in the reachability test request.

If full context information is included, i guess it would be easier to 
detect the cases where there is a context loss

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

Agree that this is not clear, but from 30.000 meters it seems that:
- reachability tests may be performed quite often
- if those carry context information, then they can provide a hint of a 
context loss event, since a node that receives such a packet and does 
not has the associated context can reply saying the no context is 
available, allowing the other end (which does have context information) 
to detect the problem. BTW i guess that the error message could inform 
if the problem is that the ULID does not belong to the node (potential 
flooding) or the context tag is non associated to any context 
(potential context loss)

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

well, as i see it, the different packets will be addressed to different 
addresses, right? so i am not sure that congestion control would limit 
the rate of packets, since they will be routed through different paths 
(i am assuming that congestion control is performed per path basis, 
which i am not sure would be the case though...)

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

as i said above, conceptually they are different, but in practice, i 
would guess that they would be the same packet exchange for performance 
reasons.

regards, marcelo


>   Erik