>>>>> "Vishwas" == Vishwas Manral <[email protected]> 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.
--
Michael Richardson <[email protected]>, Sandelman Software Works
IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/
pgpAXAtVzjpcL.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
