Subject: RE: Frame Formats

From: Gary Kotzur <[email-masked]>
Date: Tue, 27 Mar 2001 13:12:08 -0800

I vote for Format-2.  Looking at it from a hardware perspective, having the
fixed placement for the AHS and data length would make it easier for data
allocation and placement in buffer space.

---

From: [email-masked]
Date: Wed, 28 Mar 2001 09:11:57 +0200

Mike,

I understand your concerns (as my hearth is still divided between hardware
and software -:))

Regarding digests including only BHS - it has crossed my mind too several
times.  The argument against it is that it is not future proof - yes todays
AHSs don't get modified by a proxy but how long will it hold?

In addition I have some trouble understanding what you find objectionable
on format 1 (remember I am neutral).  With both 1 and 2 you know where the
digest is and you don't have to use the data length until the header is
checked. With 1 you have the additional benefit of a parity check for the
length. In 99.99% of the cases
you have only one length to care about and in format 1 this is additionally
protected with parity (makes resynch easier in case of a header digest
failure).

As for the size of the PDU - I am older and more cautious on this as I
recall the days when 64k was more that you would ever need and I built a
large machine with an ALGOL compiler on 24k -:).  But I agree that for now
24 bit should suffice and for later we can use an AHS if need arises.

Julo

Mike Thompson <[email-masked]> on 27/03/2001 19:05:36

Please respond to Mike Thompson <[email-masked]>

To:   "[email-masked]'" <[email-masked]>
cc:
Subject:  Re: Frame Formats

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.

---

From: Mike Thompson <[email-masked]>
Date: Wed, 28 Mar 2001 11:01:03 -0800

Julian,

My major objection to Format 1 is that, as I interpret it, to determine the
total length of the PDU requires a more processing. In format 2, I only have
to interpret the first word (of course after verifying the digest). This
allows hardware to quickly scan for data PDUs to do data placement when in
an out of order condition. In format 1, the first word sometimes has the
data length and I have to interpret the DL bits and conditionally look in a
couple of locations to gather up the lengths to do the processing.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Tuesday, March 27, 2001 11:12 PM
> To: [email-masked]

---

From: Mike Thompson <[email-masked]>
Date: Wed, 28 Mar 2001 10:51:36 -0800

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

> From: Robert D. Russell [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2001 12:30 PM
> To: Mike Thompson
> Cc: [email-masked]'
> 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
> > reasonable. With these two fields at the beginning of the 
> PDU, hardware will
> > to allow for iSCSI routers to be able to modify a PDU 
> header if it is acting
> > I also think that the 24 bit total data length is more than 
> adequate for the

---

From: [email-masked]
Date: Thu, 29 Mar 2001 07:56:31 +0200

Venkat,

Thanks.  Only one point about lengths - AHS length is in 4 byte units (and
all are 4 byte aligned). Data is paded to 4 bytes but the data length
covers only real data in bytes.   As for digests covering the data padding
we could go either way.

Regards,
Julo

Venkat Rangan <[email-masked]> on 29/03/2001 04:22:00

Please respond to Venkat Rangan <[email-masked]>

To:   "'Mike Thompson'" <[email-masked]>, "[email-masked]'"
      <[email-masked]>
cc:
Subject:  RE: Frame Formats

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:[email-masked]]
Sent: Wednesday, March 28, 2001 10:52 AM
To: [email-masked]'
Subject: RE: Frame Formats

Robert,

Mike

---

From: [email-masked]
Date: Thu, 29 Mar 2001 09:50:22 -0500

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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> From:	Mark Bakke [SMTP:[email-masked]]
> Sent:	Thursday, March 29, 2001 9:28 AM
> To:	[email-masked]
> Cc:	[email-masked]
> 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
> 
> [email-masked] wrote:
> > 
> > Mark,
> > 
> > Security guys want you to randomize pad.  0s are a weakness.
> > 
> > Julo
> > 
> > Mark Bakke <[email-masked]> on 29/03/2001 15:24:15
> > 
> > Please respond to Mark Bakke <[email-masked]>
> > 
> > To:   Venkat Rangan <[email-masked]>
> > cc:   "'Mike Thompson'" <[email-masked]>, "[email-masked]'"
> >       <[email-masked]>
> > 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,
> > >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > [email-masked]
> > 763.398.1054
> -- 
> Mark A. Bakke
> Cisco Systems
> [email-masked]
> 763.398.1054

---

From: [email-masked]
Date: Thu, 29 Mar 2001 17:28:45 +0200

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

Mark Bakke <[email-masked]> on 29/03/2001 16:27:48

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  Re: Frame Formats

Julian-

--
Mark

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: [email-masked]
Date: Fri, 30 Mar 2001 07:31:39 +0200

Thanks Glen - the online copy is at:

http://www.haifa.il.ibm.com/satran/ips

Julo

Glen Turner <[email-masked]> on 30/03/2001 06:35:14

Please respond to Glen Turner <[email-masked]>

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

Hi Julo,

Ignore the "security people".  I've worked on three crypto
products and good crypto people know that random numbers
are hard.

Furthermore, poor pseudo-random numbers by definition leak
machiine state.  This gives you something to hang your
hat on when seeking to defeat the crypto.

Zero-fill any unused bytes.  Don't leak further machine
state by leaving them at pre-existing values.

If a cryptographer needs a more random stream then they'll
insert their own random header (as this is under the crypto
device's control whereas a user-inserted header isn't) and
compress the user data.

Regards,
Glen

PS: Where is the online copy of the frame formats presented
at the meeting?

--
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 [email-masked]          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised

---

From: "John Hufferd" <[email-masked]>
Date: Sat, 31 Mar 2001 17:20:17 -0800

Well, perhaps I was just not quick enough.  I thought I would let this
settle out a bit before I added my two cents.

If you all remember, some folks on this reflector gave Julian a hard time
because you would have to use a length field that you were not sure was OK,
if you had a digest error and wanted to jump forward to the next, etc. etc.
etc.  I am sure you all remember this.  OK, now that Julian proposed a
parity way to ensure that you could trust the length field, some of the
parties, have now, I think, voted for format #2.  Unless you want now to
reconsider your vote, we should stop giving Julian a hard time about the
length not being ensured correct in the presents of a Digest Error.

Either drop the session, or use the length to see if you can get somewhere,
search for the next marker etc.  All the stuff you said you did not like
before.  OK, now you have format 2, but lets not go over that old ground
now that you have decided against the parity.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: [email-masked]

Julian Satran/Haifa/IBM@[email-masked] on 03/30/2001 08:51:50 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  frame formats

Dear colleagues,

It look like Format-2 is selected by popular vote.

Julo