Re: possibly related draft

Hi Joe,

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

Anything that uses a proxy would be an example of a situation
where there's application layer connectivity but no lower layer
connectivity (to the peer). Anyway, maybe that is not so important
from the point of view of our discussion.

What's perhaps more important is that having network layer
connectivity does not imply IPsec/IKE gets through. And having
transport layer connectivity without IPsec/IKE at the bottom
does not imply that you would have IPsec/IKE connectivity.
Pretty much nothing else than IPsec/IKE can ensure that
there's IPsec/IKE connectivity...

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

I agree, but the way that I wanted to look at this is that
a hint leads to an activity that attempts to verify the hint
using a more secure mechanism (such as DPD). If this secure
mechanism reports that there is a problem, THEN we act, not
sooner. So the hint never directly leads to an actual change
in the IPsec/IKE addressing behavior.

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

I believe many people on this list have expressed the desire
to rely (at least partially) on other modules whose tasks
include things like verifying connectivity to the local router,
or change of on-link prefixes.

I take it that you feel uneasy with this. But let me point out
a few things:

(1) There's a difference between local information and
     global connectivity. I too would be hesitant to trust
     other protocols for the latter. But for the former
     I see little alternatives.

(2) Some of these other modules have security support. ND
     has SEND, for instance. And DHCP has some security
     tools too, although in many cases these tools aren't
     used.

(3) I can in a way understand your reluctance to use
     a particular insecure information piece from other
     modules. However, it seems that you MUST rely on
     it at least in some cases. For instance, when you
     boot your computer and get an IP address from the
     local network (possibly using an insecure version
     of ND or DHCP), there's really nothing that you
     could do in IPsec/IKE to avoid this. IPsec/IKE
     does not include the DHCP functionality.

     So it seems that you are stuck with the insecure
     modules/protocols at least for getting information
     about new addresses and connections. Presumably
     you could stick to these (despite advice from the
     other modules) until you have verified in the IPsec/IKE
     layer that they no longer work. But I think it
     doesn't help much, and could break other things.
     For instance, if ND says the link has changed and
     old addresses are gone, you should not continue to
     use your old address because it might collide with
     someone else's address on the new link.

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

Yes.

--Jari