Re: New issue 17: Full connectivity

 In your previous mail you wrote:

   >    Yes, certainly a node is likely to know better its own conditions
   >    than the other node. But I don't quite understand the last point: 
   >    in 2401bis, inbound IPsec SAs don't seem to have the local (tunnel 
   >    header) address at all? (unless they're multicast, but 
   >    that's beyond IKEv2)
   >    
   > => tunnel inbound IPsec SAs have a local (destination) 
   > end-point address. What I mean is the only way to fix this 
   > address is to send a message to the other end saying what 
   > address to use. BTW this is the central point of MOBIKE.
   
   Err, I'm a bit confused today... I cannot find anything in 2401bis
   that would actually use the (outer) address in _inbound_ IPsec SAs 
   for anything when processing unicast traffic.

=> the destination address of packets sent over an IPsec tunnel SA is
a mandatory parameter on the sending side, in this case the other peer.

   And if it's not used,

=> it is used, here tunnel is not tunnel effect (:-).

   implementations don't even need to store it,

=> it is stored. We can argue about the source address of the encapsulating
header, but the destination address is a mandatory parameter.

   and MOBIKE does not need to update it, right?

=> as this is something the local peer can't update without a signaling
with the other peer, this is something which can only be managed with
MOBIKE or a similar mechanism (in fact MOBIKE is the explicit mechanism,
the other mechanism, the implicit one, is part of NAT traversal).
   
   Or am I missing something in 2401bis that actually uses it?
   
=> we only misunderstand ourselved (:-).

Regards

[email protected]