[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:
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?
Presumably they both need to exchange packets.
But that doesn't mean they flow in the same "directions" for the locator
pair testing and for the flooding attack prevention.
For instance, A might send packets to B (with B responding) to discover
that the A2<->B2 locator pair is working (in both directions), followed
by A telling B "please use locator pair <B2, A2>".
At that point in time B hasn't actually verified that A is present at
locator A2, since B hasn't done a packet exchange that verifies this.
B needs to send a packet to A2, and expect A to send back the response
in order to prevent the 3rd party flooding.
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?
If the packets are exchanged in the "right" direction, one can
presumably optimize this. But I'd prefer waiting with optimizations
until we have the pieces worked out.
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.
The benefits is that you don't need to also worry all the different
combinations of reachability test outcome and context state present.
My head starts hurting if I try to do all of that at the same time.
However, it *might be* that a test mechanism which includes both the
ULID and the context tag(s) would be part of an optimization that can
minimize the number of messages. That allows the receiver to distinguish
between a test packet delivered to the wrong ULID (perhaps a 3rd party
DoS attempt, or a bit error in transit) and one delivered to the correct
ULID, but no context state which matches the context tag.
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?
Agree that this is not clear, but from 30.000 meters it seems that:
- reachability tests may be performed quite often
I think we can use the same host mechanism which avoids NUD probes to
avoid reachability tests (this mechanism is a positive advise
"everything is fine" from the transport layer to the IP layer).
For transports like TCP that is sufficient.
- 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
Yes, you'd want both the ULIDs and the context tag to be able to make
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...)
You hope the packets will follow as disjoint paths as possible, but that
doesn't mean that you can assume that there will be no common point of
congestion between the paths (which really aren't "paths" but merely
different locator pairs).