[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt

On 15-jul-2005, at 21:14, Jari Arkko wrote:

There have been some discussions about positive versus negative
feedback. The first model doesn't have any use for negative feedback,
but needs positive feedback to reduce overhead. The second model has
little or no use for positive feedback, but may use negative feedback
to detect failures faster.


Can you explain why the first model wouldn't be able to use negative
feedback for faster failure detection? It seems like it could use a
trigger from TCP to send a probe earlier than it would otherwise
do it.

(The "first model" is the neighbor unreachability detection -like one, the "second model" is one where the shim makes sure there is always be bidirectional packet flow so packets flowing in just one direction means there are problems.)

In the first model the idea is that upper layer protocols say "going well, going well" so the shim knows it doesn't have to send probes to see if everything still works. When the upper layer protocol stops providing positive feedback, the upper layer protocol starts probing. As I remarked earlier, in a binary system, not saying yes is the same thing as saying no. So negative feedback is the same as lack of positive feedback in this scenario.

Of course negative feedback would be a stronger signal than lack of positive feedback, but I don't think the difference would matter here, except maybe that lack of positive wouldn't necessarily imply immediate action, but negative feedback would. But this can be solved by sending a probe as soon as positive feedback stops and there are still outgoing packets.

Also, the fact that everything still works can be detected fast, while detecting that things don't work usually means some kind of timeout, which takes longer.

To avoid exposing information (even if it's just the fact that an
address is reachable), hosts will probably want to limit themselves to
taking part in reachability detection with known correspondents. This
means that there must be identifying information and a nonce that is at
least hard to guess but easy to check in all reachability detection
packets.

This may need to be spelled out in more detail. 

Yes, when the protocol becomes clear we need to look at this.

For instance,
when verifying reachability of the current address pair, "known
correspondent" probably means that (a) we have a shim6
"connection" to the peer and that (b) some secret information
from that connection is employed that makes at least blind
attacks from the internet impossible.

"Impossible" is a very high standard. We should be careful not to impose very heavy security on an otherwise light-weight mechanism.

On the other hand, when
doing address state exploration, "known correspondent" has
to mean something else, as we may need to do address
exploration even for the initial connection -- or am I missing
something?

No, this is absolutely true. So we can't just leverage shim state to reject reachability detection from undesired correspondents.

I think we talked about having a cookie or something like that in the first packet of a new session. (Obviously this wouldn't apply to all protocols.) The first packet is attractive for this because an attacker with just sniffing capability can't inject a fake first packet, and the chance an attacker was already active is slightly smaller.

Since in most cases we'll be initiating shim state for existing sessions, we already have return reachability here.

However, using negative feedback from upper
layer protocols may prove challenging because upper layers can't be
trusted to provide the right quality or quantity feedback ("feedback
spamming").


I guess this is arguable. You could also claim that the upper layers
are the place that really knows what the requirements for this
particular flow are.

I'm afraid that's exactly what some implementers are going to think. :-)

"My protocol needs 100 ms failovers! So I need to send negative feedback if I didn't hear from the other side when I don't hear an ack within 50 ms. What, transatlantic links? No, most of my users use the protocol on a LAN. They don't...?"

Even when a particular protocol does the right thing, when something changes, we need to update all protocols. If the shim is in charge, we only need to update the shim.

Iljitsch