Subject: [IPsec] #213 - Multiple interfaces or mobile endpoint

From: Vishwas Manral <[email-masked]>
Date: Mon, 14 May 2012 14:05:54 -0700

Hi,

Description: 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?

Detail Arguments: From what I understand if we are talking of mobile end
points, there are 2 ways we could have mobility:

    1. Behind a gateway which is moving.

     2. Device itself is moving.

The current tunnel mechanisms I know of is tied to an interface. If there
is a choice of multiple mobile endpoint interfaces, we should allow for the
ability to maintain the tunnel.

I am unsure of the above description of gateways? Could someone explain the
same please?

Suggested Resolution: We need to clarify what the gateway functionality in
the description means. We then need to clarify the problem statement with
the use cases.
Thanks,
Vishwas

==========================================================
  # 216 Multiple interfaces or mobile endpoint
           Solution-specific or requirement
           Tero: Is there a use case where the end point moves from
                   outside the gateway to inside
           Paul: Mobility is a use case, but not just for multiple
                    interfaces
           Steve: Either a new use case, or within the existing ones

==========================================================

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 May 2012 13:57:53 -0400

<#part sign=pgpmime>

>>>>> "Vishwas" == Vishwas Manral <[email-masked]> writes:
    Vishwas> Hi,

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

    Vishwas> Detail Arguments: From what I understand if we are talking
    Vishwas> of mobile end points, there are 2 ways we could have
    Vishwas> mobility:

    Vishwas>     1. Behind a gateway which is moving.

    Vishwas>      2. Device itself is moving.

I think the focus on "movement" and "mobility" is wrong.
Instead, focus on connectivity.

Tero (and I) asked the question about a device which was, from a
topological point of view, originally connected to "outside" (on the
public Internet, effectively), and had built up a mesh.

There is a connectivity change (let's not worry about how, why, but I
can describe a dozen ways if you like, and not all of them involve 3G or
802.11), and the device is now connected behind a gateway which is also
part of the mesh.

Let's assume a multiple star topology situation. (We draw these on
napkins in Paris. I promise to re-read the problem statment to learn if
this scenario has been named)

Let's say that said device ("A") previously was part of VPN-Concentrator X.
(It was perhaps part of that star via NAT-T transport).  Packets flowed
from A to device B.  Device B is located on network B-location, and is
served by B-gateway, and these packets flowed via VPN-Concentrator X.

X attempts to ask A to connect directly to B-gateway so that packets
from A<->B take the shortcut.  A presently has connectivity *on* 
"network B-location".  That is, A and B are in fact, co-located (but
might not be on the same link).

1) Is there a requirement that B-gateway must be able to make a bypass
   connection to another spoke, from *behind* B?

2) Many would feel that actually there should be *no* IPsec tunnel
   between A and B, as they are presently co-located.
   Do we have a requirement that the policy between two spokes
   (a "bypass") could in fact be "clear"?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 21 May 2012 17:09:52 -0700

Hi Michael,

I am working on updating the text of the draft. I had a few doubts.

> Are you talking of a case where the device had Public internet
connectivity and has now roamed to a place where it is inside the network,
so the IPsec tunnel is not required. You are probably looking at a way to
gracefully tear down the IPsec tunnel and use the native connectivity. Is
the understanding of the usecase you had in mind correct?

> Let me see if I understood the question. We are talking of a gateway-B
which is on the path between 2 spokes (A and B) which are talking via a VPN
concentrator (X). You are asking if we allow the Gateway-B to allow for a
bypass and if so can we allow for a "clear" bypass connectivity. Is my
understanding correct?

I agree there is a use case for this optimization, but do we want to tackle
the use case as part of the base solution or as an extension once the base
solution is created (so a future use case).

Thanks,
Vishwas

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 May 2012 23:34:53 -0400

>>>>> "Vishwas" == Vishwas Manral <[email-masked]> writes:
    Vishwas> Hi Michael,
    Vishwas> I am working on updating the text of the draft. I had a few
    Vishwas> doubts.

(fixing the quoting to clarify who said what)

    mcr> I think the focus on "movement" and "mobility" is wrong.
    mcr> Instead, focus on connectivity.
    mcr> 
    mcr> Tero (and I) asked the question about a device which was, from a
    mcr> topological point of view, originally connected to "outside" (on the
    mcr> public Internet, effectively), and had built up a mesh.
 
    Vishwas> Are you talking of a case where the device had Public internet
    Vishwas> connectivity and has now roamed to a place where it is inside the network,
    Vishwas> so the IPsec tunnel is not required. You are probably looking at a way to
    Vishwas> gracefully tear down the IPsec tunnel and use the native connectivity. Is
    Vishwas> the understanding of the usecase you had in mind correct?

Yes, this is an example, but not the only situation.

"Public internet connectivity" is not exactly the right term, because
that almost implies that the device was never NAT'ed, but in fact it
might have been.  What matters is that it wasn't behind the home
enterprises' security gateway(s).

    mcr> There is a connectivity change (let's not worry about how, why, but I
    mcr> can describe a dozen ways if you like, and not all of them involve 3G or
    mcr> 802.11), and the device is now connected behind a gateway which is also
    mcr> part of the mesh.
    mcr> 
    mcr> Let's assume a multiple star topology situation. (We draw these on
    mcr> napkins in Paris. I promise to re-read the problem statment to learn if
    mcr> this scenario has been named)
    mcr> 
    mcr> Let's say that said device ("A") previously was part of VPN-Concentrator X.
    mcr> (It was perhaps part of that star via NAT-T transport).  Packets flowed
    mcr> from A to device B.  Device B is located on network B-location, and is
    mcr> served by B-gateway, and these packets flowed via VPN-Concentrator X.
    mcr> 
    mcr> X attempts to ask A to connect directly to B-gateway so that packets
    mcr> from A<->B take the shortcut.  A presently has connectivity *on*
    mcr> "network B-location".  That is, A and B are in fact, co-located (but
    mcr> might not be on the same link).
    mcr> 
    mcr> 1) Is there a requirement that B-gateway must be able to make a bypass
    mcr> connection to another spoke, from *behind* B?

    Vishwas> Let me see if I understood the question. We are talking of a gateway-B
    Vishwas> which is on the path between 2 spokes (A and B) which are talking via a VPN
    Vishwas> concentrator (X). You are asking if we allow the Gateway-B to allow for a
    Vishwas> bypass and if so can we allow for a "clear" bypass connectivity. Is my
    Vishwas> understanding correct?

Yes.
Just to be clear, A and B are *hosts*
A was a "road warrior".  Whether or not B is also a road warrior is not
relevant, what's important is that B is behind B-gateway, and gets VPN
service from B-gateway (and concentrator-X).

    Vishwas> I agree there is a use case for this optimization, but do we want to tackle
    Vishwas> the use case as part of the base solution or as an extension once the base
    Vishwas> solution is created (so a future use case).

good enough.