Subject: RE: [Mobike] New issue 17: Full connectivity

From: <[email-masked]>
Date: Mon, 6 Sep 2004 18:26:16 +0300

[email-masked] 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. And if it's not used,
implementations don't even need to store it, and MOBIKE does not 
need to update it, right?

Or am I missing something in 2401bis that actually uses it?

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Sep 2004 21:00:52 +0200

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

=> we only misunderstand ourselved (:-).

Regards

[email-masked]

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Mon, 6 Sep 2004 12:27:02 -0700

Umm... I guess it depends on how IPSec is implemented.

At the originitaing security gateway must know the remote peer IP address and uses
it as Destination IP address.

On the receiving end, some implementations would only check if the destination
IP address of the received packet is its local IP address. If so, it consumes the
packet and if not, the packet is forwarded. Some implementation might go beyond
this and might even look for exact match. 

MOBIKE might need to keep both kinds of implementation in mind or make 
explicit statement on the behaviour it expects from inbound processing.

Srini

Intoto Inc.
www.intoto.com

---

From: Francis Dupont <[email-masked]>
Date: Tue, 07 Sep 2004 11:10:06 +0200

At the originitaing security gateway must know the remote peer IP
  address and uses it as Destination IP address.
   
=> this is what matters.

   On the receiving end, some implementations would only check if the
  destination IP address of the received packet is its local IP
  address.

=> all implementations check if the destination address is local.
If it is not the packet is dropped or forwarded.

   Some implementation might go beyond this and might even look for
  exact match.
   
=> I believe you think to the SA lookup (on the destination, protocol
and SPI triple, or as it is recommended by RFC 2401bis on the SPI only
for unicast. Note the last one is in fact the easier to implement).

=> we already discussed about this point and the RFC 2401bis was updated
to say any local address should be accepted ad the destination address
of an incoming packet.
   
Regards

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Sep 2004 12:44:44 -0400

>it as Destination IP address.

right.

>this and might even look for exact match.

If the destination is a security gateway, it must distinguish between 
IPsec traffic addressed to it and IPsec (or non-IPsec) traffic 
addressed to hosts behind it, and thus potentially bypassed. So, in 
that context, it is necessary to pay attention to the destination 
address!

Steve