Re: about reachability detection draft

[Jari Arkko <jari.arkko@piuha.net>]

Hi Marcelo,

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

This is related to the discussion we had in the MOBIKE WG about
the separation between detection and action. As an example,
the IKEv2 initiator could be in charge of all actions, i.e., actual
address pair changes, and the other party would only provide
indications to the initiator regarding its own address status,
current status of the communications, and it would assist in
address pair exploration. But all of this requires some signaling
communications.

> 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

Yes. Of course, it may also be useful to find abstractions, e.g., addresses
having some kind of a state that the lower layers (whatever they are) 
indicate
to the shim6 layer. Even so, my sense is that its still complicated enough
that some of the assumed impacts from lower layer need to be specified
in our protocol documents.

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

Good point.

--Jari