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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 2 Sep 2004 17:14:27 -0700

Pasi,

I might have missed this at San Deigo. Why would anybody assume about the connectivity
about the address i.e why is this question even coming up ? If both the peers have multiple
address, then you have to support address list and can't make any assumptions about
the connectivity. You said below that if we don't make the assumption, then both address
can change at the same time on the SAs. Perhaps, i am missing the "assumption" part.
Assuming something is fully connected at some point in time does not mean that it stays
that way forever. So, even if we make the assumption, both the address may change
at the same time, right ? What am i missing ?
 
-mohan

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 24, 2004 8:10 AM
Subject: [Mobike] New issue 17: Full connectivity

Hi,

Based on talks at San Diego, I've created a new issue
on the issue tracker:

   "If both parties have several addresses, do we assume 
  that all pairs have connectivity between them?"

There was discussion about this in mid-April (one example 
mentioned was two SGWs connected via two different private 
networks), and most people thought we should not assume this.

Assuming this would also seem to largely rule out IPv4/v6
mobility.

If we decide _not_ to make this assumption, then we have cases 
where we have to change both parties's addresses in SAs 
at the same time.

It also seems the protocol will require some kind of address
lists, so something like SMOBIKE won't work (unless we assume 
one party knows several addresses for the other party via some 
other means than address lists sent within the protocol).

Any comments?

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

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Mon, 6 Sep 2004 16:21:39 -0700

Intoto Inc.
www.intoto.com
----- Original Message ----- 
From: "Srinivasa Rao Addepalli" <[email-masked]>
To: <[email-masked]>; "Francis Dupont" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 06, 2004 12:27 PM
Subject: Re: [Mobike] New issue 17: Full connectivity 

> 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]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, September 06, 2004 12:00 PM
> Subject: Re: [Mobike] 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-masked]
> >

---

From: <[email-masked]>
Date: Tue, 7 Sep 2004 09:20:29 +0300

[email-masked] wrote:
> => 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.

Ok, now I understand where the confusion came from: we had
a small mismatch in terminology (2401bis calls those SAs
"outbound" :-)

Best regards,
Pasi