Subject: [AAA-WG]: RE: Issue 402: NASREQ-11 Comments

From: David Mitton <[email-masked]>
Date: Wed, 18 Jun 2003 14:27:11 -0400

Note: This was posted by me originally on 5/11/2003 1:28am,
between the notice on NASreq 12a updates, and the discussion of Issue 403.
I didn't notice it missing until recently....

It was not being forwarded to the list because of a 50K size limit on 
forwarding.
The list people have raised the limit to 100K.

This is a revised repost.  I've tried to shorten it anyways.

Dave.

----------------

JARI: Comments marked with "JARI:"
DJM: Responses marked with "DJM:"
	major snips to document marked with "..."

	Some more work is required, but I will whittle further discussions down 
to 	active paragraphs.

JARI: We are nearing a state where this draft can be made an RFC.
       However, some work still remains. Some of the main comments:

       - Some keyword issues in, e.g., advertising, sending acct
         messages, ...

       - Some clarifications, e.g., should service still be provided
         while re-auth is going on, Accounting-Realtime-Required
         effects, Auth-Request default values, optionality of some AVPs
         in AAA/AAR requests, EVENT_RECORD, ...

       - Normative/informative nature of the old RADIUS AVP semantics
         needs clarification.

       - Some question marks on the semantics of the AVPs, but I'm not
         sure we can do much if the old RADIUS specifications apply in
         any case.

       - I'd prefer sections 9.1 and 9.1.1 to be more in the usual
         keyword style than in the current "example of steps that may
         be followed format".

       - AVP table inconsistencies wrt base.

       - Some additions to the security considerations may be needed,
         e.g. RADIUS translation.

       - Editorial corrections

AAA Working Group                                         Pat R. Calhoun
Internet-Draft                                      Black Storm Networks
Category: Standards Track                                      Glen Zorn
                                                      Cisco Systems, Inc.
                                                             David Spence
                                                 Interlink Networks, Inc.
                                                             David Mitton
                                                           Circular Logic

                                                            February 2003

                Diameter Network Access Server Application
                  draft-ietf-aaa-diameter-nasreq-11.txt
<snip>
                             Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .   6
1.1.  Requirements Language  . . . . . . . . . . . . . . . . . . . .   6
1.2.  Advertising Application Support  . . . . . . . . . . . . . . .   6

JARI: A terms section might be useful. NAS, ARAP, IPX, CHAP, PAP etc.
DJM: Not sure it's necessary.  Maybe at end.

2.  NAS Calls, Ports, and Sessions . . . . . . . . . . . . . . . . .   6

JARI: Looking at the contents list, it might make sense to change the
       section titles from "NAS <something>" to simply "<something>"?
       What do you think?

DJM: Current is a simplification from previous, every thing was NASREQ.

JARI: And I still think the contents list should be more readable...
       oh well, maybe the RFC editor has to generate the contents list
       anyway and maybe they use some tool that generates nice
       looking, indented contents lists... Ok, I'll send you the
       script for that...

DJM: received... Used this with winawk on the 12a draft.

...

1.  Introduction

    This document describes Diameter applications that are used for AAA
    in the Network Access Server (NAS) environment. The Diameter NAS
    application, when combined with the Diameter base protocol [Base],
    Transport Profile [DiamTrans] EAP [DiamEAP], and CMS Security
    [DiamCMS] specifications, satisfies NAS-related requirements defined
    in RFC2989 [AAACriteria] and RFC3169 [NASCriteria].

    Initial deployments of the Diameter protocol are expected to include
    legacy systems. Therefore, this application was carefully designed to
    ease the burden of protocol conversion between RADIUS and Diameter.
    This is achieved by including the RADIUS attribute space, and
    eliminating the need to perform many attribute translations.

    This document first describes the operation of a Diamter NAS
    application.  Then it defines the Diameter message Command-Codes.
    The following sections enumerate the AVPs used in these messages
    grouped by common usage.  These are Session Identification,
    Authentication, Authorization, and Accounting.  The Authorization

JARI: s/, and/, Tunneling, and/	  DJM: done

JARI: An overall comment: Does it make sense to capitalize words
       like Authorization? I think the text would read better
       if it was just "authorization". But this is not my
       native language...	DJM: done

    AVPs are further broken down by service type.  Interaction and
    backwards compatibility issues with RADIUS are discussed in later
    sections.

1.1.  Requirements Language

    In this document, the key words "MAY", "MUST", "MUST NOT",
    "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be
    interpreted as described in [Keywords].

1.2.  Advertising Application Support

    Diameter nodes conforming to this specification MAY advertise support
    by including the value of one (1) in the Auth-Application-Id or the
    Acct-Application-Id AVP of the Capabilities-Exchange-Request and
    Capabilities-Exchange-Answer commands [Base].

JARI: Why is this a MAY? I realize that the support for NASREQ is
       a MAY, but if you support it why do we allow not advertising
       this fact? Or is this a configuration issue?
DJM: Changed (also Bernard Issue 404, second item)
	  I did not write this requirement, so I'm curious
       why it may have been this way for so long.

2.  NAS Calls, Ports, and Sessions

    The arrival of a new call or service connection at a port of a
    Network Access Server (NAS) starts a Diameter NAS message exchange.
    Information about the call, the identity of the user, and his

JARI: s/his/the user's/? - DJM:done

    authentication information are packaged into a Diameter AA-Request
    (AAR) message and sent to a server.

...

2.1.  Diameter Session Establishment

    When the authentication or authorization exchange completes
    successfully, the NAS application SHOULD start a session context, and
    MAY send an Accounting START_RECORD message [Base].  The failure to

JARI: The MAY above is a bit weak? Is this a configuration issue
       again, or are NASes generally allowed to skip accounting
       if they feel like it? ;-)
DJM: Yes, I've reworded this per your later comments.
	Accounting should not be skipped if implemented, but the spec
     doesn't require the capability either.

    start a session SHOULD cause an Accounting EVENT_RECORD message.

JARI: Is there an AVP which holds the type of failure? Or are all
       EVENT_RECORD messages for this particular error?

DJM: It depends on the error.  At this point I am worrying about
message flow.  Not AVP content.

2.2.  Diameter Session Re-Authentication or Re-Authorization

    The Diameter protocol allows for users to be periodically re-
    authenticated and/or re-authorized. In such instances, the Session-Id
    AVP in the AAR message MUST be the same as the one present in the
    original authentication/authorization message. A Diameter server
    informs the NAS of the maximum time allowed before re-authentication
    or re-authorization via the Authorization-Lifetime AVP [Base].  Note,
    however, that the Authorization-Lifetime AVP SHOULD NOT be used if
    the AAR message contained a NAS-IP-Address, NAS-IPv6-Address, or NAS-
    Identifier AVP since this would mean that the NAS is using RADIUS
    which does not support server-initiated re-authentication or re-
    authorization.

    A NAS MUST re-authenticate and/or authorize after the period provided
    by the server. Furthermore, it is possible for Diameter servers to
    issue an unsolicited re-authentication and/or re-authorization by
    issuing an Re-Auth-Request message to the NAS. Upon receipt of such a
    message, the NAS is instructed to issue a request to re-authenticate
    and/or re-authorize the client.

JARI: Is this always possible? I think it is possible on PPP, but
       perhaps there are other access types for which it might not
       be possible. Is re-auth possible on all types of WLAN
       links?
DJM: Yes, this is weakly described.	And yes it varies.
	Open issue

JARI: While re-auth is going on, can service still be provided?
DJM: Good question.  I think it will be service specific.

2.3.  Diameter Session Termination

    When a NAS receives an indication that a user's session is being
    disconnected (e.g. LCP Terminate is received), the NAS MUST issue a
    Session-Termination-Request (STR) [Base] to its Diameter Server. This
    will ensure that any resources maintained on the servers is freed
    appropriately.

    Further, a NAS that receives a Abort-Session-Request (ASR) [Base]
    MUST issue an STR if the session requested is active, and disconnect
    the PPP (or tunneling) session.

    Termination of the session context, MUST cause the sending of an
    Accounting STOP_RECORD message [Base], if accounting is active.

JARI: Compare the above text to the MAY for sending the START_RECORD!
       Perhaps the above is the right text and something similar
       should be written also for START_RECORD.

DJM: Done

JARI: Shouldn't we somehow take in account also
       Accounting-Realtime-Required AVP from base?

DJM: hmm... where is that AVP described? Base?

    More information on Diameter Session Termination is in [Base] section
    8.4.

...
3.1.  AA-Request (AAR) Command

    The AA-Request message (AAR), indicated by the Command-Code field set
    to 265 and the 'R' bit set in the Command Flags field, is used in
    order to request authentication and/or authorization for a given NAS
    user. The type of request is identified through the Auth-Request-Type
    AVP, and the default mode is both authentication and authorization.

JARI: Default... hmm... does this mean Auth-Request-Type AVP
       is optional? Base 8.7 does not talk about this. Please
       clarify. Suggestion: don't talk about defaults.

DJM: needs work/input - Still open

    If Authentication is requested the User-Name attribute SHOULD be
    present, as well as any additional authentication AVPs that would
    carry the password information. A request for authorization only
    SHOULD include the information from which the authorization will be
    performed, such as the User-Name, Called-Station-Id, or Calling-
    Station-Id AVPs. All requests SHOULD contain AVPs uniquely identifing

JARI: s/identifing/identifying/	  - DJM: done

    the source of the call, such as Origin-Host, and NAS-Port.  Certain
    networks MAY use different AVPs for authorization purposes. A request
    for authorization will include some AVPs defined in section 6.

  ...
3.2.  AA-Answer (AAA) Command

    The AA-Answer (AAA) message, is indicated by the Command-Code field
    set to 265 and the 'R' bit cleared in the Command Flags field, is
    sent in response to the AA-Request message. If authorization was
    requested, a successful response will include the authorization AVPs
    appropriate for the service being provided, as defined in section 6.

    For authentication exchanges that require more than a single round
    trip, the server MUST set the Result-Code AVP to
    DIAMETER_MULTI_ROUND_AUTH. An AAA message with this result code MAY
    include one or more Reply-Message and MAY include zero or one State
    AVPs.

    If the Reply-Message AVP was present, the access device SHOULD
    display the text message to the user, and MUST prompt the user for a
    response.  If the access device is unable to prompt the user for a
    new response, which could be achieved via PAP, it MUST treat this
    answer as an error, and deny access.

JARI: s/access device/network access server/g ? (the term appears
       just in two places)	- DJM: Rewritten

JARI: In any case, the above paragraph is pretty confusing. At first,
       I read it as if the access device was the user's equipment, but
       it can't be because its the NAS that should be doing the access
       denial and other tasks. I believe what is meant here is that the
       NAS must be able to send a protocol message to the user's device
       which would result in a text message. Suggested rewrite: "If the
       Reply-Message AVP was present, the NAS SHOULD send a message to
       the client, instructing it to prompt the user for a response.
       This can be achieved via PAP in PPP, for instance.  If the NAS
       is unable to achieve this, it MUST treat the AA-Answer with the
       Reply-Message AVP as an error, and deny access."

DJM: done.

    Message Format

       <AA-Answer> ::= < Diameter Header: 265, PXY >
                       < Session-Id >
                       { Auth-Application-Id }
                       { Auth-Request-Type }
                       { Result-Code }
                       { Origin-Host }
                       { Origin-Realm }
                       [ User-Name ]
                       [ Service-Type ]

JARI: I don't understand how some of this information
       can be optional. How come Service-Type, for instance,
       is not always necessary? Or is the optionality due to
       the original RADIUS specifications? This comment
       may apply to AAR as well.

DJM: Good observation, unfortunately it's due to the multiple uses of
these messages.  We don't segregate final from interim or partial, and
some information is not appropriate in all situations.

...

4.  NAS Session AVPs

    Diameter reserves the AVP Codes 0-255 for RADIUS functions that are
    implemented in Diameter.

    AVPs new to Diameter have code values 256 and greater. A Diameter
    message that includes one of these AVPs MAY cause interoperability

JARI: s/AVPs MAY/AVPs represent functionality not present in RADIUS,
       and may/
DJM: ummm... well the RADIUS implementation may have the function, just
in a different representation.  Also at this time, it may be conceivable
to have Diameter aware RADIUS implementations.	I have "improved" this
sentence along your suggestion.

    issues should the request traverse a AAA node that only supports the
    RADIUS protocol. However, the Diameter protocol should not be
    hampered from future developments due to the existing installed base.

JARI: Delete the last sentence.		
DJM: well... I was looking at fixing it, but might as well - done.

    There are some RADIUS attributes that are not allowed or supported
    directly in Diameter. See section 9 below for more information.

4.1.  Call and Session Information

    This section contains the NAS unique AVPs that are needed to identify

JARI: s/NAS unique AVPs/AVPs specific to the NAS Diameter extension/
DJM: done.

    call and session context information, and allows the server to set
    constraints on a session.

...
4.4.  NAS-Port-Type AVP

    The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and
    contains the type of the port on which the NAS is authenticating the
    user.  This AVP SHOULD be present if the NAS uses the same NAS-Port
    number ranges for different service types concurrently.

    The supported values are defined in [RADIUSTypes]. The following list
    is informational:

JARI: An overall comment on all old RADIUS attributes. Its good that
       the list below is marked as informational and the reference
       to the normative information is given. However, there seems to
       values and rules in this document that do not say this. E.g.
       connectinfo slash rules in 4.7. What is their status? Should
       we say somewhere that for any semantics about the RADIUS
       attributes, this document is informational and the normative
       definition can be found from the RADIUS specifications? Or
       is the intention that this specification too is normative here
       and we just have verified that there are no differences?

DJM: Over the life of this document, there has been schizophrenic
efforts	to either include everything and ignore the past documents.  Or
defer everything to past documents.  The former means that we duplicate
everything (warts and all) and attempt to set the new bar. Problems of
combatibility will result.   The latter approach leaves a document full
of pointers and  difficultly in patching any of the old problems.  The
Normative/non-normative/Standards-Track/Informational wrinkles pop up
here too.

I have been attempting to balance the work, but pulling things forward
but leaving pointers to where they came from.

  ...
4.7.  Connect-Info AVP

    The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent
    in the AA-Request message, and indicates the nature of the user's
    connection. The connection speed SHOULD be included at the beginning
    of the first Connect-Info AVP in the message.  If the transmit and
    receive connection speeds differ, they may both be included in the
    first AVP with the transmit speed first (the speed the NAS modem
    transmits at), a slash (/), the receive speed, then optionally other
    information.

JARI: Is the space mandatory separator for the optional other
       information?

DJM: ??? no ikling.  The text is straight out of RFC2869
	Actually not all of the original was lifted.  I've added some more
     because of the 253+ attribute issue.  This is one.

    For example, "28800 V42BIS/LAPM" or "52000/31200 V90"

...
5.2.  Password-Retry AVP

    The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be
    included in the AA-Answer if the Result-Code indicates an
    authentication failure. The value of this AVP indicates how many
    authentication attempts a user may be permitted before being
    disconnected. This AVP is primarily intended for use when the Framed-
    Protocol AVP (see Section 6.9.1) is set to ARAP.

JARI: I don't understand why Pwd-Rtr is related to ARAP only.
DJM: This attribute was defined in sect 5.9 of RFC2869 for ARAP.
	We could generalize it, are you making a request?

5.3.  Prompt AVP

    The Prompt AVP (AVP Code 76) is of type Enumerated, and MAY be
    present in the AA-Answer message. When present, it is used by the NAS
    to determine whether the user's response, when entered, should be
    echoed.

    The supported values are listed in [RADIUSTypes].  The following list
    is informational:

        0  No Echo
        1  Echo

JARI: Hmm... this doesn't seem to apply to all service types. Or?
DJM: This section doesn't segregate by service types or give all
possible combinations.

...
6.1.  Service-Type AVP

    The Service-Type AVP (AVP Code 6) is of type Enumerated and contains
    the type of service the user has requested, or the type of service to
    be provided.  One such AVP MAY be present in an authentication and/or
    authorization request or response. A NAS is not required to implement
    all of these service types, and MUST treat unknown or unsupported
    Service-Types as though a response with a Result-Code other than
    Diameter-SUCCESS had been received instead.

JARI: s/Diameter-SUCCESS/DIAMETER_SUCCESS/g	
DJM: Done.	2 Occurances found

    When used in a request, the Service-Type AVP SHOULD be considered to
    be a hint to the server that the NAS has reason to believe the user
    would prefer the kind of service indicated, but the server is not
    required to honor the hint. The following values have been defined
    for the Service-Type AVP:

JARI: Question: If the user connects through some protocol, such as
       PPP, how can it be changed to something else if the server
       decides to send back something else? I think it is possible in
       some cases, but not in general.

<DJM: Yes, Typical is ASCII dial up to SLIP conversion.>

       Perhaps some words are needed to
       explain that the NAS may disconnect the user if it can't start
       the service in the given situation, even if it does support it.

DJM:  Not sure. The situation you describe is more of a
configuration/situation error.  If the service only supports particular
methods of connection, then using others should not be assumed to be
successful.  If a mode shift is not possible, then the service should
fail the connection, and that is the disconnect mechanism.
In any case, I have added the following:
    Furthermore,	if the service specified by the server is supported, but
    not compatible with the current mode of access, the NAS MUST
    fail	to start the session.  It must also generate the appropriate
    error message(s).

    The complete list of defined values can be found in [RADIUS] and
    [RADIUSTypes].  The following list is informational:
...
6.2.  Callback-Number AVP

    The Callback-Number AVP (AVP Code 19) is of type UTF8String, and
    contains a dialing string to be used for callback.  It MAY be used in
    an authentication and/or authorization request as a hint to the
    server that a Callback service is desired, but the server is not
    required to honor the hint in the corresponding response.

JARI: I don't understand how the client would know the callback number.
       Or is this a copy of the calling number avp?
DJM: There are many (too many!) types of callback.  Some clients know
	the desired number (it may not to be initiating system!) and some
     callback servers allow this.

    The codification of the range of allowed usage of this field is
    outside the scope of this specification.
  ...
6.4.  Idle-Timeout AVP

    The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the
    maximum number of consecutive seconds of idle connection allowed to
    the user before termination of the session or prompt. It MAY be used
    in an authentication and/or authorization request (or challenge) as a
    hint to the server that an idle timeout is desired, but the server is
    not required to honor the hint in the corresponding response.

JARI: Default is?
DJM: The default is none, or system specific.

...
6.10.  IP Access

    The AVPs defined in this section are used when the user requests, or
    is being granted, access to IP. They are only present if the Framed-
    Protocol AVP (see Section 6.9.1) is set to PPP, SLIP, Gandalf
    proprietarySingleLink/MultiLink protocol, or X.75 Synchronous.

JARI: Add space after "proprietary"	- DJM: Done.

...

7.3.  Tunnel-Client-Endpoint AVP

...
    If Tunnel-Medium-Type is IPv4 (1), then this string is either the
    fully qualified domain name (FQDN) of the tunnel client machine, or
    it is a "dotted-decimal" IP address.  Conformant implementations MUST

JARI: s/Conformant/Conforming/?
DJM: delete the word, "Implementations MUST..."

    support the dotted-decimal format and SHOULD support the FQDN format
    for IP addresses.

    If Tunnel-Medium-Type is IPv6 (2), then this string is either the
    FQDN of the tunnel client machine, or it is a text representation of
    the address in either the preferred or alternate form [IPv6Addr].
    Conformant implementations MUST support the preferred form and SHOULD
    support both the alternate text form and the FQDN format for IPv6
    addresses.

    If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag
    referring to configuration data local to the Diameter client that
    describes the interface and medium-specific address to use.

7.4.  Tunnel-Server-Endpoint AVP

    The Tunnel-Server-Endpoint AVP (AVP Code 67) is of UTF8String, and
    contains the address of the server end of the tunnel. It MAY be used
    in an authorization request as a hint to the server that a specific
    endpoint is desired, but the server is not required to honor the hint
    in the corresponding response.

    This AVP SHOULD be included in the corresponding Accounting-Request
    messages, in which case it indicates the address from which the
    tunnel was initiated. This AVP, along with the Tunnel-Client-Endpoint
    and Session-Id AVP [Base], MAY be used to provide a globally unique
    means to identify a tunnel for accounting and auditing purposes.

    If Tunnel-Medium-Type is IPv4 (1), then this string is either the
    fully qualified domain name (FQDN) of the tunnel client machine, or
    it is a "dotted-decimal" IP address.  Conformant implementations MUST
    support the dotted-decimal format and SHOULD support the FQDN format
    for IP addresses.

JARI: I find the SHOULD troubling for interoperability. If a NAS gets
       the TSE AVP from the server in FQDN format, what should it do?
DJM: there was a time when a lightweight NAS may not implement a DNS
client.
	If it cannot support it, it barfs (in the technical sense).
     The Session setup fails, the service is not provided, errors are
     logged. Users curse and admins figure how to to provision so it
     works within the capabilities of the NAS.

    If Tunnel-Medium-Type is IPv6 (2), then this string is either the
    FQDN of the tunnel client machine, or it is a text representation of
    the address in either the preferred or alternate form [IPv6Addr].
    Conformant implementations MUST support the preferred form and SHOULD
    support both the alternate text form and the FQDN format for IPv6
    addresses.

    If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag
    referring to configuration data local to the Diameter client that
    describes the interface and medium-specific address to use.
...

7.6.  Tunnel-Private-Group-Id AVP

    The Tunnel-Private-Group-Id AVP (AVP Code 81) is of type UTF8String,
    and contains the group Id for a particular tunneled session. The
    Tunnel-Private-Group-Id AVP MAY be included in an authorization
    request if the tunnel initiator can pre-determine the group resulting
    from a particular connection and SHOULD be included in the
    authorization response if this tunnel session is to be treated as
    belonging to a particular private group. Private groups may be used
    to associate a tunneled session with a particular group of users.
    For example, it MAY be used to facilitate routing of unregistered IP
    addresses through a particular interface.  This AVP SHOULD be
    included in the Accounting-Request messages which pertain to the
    tunneled session.

JARI: I understand the treatment at DIAMETER level for this AVP, but I
       couldn't implement anything based on the above explanation for
       actually using the group information. A particular interface
       may be used but is not required, for instance.
DJM: ummm... and your point? ;-)
	  This attribute comes from RFC 2868 and is used to (excuse me if
       I don't get it technically right) to join individual links into
       an existing or desired group, via a specified connection point.
       Not all tunnel implementations or configurations, support this
       concept or capability, hence it's non-requiredness.  I'm fairly
       certain that there are running uses of this (but I didn't write
       one either).

...

8.  NAS Accounting

    Applications implementing this specification use Diameter Accounting
    as defined in the Base [Base] with the addition of the AVPs in the
    following section.

    Accounting Request messages (ACR) SHOULD be sent after any

JARI: Earlier in the document there was some confusion about when
       accounting messages should be sent.
DJM: this requires a bit more work, more comments below.  This stems
from the lack of desire or work wanting to be put into an overall
description of A//accounting.

    Authentication or Authorization transaction and at the end of a
    Session.  The Accounting-Record-Type value indicates the type of
    event.  All other AVPs identify the session and provide additional
    information relevant to the event.

    If Authentication and Authorization are contained in one message
    (typical case), then one START_RECORD should be sent.  If
    Authentication and Authorization occur in seperate transactions, the

JARI: s/seperate/separate/g	   - DJM: done.

    first message should generate a START_RECORD, and the later, an
    INTERIM_RECORD.  For a given session, there should only be one set of
    matching START and STOP records, with any number of INTERIM_RECORDS
    in between, or one EVENT_RECORD.

JARI: Compare to Section 2.1. I'm not sure I understand what "failure
       to start a session" exactly means, but let's assume we do a
       successful authentication, successful authorization, and the
       "fail to start a session". It would be incorrect in this case to
       send START_RECORD, INTERIM_RECORD, EVENT_RECORD, as seems to be
       indicated by 2.1. Suggestion: make 2.1 inline with the text
       here.
DJM: Okay, it's sort of fuzzy, as you're beginning to see.
	Most NAS type applications do Authentication/Authorization in one
     exchange.  So a session "starts" cleanly on receipt of the AAA.
     But thanks to the flexibility of Diameter this can get drawn out.

     In practice, we have a session context that is initialized at
     the time of the call "pickup" and it gets filled in
     as we progress, until we have enough to deliver the service or not.
     It's at that point that we fail or "start" service.

     We got in trouble in RADIUS because some NASes would issue a
     Acct-Start on a PPP session before NCP finished, and could not tell
     you the IP addr of the user system.  Others would delay for that,
     which in turn drives the real-time people crazy.

     So I agree, we should define Accounting messages linked to specific
     protocol events to eliminate some implementation confusion. (there
     will be other forms of confusion that arise)

     This will take some more wordsmithing and proper sequence
     construction. 	-- Open Issue
</DJM>

...

9.  RADIUS/Diameter Protocol Interactions

    This section describes some basic guidelines that may be used by
    servers that act as AAA Translation Agents. A complete description of
    all the differences between RADIUS and Diameter is beyond the scope
    of this section and document.  Note that this document does not
    restrict implementations from creating additional methods, as long as
    the translation function doesn't violate the RADIUS or the Diameter
    protocols.

                                             +---------------------+
                                             |    AVP Flag rules   |
                                             |----+-----+----+-----|----+
                    AVP  Section             |    |     |SHLD| MUST|    |
    Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
    -----------------------------------------|----+-----+----+-----|----|
    NAS-Identifier    32  9.2.1   UTF8String | M  |  P  |    |  V  | Y  |
    NAS-IP-Address     4  9.2.2   OctetString| M  |  P  |    |  V  | Y  |
    NAS-IPv6-Address  95  9.2.3   OctetString| M  |  P  |    |  V  | Y  |
    State             24  9.2.4   OctetString| M  |  P  |    |  V  | Y  |
    Termination-     295  9.2.5   Enumerated | M  |  P  |    |  V  | Y  |
       Cause                                 |    |     |    |     |    |
    -----------------------------------------|----+-----+----+-----|----|

JARI: This table is not explained by the nearby text.
DJM: Every major section has a table of Diameter AVPs in it.  I will add
this sentence:
	The following Diameter AVPs pertain to RADIUS interactions and are
described in this section:

    There are primarily two different situations that must be handled;
    one where a RADIUS request is received that must be forwarded as a
    Diameter request, and the inverse.  RADIUS does not support a peer-
    to-peer architecture and server initiated operations are generally
    not supported.  See [RADDynAuth] for an alternative.

    Some RADIUS attributes are encrypted.  RADIUS security and encryption
    techniques are applied on a hop-per-hop basis. A Diameter agent will
    have to decrypt RADIUS attribute data entering the Diameter system
    and if that information is forwarded, MUST secure it using Diameter
    specific techniques.

    Note that this section uses the two terms; AVP and attribute in a
    consise manner. The former is used to signify a Diameter AVP, while

JARI: Replace the first sentence with "Note that this section uses two
       different terms, AVP and attribute."
DJM: Not sure the improvement you were after.  How about this:
	Note that this section uses the two terms; "AVP" and "attribute" in
     a concise and specific manner. The former is used to signify a
     Diameter AVP,...

    the latter is used to signify a RADIUS attribute.

...
    The corresponding Diameter response is always guaranteed to be
    received by the same Translation Agent that translated the original
    request, due to the contents of the Origin-Host AVP in the Diameter
    request. The following steps are applied to the response message
    during the Diameter to RADIUS translation:

       - If the Diameter Command-Code is set to AA-Answer and the Result-
         Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must
         send a RADIUS Access-Challenge with the Diameter Session-Id and
         the Origin-Host AVPs encapsulated in the RADIUS State attribute,
         with the prefix "Diameter/". This is necessary in order to
         ensure that the Translation Agent that will receive the
         subsequent RADIUS Access-Request will have access to the Session
         Identifier, and be able to set the Destination-Host to the
         correct value. If the Multi-Round-Time-Out AVP is present, the
         value of the AVP MUST be inserted in the RADIUS Session-Timeout
         AVP.
       - If the Command-Code is set to AA-Answer, the Diameter Session-Id
         AVP is saved in a new RADIUS Class attribute, whose format
         consists of the string "Diameter/" followed by the Diameter
         Session Identifier. This will ensure that the subsequent
         Accounting messages, which could be received by any Translation
         Agent, would have access to the original Diameter Session
         Identifier.
       - If a Proxy-State attribute was present in the RADIUS request,
         the same attribute is added in the response. This information
         may be found in the Proxy-Info AVP group, or in a local state
         table.
       - If state information regarding the RADIUS request was saved in a
         Proxy-Info AVP or local state table, the RADIUS Identifier and
         UDP IP Address and port number are extracted and used in issuing
         the RADIUS reply.

JARI: Question: Does the above rules work even in a situation where
       there's been a change to another translation agent due to
       load balancing or a fault?
DJM:  Groan... I don't know, I didn't design this part	- Open Issue

9.1.1.  Diameter Request Forwarded as RADIUS Request

JARI: This should be 9.2 not a subsection of RADIUS->DIAMETER!
DJM: whoops, must fix table or two and some cross references then

    When a server receives a Diameter request that is to be forwarded to
    a RADIUS entity, the following steps are an example of the steps that
    may be followed:

JARI: "... example of the steps that may be followed... " are we sure
       that we can't create normative keyword language for these
       operations?

       - The Origin-Host AVP's value is inserted in the NAS-Identifier
         attribute.
       - The following information MUST be present in the corresponding
         Diameter response, and therefore MUST be saved either in a local
         state table, or it MAY be encoded in a RADIUS Proxy-State
         attribute:
            1. Origin-Host AVP
            2. Session-Id AVP
            3. Proxy-Info AVP
            4. Route-Record AVPs (in the proper order)
            5. Any other AVP that MUST be present in the response, and
               has no corresponding RADIUS attribute.
       - If the CHAP-Auth AVP is present, the grouped AVPs are used to
         create the RADIUS CHAP-Password attribute data.
       - If the User-Password AVP is present, the data should be
         encrypted using RADIUS rules.  Likewise for any other encrypted
         attribute values.
       - AVPs that are of the type Address, must be translated to the
         corresponding RADIUS attribute.
       - If the Accounting-Input-Octets, Accounting-Input-Packets,
         Accounting-Output-Octets or Accounting-Output-Packets AVPs are
         present, these must be translated to the corresponding RADIUS
         attributes.  Further, the value of the Diameter AVPs do not fit
         within a 32-bit RADIUS attribute, the RADIUS Acct-Input-
         Gigawords and Acct-Output-Gigawords must be used.
       - If the RADIUS link supports the Message-Authenticator attribute
         [RADIUSExt] it SHOULD be generated and added to the request.

    When the corresponding response is received by the Translation Agent,
    which is guaranteed in the RADIUS protocol, the following steps may
    be followed:

       - If the RADIUS code is set to Access-Challenge, a Diameter AA-
         Answer message is created with the Result-Code set to
         DIAMETER_MULTI_ROUND_AUTH. If the Session-Timeout AVP is present
         in the RADIUS message, its value is inserted in the Multi-Round-
         Time-Out AVP.
       - If a Proxy-State attribute is present, extract the encoded
         information, otherwise retrieve the original Proxy-Info AVP
         group information from the local state table.
       - The request's Origin-Host information is added to the
         Destination-Host AVP.
       - The Acct-Session-Id information is added to the Session-Id AVP.
       - The Route-Record AVPs MUST be added to the Diameter message, in
         the same order they were present in the request.
       - If a Proxy-Info AVP was present in the request, the same AVP
         MUST be added to the response.
       - If the RADIUS State attributes are present, these attributes
         must be present in the Diameter response.
       - Any other AVPs that were saved, and MUST be present in the
         response, are added to the message.

9.2.  AVPs Used Only for Compatibility
  ...
9.2.4.  State AVP

    The State AVP (AVP Code 24) [RADIUS] is of type OctetString and has
    two uses in the Diameter NAS application.

    The State AVP MAY be sent by a Diameter Server to a NAS in an AA-
    Response command that contains a Result-Code of
    DIAMETER_MULTI_ROUND_AUTH.  If so, the NAS MUST return it unmodified
    in the subsquent AA-Request command.

JARI: s/subsquent/subsequent/g	- DJM: done.

...
9.3.  Prohibited RADIUS Attributes

    The following RADIUS attributes MUST NOT be transfered to a Diameter
    message.  Many of these are discussed in section 9.1.

JARI: I spent some time reading the previous sections and trying to
       figure out what "transferred" meant above. Apparently, it means
       that they must not appear in a diameter message and must be
       translated instead to some other Diameter AVPs.  They are not
       completely forbidden. Suggested reformulation: "The following
       RADIUS attributes MUST NOT appear in a Diameter
       message. Instead, they are translated to other Diameter AVPs or
       handled in some special manner. The rules for the treatment of
       the attributes are discussed in Sections 9.1 and 9.5."
DJM: Excellent, done.  modulo section reference changes

    Attribute Description       Defined     Nearest Diameter AVP
    -----------------------------------------------------------------
     3 CHAP-Password            RFC 2865    CHAP-Auth Group
    26 Vendor-Specific          RFC 2865    Vendor Specific AVP
    40 Acct-Status-Type         RFC 2866    Accounting-Record-Type
    42 Acct-Input-Octets        RFC 2866    Accounting-Input-Octets

...
10.1.  AA-Request/Answer AVP Table

    The table in this section is limited to the Command Codes defined in
    this specification.

JARI: I don't understand the above comment. Remove?
DJM: Sorry, had to add that to fend off someone else's problem with this
table.	Perhaps I need to spend more/different text on this.

...
10.2.1.  Accounting Framed Access AVP Table

    The table in this section is used when the Service-Type specifies
    Framed Access.

                                           +-----------+
                                           |  Command  |
                                           |-----+-----+
    Attribute Name                         | ACR | ACA |
    ---------------------------------------|-----+-----+
    Accounting-Application-Id              | 0-1 | 0-1 |

JARI: No such AVP in base or nasreq...
DJM:  Yes, but there probably was at one time, and there is an 
Acct-Application-Id 	also listed below.  Seems to be an editing error. Most 
Diameter Accounting 	AVPs spell out "Accounting" but this one is of the few 
exceptions.

    Accounting-Input-Octets                | 1   | 0   |
    Accounting-Input-Packets               | 1   | 0   |
    Accounting-Output-Octets               | 1   | 0   |
    Accounting-Output-Packets              | 1   | 0   |
    Accounting-Record-Type                 | 1   | 1   |
    Accounting-Record-Number               | 0-1 | 0-1 |
    Accounting-Realtime-Required           | 0-1 | 0   |
    Accounting-Sub-Session-Id              | 0-1 | 0-1 |
    Acct-Application-Id                    | 0-1 | 0-1 |

JARI: I don't fully understand the construction of this table
       vs. the one in the base spec. The above attribute,
       for instance, is included but not discussed in this
       specification. But some other base attributes such
       as Auth-Application-Id are not included. Is this
       an old version of the base table, with the NASREQ
       additions? May I suggest taking a new version from
       base-17...?

DJM: ...moving targets aren't always hit. (or stay hit)
	I checked everything against Base-16? at the time.
	If there are further changes, I need to know.

     The BASE does not describe this application, I must.
     This application uses Base AVPs, how it uses them (not what they
     are) must be described here, even if it's just an inclusion that
     says it's allowable.   I guess more verbage is required to make
     these tables self explanatory.

...
11.2.  AVP Codes

    This specification assigns the values 363-366 and 400-405 from the
    AVP Code namespace defined in [Base]. See sections 4, and 5 for the
    assignment of the namespace in this specification.  Note that the
    values 363-366 are jointly, but consistently, assigned in [DiamMIP].

    This specification also specifies the use of AVPs in the 0-255 range,
    which are defined in [RADIUSTypes].  These values are assigned by the
    policy in RFC 2865 Section 6. [RADIUS]

JARI: I can't find a statement either in this document or in the base
       that would say something about the attribute lengths for the
       0-255 AVPs. Presumably, 253 bytes may not be exceeded, or at
       least if it is, translation agents will fail? No wait...  9.4
       has some text. But unfortunately it doesn't describe for which
       attributes the concatenation approach is possible.  Add a list
       there.
DJM: grrr... okay, but this is getting near exceding the scope of
this document.  I cannot re-document RADIUS.

11.3.  Application Identifier
...
12.  Security Considerations

    The security considerations  of the Diameter protocol itself have
    been discussed in [Base].

    This document does not contain a security protocol, but does discuss
    how PPP authentication protocols can be carried within the Diameter
    protocol. The PPP authentication protocols that are described are PAP
    and CHAP.

    The use of PAP SHOULD be discouraged, since it exposes user's
    passwords to possibly non-trusted entities. However, PAP is also
    frequently used for use with One-Time Passwords (OTP), which do not
    expose a security risk.

    This document also describes how CHAP can be carried within the
    Diameter protocol, which is required for RADIUS backward
    compatibility. The CHAP protocol, as used in a RADIUS environment,
    facilitates authentication replay attacks.

JARI: Any references to the attacks discussed above?

JARI: Maybe there should be some discussion of what it implies
       if authorization-only AAA requests are made, and in which
       cases such usage is safe.
DJM: Submissions are welcome.

JARI: What are the security impacts of RADIUS-DIAMETER translation?
       Are all or only some of the known radius vulnerabilities carried
       onto DIAMETER in such a setup? See reference "Joshua Hill. An
       Analysis of the RADIUS Authentication Protocol.
       http://www.untruth.org/~josh/security/radius/, 2001."

DJM: I have read that document in the past, however, we have tried
to document the Diameter NAS Application protocol in this document, and
avoided including a full treatis on Diameter/RADIUS how-to build a
gateway.  This really requires another document.  If I could make it
relate to my job (what's that?) I'd write it myself.

...
Intellectual Property Considerations

    The IETF takes no position regarding the validity or scope of any
    intellectual property or other rights that might be claimed to  per-
    tain to the implementation or use of the technology described in this

JARI: Why does this section have hyphenation on???
DJM: It does not. However, the source text was cut and pasted from
another document which had the one split word. Identification of the source
is an exercise left to the reviewer. (hint: ends in -17)
((and certainly don't look at the Full Copyright statement in that
document, it has 3 hypenated split words)

...