Re: possibly related draft

Jari Arkko wrote:
> 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.

Can you clarify this? it doesn't make sense to me. Sure, the network 
connectivity may be at multiple layers - the IP that carries the IPsec, 
the IP inside the IPsec (e.g., tunnel), etc., but I can't see how an 
application can connect in the absence of network connectivity.

> SImilarly,
> network connectivity does not imply that IKE/IPsec gets
> through.

Agreed.

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

It's not yet clear that such hints should be acted on, or could trigger 
behavior that is unintended. The latter needs to be considered before 
assuming opportunistic reaction.

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

I was thinking more of non-protocol API signals, e.g., that a wireless 
card loses the carrier. I agree that protocol-based signals of link 
failure are worrisome - for many reasons, not just security.

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

It makes more sense to create a system with keepalives that tears down 
the IKE or somesuch when they are not received, rather than to 'infer' 
anything based on hearing indirect information from an API. I.e., it is 
safe (IMO) to react to direct-connect API signals (carriers on cards on 
your box) or to signals you create for this purpose (e.g., keepalives 
inside an IKE association), but not to infer them from other protocols.

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

Presumably this would be akin to the keepalives noted above; if so, agreed.

> 
> --Jari

_______________________________________________
Mobike mailing list
[email protected]
https://www.machshav.com/mailman/listinfo.cgi/mobike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBgc7mE5f5cImnZrsRAux3AKCnEfxCqbgF05U3olAAspLA4rYfdwCgqGop
JrkOhlPr43Z1M+iGZ7k8p+A=
=vGpq
-----END PGP SIGNATURE-----