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.
[Bart
Crane]
Sec. 4.2 stating that "None",
"Reject", "Irrelevant" and
"NotUnderstood"
are reserved implies that they do
need to be tested. The proposed
rule also implies that they be
tested.
My
interpretation is that these values must not be used, except
in
the
way that the spec defines their use.
The
spec defines their use ONLY as a response to an iSCSI-defined
key.
So,
their being used as the initial value to any key is
prohibited.
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.
Bart.
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
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:wrstuden@wasabisystems.com]
Sent: Friday, August 09, 2002 9:12 AM
To: ips@ece.cmu.edu
Subject: Problem with use
of NotUnderstood in negotiations
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
