RE: IPsec Usage Question

[Black_David@emc.com]

IMHO, both Ofer and Paul appear to be right, so let me
attempt to explain ...

We cannot place general constraints on the extent of an IPsec
implementation that happens to be used for IP Storage -
if someone wants to implement full IPsec (e.g., additional
ciphersuites, IKE ID payloads) and use that functionality to
talk to security gateways that are not part of IP Storage
implementations, there's nothing we can do to stop this ...
and we probably should encourage this sort of thing.

The upshot is that the implementation requirements and
usage requirements/restrictions being placed on IPsec for
securing IP Storage protocols apply only to SAs that have
an IP Storage system (e.g., a security gateway that is
part of an IP Storage system) at both ends.  I don't
believe that either of Paul's examples fall into this category
as he described them, hence neither would be prohibited by what
we do here, and I agree with Ofer that at least Paul's VPN
scenario should not be used to motivate iSCSI security
requirements.

OTOH, Paul's second example could fall into this category if
one considered an iSCSI system consisting of multiple initiators
bundled with a security gateway, and based on that example,
I'm inclined to agree with Paul's contention that requiring
inner IP addresses to match outer IP addresses would be a
mistake.

The fact that IPS usage requirements/restrictions for IPsec
only apply to SAs that have IPsec implementations that are
part of IP Storage systems at both ends probably needs to be
stated somewhere for clarity to avoid others jumping to the
conclusion that an IPsec implementation used for IP Storage
cannot use additional features when talking to a peer that
is not an IP Storage system.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Ofer Biran [mailto:BIRAN@il.ibm.com]
> Sent: Tuesday, February 05, 2002 4:12 PM
> To: Paul Koning
> Cc: Black_David@emc.com; marjorie_krueger@hp.com; ips@ece.cmu.edu
> Subject: RE: IPsec Usage Question
> 
> 
> 
> Paul,
> 
> I only meant that the 2-site tunnel scenario has nothing to 
> do with the
> IPsec protection mandated to be implemented (yes, implemented,
> not used) by iSCSI.  So I would not use this scenario at all 
> to conclude
> about iSCSI security requirements (outer=inner etc.).
> 
>   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 18:52:28
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   Ofer Biran/Haifa/IBM@IBMIL
> cc:   Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu
> Subject:  RE: IPsec Usage Question
> 
> 
> 
> Excerpt of message (sent 5 February 2002) by Ofer Biran:
> >
> > 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.
> 
> No, you're mistaken.
> 
> I said nothing about what the iSCSI devices IMPLEMENT.  I only talked
> about what was IN USE by the customer.  In the example, the customer
> chose to USE a different security mechanism for reasons of cost,
> convenience, site policy, or whatever.
> 
> Remember that the proposed requirement is "required to implement" and
> NOT "required to use".
> 
> My interpretation of having "use" be optional is that you also have
> the option of securing your traffic via other means.
> 
> Am I right?  Or is it the intent of the WG to say that no other
> security mechanisms are allowed -- if you want security you MUST use
> the one that is mandated in iSCSI nodes?  If so, for what reason?
> 
>     paul
> 
> 
> 
>