about reachability detection draft

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

Hi Iljitsch,

thanks for the draft, it is very clear in its presentation

i know this is 00 version, but some comments anyway of things i 
consider relevant.


In section 2 it is stated that:

- In the second model, a host can only detect problems in the receiving
  direction so it must depend on the correspondent to detect problems
  in the other direction

I think it is important to consider one step further then. I mean, what 
can a host possibly do when he detects an outage in the incoming path? 
If a host detects an outage in the outgoing path, he can change the 
address pair that he is using to send packets and see if it solves the 
problem, but what can he do if he detects an outage in the incoming 
path? I guess that the only option would be to notify the correspondent 
node about the failure so that the correspondent uses an alternative 
path (Note that we are asuming the the case of unidirectional 
connectivity is possible)
So i guess that this mode needs an additional message informing the 
failure, which needs to be taken into account when comparing the 
options.

I guess it would also make sense to state how the those mechanisms 
behave when there are no outgoing packets? i mean, i guess that in any 
of the modes signaling is suppressed right?, however, i guess that the 
hosts assume that the address pair is reachable, right?

Additionally, i guess that there are other information that needs to be 
taken into account when detecting reachability, such as ICMP error 
messages, address deprecation, lower layers information (i know that 
you state that you assume that addresses are available, but what 
happens if an address of the currently used address pair is deprecated? 
or if the associated interface goes down?) i guess it would be 
important to deal with this cases also

Another issue that may be of interest is what happens with an address 
(pair) after it becomes unreachable? i mean, is it used in followings 
address pair explorations? is it putted in quarantine?

Later on in section 3 it is stated that:

  In its essence, address pair exploration is very simple: just send
  probes using every possible address pair, wait for something to come
  back and possibly consider the round trip time.

I guess we agree that you are oversimplifying the issue here :-)
I mean, the complexity is not only due to the amount of probe packets 
that are needed, but also becuase of unidirectional connectivity. I 
think it is very important to express such difficulty. I mean, even 
with two address pairs, the problem can be quite complex, because 
replies need to carry information, not only about the particular 
incoming packet, but also from other previously received probes, in 
order to allow the transmitter to determine if previous probes have 
succesfully arrived. I think it is important to describe this problem 
and possible approaches to deal with it.

Finally, in the security considerations section, i think that there is 
closely related problem that perhaps needs to be presented here that is 
flooding protection. I mean, the path exploration exchange can be used 
for identifying working address pairs but also for preventing that the 
shim can be used for flooding attacks. In order to enable the path 
exploration exchange to be used for this, you need to include some 
additional information in the exchange, some information that 
identifies the shim context, so that the receiver of a packet of the 
address pair exploration process can determine if this is one of its 
own established sessions that are being genuinely rehomed or if this is 
a flooding attack.

regards, marcelo