|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: IPsec Usage Question>>>>> "BlackG" == Black David <Black_David@emc.com> writes: BlackG> AFAIK, IPsec has no standard or widely deployed mechanism for BlackG> handling gateway discovery or address association BlackG> dynamically. True. But let's consider a very common IPsec deployment scenario. I think this is actually the predominant one, but let's not argue about that; it certainly is quite common. Scenario: two sites, each with an IPsec gateway, and an IPsec tunnel set up between the two sites. All traffic between the two sites goes through the tunnel. (This is the classic IPsec based VPN scenario.) The way this is handled is simply by configuring the routing tables on the two IPsec gateways to forward to the other site through the tunnel. As far as the other nodes on the two sites is concerned, the other site is simply reachable via ordinary IP mechanisms, and the existence of the tunnel, or the addresses used in the outer headers, are none of its concern. And of course the IP addresses of the inner header cannot possibly equal those of the outer header in this example. This example MUST work. So you cannot require inner == outer address, because that translates into saying that IP Storage cannot be protected by a site to site IPsec tunnel. Now for a different case: if you use tunnel mode to protect traffic for a single node (a common case for laptops, so this is often called the "road warrior" case) then it may well be useful to allow inner == outer. Some road warrior OS types will want that, others don't care so much, so it can be a simplifying approach. I have no objection at all to saying that inner == outer is useful, and for that matter I can go along with saying inner == outer should be supported. But, either way, inner != outer must be supported. paul
Home Last updated: Mon Feb 04 20:17:55 2002 8628 messages in chronological order |