Re: Frame Formats

[julian_satran@il.ibm.com]

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