Re: Frame Formats

[julian_satran@il.ibm.com]

I have no idea. I guess that they think random is easy. Julo

Mark Bakke <mbakke@cisco.com> on 29/03/2001 16:27:48

Please respond to Mark Bakke <mbakke@cisco.com>

To:   Julian Satran/Haifa/IBM@IBMIL
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