RE: IPsec Usage Question

["CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>]

Hi Ofer

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

Could you elaborate on this. Why would such devices be in violation of the
iSCSI spec? 

Thanks.

Vince

|-----Original Message-----
|From: Ofer Biran [mailto:BIRAN@il.ibm.com]
|Sent: Monday, February 04, 2002 9:30 PM
|To: Paul Koning
|Cc: Black_David@emc.com; marjorie_krueger@hp.com; ips@ece.cmu.edu
|Subject: RE: IPsec Usage Question
|
|
|
|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
|
|
|
|