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

Yes.

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? 

Yep


Agree that this is not clear, but from 30.000 meters it seems that:
- reachability tests may be performed quite often

Why so?
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 context loss)

Yes, you'd want both the ULIDs and the context tag to be able to make this distinction.


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

   Erik