Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"

[Michael Krause <krause@cup.hp.com>]

At 06:22 PM 4/9/2001 -0400, Stephen Bailey wrote:

>No.  However, middlebox-proofing we do will be circumvented when the
>middle box decides it wants to look in iSCSI as a L7 protocol.  I know
>it sounds horrible, but there are zillions of companies doing this for
>HTTP now.  The reason why middle boxes manipulate the data is because
>that allows them to provide the desired behavior.  It seems like a
>really natural product idea for some people (personally I don't get
>it) to plumb HTTP and iSCSI (hey, why not CIFS, NFS, SIP and RTP while
>we're at it :^) into one big, happy L7 router/switch type box.
>Fundamentally, if the middle box is going to diddle in the payload,
>there's not squat we can do.

This is why the concept of a variant CRC for those fields within the header 
subject to change and an invariant CRC for the data and header fields that 
are not subject to change is a preferred solution.  The middle boxes cannot 
screw up everything.  However, this is primarily practical only when PDU do 
not span multiple packets which many people seem to want for some reason.

>I am somewhat ambivalent about CRC digests (I'd rather have end-to-end
>security and kill all those birds with the same stone), but what I'm
>really averse to is assuming that digest failures are frequent, and a
>less than brute force (connection bounce) recovery mechanism is
>required.

Given security solutions can change over time it is unclear whether this 
would be practically. Doing something as simple as a secured hash for 
modification detection is much more complex and performance inhibiting than 
calculating a CRC.

Also the frequency of many aspects - the number, type, and bandwidth of the 
fabrics involved in the end-to-end solution come immediately to 
mind.  Given these can vary in quality and rate of change (bandwidth is 
already at 40 Gbps on some fabrics and rising to 100 Gbps and it is 
important for the same solution to work from DSL speeds to 100 Gbps and 
beyond), it is unclear whether any study done to date can quantify the 
actual frequency that will be present. As such, it is better to error on 
the side of strong data integrity at the start (provide investment 
protection to the customer) and then adapt as required.  Not doing anything 
now leaves customers buying hardware that will be throw-away / of limited use.

Mike