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

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

Thanks for writing this up, Iljitsch -- it captures the essence
of the problem very nicely. A couple of quick questions and
comments after the first read:

In order to reduce packet overhead, it makes sense to have different
on-the-wire protocols for confirming existing reachability and full
exploration of potential reachability.


This makes a lot of sense.

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.

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

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.

--Jari