RE: iSCSI - three negotiation items

[Black_David@emc.com]

Comments below.  --David

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 02, 2001 3:14 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI - three negotiation items
> 
> 
> 
> comments in text. Julo
> 
> 
> 
> Black_David@emc.com on 02-08-2001 04:46:53
> 
> Please respond to Black_David@emc.com
> 
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI - three negotiation items
> 
> 
> 
> 
> Going through the list of simplification suggestions,
> I found a few items that look like they
> should be reasonable to deal with on the list.
> 
> (1) For any key that can take a numeric value, could
> we specify the required base for the number, either
> decimal or hex, not both.  The practical issue is that
> the sort of large values used for keys and the like
> in security are much easier to deal with in hex than
> decimal.
> 
> +++ the current draft allows for both - Is there something 
> wrong with that?
> Hex is simpler but if data gets copied from somewhere else 
> and that is a
> decimal source then that is error prone +++

DLB> Possibly.  The implementation issue is that converting
DLB> large quantities (e.g., 128 bit) from decimal to hex
DLB> is annoying (it's bignum arithmetic).  Does anyone
DLB> ever use decimal to represent this sort of keying
DLB> material?  The major concern is apparently the
DLB> security-related stuff (e.g., I doubt it's
DLB> a big deal if someone wants to use hex instead of
DLB> decimal for MaxConnections).
 
> (2) The KRB5 and SPKM inband cryptographic integrity
> digests on p.136 seem to be relics of a prior inband
> approach to security.  Has anyone implemented them?
> Does anyone want them to remain?  Can we just delete
> them?
> 
> +++ Yes - I think we can take them out although UMAC may 
> get-in at some
> point :-) +++

DLB> Good.  

> (3) Can HeaderDigest and DataDigest be combined?
> If (2) is done, this is about making use of CRC-32C
> a single on/off switch rather than two separate switches
> for header and data?
> 
> +++ combining defeats the purpose of the iSCSI CRC - to get 
> you through
> iSCSI proxies that may change the header but will not change 
> the data +++

DLB> My fault for not being clear.  The proposal is to still
DLB> compute separate CRCs on header and data for exactly
DLB> that iSCSI proxy reason that Julian cites, but to
DLB> combine the negotiation keys into one key so that
DLB> the only two possibilities are:
DLB>  - Both CRCs are generated.
DLB>  - Neither CRC is generated.
DLB> Does anyone see a compelling case for one of these
DLB> CRCs without the other?