RE: iSCSI: Framing Steps

[Black_David@emc.com]

Attempting to kill a few red herrings ...

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 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.
The intended usage of FIM affects only the placement of incoming
data in memory and hence does not change TCP.

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 ...

> 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.

> 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.

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 judgement 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
> > ---------------------------------------------------
> >
>