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

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

marcelo bagnulo braun wrote:

> I mean, is it possible to create two contexts between the same two nodes 
> with the same two ULIDs (and perhaps a different context tag)? would 
> this make any sense?

It doesn't seem useful to me.


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


> :-)
> Context state AND path failure AND unidirectional connectivity.... this 
> seems amusing enough

Yep. It's like a car where one can turn left, hit the breaks, while the 
CD player is searching for track 3. All at the same time! Wow! :-)

The easiest way to deal with such complexity is to make sure the 
mechanisms are independent (the CD player doesn't connect to the break 
system etc).

> 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. 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" and 
perhaps also trigger its own exploration of the B->A direction (since it 
knows that Ai,Bj works for the A->B direction).

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

There is a potential for reflection attacks when A asks B to respond to 
a different locator, but there is no amplification involved here. 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.

> in the flow label case, this is not enough, as you point out below, you 
> also need a shim bit to indicate that this is shim data packet, right?

Yes, you need to know it is a shim packet (just like TCP only operates 
on TCP packets, the shim should only operate on shim packets).

   Erik