RE: iSCSI: Proxies (was Security in iSCSI)

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

Is this a call for concensus on removing references to proxies (except where
pertaining to digests) and deferring any discussion of proxy issues until
after the draft is complete?

If so, I agree it's the right thing to do. (I agree w/Jim)

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Thursday, August 23, 2001 10:15 AM
> To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu
> 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
> ---------------------------------------------------
>