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

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

El 13/05/2005, a las 2:24, Erik Nordmark escribió:
>
...
> > Well, i guess that what i am assuming is that a shim enable context 
> > will verify that received reachability test packets corresponds to an 
> > existent context, i.e. that upon the reception of a reahcability 
> > test, the node will verify that this corresponds to an exsitent 
> > context. If it does, it will reply, if not it won't
> > I don't know if you consider that i am assuming something else... 
> > (please let me know)
>
> The above assumption is what I find problematic.
> > The above assumption is based in that i think this is needed to 
> > properly protect from flooding attacks.
>
> I'm far from convinced. See below.

Ok, i think we are considering different types of attacks:

From what i understand there are three types of attacks involved here:

- DoS attack when establishing a new shim context: this is the case 
where the attacker plays the role of an initiator and tries to DoS a 
receiver, through resource consumption, in particular, memory of CPU 
exhaustion. (this type of attacks is taken into account in reachability 
exchange you describe below)

- Flooding attacks (with or without amplification) when  establishing a 
new shim context: In this case, the attacker also plays the role of an 
initiator and uses the initial reachability test defined for 
identifying working address pairs for initial contact for flooding a 
third party. In this case, the situation is that the receiver has no 
context (or very limited) and the packets involved are only the packets 
associated with the reachability test exchange (this type of attack is 
also taken into account in the reachability test exchange that you 
describe below)

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

Let me put an example:

Attacker X address IPX
Server S address IPS
Victim V address IPV

Attacker X initiates a communication with Server S and creates a shim 
context with ULIDs IPX and IPS, and X include IPV as an alternative 
locator for IPX.

Next, X starts downloading a heavy flow from S
Next, X rehomes to communication to IPV, flooding V

One mechanism to prevent this attack is to use a reachability test, 
right?

I mean, if we include a reachability test it would look like this, i 
guess:

Attacker X initiates a communication with Server S and creates a shim 
context with ULIDs IPX and IPS, and X include IPV as an alternative 
locator for IPX.

Next, X starts downloading a heavy flow from S
Next, X rehomes to communication to IPV,
However, S before sending packets to IPV performs a reachability test 
to IPV, in order to verify the the node sitting at IPV is willing to 
receive packets.
Now the question is which information needs to be included in this 
reachability test in order to make it useful to prevent the considered 
flooding attack?
If no context information is included in the reachability test request 
sent by S to IPV, then V is not able if this reachability test request 
is associated to one of its own contexts, or a reachability test 
performed for initial contact or if this is an atempt of flooding 
attack as described.
This is important, because V should react differently in the different 
cases (V should reply to the reachability test request in the first two 
cases and not reply in the third case, in order to prevent the attack)

So, i think that we have different situations here:

- reachability test request for exploring address pairs for initial 
contact do not carry context information (since ther is no context 
created yet)

- reachability test request for exploring alternative address pairs for 
rehoming an established communication require context information in 
order to prevent flooding attacks

In the second case, i still think that it is reasonable to assume that 
a shim enable context will verify that received reachability test 
packets corresponds to an existent context, i.e. that upon the 
reception of a reahcability test, the node will verify that this 
corresponds to an exsitent context. If it does, it will reply, if not 
it won't

BEsides, i think this is the case to consider when we are dealing with 
lost state, since one of the nodes still has the state, so when it 
sends a reachability test request it will include the context 
information in the packet.

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


>
...
> > Ok, but let's first discuss how do we deal with this situation when 
> > establishing the initial context, so we can then move to this 
> > scenario after a context loss event, agree?
>
> I think it is actually more fruitful to try to design a test protocol 
> which doesn't assume context state on the peer and that can cope with 
> a DoS.

As i mention above, i think we are considering different DOS attacks...

>  I see two avenues to pursue here:
> 1. Limiting the amount of state on the peer (some finite size) but 
> allow
>    it to be non-zero, since this can be an important performance
>    optimization.
> 2. A test protocol with no state created on the peer.
>
> Here is a rough sketch of such a test protocol.
> Assume that A has n IP addresses (A1,,An) and B has m IP addresses 
> (B1,,Bm).
>
> To find a working bidirectional locator pair we need to try m*n 
> combinations. But when the locator pairs can be unidirectional, then 
> we need to be able to test the m*n combinations in each direction, for 
> a total of (m*n)^2 combinations.
>
> A can do this by explicitly instructing B which source and destination 
> locator to use in its response.
> Thus A would send from Ai to Bj asking B to respond from Bk to Al 
> (letter L).
> This doesn't require any state being created on B, but the search 
> space is huge (36 combinations if n=2, m=3 for example).
>
> We can optimize this case when it is ok for B to create state.
> This can always be ok when B knows that the locators are part of some 
> existing context.
> But it can also be ok for a small number of tests (basically, B having 
> a fixed amount of memory dedicated to this).
> In such a case, B can indicate to A "I have heard you using Ai,Bj"

so far, i agree

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

> Such an optimization is important. If you take the (unlikely case) 
> with m=3,n=2 when only one locator pair works in each direction and it 
> is a different pair for each direction, then with no state on B, A has 
> to scan 36 combinations thus on average it is likely to find the only 
> working combination after 18 tries.
> But if B can retain state, then A can try all the different 
> combinations for the forward path. There are only 6. So on average B 
> will receive a packet from A after 3.5 tries.

right

> This can then trigger B to try the 6 combinations for the reverse 
> path, resulting in an average of about 7 tries to find the combination 
> of pairs that work.


here is the part that i am concerned, since B would generate 6 packets 
as reply to one packet, right?

> There is a potential for reflection attacks when A asks B to respond 
> to a different locator, but there is no amplification involved here.

no? i mean, B is doing its own exploration to all available locators, 
right?

>  Also, we can design the protocol so that B's response always includes 
> the locators from the request. This means that if X is sending a 
> packet to B, telling B to respond to IP address A, then A can at least 
> tell that it was X that triggered the response.
>
> > i deduce from your statement that you are considering the possibility 
> > to perform reachability tests that are not bound to any context, so 
> > it can be used for initial contact, right?
>
> Correct.

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


Regards, marcelo