RE: IPsec Usage Question

["Ofer Biran" <BIRAN@il.ibm.com>]

Paul,

>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.

This is not Kansas any more... The iSCSI devices on both sites (assuming
that's their only IPsec protection) are not iSCSI compliant. This
definitely
doesn't cover the IPsec protection mandated by iSCSI.

  Regards,
    Ofer


Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com  972-4-8296253


Paul Koning <ni1d@arrl.net>@ece.cmu.edu on 05/02/2002 00:17:54

Sent by:  owner-ips@ece.cmu.edu


To:   Black_David@emc.com
cc:   marjorie_krueger@hp.com, ips@ece.cmu.edu
Subject:  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