SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: Frame Formats



    
    
    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
    
    
    
    


Home

Last updated: Tue Sep 04 01:05:14 2001
6315 messages in chronological order