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

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 16/05/2005, a las 19:18, Erik Nordmark escribió:

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

right, good point.
but in the three way reachability test that is outlined in the faildet 
draft, this exchange could be good for both purposes, right?
i mean, to verify reachability in both directions and flood prevention 
in both sentences... i guess that for determining what is achieved in 
the case of failure would require additional analysis

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

Ok, i can live with that.
So conceptually we need three different mechanisms:
- reachability test for (unidirectional) path exploration
- flood prevention mechanism
- context loss detection mechanism

We can now try to understand what it takes for each one of them, and 
eventually try to mingle them together later on.

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

:-)

ok, i guess that if we follow the dissection approach, we can first 
identify which information is required for each of the three exchanges 
above, and then, when trying to optimize by combining them, we can 
determine which info needs to be kept in the packets.

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

right

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

well, i guess that my perception is that ULP feedback is not so common, 
and that it will be common to fall back in reachability test to verify 
that the path is working...
Does current TCP usually implement this positive feedback for avoiding 
NUD?

Regards, marcelo