Subject: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint

From: Stephen Hanna <[email-masked]>
Date: Tue, 20 Mar 2012 21:36:21 -0400

Another issue. Please comment.

And don't miss Yaron's comment below.

Thanks,

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2012 6:57 PM
To: [email-masked]; [email-masked]
Subject: [ipsecme] #216: Multiple interfaces or mobile endpoint

#216: Multiple interfaces or mobile endpoint

 What if an endpoint has multiple interfaces and/or is mobile?
 Which tunnels should be torn down as this endpoint moves around,
 sometimes behind a gateway and sometimes not?

 Suggested Resolution: We should not specify this in the problem
 statement. It should be specified in the solution.

 YS: sounds like a requirement question to me. In fact we may be
 able to simplify things by making this issue an explicit non-goal.

-- 
-------------------------+-------------------------------------------------
  Reporter:              |      Owner:  draft-ietf-ipsecme-p2p-vpn-
  yaronf.ietf@…          |  problem@…
      Type:  defect      |     Status:  new
  Priority:  normal      |  Milestone:
 Component:  p2p-vpn-    |   Severity:  -
  problem                |   Keywords:
Resolution:              |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/216#comment:1>
ipsecme <http://tools.ietf.org/ipsecme/>

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 21 Mar 2012 12:22:51 -0700

Hi Steve,

Branch routers have 3G/ 4G interfaces as backups for the primary interface
and sometimes even multiple 3G/ 4G interfaces with no wired interface at
all to the backend.

I however do not see any issue that occurs as a result of this. Currently
if an interface goes down the tunnel is torn down. Is the question about
bonding the multiple interfaces instead?

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna <[email-masked]> wrote:

> To: [email-masked];
> [email-masked]
> Ticket URL: <
> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/216#comment:1>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 21 Mar 2012 15:36:39 -0400

This issue was based on Michael Richardson's March 12, 2012 email where he said:

Finally, say my laptop is normally part of such a mesh (as a /32,/128
subnet).  When I'm "trapped" behind a NAPT, I naturally use
NAT-traversal to get out and join the MESH.

Now, what happens if I come to the office, which is itself part of the
MESH. This is not a new problem, btw, but normally I have only a single
tunnel to bring up or down.  Now that I have all these tunnels and
policy.  Should any of this MESH continue to be used?
Are there some non-convex topologies where this can be important (should
some traffic be double encrypted as a result?), or is it all just out of
scope.   (We dealt with these things as implementation challenges when
combining an extruded IPsec tunnel with RFC4322.  We had
co-terminal tunnels of the near kind, which was solved, and co-terminal
tunnels of the far kind, which we did not manage to implement)

For the above, consider a laptop/tablet which might now have multiple
exit routes via 3G+wifi+wired...  and that it's moving.

I hope that helps clarify the issue. If not, perhaps you and Michael can clarify and discuss it further.

Thanks,

Steve

From: Vishwas Manral [mailto:[email-masked]]
Sent: Wednesday, March 21, 2012 3:23 PM
To: Stephen Hanna
Cc: IPsecme WG
Subject: Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint

Hi Steve,

Branch routers have 3G/ 4G interfaces as backups for the primary interface and sometimes even multiple 3G/ 4G interfaces with no wired interface at all to the backend.

I however do not see any issue that occurs as a result of this. Currently if an interface goes down the tunnel is torn down. Is the question about bonding the multiple interfaces instead?

Thanks,
Vishwas
On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna <[email-masked]<mailto:[email-masked]>> wrote:
Another issue. Please comment.

Thanks,

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 20, 2012 6:57 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [ipsecme] #216: Multiple interfaces or mobile endpoint

 yaronf.ietf@...          |  problem@...

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2012 10:57:58 +0200

I think that whenever a node moves from the point of view of it's
"primary" connection, that it should tear down all "auxiliary" tunnels.

Due to the movement of the node, it may be impossible to communicate
with the end-points of the auxiliary tunnels (due to NAT restricted-cone
at one end or the other), so we will need a way to send tear down
notices (and/or I've moved notices) via the "hub" systems.  

There are many ways to do this (various ways inside IKEv2, via IP
routing...), but it's really important that the auxiliary tunnels for
"A" get destroyed on node "B" when "A" moves, reboots, updates it's NAT
address, etc.

This is not exclusively about MOBIKE: there are lots of other ways in
which the A<-->H1 connection can change which would affect "B".

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2012 11:04:07 +0200

>>>>> "Vishwas" == Vishwas Manral <[email-masked]> writes:
    Vishwas> Branch routers have 3G/ 4G interfaces as backups for the
    Vishwas> primary interface 
    Vishwas> and sometimes even multiple 3G/ 4G interfaces with no wired
    Vishwas> interface at 
    Vishwas> all to the backend.

Vishwas, it's not about requirements on immobile branch offices, or
*they* connect to the internet.

It's about laptops/smartphones which are typically "remote" on various
interfaces (including 3G and wifi going up/down regularly), and what
happens when such a device is now *inside* a branch office.

(A laptop with an ethernet is more likely to be 'inside' the branch
office than a laptop/smartphone with wifi at the office, depending
whether the WIFI is bridged to LAN, or the wifi is considered untrusted)

How does this device learn that it should now rely in the branch
office's MESH membership, rather than it's own MESH membership?

I don't think that the title of this ticket is well chosen.
I can do a diagram.

---

From: Daniel Migault <[email-masked]>
Date: Mon, 26 Mar 2012 13:19:56 +0200

My understanding is that there are two things, that may be considered
independently:
    - configuring IPsec layer
    - defining which route the communication should take

I don't understand why only one tunnel should be used. A mobile node, when
it detects a new interface, should be able to "add" this Interface on the
already existing tunnel. It looks to me as a limitation of MOBIKE. * This
would would allow the mobile node to use multiple tunnels. Which tunnel to
choose depends on other inputs. The important thing is that the mobile can
can use multiple tunnels. **

* "adding" could mean deriving a new SA from the old tunnel. This important
thing here seems to avoid re-doing an IKE exchange.

** this would require that SPD-O is derived per interface. Since a single
SPD is ordered and will always provide the same first match. I am not sure
how that can be implemented and would appreciate feed backs on that point.

Regards,

Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Mar 2012 15:16:15 +0300

> thing here seems to avoid re-doing an IKE exchange.

MOBIKE already does that. I.e. when it detects another interface
(IP-address) it will send ADDITIINAL_IP{4,6}_ADDRESS notifications and
then new IP-addess is also one of the address which can be used. With
MOBIKE we still only use one address, but we can change which address
we use easily.

On the other hand I do not think MOBIKE is really applicable in this
case, as I think in most of the cases the tunnel end points are NOT
going to be same. I.e. we do not try to create multiple tunnels
between same endpoints, but create multiple tunnels between different
endpoints, and in that case MOBIKE cannot be used. 
-- 
[email-masked]