Subject: RE: Problem with use of NotUnderstood in negotiations

From: "Julian Satran" <[email-masked]>
Date: Sun, 11 Aug 2002 08:40:16 +0300

Bill,

I am afraid you have to remember any key received just to avoid a rough 
initiator/target knowingly send noise.
You may also want to terminate a session with too many "NotUnderstood".

Julo

Bill Studenmund <[email-masked]>
08/11/2002 07:57 AM

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

On Sun, 11 Aug 2002, Julian Satran wrote:

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

And my appologies if I saw rudeness that was not intended.

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

Ok. That would work. Also see my proposed text that crossed this one in
the mail.

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

But do we need to remember keys we didn't understand? I hadn't taken that
away from the spec before now; I (and others, as evidenced by code :-)
thought it was safe to just respond and be on with it. For the
double-negotiation rule to catch it, we have to remember them.

Is that really what we want? I have this unplesant image of one side
wanting to try a whole lot of vendor keys (different vendors), and the
other side being a simple negotiator and getting overwhelmed.

Take care,

Bill

---

From: Bill Studenmund <[email-masked]>
Date: Sat, 10 Aug 2002 22:49:29 -0700 (PDT)

> You may also want to terminate a session with too many "NotUnderstood".

Ugh.

Well, if that's the way we want to do it, then you're right that the
no-double-negotiation rule will cover it, and your text you sent earlier
is probably fine.

Thanks for the input!

Take care,

Bill

---

From: Martins Krikis <[email-masked]>
Date: Mon, 12 Aug 2002 18:32:58 -0700 (PDT)

> You may also want to terminate a session with too

Alright, so I understood everything so far and do
realize that checking values for keys I don't
understand may let me notice a protocol error
quicker than by just returning NotUnderstood. 

I also think that the likelihood of this
problem occuring is so low that letting both sides
bounce back and forth the OGMarker=NotUnderstood
until they time out or reach negotiation round 
limits would be acceptable.

What I don't understand, however, is why I should
try to remember the keys that I don't understand.
What can possibly be gained from this? If the
other party is dumb enough to send me a key that
I don't understand twice, I don't mind noticing
the problem only after a timeout or a negotiation
round limit reached. And if the other side is 
simply just DoS-ing me, it can do it whether I am
remembering unknown keys or not. That possibility
was always in the protocol and there are no
good ways to guard against it. That's why a good
overall timeout or a limit on negotiation rounds
is needed.

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
            be those of my employer

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

---

From: Paul Koning <[email-masked]>
Date: Tue, 13 Aug 2002 09:32:25 -0400

>>>>> "Martins" == Martins Krikis <[email-masked]> writes:

 Martins> --- Julian Satran <[email-masked]> wrote:
 >> I am afraid you have to remember any key received just to avoid a
 >> rough initiator/target knowingly send noise.  You may also want to
 >> terminate a session with too many "NotUnderstood".

 Martins> What I don't understand, however, is why I should try to
 Martins> remember the keys that I don't understand.  What can
 Martins> possibly be gained from this? If the other party is dumb
 Martins> enough to send me a key that I don't understand twice, I
 Martins> don't mind noticing the problem only after a timeout or a
 Martins> negotiation round limit reached. And if the other side is
 Martins> simply just DoS-ing me, it can do it whether I am
 Martins> remembering unknown keys or not. 

Agreed.

It is quite unreasonable to require a pile of extra overhead that ONLY
does anything if the other side is actively malicious.  Robustness in
the presence of Byzantine failure was never in the iSCSI requirements,
nor as far as I know is it in the requirements of ANY IETF protocol.

    paul