SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: Problem with use of NotUnderstood in negotiations




    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 <wrstuden@wasabisystems.com>

    08/11/2002 07:57 AM

           
            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        <ips@ece.cmu.edu>
            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





Home

Last updated: Mon Aug 12 22:18:55 2002
11618 messages in chronological order