RE: iSCSI: Framing Steps

["Douglas Otis" <dotis@sanlight.net>]

David,

> Attempting to kill a few red herrings ...

A "red herring" is irrelevance offered to distract.  For red herrings, your
statements are examples.

> TCP is vulnerable to packet injection based on guessing or observing
> the initial sequence number in the absence of fixed-interval-markers
> (FIM).  The well-known connection hijack attack is an example.  An
> attacker can inject arbitrary data into a connection without FIM and
> cause TCP to misbehave as a result.  FIM does not make this any
> easier or change the ways in which TCP would misbehave when attacked
> in this fashion.

FIM enables *processing* of packets out of sequence from the initial send.
The intent of FIM is to make such processing possible and that *does* enable
a greater opportunity for attack especially if the measure is predictable
within future headers.

> FIM does not entail any changes to TCP.  TCP does not care about
> where incoming data is placed in memory - it cares about the order
> in which data is processed by TCP and delivered to the application.

A process that examines application specific structures at the packet (IP)
level, to then move portions of the expected TCP byte stream into user space
based on application references matching these structures, is *not* a
modification to TCP provided there is a *sequential* order of delivery?
Clearly placing a portion of the application below TCP is a modification to
TCP and network layering.  Are you referring to a means at the TCP API to
hide this activity?  Are you saying that the TCP API does not change?  How
is this done without changing TCP?

The application specific processing below this modified TCP transport is to
de-encapsulate the iSCSI payloads into user space. iSCSI user space may not
be satisfied in the sequence they were established.  The complexity involved
will require modification of TCP to support this buffer handling and
application specific structure processing.  In the case of iSCSI, the
content of the byte stream is not known before hand.  This activity below
TCP places and splices sections of the TCP byte stream into designated iSCSI
user space.  Clearly there are many questions one may have with respect to
what and when TCP validates and delivers.  TCP could easily reject a packet
based on the byte sequence within headers that was not rejected by this
"below the transport process" that would be unable to see the header
continuum.  This added state below the TCP transport provides opportunity
for attack or in some implementations, poor behavior.

> The intended usage of FIM affects only the placement of incoming
> data in memory and hence does not change TCP.

Placement of application specific payloads into regions matched against
application specific structure content prior to being handled by the TCP
layer is a change to TCP.  TCP is not able to manipulate buffers in this
manner without extensive modification.  Such modification is quite possible
however, and all the details should be explored before the use of this
scheme is placed into a standards draft however.  My concern remains that
the IPS wg is NOT the place to discuss these concerns as that is not their
expertise nor their charter.

> Meanwhile, Doug appears to have resumed his smear campaign against
> the IPS wg.  Here are three examples:
>
> > FIM has been suggested by those within the IPS wg that implementers
> > consider implementing an otherwise obnoxious scheme requiring the
> > injection of markers or suffer from discarded data otherwise
> > retained using standard versions of TCP.
>
> Indeed it is obnoxious, and Doug conveniently omitted the fact that the
> original message in this thread contains a strong suggestion from this
> IPS wg chair that such an implementation approach is a bad idea because
> it violates an important SHOULD in RFC 1122 (SHOULD queue out of order
> data).
> Scroll to the bottom of this email - it's still there ...

As you point out, I did include such a statement made by you.  You have also
asked the group to drive the framing issue to conclusion but you failed to
indicate that such discussion should not take place within the IPS.  Ensure
that an error is not made where everyone expects such modifications to TCP
even if done unofficially by the IPS.

> > It is clear this group wishes extensive modifications to TCP and
> > does not wish to share these details openly.
>
> Extensive is in the eye of the beholder, but ALL of the proposed framing
> schemes have been openly described on the IPS and/or TSVWG lists and/or
> in Internet-Drafts.

That is a valid statement.  In this case, these details should be extensive
to ensure some problem is not overlooked.

> > One suggestion was to have each iSCSI PDU become framed by a
> > TCP segment. Just the reduction in the average packet size within
> > a high bandwidth stream will stress standard versions of TCP as
> > well as the intervening equipment. SCTP had the foresight to
> > include bundling methods.  This is just one aspect of these
> > proposals to fail consideration within the IPS wg.
>
> This refers to draft-ietf-tsvwg-tcp-ulp-frame-01.txt, a tsvwg that
> proposes changing TCP.  Despite Doug's proclamations that the IPS wg
> should not be discussing changes to TCP, he now criticizes the IPS
> wg for failing to discuss an aspect of a change to TCP???  There's
> just no pleasing some people ... especially as I don't recall this
> specific issue being raised in the past.

I think your using the word smear and this cynical statement are intended to
divert attention from concerns expressed rather than addressing them.  My
critique was with respect to expertise within the IPS in regard to transport
related issues.  A discussion within the IPS should not be expected to fully
vent transport related concerns nor should the IPS be able to declare
closure on this subject.

Doug

>
> Thanks,
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
> black_david@emc.com         Cell: +1 (978) 394-7754
> ---------------------------------------------------
>
> > -----Original Message-----
> > From: Douglas Otis [mailto:dotis@sanlight.net]
> > Sent: Friday, January 25, 2002 6:13 PM
> > To: ips@ece.cmu.edu
> > Cc: Tsvwg
> > Subject: RE: iSCSI: Framing Steps
> >
> >
> > David,
> >
> > Thank you for the response.  I think a further point should have been
> > strongly made.  Such changes to TCP are not actions of the IPS
> > workgroup. These matters should be discussed within the tsvwg.  Even
> > matters of Fixed Interval Marking brings concerns with respect to the
> > impact even this seemingly innocuous iSCSI option may have.
> >
> > Should the interval within the FIM be a power of 2, guessing an initial
> > sequence value allows injection of packets within existing connections.
> > A layer below TCP, as devised for iSCSI, is to place de-encapsulated
> > iSCSI information from isolated packets that include marker information
> > despite prior packet loss.  A general goal of all the framing
> > approaches being sought by the IPS wg.
> >
> > This would require extensive modification of TCP to facilitate this
> > behavior.  In addition, without the specific details of this scheme,
> > largely due to a desire to claim no changes, it is difficult to evaluate
> > related security risks.  One risk of this scheme is the requirement for
> > application specific code to be routinely placed below the transport.
> > There are no conventions for instituting the requisite signaling between
> > this below the transport layer application process and the modified TCP.
> > Should an attack successfully inject even null structures, it would not
> > be clear how the transport would behave.
> >
> > FIM has been suggested by those within the IPS wg that implementers
> > consider implementing an otherwise obnoxious scheme requiring the
> > injection of markers or suffer from discarded data otherwise retained
> > using standard versions of TCP.  Clearly just sending these markers are
> > not in themselves a risk to TCP.  It is their intended use that causes
> > concern.  This FIM has also been indicated by several including the
> > author of iSCSI that FIM is just an interim measure to be followed by a
> > full framing scheme later.  It is clear this group wishes extensive
> > modifications to TCP and does not wish to share these details openly.
> >
> > One suggestion was to have each iSCSI PDU become framed by a
> > TCP segment. Just the reduction in the average packet size within
> > a high bandwidth stream will stress standard versions of TCP as
> > well as the intervening equipment. SCTP had the foresight to
> > include bundling methods.  This is just one aspect of these
> > proposals to fail consideration within the IPS wg.  In general,
> > I think the IETF made a wise choice in proposing SCTP as the means
> > of incorporating framing within IP protocols and the IPS wg was
> > informed of SCTP at the outset of their endeavors.  SCTP provides
> > many advantages with respect to pressing concerns especially the
> > less disruptive nature incorporation of framing using SCTP would
> > cause over an attempt of framing within TCP.  It is clear there is
> > consensus within the IPS wg that SCTP is not to be considered and
> > that TCP framing is despite prohibitions within the charter and
> > the good judgment of the IETF.  The ongoing tacit approval of
> > these discussions regarding modification of TCP within the IPS wg
> > is troubling.
> >
> > Doug
> >
> > > -----Original Message-----
> > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]
> > On Behalf Of
> > > Black_David@emc.com [mailto:David_Black@emc.com]
> > > Sent: Wednesday, January 23, 2002 11:10 PM
> > > To: ips@ece.cmu.edu
> > > Subject: iSCSI: Framing Steps
> > >
> > >
> > > I want to attempt to make some steps towards resolving
> > > the framing issues.  In reviewing the recent discussions
> > > on framing, I have a couple of conclusions:
> > >
> > > (1) I do not believe that WG consensus (rough or otherwise)
> > > 	can be obtained for a "MUST implement" requirement
> > > 	for any form of framing.
> > > (2) The COWS mechanism has a lot of potential, but
> > > 	its newness, the multiple versions that
> > > 	have been mentioned, and the desire for some
> > > 	sort of alignment with new work on DDP/RDMA
> > > 	suggest that COWS is premature to specify as
> > > 	part of iSCSI.
> > >
> > > I suggest that these conclusions form the
> > > basis for further ips WG consideration of framing.
> > >
> > > Please think carefully before objecting to these
> > > conclusions on the list (I'm happy to respond to
> > > private questions/expressions of concern).  If the
> > > framing issue cannot be driven to closure in
> > > the next few weeks, I will be forced to conclude
> > > that the entire topic is experimental, and hence
> > > needs to be removed from the iSCSI specification
> > > and handled in separate drafts intended to become
> > > experimental RFCs.
> > >
> > > Thanks,
> > > --David
> > >
> > > p.s. A desire to build NICs that never behave in
> > > accordance with an important SHOULD in RFC 1122
> > > (out-of-order segments SHOULD be queued) does not
> > > strike me as a good reason for changing the first
> > > conclusion above.
> > >
> > > ---------------------------------------------------
> > > David L. Black, Senior Technologist
> > > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > > +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
> > > black_david@emc.com         Cell: +1 (978) 394-7754
> > > ---------------------------------------------------
> > >
> >
>