Subject: Problem with use of NotUnderstood in negotiations

From: Bill Studenmund <[email-masked]>
Date: Fri, 9 Aug 2002 09:12:23 -0700 (PDT)

I encountered a problem with how draft 15 specifies using NotUnderstood as
a reply to keys that aren't understood. Namely if something injects
garbage into the negotiation stream we can end up with a key BOTH sides
don't understand, and so they both sit there sending "foo=NotUnderstood"
back and forth to each other.

Yes, well-behaved negotiators won't offer a key they don't understand. But
the data stream can be corrupted, and all it would take is a single-bit
error in a key name and we encounter the above.

I propose we change the text to:

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. If the value for the key was "NotUnderstood", the
acceptor MUST not answer the key.

Note: I can easily see closing the connection with an error in the above
case too.

Thoughts?

Take care,

Bill

---

From: Bart Crane <[email-masked]>
Date: Fri, 9 Aug 2002 12:32:44 -0700

This new rule is not necessary.

Sec. 4.2 says:

   The constants None, Reject, Irrelevant, and NotUnderstood
   are reserved and must only be used as described here.

In the situation you describe, the sender will be expecting 
a response to "keyA", but the key-name was corrupted to "keyB".

The receiver does not understand "keyB", and so responds with 
"keyB=NotUnderstood".

To the sender, this appears to be the start of negotiating a
new key, "keyB", with the value "NotUnderstood".  

But, this is not a valid use of the value "NotUnderstood", 
so it is a protocol error.

So, the new rule of not-responding to keys with the value 
"NotUnderstood" is not necessary.

Bart.

-----Original Message-----
From: Bill Studenmund [mailto:[email-masked]]
Sent: Friday, August 09, 2002 9:12 AM
To: [email-masked]
Subject: Problem with use of NotUnderstood in negotiations

Thoughts?

Take care,

Bill

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 10 Aug 2002 07:11:21 +0300

Pat,

The current text is explicit in restricting the use of the special values
NotUnderstood, Reject etc.

Julo

                      pat_thaler@agilen                                                                                             
                      t.com                    To:       [email-masked], [email-masked]                                         
                      Sent by:                 cc:                                                                                  
                      [email-masked]        Subject:  RE: Problem with use of NotUnderstood in negotiations                      
                      .edu                                                                                                          

                      08/09/2002 11:04                                                                                              
                      PM                                                                                                            

Bart,

So the question is, in what order does a device do the checking.

There are many possibilites for handling a received key that is
unknown and comes in with the value unknown:

A) Check key
       if key unknown, send key=NotUnderstood
         else ...process key=value pair

B) Check key
       if key unknown
         if value=NotUnderstood silently drop (or close connection)
           else send key=NotUnderstood

I expect case A is more likely to get implemented in the absence
of an explicit statement. There would normally be no need to
examine the value of a key when one doesn't understand the key.
In this case, the receiver never does a test that detects the
apparent protocol violation of making an offer with a value
NotUnderstood.

So, if we want to stop the loop that Bill has found, we should
put in an explicit requirement to test the value for NotUnderstood
before responding to a key with NotUnderstood.

The alternative is to leave things as they are and count on
implementations to abort the negotiation based on a timeout
or a count of excessive number of negotiation PDU exchanges.

Regards,
Pat

-----Original Message-----
From: Bart Crane [mailto:[email-masked]]
Sent: Friday, August 09, 2002 12:33 PM
To: [email-masked]
Subject: RE: Problem with use of NotUnderstood in negotiations

Sec. 4.2 says:

Bart.

-----Original Message-----
From: Bill Studenmund [mailto:[email-masked]]
Sent: Friday, August 09, 2002 9:12 AM
To: [email-masked]
Subject: Problem with use of NotUnderstood in negotiations

Thoughts?

Take care,

Bill

---

From: [email-masked]
Date: Mon, 12 Aug 2002 14:08:24 -0600

Julian,

I agree that the current text is explicit in restricting the use of the special values. In the scenario suggested each device is using NotUnderstood as the text requires.

Where the ambiguity arises is what checking one does on values of a key that one doesn't understand. When you are doing a series of tests for validity and the first one fails, do you take the action that failure requires or do you first do some of the following tests? Usually one would do the former unless there was an explicit requirement to do additional tests.

I don't find anything in the current text that requires checking the value when one receives an not understood key. Furthermore, I don't think it is necessary to require such a check. 

The scenario that was brought up was a corner case that hangs up login. There can be other corner cases we haven't discovered yet. It makes more sense to deal with it by timing out a negotiation that goes on too long (in time or number of exchanges) than by making a special rule for this particular corner case.

Regards,
Pat

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, August 09, 2002 9:11 PM
To: [email-masked]
Subject: RE: Problem with use of NotUnderstood in negotiations

Pat,

Julo

                      pat_thaler@agilen                                                                                             

                      08/09/2002 11:04                                                                                              
                      PM                                                                                                            

Bart,

A) Check key

B) Check key
       if key unknown

Regards,
Pat

-----Original Message-----
From: Bart Crane [mailto:[email-masked]]
Sent: Friday, August 09, 2002 12:33 PM
To: [email-masked]
Subject: RE: Problem with use of NotUnderstood in negotiations

Sec. 4.2 says:

Bart.

-----Original Message-----
From: Bill Studenmund [mailto:[email-masked]]
Sent: Friday, August 09, 2002 9:12 AM
To: [email-masked]
Subject: Problem with use of NotUnderstood in negotiations

Thoughts?

Take care,

Bill

---

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Mon, 12 Aug 2002 14:08:31 -0600

Julian,

In the scenario, each device does use Notunderstood in a response. 

A sends keyxxx
Silent data corruption occurs that changes keyxxx to keyxxy
B gets keyxxy and doesn't recognize it so it responds
keyxxy=Notunderstood
A gets that and thinks it is an offer of a key it doesn't understand because it never sent keyxxy.
A therefore sends
keyxxy=Notunderstood
B gets keyxxy and doesn't recognize it so it responds
keyxxy=Notunderstood
.....

Regards,
Pat

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, August 09, 2002 9:24 PM
To: [email-masked]
Subject: RE: Problem with use of NotUnderstood in negotiations

Bill,

Perhaps the text is unabiguos but you just ignored the text that forbids
it.
The use of Notunderstood is limited to responses. Using it as you suggest
is a protocol error.
A repeated use will also violate the "no renegotiation rule".

Julo

                      Bill Studenmund                                                                                               
                      <wrstuden@wasabis        To:       Bart Crane <[email-masked]>                                             
                      ystems.com>              cc:       <[email-masked]>                                                          
                      Sent by:                 Subject:  RE: Problem with use of NotUnderstood in negotiations                      
                      [email-masked]                                                                                             
                      .edu                                                                                                          

                      08/10/2002 02:22                                                                                              
                      AM                                                                                                            

On Fri, 9 Aug 2002, Bart Crane wrote:

?? In the scenario I describe, neither side believes it offered the key.

> Thus, there is no need to add another rule regarding not-responding to
> keys with NotUnderstood as a value, because a key with that value is
> a protocol error.
>
> This could be made more explicit, but there does not seem to be any
> ambiguity.

There obviously is ambiguity. The fact we're having this discussion is
proof. :-)

I'd support saying this case is a protocol error, since it means something
neither side understands got into the stream (and chances are an offer got
removed). But I think adding an explicit direction as to what to do is
needed.

Take care,

Bill

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 13 Aug 2002 10:02:54 +0300

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

[email-masked]
Sent by: [email-masked]
08/13/2002 03:35 AM

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc:     [email-masked]
        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:[email-masked]]
Sent: Saturday, August 10, 2002 9:40 PM
To: Bill Studenmund
Cc: [email-masked]
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 <[email-masked]> 
08/11/2002 06:11 AM 
        
        To:        Julian Satran/Haifa/IBM@IBMIL 
        cc:        <[email-masked]> 
        Subject:        RE: Problem with use of NotUnderstood in 
negotiations 

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

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

---

From: [email-masked]
Date: Tue, 13 Aug 2002 10:28:07 -0600

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:[email-masked]]
Sent: Tuesday, August 13, 2002 12:03 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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 

	[email-masked] 

08/13/2002 03:35 AM 

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. 

Regards, 
Pat 
  
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Saturday, August 10, 2002 9:40 PM
To: Bill Studenmund
Cc: [email-masked]
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 

08/11/2002 06:11 AM 

Julian,

***

Take care,

Bill

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 14 Aug 2002 01:42:27 +0300

OK - Julo

[email-masked]
08/13/2002 07:28 PM

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc:     [email-masked], [email-masked], [email-masked]
        Subject:        RE: Problem with use of NotUnderstood in negotiations

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.

Regards,
Pat

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, August 13, 2002 12:03 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Problem with use of NotUnderstood in negotiations

Pat, 

as well as add to 8.3 

Julo 

[email-masked] 
        
        To:        Julian Satran/Haifa/IBM@IBMIL, 
[email-masked] 
        cc:        [email-masked] 
        Subject:        RE: Problem with use of NotUnderstood in 
negotiations 

Julian, 

  

  

or 

  
  
Regards, 
Pat 
  
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Saturday, August 10, 2002 9:40 PM
To: Bill Studenmund
Cc: [email-masked]
Subject: RE: Problem with use of NotUnderstood in negotiations

Bill, 

Julo 

Julian,

***

Take care,

Bill