Re: iSCSI: Proxies (was Security in iSCSI)

[Mark Bakke <mbakke@cisco.com>]

I agree with Jim.  Since an iSCSI initiator's discovery (or configuration)
of a set of targets makes use of address-independent iSCSI names, iSCSI
does not have the same problems implementing proxies as HTTP.  The
"proxy required" status code is unnecessary for the reasons that Jim
provided.

The only concession we do need to make a proxy or gateway work is the
one we already have, which is the separation of the header and data
CRC.  Since a proxy will almost certainly be the end-point for any
change in security environments between an initiator and a target,
attempting to create a "secure" end-to-end data integrity check will
probably not work anyway.

I also vote that we put a lid on this one.

--
Mark

Jim Hafner wrote:
> 
> David,
> 
> I entirely agree with all the points you make.  I have argued that there is
> in the current draft no definition of a proxy, no model for such things and
> only vague references to them.  I have even suggested that the term "proxy"
> and all related text be removed from the document (including the vague
> status code of "proxy required").
> 
> It turns out that for the purposes of iSCSI, proxies can be implemented
> without any change to the protocol (provided you have a fairly intelligent
> iSCSI-aware proxy).  All you need to do is have the actual target advertise
> (via th normal discovery mechanisms, like SLP, iSNS, admin, etc.) that it's
> network addresses are those of the proxy machine and only allow the actual
> proxy to make direct connection to the target (the target would not
> authenticate and allow login from any other source).  You get proxy
> function without any protocol changes.  Security is initiator to proxy (by
> the rules configured for that proxy) and proxy to target (by the rules
> configured for that proxy-target pair).  The rest is completely transparent
> to the protocol and to the host.   This description fits yours where the
> proxy participates in the security context directly.
> 
> If this model of proxy requires too much function in the proxy boxes, then
> we can revisit this issue latter in the iSCSI layer directly.  In the
> meantime, I vote (with you) that we put a lid on this issue of proxy (by
> removing the notion) and get on with completing the hard issues that are
> still on the table for basic operation.
> 
> Jim Hafner
> 
> Black_David@emc.com@ece.cmu.edu on 08/23/2001 10:14:30 am
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: Proxies (was Security in iSCSI)
> 
> Julian,
> 
> > You seem to missing my main point. I am ready to take out the
> > table but not the general notion of a cryptographic digest.
> > To do the later I have to have the community understand that
> > their are left with no protocol provided means to authenticate
> > data that pass through iSCSI proxies.
> 
> Actually, I was hoping that you weren't going there.  Just when
> one thinks one has obtained a good understanding of a network
> technology/protocol/solution/etc., adding the notion of proxies
> is almost certain to restore the previous state of confusion.
> Multicast also has this property, but fortunately, I haven't
> seen anyone in the WG take any serious interest in it (and
> woe betide anyone who takes this as an invitation ;-) ).
> 
> My primary concern is one of schedule - if full support for
> proxies is a requirement for the first version of the iSCSI
> RFC, the schedule guesstimate I posted yesterday is probably
> optimistic by 6+ months.  Issues that come up in the area of
> proxies that will take a while to resolve will likely include:
> 
> - What's the right scope of proxy support?  How much
>      consideration for SCSI level proxies to which other
>      transports needs to be reflected in the iSCSI standard?
> - SCSI is not an end-to-end transport independent protocol.
>      T10 had the opportunity to go in this direction in the
>      SCSI GPP work) and chose not to do so. Extensive iSCSI
>      work on proxies risks running into SCSI architecture,
>      and our experience with ACA suggests that they'll take
>      a while to resolve.
> - Security interaction with proxies is a very complicated
>      subject.  IPsec and NATs is a well-known tarpit that
>      is finally getting resolved years later.  I hesitate
>      to promise that the iSCSI proxy issues will be significantly
>      simpler by comparison.
> - There is precedent for proxies adapting to the requirements
>      of protocols - TLS requires http proxies to accommodate
>      it rather than the other way around.  Whether proxies
>      should drive iSCSI security architecture or iSCSI
>      security architecture should drive proxy design will
>      at the minimum be fodder for serious debate.
> 
> If we want to get the iSCSI spec done in a reasonable timeframe,
> I suggest closing the lid on this Pandora's box labeled
> "proxies" and deferring serious work on iSCSI proxy support
> to a future revision.  The separate header and data CRCs are a
> useful step towards making life better for those who want to
> build proxies, but I hesitate to go much further in that
> direction, particularly in the area of security.  As things
> currently stand, one way to authenticate data passing through
> an iSCSI proxy is to have the iSCSI proxy participate in the
> authentication which seems like an acceptable situation (and
> one that has a straightforward security explanation).
> 
> Comments?
> 
> Thanks,
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054