Subject: Re: [Tsvwg] RE: [rdma] a proposal for a different No-Data-Touch framer for TCP

From: Lloyd Wood <[email-masked]>
Date: Thu, 7 Feb 2002 20:54:32 +0000 (GMT)

On Thu, 7 Feb 2002, Julian Satran wrote:

> The salt is a random number that is changing on every PDU.

you mean a nonce?

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 7 Feb 2002 22:22:39 +0200

Paul,

The salt is a random number that is changing on every PDU. That changes
radically the false detection probability in face on an infinite stream
form certainty to a value that is acceptable from engineering point of
view. Neither protects against malicious user. However the probability of
random good framer in the data becomes nil.

Julo

                    "Culley, Paul"                                                           
                    <Paul.Culley@C       To:     Julian Satran/Haifa/IBM@IBMIL               
                    OMPAQ.com>           cc:     <[email-masked]>, <[email-masked]>    
                                         Subject:     RE: [rdma] a proposal for a different  
                    07-02-02 16:06        No-Data-Touch framer for TCP                       

I am having a hard time understanding the advantage of the "salt", as
opposed to a longer framing key.  Both would seem to have the same
probability of false recognition.  Neither protects against the extreme
case where an application places a valid frame within the ULP data (I
assume that the application knows the frame key, adds its own salt, that
it can generate a CRC etc.).

I also presume that reasonable implementations will chose the framing
key randomly, perhaps with a bit of selectivity, like not using values
with leading zeros etc.

Also, do you have a probability of false recognition that you are
shooting for?  How does it compare to the probability of other types of
false negative errors associated with TCP with a PDU CRC?

For example, has anyone looked at what happens if a (lightly protected)
TCP sequence number is corrupted, possibly while a packet is also
dropped?

Given a few other rules around out of order placement which also improve
the odds, I personally feel like this issue is being over designed.
Rules like:
 1) don't actively search for frames, unless it appears on a segment
boundary, wait for previous segments to arrive so the correct boundary
can be calculated.  (resegmenting middle boxes kill out of order
placement).
 2) don't place unless its in the TCP RWIN
 3) ULP checks should still be made, and failures could cause the
implementation to drop/wait until framing can be assured. (bigger layer
violation, for more paranoid designers).

Paul R. Culley
Compaq Sr. Fellow
281-514-5543

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 8:08 PM
To: Martin, Nick
Cc: [email-masked]; [email-masked]
Subject: RE: [rdma] a proposal for a different No-Data-Touch framer for
TCP

Martin,

I am glad you like it.
The salt is a random number (a RN generator generates a new one at every
PDU). That is why it is hard to guess.
PDU headers are not random enough. It is essential that it is random and
different in every frame.
For iSCSI this comes a bit late but for a "generalized framing" I think
that this is a good solution with a very low price tag.

Thanks,
Julo

                    "Martin, Nick"

                    <Nick.Martin@C       To:     Julian
Satran/Haifa/IBM@IBMIL
                    OMPAQ.com>           cc:

                                         Subject:     RE: [rdma] a
proposal for a different
                    06-02-02 02:42        No-Data-Touch framer for TCP

Julian,

I *really* like this proposal.

Here is what I think I understand about the NDT framing draft
(un-optimized).  The two ends would agree upon a unique 32-bit value to
be
used as the framing pattern.  The next 32 bits are random, and the next
32-bits are a digest.  This effectively defines 2**32 sets each
containing
2**32 valid 96-bit frame markers.  Each connection will use markers from
one of the 2**32 sets.  If a secret value is added, there become 2**64
sets
each containing 2**32 valid 96-bit frame markers.  Entities other than
the
intended recipient are less likely to know whether the digest is
correct.
However, with each frame beginning with the same framing pattern, and a
published standard for how to compute the digest, it still seems fairly
easy to synthesize the "secret" on a long living connection.

I like NDT (optimized) for iSCSI framing.  Except for the salt and
shared
secret, this version looks equivalent to having each iSCSI PDU header
start
with a framing pattern, and including that pattern in the header digest.
If someone asked me how to do framing for iSCSI, that is what I would
have
done.  [Start of PDU marker without salt or secret, turn on digests].
It
is simple and obvious how to do this in either software or hardware,
with
or without turning your network stack inside out. [I have had difficulty
understanding why all the more complex proposals were desired.]  As you
point out, statistically the 32-bit framing pattern alone, even if
required
to be on a frame boundary, can easily be fooled into making a mistake.
However, with ULP (iSCSI) digests enabled, the probability of an
undetected
mistake is much lower.  [I would say acceptable.]  Given that digests
are
enabled, I believe the probability of an undetected mistake with the
32-bit
framing pattern included in the digest is about the same as with the
framing pattern excluded from the digest.  Just adding the framing
pattern
to iSCSI requires only 32-bits per PDU.  Adding the framing pattern and
salt is only 64-bits.

For an iSCSI software implementation on top of an unmodified [Operating
System Vendor provided] TCP stack, I can not take advantage of out of
order
placement and also may not be able to detect TCP/IP packet boundaries.
When discarding a PDU header with a bad digest possibly followed by data
of
un-trusted length, I would like to be able to quickly recover/confirm
the
next PDU boundary using a framing marker and a digest, rather than
computing the iSCSI digest at each succeeding 4 byte boundary.  [I would
*not* like to have to generate, nor to locate and discard, framing
markers
in the middle of otherwise perfectly good PDUs.]

I have a couple of questions about the salt.  Are there any rules for
generating it?  If the rest of the ULP PDU header is included in the
digest, would this not be as effective as the salt?  When a shared
secret
or other data value not transmitted with the PDU is included in the
digest
calculation, is this as effective as adding salt, so that explicit salt
would not be needed?  If the secret and/or the ULP header can replace
the
salt, the frame markers overhead shrinks another 32-bits.

I also appreciate that the un-optimized version of the NDT framer can
easily and efficiently be inserted above or below almost any other
protocol
layer by hardware or software.  On the outbound side, it does not need
to
be told the length of the next ULP PDU.  It only needs to know when a
PDU
boundary (either beginning, ending, or both) has been reached.

Thanks,
Nick

P.S. I did not copy this message the reflector.  You are free to do what
you please with it.
 -----Original Message-----
 From: Julian Satran [mailto:[email-masked]]
 Sent: Saturday, February 02, 2002 3:49 AM
 To: [email-masked]; [email-masked]
 Subject: [rdma] a proposal for a different No-Data-Touch framer for TCP

 Dear Colleagues:

 I've recently submitted a draft including a different
"No-Data-Touch"(NDT)
 framer.
 Unlike the current proposed NDT framer that has a "mistake" probability
 that increases asymptotically (to 1) with the stream length the framer
I
 am suggesting has a very low and constant mistake probability and is
thus
 safe to use even in the absence of alignment or in the presence of
 re-segmentation.

 It does not contain the standard RFC2026 reference not as an indication
of
 patent - I have no  patent on it and I do not know about the existence
of
 one (nor did I search thoroughly) - but rather as a sign of discomfort
for
 it to be used without me being asked about it.

 Until it apperas you can find it also at:

 http://www.haifa.il.ibm.com/satran/ips/draft-satran-NDT-Framing-00.pdf

 http://www.haifa.il.ibm.com/satran/ips/draft-satran-NDT-Framing-00.txt

 Julo

       Yahoo! Groups Sponsor

           ADVERTISEMENT

 To unsubscribe from this group, send an email to:
 [email-masked]

 Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Tiny Wireless Camera under $80!
Order Now! FREE VCR Commander!
Click Here - Only 1 Day Left!
http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/W6uqlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email-masked]

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 07 Feb 2002 22:17:05 -0500

Julian,

I was also initially excited by your proposal, but I've come to a
similar conclusion to Paul.

The key question is what property is probability in the framing
mechanism providing.  I claim it's for safety.

A safety analysis should assume a worst possible data stream.  But not
worst `impossible'---bits that are knowable are knowable, and bits
that are unknowable can't be used to construct a worst possible
stream).

I do not think your proposal provides better safety than the current
TUF.  In fact, it might be worse.  I agree that both are difficult to
analyze, in any case.

Bad data streams in your proposal would be something like groups of 3
words, with an incrementing first word (the supposed marker), a 0
salt and the corresponding digest.  If you got clever, I bet
you could even interleave so that the digest from the first candidate
is is the marker for the second.  Really clever would be to use the
salt of the first as the marker for the second.  I imagine that a
`good digest' would have the property that you could cover all the
marker possibilities this way in only 2^32 words.

As far as I can tell, ceasing PDU containment validation attempts long
before you've checked many false candidates is of primary importance
to maximizing safety in EITHER approach.  I don't buy your claim that
safety is not a function of the number of tests of false candidates in
your approach.  The probability that must be controlled in either
case, is the chance of actually testing a false candidate.

Steph