[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address pair exploration, flooding and state loss
El 26/05/2005, a las 23:02, Erik Nordmark escribió:
marcelo bagnulo braun wrote:
but this would require to include in all data packets of a context
session the following information:
- some indication that this is a shim data packets (note that until
now, data packets exchanged within a shim session that used ULIDs as
locators were not necesarily tagged as shim packets i.e. there were
simple IP packets. this would need to change if these data packets
are to be used to detect context loss)
- some context identifier in order to properly id to involved context
- some random nonce in order to limit TCP rst type of attacks to mitm
Note that the flow label option for carrying context id can carry a
context id, perhaps a shim flag bit but i guess it cannot carry the
The extension header can carry the three of them, but it may be
required to carry it in all shim data packets
I'm not sure what type of state loss you are trying to guard against,
because there are at least two.
1. B crashes and reboots hence it looses all shim6 as well as
transport and application state.
2. The shim6 layer on B garbage collects some context too early - when
there is still some use of it.
In #1 it is key that we can get A to realize that the context has been
lost on B, so that we can get to the point where the shim on B can
pass up the packets to the ULPs. This will cause the ULPs to generate
errors (e.g. TCP RST) and we are back to what we have today without a
besides at this point, there is no possible recovery, since ULP state
also has been lost
For #2 I think we should figure out how an implementation can minimize
the occurrence. But in many implementations I suspect we can't
completely get rid of them when there are long lived UDP "sessions" in
the applications; the kernel TCP/UDP/IP stack wouldn't be aware of
this is the case that i am more concerned, since this would be the case
where the shim mechanism behaviour results in communication
Above you seem to be concerned about case #2, with the added twist
that the context state has been established but the original ULIDs
still work as locators.
I think I commented before that the heuristics on B for deferred
context establishment might recover from this. If the heuristic is to
try to set up a shim6 context after N packets, then after N packets
have passed, B would try to set up a context with A, at which point A
would see that it already has a context with B.
right, the only point that i wonder w.r.t. this is if it is wise to
base the context loss detection procedure on the heuristics to
establish shim context... i mean, the heuristics for establishing shim
context may greatly vary, i guess. For instance, i think it may be a
possibility that some heavy loaded servers use the policy to never
initiate shim session establishment procedure, but they only accept
establishment request from clients. In such a case, they wouldn't
detect context loss.
In any case, if the procedure you described in the previous mail for
including both the context identifier and the nonce in a compact way in
20 bits, we could stuff all we need in all data packets, i guess, so if
the flow label approach is used, all data packets of established shim
sessions can be identified as such
Should the <A1, B1> locator pair fail before those N packets, then if
A detects the failure it will start probing additional locator pairs.
As you've pointed out earlier, it makes sense for this probing to also
be able to detect when the context is unknown to B.
So I think the only case which might be problematic is when
- B garbage collects the context state while it is still used
- <A1, B1> stops working before N packets have been exchanged after
- A doesn't detect that there was a failure (because A isn't trying to
In this case B wouldn't be able to recover, because it doesn't have
any context state hence doesn't know the alternate locator pairs.
I don't think this case is common enough to warrant sticking a lot of
extra bits in each data packet.
agree, the question is what happens if the session context
establishment heuristics are different.
I wonder if it is even worth while to include one extra bit in the
data packets (this would be a bit which asserts that the sender has
shim6 state for the context).
ok, now i am confused
AFAIU until now, if we want to detect context loss based on the
reception of data packets, we need to have some falg in the data packet
that this packet belongs to a existent shim session. If we eliminate
this bit, then we cannot detect loss context from data packets, right?
or have i lost track of our reasoning?
It's hard to find a free bit, and the "usual" :-) place to steal one
is the nexthdr field, which would raise a bunch of issues about
firewall uniformity. (If a TCP packet is 6 before the context state is
setup, and e.g. 250 after it has been setup, then firewalls might drop
the packets after the setup even though the initial TCP packets made
So I'd punt on this rare case. If B drops context state too early then
it shouldn't be surprised if failover to a different locator pair