[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:
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
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
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
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
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?
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).