RE: iSCSI Some Thoughts on Digests

[Black_David@emc.com]

> >Could you explain how the requirement for a 32 bit end to end CRC 
> >for TCP 
> 
> Oh, so we're talking about *another* change to TCP?

This appears to answer the original question about why CRC digests
have been proposed as iSCSI-specific ;-).  The end to end 32 bit
CRC requirement is somewhat specific to iSCSI, since protocols
such as http are quite happy without it.

> >IPsec in situations where it would otherwise not be needed (e.g.,
> >the cryptography is not necessary)?  
> 
> I suppose this begs the question of "when is security needed" for
> iSCSI. My own take on this is that as soon as you move from the realm of
> a private SAN and start using routable addresses, you need
> per-packet authentication and integrity protection. The threat
> of spoofed iSCSI commands seems very considerable to me in the
> case where the storage controller is reachable over the Internet.
> 
> BTW, it's not entirely clear to me that all private addressing
> cases are immune either; note that the ZEROCONF prefix 
> 169.254/16 is not recognized by many routers today, which will
> happily forward packets to or from this prefix, even though
> that is forbidden.

For the purposes of the original question, I don't think the position
that security is needed whenever integrity is needed (which lead to
the notion of using IPsec for 32 bit CRC-grade integrity) is tenable.  I
would expect to see all sorts of private and semi-private addressing
used with iSCSI, including LANs/VLANs that won't switch/route layer
3 addresses, and folks who believe that they're safe behind a firewall.

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