RE: Frame Formats

[Black_David@emc.com]

I wouldn't worry about the "security" issue
of padding with zeroes vs. padding with random
bits.  Anyone who cares about this sort of
issue will put a compression algorithm in
the security implementation, and zeroes tend
to compress very nicely :-).

The best thing to do with the padding
is probably to incorporate it into the AHS
header specifications - e.g., rather than
tacking 3 bytes of pad onto an AHS, add 3
reserved bytes to the header itself in the AHS,
so that all headers that might turn up in the
AHS are 4-byte aligned.  This is a good thing
to do in any case, as dealing with things like
a 32-bit quantity that is disaligned by 16 bits
tends to be awkward.

Reserved bytes are easy to deal with - they
MUST be sent as zero, and MUST be ignored at
the receiver.  This is a variant of the usual
admonition to be conservative in what is
sent and liberal in what is accepted.

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

> -----Original Message-----
> From:	Mark Bakke [SMTP:mbakke@cisco.com]
> Sent:	Thursday, March 29, 2001 9:28 AM
> To:	julian_satran@il.ibm.com
> Cc:	ips@ece.cmu.edu
> Subject:	Re: Frame Formats
> 
> Julian-
> 
> If generating random numbers to place in a pad field is
> too expensive, is the next best thing (from a security
> point-of-view) to zero the pad, or to leave whatever was
> there?
> 
> --
> Mark
> 
> julian_satran@il.ibm.com wrote:
> > 
> > Mark,
> > 
> > Security guys want you to randomize pad.  0s are a weakness.
> > 
> > Julo
> > 
> > Mark Bakke <mbakke@cisco.com> on 29/03/2001 15:24:15
> > 
> > Please respond to Mark Bakke <mbakke@cisco.com>
> > 
> > To:   Venkat Rangan <venkat@rhapsodynetworks.com>
> > cc:   "'Mike Thompson'" <mike.thompson@qlogic.com>, "'ips@ece.cmu.edu'"
> >       <ips@ece.cmu.edu>
> > Subject:  Re: Frame Formats
> > 
> > Venkat and Mike-
> > 
> > I am also in favor of Format 2, as long as we do not include
> > the AHS in the data digest.
> > 
> > We had originally separated the header and data digests, so iSCSI
> > gateways or other middle boxes could modify the header, but keep
> > the data CRC end-to-end.  By including AHS in the data CRC, this
> > capability will be lost.
> > 
> > I agree that we should have a single header digest, but I would
> > like to see it after the AHS.  If we must have a BHS digest, then
> > I would rather have two header digests than combine AHS with data.
> > 
> > I also agree with your comments on lengths and padding.  I would
> > add that any pad bytes MUST be set to zero; it's sort of a nit, but
> > they could contain old data.  The security folks seem to get upset
> > whenever someone sends "previously-owned" data around, even though
> > it's no more than three bytes.
> > 
> > Regards,
> > 
> > Mark
> > 
> > Venkat Rangan wrote:
> > >
> > > Mike,
> > >
> > > We would be in favor of Format 2 with your proposed changes as well:
> > > - a AHS length and Data length inside the BHS
> > > - a header digest right after the BHS
> > > - AHS (if present) after the BHS
> > > - Data after the AHS
> > > - Data Digest after the data
> > >
> > > If someone wants protection of the AHS, a single Data Digest can cover
> > > everything after the header digest.
> > >
> > > An oddity with Format 2 in the PDF file is that the AHS Length and
> Data
> > > Length
> > > are the first items. We would like to see it in BHS after the first
> word
> > > which
> > > describes the OpCode and flags, which would allow for introduction of
> new
> > > OpCode formats which do not have any AHS or Data in the BHS.
> > >
> > > Another area that hasn't been covered, but mentioned tangentially:
> > > - All lengths are in units of four-bytes
> > > - All AHS and Data is padded to the nearest four-byte boundary
> > > - There is some indication of "fill-bytes" in two-bit fields to tell
> > >   us how much of the data is actually valid.
> > > - Digests cover any fill-bytes also; i.e., the digests are always on
> > >   quantities that are four-byte aligned.
> > >
> > > This facilitates word-oriented data movement and is known to be a big
> > > win in achieving higher performance.
> > >
> > > Venkat Rangan
> > > Rhapsody Networks Inc.
> > > http://www.rhapsodynetworks.com
> > >
> > > -----Original Message-----
> > > From: Mike Thompson [mailto:mike.thompson@qlogic.com]
> > > Sent: Wednesday, March 28, 2001 10:52 AM
> > > To: 'ips@ece.cmu.edu'
> > > Subject: RE: Frame Formats
> > >
> > > Robert,
> > >
> > > First off let me state the obvious, more digests create
> > > more complication, hardware or software. That said, the
> > > approach that you describe is relatively painless because
> > > all the information is in the BHS about how long each section
> > > of the PDU is. This definitely makes it easier to process
> > > PDUs, especially in an out of order case. When you have to
> > > process one header to find the next header to find the data,
> > > this causes a lot of grief.
> > >
> > > In the case of out of order processing, the hardware wants to
> > > just find the data PDUs and skip over the other ones until they
> > > are in order. With your scheme, I could look at just the BHS, find
> > > out if it is a data PDU and if not, skip to the next PDU without
> > > further processing of numerous headers. Also as you stated, the BHS
> > > digest is always in the same location. This definitely makes
> > > processing easier.
> > >
> > > Mike
> > >
> > > > -----Original Message-----
> > > > From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu]
> > > > Sent: Tuesday, March 27, 2001 12:30 PM
> > > > To: Mike Thompson
> > > > Cc: 'ips@ece.cmu.edu'
> > > > Subject: Re: Frame Formats
> > > >
> > > >
> > > > Mike:
> > > >
> > > > I agree with all your comments.
> > > >
> > > > Earlier I had proposed that the BHS be covered by a digest that
> > > > was always after the 48th byte (i.e., at a fixed offset), and that
> > > > the AHS, if present, would be covered by a second digest of its own.
> > > > (not by the data digest, which would be after the end of the data).
> > > > By having 3 digests, 1 for the BHS, 1 for the AHS, 1 for the data,
> > > > every read is fixed length and the digest is at the end of each
> > > > of the reads.
> > > > However, there was opposition to having a second header digest
> > > > that just covered the AHS, so now there is only 1 header digest
> > > > which covers both the BHS and the AHS and therefore, as you pointed
> > > > out, it is at a position that is unknown when you start to read the
> > > > header.
> > > >
> > > > Since you are a hardware implementer, let me ask the obvious
> > > > question --
> > > > wouldn't it simplify everything to have a 2nd digest that covered
> just
> > > > the AHS?  The steps to receive a PDU would then be:
> > > >       1. Read the fixed length BHS with its own digest and check it.
> > > >       2. Extract the length of the AHS from the BHS
> > > >          If this length is 0 there is no AHS.
> > > >          If this length is positive, read that many bytes of AHS
> plus
> > > >          the AHS digest and check it.
> > > >       3. Extract the length of the data from the BHS
> > > >          If this length is 0 there is no data.
> > > >          If this length is positive, read that many bytes of data
> plus
> > > >          the data digest and check it.
> > > >
> > > > From a software point of view this looks a lot simpler, since every
> > > > read is for a known number of bytes and every read ends with a
> digest.
> > > > However, I am not sure if it simplifies the hardware significantly.
> > > >
> > > > Thanks,
> > > > Bob Russell
> > > >
> > > >
> > > > On Tue, 27 Mar 2001, Mike Thompson wrote:
> > > >
> > > > > As an implementer of a hardware implementation of
> > > > iSCSI/TCP, I would like to
> > > > > see format 2 from the slide set presented at IETF. The
> > > > fixed location of the
> > > > > total data length and AHS length will make out of order
> > > > data placement
> > > > > reasonable. With these two fields at the beginning of the
> > > > PDU, hardware will
> > > > > immediately know how much data needs to be checked to
> > > > verify the header
> > > > > digest and if the digest is valid, it can go on to process
> > > > the next PDU,
> > > > > looking for data PDUs that can be processed. In previous
> > > > formats, the
> > > > > hardware has to process too many fields to get to the digest.
> > > > >
> > > > > Ideally, I would like to see a slight modification to this
> > > > format where the
> > > > > header digest just covers the BHS. My understanding of the
> > > > header digest is
> > > > > to allow for iSCSI routers to be able to modify a PDU
> > > > header if it is acting
> > > > > as a proxy of some type. It seems that in this case the
> > > > only thing that
> > > > > would be modified would be the BHS and not the AHS. With
> > > > this change, I
> > > > > would envision the AHS be covered by the data digest.
> > > > Again, this makes
> > > > > hardware processing easier, since the header that the digest
> covers
> > > > > is always a fixed length.
> > > > >
> > > > > I also think that the 24 bit total data length is more than
> > > > adequate for the
> > > > > total PDU length. In order to be able to
> > > > efficiently/reliably process PDUs,
> > > > > the PDU length should be on the order of 8-64kBytes in
> > > > length. PDUs of 4
> > > > > GBytes will require 4 Gbytes of reassembly memory in out of
> > > > order cases.
> > > > > This is not reasonable.
> > > > >
> > > >
> > 
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 
> -- 
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054