Subject: [AAA-WG]: [issue] my issues

From: Pat Calhoun <[email-masked]>
Date: Fri, 18 May 2001 12:28:32 -0700

These were sent to the chairs, but I thought I should probably share
them with the WG. They are the same as the various e-mails I sent
earlier this week. Note that most of these weren't initiated by
myself, but since I collected them into e-mails, I wasn't sure
if the original owners would step up, so just in case I have
create an issue for each of them.

See y'all next week,

PatC
----

Routing of Indication messages

Submitter name: Pat Calhoun
Submitter email address: [email-masked]
Date first submitted: May 15, 20001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00878.html
Document: Base
Comment Type: Technical
Priority: S
Section: (throughout)
Rationale/Explanation of issue:
        Since successful Indication messages have no response, and these
        messages MUST be queued in the pending message queue, a Diameter
        node does not know when to remove the message from the queue.

Requested change:
        Indication messages ALWAYS have a response.

Proposal to modify STI

Submitter name: Paul Funk
Submitter email address: [email-masked]
Date first submitted: May, 20001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00881.html
Document: Base
Comment Type: Technical
Priority: 1
Section: (throughout)
Rationale/Explanation of issue:
        There is a desire to eliminate the STI message. Currently, a
        server that wishes to terminate a session requires 1.5 round
        trips (STI, STR, STA).

Requested change:
        Either allow the server to initiate the STR, or create a new
        message set (Kill-Session-Request and Kill-Session-Answer),
        which cannot be sent by the access device.

Sessions that do not start

Submitter name: Paul Funk
Submitter email address: [email-masked]
Date first submitted: May, 20001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00884.html
Document: Base
Comment Type: Technical
Priority: S
Section: 10.1, and a new 10.9
Rationale/Explanation of issue:
        If an access device receives an answer that it doesn't like
        (perhaps a protocol error, or bad configuration), it should
        inform the server.

Requested change:
        There are two changes required, the first in section 10.1:

   State     Event                          Action     New State
   -------------------------------------------------------------
   [...]

   Pending   Successful Service-Specific    Grant      Open
             Authorization response         Access
             received

   <new>
   Pending   Successful Service-Specific    Send STR   Discon
             Authorization response
             received, but service not
             provided.

   Pending   Successful Service-Specific    Send STR   Discon
             Authorization response
             received, but error processing
             response
   </new>

        and the following new section 10.9:

   10.9  Termination-Cause AVP

     The Termination-Cause AVP (AVP Code TBD) is of type Unsigned32, and
     is used to indicate the reason why a session was terminated on the
     access device. The following values are defined:

     DIAMETER_LOGOUT               1
       The user initiated a disconnect.

     DIAMETER_CLIENT_GONE          2
       This value is used when the user disconnected prior to the
       Diameter auth response was received.

     DIAMETER_BAD_ANSWER           3
       This value indicates that the auth response received by the
       access device was not processed successfully.

     DIAMETER_ADMINISTRATIVE       4
       The user was not granted access due to administrative reasons.

     DIAMETER_LINK_BROKEN          5
       The communication link to the user was abruptly disconnected.

Grouped AVP

Submitter name: Paul Funk, Dave Frascone
Submitter email address: [email-masked], [email-masked]
Date first submitted: May, 20001
Reference: many but look at http://www.merit.edu/mail.archives/aaa-wg/msg00883.html
Document: Base
Comment Type: Technical
Priority: 1 or 2 (?)
Section: Somewhere in section 4
Rationale/Explanation of issue:
        Grouped AVPs MUST NOT be fixed. The same flexibility that Diameter
        provides is required for Grouped AVPs. See the above URL for a problem
        that was discussed on the list. Not solving this problem will
        require that many GRouped AVPs be defined for all possible
        combinations.

Requested change:
        Make Grouped AVP definitions use ABNF, same as command codes.

Boot Id

Submitter name: Paul Funk
Submitter email address: [email-masked]
Date first submitted: May, 20001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00135.html
Document: Base
Comment Type: Technical
Priority: 1 or 2 (?)
Section: Somewhere in section 6
Rationale/Explanation of issue:
        Given that the DRI message is hop-by-hop, home servers that
        maintain state information need to know when a particular
        NAS has rebooted.

Requested change:
        See the URL above which proposes three alternatives, which are
        not mutually exclusive.

DSI

Submitter name: Paul Funk
Submitter email address: [email-masked]
Date first submitted: May, 20001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00183.html
Document: Base
Comment Type: Technical
Priority: 1
Section: Somewhere in section 9
Rationale/Explanation of issue:
        The DSI is currently defined as a hop-by-hop message, but
        Paul believes that it is necessary to keep some of the
        information about the originator of the DSI (e.g. Origin-FQDN).

Requested change:
        In fact, I'd like to see the whole DSI eliminated, and only
        have the Result-Code AVP. Move all DSI-Events to the Result-Code
        and require that proxies treat a certain class of Result-Codes.
        This would really simplify the protocol.

Watchdogs

Submitter name: Jonathan Wood
Submitter email address: [email-masked]
Date first submitted: May, 20001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00887.html
Document: Base
Comment Type: Question
Priority: ?
Section: Somewhere in section 7
Rationale/Explanation of issue:
        Why are watchdogs required if the transport already provides them?

Requested change:
        Elimination of watchdogs

ASI Messages

Submitter name: ???
Submitter email address: ??
Date first submitted: May, 20001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00888.html
Document: Base
Comment Type: Clarification Required
Priority: S
Section: Somewhere in section 7
Rationale/Explanation of issue:
        Where are ASI messages supposed to be sent? First proxy?

Requested change:
        Add clarifying text

Redirect Server Certificates

Submitter name: Paul Funk
Submitter email address: [email-masked]
Date first submitted: May, 20001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00890.html
Document: End-to-End Security
Comment Type: Technical
Priority: S
Section: 
Rationale/Explanation of issue:
        Is it possible for a single certificate to be used for all
        Diameter servers in a domain (essentially all sharing the same
        private key). If so, would the cert include some fqdn? If not,
        how would a match of certiciate in the CMS-Cert AVP and the
        Redirect-Host be made?

Requested change:
        Add clarifying text

Redirect Server Certificates

Submitter name: Henry Haverinen 
Submitter email address: (darn archives doesn't show that)
Date first submitted: May, 20001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00230.html
Document: NASREQ
Comment Type: Technical
Priority: ?
Section: 
Rationale/Explanation of issue:
        NASREQ extension should allow for key distribution, which could
        be used with 802.11 and other link layers.

Requested change:
        Add text provided in URL above.

Head of Line Blocking Prevention

Submitter name: Jonathan Wood
Submitter email address: [email-masked]
Date first submitted: May, 20001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00897.html
Document: Base
Comment Type: Technical
Priority: ?
Section: Somewhere in section 7
Rationale/Explanation of issue:
        Should the base draft make use of streams, which would prevent
        head of line blocking

Requested change:
        See URL for proposed change.

Multiple Result-Code AVPs

Submitter name: Pat Calhoun
Submitter email address: [email-masked]
Date first submitted: May 16, 20001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00916.html
Document: Base
Comment Type: Technical
Priority: S
Section: (throughout)
Rationale/Explanation of issue:
        End-to-End security MAY cause the Result-Code AVP to be protected.
        If so, a proxy has no way to change the Result-Code AVP, since it
        would break message authentication. Proxies must therefore have
        a way to add their errors in such messages.

        Furthermore, The Error-Reporting-FQDN is never any different from
        the Origin-FQDN.

Requested change:
        Eliminate the Error-Reporting-FQDN, and add clarifying text to the
        Result-Code AVP to state that the Origin-FQDN was the one that
        added the AVP.

        Create a Grouped AVP called the Proxy-Result-Code, which MUST NOT
        contain a successful code. It is only used by proxies to add error
        conditions. This AVP would include the Error-Reporting-FQDN AVP,
        and the Result-Code AVP.

Extensions that Diameter servers MUST support

Submitter name: Canales Valenzuela 
Submitter email address: (darn archives)
Date first submitted: May 16, 20001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00911.html
Document: Base
Comment Type: Editorial
Priority: S
Section: (throughout)
Rationale/Explanation of issue:
        The following paragraph states that all servers MUST support
        extensions, which one can only assume includes proxies:

        "  Diameter servers MUST support the Base protocol, which includes
            Accounting, and both the NASREQ and Mobile IP extensions. Diameter
            Clients MUST support the Base protocol, including Accounting, and
            MAY support any other extension that would be required to provide
            service."

Requested change:
        Change the above paragraph to the following:

        "  Diameter home servers MUST support the Base protocol, which includes
           Accounting, and both the NASREQ and Mobile IP extensions. Diameter
           proxies and redirect servers MUST support the Base protocol, and
           MAY support other extensions. Diameter Clients MUST support the
           Base protocol, including Accounting, and MAY support any other
           extension that would be required to provide service."