RE: Problem with use of NotUnderstood in negotiations

[pat_thaler@agilent.com]

Julian,

 

Silent data corruption is when errors change the data in a way that is not detectable. It should be a rare event in a well designed system but it does occasionally occur. For iSCSI, silent data corruption would require:

 

Error changes the payload such that the link layer CRC check passes (very low probablility - roughly

(BER^3)*2^32) or the error occurs when the payload is not protected by link layer CRC (e.g. soft memory errors while in switch/router memory).

AND

TCP checksum escape (TCP checksum matches the corrupt data)

 

Once in operational mode, we have the option of using digest to put a further barrier against silent data corruption. We have designed at least some protocol options (digests) for dealing with checksum escape.

 

I think the approach you suggest for dealing with this is appropriate.

Shouldn't this condition also be added to the list of errors in 5.10 Negotiation Failures?

 

For the text in 4.2, it isn't clear what the must applies to. One might use:

 

An iSCSI device MAY terminate a negotiation which does not end within a reasonable time or number of exchanges.

 

For 8.3 it looks like MAY and SHOULD should be upper case.

 

Regards,

Pat

 

 

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, August 13, 2002 12:03 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; wrstuden@wasabisystems.com
Subject: RE: Problem with use of NotUnderstood in negotiations

Pat, 

I don't 
know what "silent data corruption is". The protocol is not built for this type 
of errors. 
Other than that you observe 
correctly that we do not mandate the receiver to check for every 
protocol error. However if it does not 
it has to implement some other means of protecting itself. 
None of the things that where suggested as protection are 
(or should be) mandatory. 
As for the 
count/timeout we may want to add to 4.2: 

A negotiation must end in within a reasonable time and/or number of 
exchanges. 

as well as add to 
8.3 

Text negotiations may be also 
subject to either time-limits or lim-its in the number of exchanges. Those 
should be generous enough to avoid affecting interoperability (e.g., allowing 
each key to be nego-tiated on a separate exchange). 

Julo

pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 08/13/2002 03:35 AM

To:        Julian Satran/Haifa/IBM@IBMIL, wrstuden@wasabisystems.com         cc:        ips@ece.cmu.edu         Subject:        RE: Problem with use of NotUnderstood in negotiations

Julian, 
  
Saying that a violation of a rule is a protocol error is not the same as 
saying that the receiver must detect and react to the error. I don't think your 
suggested change to the text changes anything. If we want to say that receiving 
an offer for any key (even if the key is not understood) with a value of 
"Reject", "Irrelevant" or "NotUnderstood" MUST be detected and treated as a 
protocol failure, then a specific statement to that effect should be 
added. 
  
Secondly, there is no requirement that re-negotiation MUST be 
detected. The specific text on renegotiation is (for login):

If an attempt to re-negotiate/redeclare parameters not specifically allowed is detected by the target the target MUST respond with Login reject (initiator error); if detected by the initiator the initiator MUST drop the connection.

The text for operational negotiation is similar except that the actions taken on detection are different.
 
It says "If an attempt ...is detected" which is entirely different than saying such attempts "MUST be detected".
 
As Bill as pointed out, detecting re-negotiation of unknown parameters is onerous and I am very opposed to adding such a requirement. It adds unnecessary cost for minimal benefit. For the keys that are supported, on just needs a couple of bits per parameter to keep track of whether the state is unnegotiated, received offer, sent offer or negotiation complete and one may need that state even if one wasn't going to detect re-negotiation. Thus, it is pretty trivial to detect re-negotiation of supported keys.
 
If someone wants to maliciously tie up a negotiation, they can do so by continuously offering new unknown keys and no working non-malicious implementation will keep offering the same key. One would have to save all
received unsupported keys and each time an unsupported key was received it would have to be compared to the list. This is time and memory consuming and unnecessary. It isn't required by draft 15 and no such requirement should be added.
 
A simpler solution to concerns about the silent data corruption problem Bill identified is either
 
1) add in text requiring that an offer the value equal to NotUnderstood be detected as a protocol error even if the key is not supported/not understood
 
or
 
2) rely on timing out the negotiation if it doesn't complete after reasonable time or number of exchanges (definition of reasoanble left to the implementation probably).
 
Personally, I prefer number 2 because it will catch anything that hangs up a negotiation with one test. I don't know that we can find every corner case. Even if we could, it is better to have one test that digs us out for all corner case errors than to put in many specific tests.
 
However, number 1 would also be acceptable to me.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 10, 2002 9:40 PM
To: Bill Studenmund
Cc: ips@ece.cmu.edu
Subject: RE: Problem with use of NotUnderstood in negotiations


Bill,

My only intention in the note was to be brief.  If you viewed that as rude I am really sorry.
I have a lot of mail to reply to and a limited time.

As for the crux of the matter - if one of the parties receives a key it has not seen before
with NotUnderstood as value it MUST act on it as a protocol error. The text is unambiguous on this.
However we may want to strengthen the rule in 4 (and add another line of text) as follows:

The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrele-vant", and "NotUnderstood" as proposed values).

In the second part of my comment I was just saying that if you  failed to implement the above check you still can't enter a loop
because the double negotiation rule.

To get you in a loop in which every party think it answers - then either both are buggy or somebody is altering the messages maliciously.
The protocol is not designed to handle either.

Julo

Bill Studenmund <wrstuden@wasabisystems.com> 08/11/2002 06:11 AM

To:        Julian Satran/Haifa/IBM@IBMIL        cc:        <ips@ece.cmu.edu>        Subject:        RE: Problem with use of NotUnderstood in negotiations

On Sat, 10 Aug 2002, 
Julian Satran wrote:

> Bill,
>
> Perhaps the text is 
unabiguos but you just ignored the text that forbids
> 
it.

Julian,

I must say that the tone above is very unbecoming of 
the author of a
protocol spec. In the past, I've often gotten snippy comments 
from you,
but written them off to, well, I'm not sure what. But it seems that 
you
really don't listen to what I say. You read a message, make 
an
interpretation, do not question that interpretation, and then you run 
with
it. That's really bad. Besides being quite rude and exceedingly 
arrogant,
you'll miss things. And the iSCSI spec will suffer for it. Do you 
think
whatever is going on between us worth more than a bad iSCSI spec? I 
don't.

Also, if you're going to say that the text is unambiguous, please 
quote
said text. That makes the discussion much clearer.

> The use 
of Notunderstood is limited to responses. Using it as you suggest
> is a 
protocol error.

Julian, I have to ask, what exactly do you think I'm 
suggesting? From
parsing your sentence, I read that you are telling me that 
I'm suggesting
using NotUnderstood outside its limited scope, of 
responses.

As I understand the situation I described, both parties think 
they are
using NotUnderstood as a response. How is using it as a response 
outside
its use as a response?

> A repeated use will also violate 
the "no renegotiation rule".

Please be VERY VERY VERY careful when saying 
that. Have you thought about
what the statement you just made will 
imply?

We are (or at least I started) talking about the case where one 
side
THOUGHT it sent key X, but somehow it was key Y that made it to the 
other
side. Be it a bug in the code on one side or the other, a PCI bus error 
in
transfer, a router glitch, or what. Key Y doesn't exist in the spec, 
and
it's in the negotiation stream. OGMarker or DataPDPInOrder would 
be
examples.

The point is, BOTH SIDES THINK THEY ARE RESPONDING to a 
key they don't
understand. Reading the spec, it succinctly states if you get 
a key you
don't understand, you MUST reply "NotUnderstood".

Getting 
back to the "repeated use is a protocol violation," how is each
side supposed 
to realize that they are seeing "OGMarker=NotUnderstood" for
the second time, 
other than by remembering that it saw OGMarker as a
not-understood key. i.e. 
by in addition to replying, "NotUnderstood", each
side has to remember that 
it responded NotUnderstood to key foo. That
seems unwise. I can think of at 
least one DoS attack if that really is
what implementations 
do.

Getting back to addressing the topic of the thread, what is wrong 
with
this text, slightly modified from the I proposed in the first 
message?

***
Any key not understood by the acceptor may be ignored by 
the acceptor
without affecting the basic function. However, unless the value 
for the
key was "NotUnderstood", the answer for a key not understood MUST 
be
key=NotUnderstood. The value "NotUnderstood" for a key not understood 
MUST
be considered a protocol violation.
***

As I said before, my 
main interest is the spec point out that if for a key
you don't understand 
you get the value "NotUnderstood" (i.e. the other
side is telling you it 
didn't understand a key that it turns out you also
don't understand), you 
don't just answer "NotUnderstood". Either
saying nothing, or considering it a 
protocol violation (since if we both
didn't understand the key it should have 
never gotten into the
negotiations) are both fine options. I now favor 
protocol violation as if
neither side understood the key, it should not be 
there. If it's there, 
something is wrong.

Take 
care,

Bill