Re: possibly related draft

Hi Joe,

Thanks for raising these issues. Some further discussion inline:

> I am concerned about the use of some of this inferred information from 
> the link layer or transport layer to decide connectivity at the network 
> layer.
> 
> Notably, failure of TCP to make forward progress - e.g., lack of ACKs - 
> is not an indication of a network layer connectivity failure. It can be 
> a deliberate decision of the TCP implementation to limit processing 
> associated with a connection, or can represent a security firewall being 
> enabled.

Yes. Although -- given that we are talking about TCP that runs over our
IKEv2/IPsec connection -- the firewall will also block all other traffic
from the same connection, at least if non-null encryption and ESP are used.
I believe we have several types of connectivity:

- network layer connectivity
- IKE/IPsec connectivity
- transport or application connectivity

With ALGs and other kinds of interesting devices, you could
actually have a situation where you have application
connectivity but no network or IPsec connectivity. SImilarly,
network connectivity does not imply that IKE/IPsec gets
through.

> Similarly, we've had related dicussions in TCPM regarding the use of 
> ICMP unreachable messages to tickle more rapid attempts to use alternate 
> addresses, e.g., for v4/v6 selection. Unfortunately, these messages, as 
> noted, are not secure, and so relying on them presents a DOS 
> opportunity; it is not clear that there is a significant benefit in 
> 'believing' these messages that is not undermined by this lack of security.

Right. The way that I want to see this is that anything like an
ICMP error would at best be a hint that now it would be a good
time to do another DPD round.

> Although it may be useful to consider direct evidence of connectivity, 
> e.g., linkup/linkdown interface notification via an API, it is not clear 
> yet that there is a protocol-related variant that can be appropriately 
> applied, IMO.

Yes. Or at least the security/semantics impacts of the protocol
related variants need to be considered. I think this means that
we have three classes of notifications:

- Those that came through an API. However, most of the time the
   API-based indications are really initiated by (possibly insecure)
   protocol exchanges. For instance, the reception of an RA.
   In some cases there's security available (if in use) for these
   protocols, such as for ND we have SEND.

   However, I'd still feel uncomfortable if MOBIKE did NOT believe
   everything it hears from the API. We can't have a situation
   where ND decides something but the MOBIKE/IKEv2/IPsec system
   does not believe it and continues to use a bad address, for
   instance.

- Those that came through an external protocol, such as TCP.
   The considerations that you Joe raised apply here.

- Those that came through the MOBIKE/IKEv2/IPsec system itself.
   These I believe we *can* believe, and with some assumptions
   about the cryptographic primitives that are being used, this
   really represents the connectivity that MOBIKE is concerned
   about. Or does at least as long as one would test both IKEv2
   and ESP connectivity... in NAT-T case IKEv2 over UDP test
   would probably suffice.

--Jari