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