Diameter Issues


Last Updated: December 28, 2001

This page contains the list of Diameter Issues for the following AAA WG drafts, now in WG last call:

draft-ietf-aaa-diameter-08.txt
draft-ietf-aaa-diameter-nasreq-08.txt
draft-ietf-aaa-diameter-mobileip-08.txt
draft-ietf-aaa-transport-05.txt
draft-ietf-aaa-diameter-cms-sec-03.txt

A description in red implies that no issue has been submitted (if you are the owner of such a message, please send Pat Calhoun an issue). An asterix following an Issue number (e.g. Issue #666*) means that the issue entry is not up to date, and the author is expect to send additional text to Pat Calhoun .

To submit a new issue, send an e-mail to the AAA WG Mailing List , using the following template:

Description of issue
Submitter name: Your_Name_Here
Submitter email address: Your_Email_Address_Here
Date first submitted: Insert_Date_Here
Reference: URL to e-mail describing problem, if available
Document: Document Requiring change [base, nasreq, mobileip, cms]
Comment type: ['T'echnical | 'E'ditorial]
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Section: Insert_Section_Number_Here
Rationale/Explanation of issue:
Length description of problem

Requested change:
Proposal

For open issues, the following values are used in the Status Field:

Text Proposed - Text has been proposed on the list, and no consensus has been reached
Accepted - Text has been proposed, consensus has been reached, but the fix hasn't been included in a specification yet.
Pending - Discussion is on-going, no proposed text has been proposed
No Discussion - No discussion has been initiated on this issue.
Clarifying Text Required - The issue can be closed if additional clarifying text is added to the draft
Possible Reject - Issue will be rejected unless objections occur.
Issue Number Status Description Owner
Issue #199 Pending wdRecoveryCount used for triggering failover procedures Johansson
Issue #202 Possible Reject Alternatives to the Command Code ABNF specification Rajaniemi
Issue #204 Text Proposed How to handle CER from unknown peer Calhoun
Issue #208 Text Proposed Peer State Machine incorrect in case of election Calhoun
Issue #211 Text Proposed When should Destination-Host be present in HAR? Calhoun
Issue #212 Pending How does the AAAH know the Destination-Host of a previously assigned foreign HA? Calhoun
Issue #213 Text Proposed MN-AAA SPI must be included in the HAR message Calhoun
Issue #215 No Discussion use of hmac-md5 is incorrect Calhoun
Issue #220 Pending Not possible to dynamically update capabilities Calhoun
Issue #221 Pending Why require CMS to send it's expected AVPs? Calhoun
Issue #222 Text Proposed Routing Within a Domain Calhoun
Issue #223 Text Proposed How does CMS work if the HA is unknown and in foreign network Calhoun
Issue #224 Text Proposed Handling errors in the TCP stream Frascone
Issue #225 Text Proposed Specify Statefulness/Statelessness Requirements Kopacz
Issue #226 Text Proposed Server-Initiated Re-Auth in Diameter MIPv4 not supported Johansson
Issue #227 Pending End to End Identifier Purser
Issue #228 No Discussion Remove Route_Record Avp in all the Answer message Chen
Issue #229 No Discussion Remove MIP-PEER-SPI AVP Chen
Issue #230 No Discussion Add Mip-Key-Lifetime AVP to ABNF and comand table Chen
Issue #231 No Discussion Home-Agent-In-Foreign-Network set by AAAF Chen
Issue #232 No Discussion Session Definition Eklund
Issue #233 No Discussion MIP-Candidate-Home-Agent-Host Purser
Issue #245



The following table contains the issues that have already been resolved, and the fix included in a revision of a Diameter specification.
Issue Number Fixed in Description Owner
I ssue #1 Base 05 Move Fair bits in Command Code Eklund
Issue #2 Base 05 Required Transport  Spence
Issue #3 all 06 + CMS 01 Bring Back UTF-8 Eklund
Issue #4 Base 05 Extension Compliance wording confusion Eklund
Issue #5 * Base 06 3GPP2 Accounting Requirements Spence
Issue #6 Base 05 Server Identification Spence
Issue #7 Rejected Add extension-id to the Diameter Header Eklund
Issue #8 Base 05 Routing of Indication messages Calhoun
Issue #9 Base 05 Proposal to modify STI Funk
Issue #10 Base 05 Sessions that do not start Funk
Issue #11 Base 05 Grouped AVP Funk
Issue #12 Base 05 Boot Id Funk
Issue #13 Base 05 DSI Funk
Issue #14 Rejected Watchdogs Wood
Issue #15 Base 05 Where should the ASI be sent? Calhoun
Issue #16 CMS 02 Redirect Server Certificates Funk
Issue #17 Base 05 Head of Line Blocking Prevention Wood
Issue #18 Base 05 Remove The Error-Reporting-FQDN Calhoun
Issue #19 Base 05 Extensions that Diameter servers MUST support Calhoun
Issue #20 Base 06 How to handle no Common Extensions Calhoun
Issue #21 Base 05 TLS & SCTP Streams Calhoun
Issue #22 All 06 + CMS 01 Create an Enum Data Type Jones
Issue #23 Base 05 Make AVP Header consistent with Message Header Funk
Issue #24 Base 06 Transport Selection Calhoun
Issue #25 Base 06 Support for multi-processes Eklund
Issue #26 Base 06 What to do if STR is sent to unavailable server? Eklund
Issue #27 Duplicate SCTP heartbeat vs. watchdogs (duplicate from 14) Bush
Issue #28 Base 05 Why have Max-Wait-Time? Calhoun
Issue #29 NASREQ 06 IPv6 AVPs Calhoun
Issue #30 Base 05 Failed-AVP should be Grouped Eklund
Issue #31 Base 05 Increase randomness of Session-Id to 64 bits Funk
Issue #32 NASREQ 05 NASREQ extension includes Indication messages Calhoun
Issue #33 Base 06 Is API message considered useful? Calhoun
Issue #34 Base 05 DRI should only be sent on connection establishment Calhoun
Issue #35 Base 05 Device-Reboot-Ind isn't an appropriate name Calhoun
Issue #36 NASREQ 05 Add KDC support in NASREQ extension Soininen
Issue #37 Base 06 Home State Blob Calhoun
Issue #38 Base 06 Home should state whether the Destination-FQDN is present in follow-on messages Calhoun
Issue #39 Base 05 What does Snd-Conn-Nack" Mean? Eklund
Issue #40 Rejected Can an AVP Data have zero length? Calhoun
Issue #41 Base 05 'M' bit clarification Calhoun
Issue #42 Base/NASREQ 06 Session-Timeout inconsistent with RADIUS spec Calhoun
Issue #43 Base 05 Requesting a non vendor-specific AVP Code as Specification Required Calhoun
Issue #44 Base 05 How does an implementation state it is compliant Calhoun
Issue #45 Base 05 Allow for vendor-specific extensions Calhoun
Issue #46 Base 05 Base protocol doesn't specify how to get Vendor Identifier Calhoun
Issue #47 All 05, CMS 00 Some AVPs in tables do not have 'V' bit as MUST NOT Eklund
Issue #48 Base 06 Destination-FQDN in re-auth Messages  Eklund
Issue #49 CMS 01 How to handle proxies that modify AVPs, and end-to-end security? Calhoun
Issue #50 Base 05 Proxy Behavior Aboba
Issue #51 Rejected EAP Roundtrips Haverinen
Issue #52 Mobile IP 05 Multi-roundtrip Mobile IP authentication Haverinen
Issue #53 Base 06, Mobile IP 06 What if the AAAL cannot reach the HA? Haverinen
Issue #54 All 05, CMS 01 Replace the term extension to application Calhoun
Issue #55 Base 06 Server-Initiated re-auth Calhoun
Issue #56 Base 06 Flag bit for start of conversation Aboba
Issue #57 Base 06 Accounting-Record-Type and clarification Arkko
Issue #58 Rejected e2e draft essr/essa delay Arkko
Issue #59 Base 06 e2e mandatory status Arkko
Issue #60 CMS 01 e2e draft cert names Arkko
Issue #61 CMS 01 e2e cms and pki profiling Arkko
Issue #62 Rejected e2e unnecessary step via pkcs7-mime Arkko
Issue #63 CMS 01 e2e unverified certs Arkko
Issue #64 CMS 01 e2e draft editorial issues Arkko
Issue #65 Base 05 OctetString with NULL value Funk
Issue #66 Base 06 Server Discovery Calhoun
Issue #67 Rejected How to deal with CER and CEA in the case of SCTP Johansson
Issue #68 Base 06 Address Name and 20 byte IPV6 length Johansson
Issue #69 Base 06 ABNF editorial changes Caron
Issue #70 Base 06 Caching of redirects Caron
Issue #71 Base 06 Various editorial changes Caron
Issue #72 Base 06 Downstream/upstream confusion Caron
Issue #73 Base 06 Request & answer routing clarification Caron
Issue #74 Base 06 Do not use Route-Record for answer routing Caron
Issue #75 Base 07 Unsolicited server-to-client requests Caron
Issue #76 Base 06 Destination-Realm & proxies/relays Caron
Issue #77 Base 06 Implicit termination of an Auth session Johansson
Issue #78 Base 07 DiameterIdentity (host descriptor) matching & values Caron
Issue #79 Base 07 Error handling editorial changes Caron
Issue #80 Base 06 Editorial changes Caron
Issue #81 Base 07 Route-Record change Caron
Issue #82 Base 07 Reauthorization issues Caron
Issue #83 Base 07 Routing/forwarding clarifications Caron
Issue #84 CMS 01 Possibly editorial issues in cms-sec Arkko
Issue #85 Base 06 Cms-sec optimization for pdsr-case Arkko
Issue #86 Base 07 Diameter URI Changes Calhoun
Issue #87 Base 07 Move filter-rule AVP to base Caron
Issue #88 NASREQ 07 EAP Support Issues Aboba
Issue #89 MobileIP 07 Editorial comments - Mobile-IP draft-06 Julien
Issue #90 MIP 07 MIP-Previous-XXX AVP Julien
Issue #91 MIP 07 MIP SPI Julien
Issue #92 Base 07 Some editorials on Base-06 Rajaniemi
Issue #93 Base 07 End-to-End Identifier Johansson

Issue #94

Transport 05

Typographical change to sec. 3.2 of draft-ietf-aaa-transport-04.txt



Spence

Issue #95 Base 08 Problem with removing Route-Record AVPs Spence
Issue #96 Base 08 Change Record-Route to Route-Record Spence
Issue #97 Rejected Proxies keeping a session-state Julien
Issue #98 Base 08 Peer role in Peer table? Julien
Issue #99 Rejected New AVPs to NASREQ for Basic/Digest support Srinivas
Issue #100 Base 08 Editorial comments on base-07 Caron
Issue #101 Base NASREQ MIP 08, CMS 03 Editorial changes concerning Destination-Host Schaefer
Issue #102 Base 08 More description on Session state machine Jiang
Issue #103 Base NASREQ MIP 08, CMS 03 Inconsistencies in AVP types used throughout base spec Frascone
Issue #104 Base 08 Clarification on difference between session and peer connection Jiang
Issue #105 Base 08 More editorial comments Johansson
Issue #106 Base 08 More changes to table in section 4.6 Frascone
Issue #107 Base 08 More editorial changes Johansson
Issue #108 MIP 08 Errata in Mobile-IP Application Frascone
Issue #109 Rejected Request for a new AVP called Missing-AVP Johansson
Issue #110 MIP 08 MIPv4 comments Johansson
Issue #111 Base 08 More editorial comments on base-07 Schmid
Issue #112 Base 08 More editorial comments on base-07 Caron
Issue #113 Base 08 base draft 07 comments Caron
Issue #114 Rejected DiameterIdentity Caron
Issue #115 NASREQ 08 CHAP-Password is complex Calhoun
Issue #116 Base 08 Accounting-Session-Id definition incorrect Calhoun
Issue #117 Base 08 Remove support for Source-Route Calhoun
Issue #118 Rejected Error processing/capabilities negotiation Caron
Issue #119 Base 08 E bit, P bit, and proxy-info Eklund
Issue #120 CMS 03 Minor editorial changes in CMS Security Application Monjas
Issue #121 CMS 03 More editorial changes in CMS Monjas
Issue #122 Base 08 Editorial change in draft-ietf-aaa-diameter-07.txt Andersson
Issue #123 Rejected Use of Application Identifiers in routing Sreemanthula
Issue #124 CMS 03 Inconsistency in OCSP-Request-Flags AVP Monjas
Issue #125 CMS 03 Inconsistency in OCSP-Responses AVP Monjas
Issue #126 CMS 03 Clarification in certificate naming schema Monjas
Issue #127 CMS 03 editorial changes in CMS Monjas
Issue #128 Rejected duplicate packet detection in failure case Loughney
Issue #129 NASREQ 08 NASREQ unsolicited challenge requests Purser
Issue #130 NASREQ 08 Prescribed use of encryption in NASREQ Purser
Issue #131 NASREQ 08 Use of Auth-Request-Type in NASREQ Purser
Issue #132 CMS 03 Multiple signatures on a set of AVPs Monjas
Issue #133 CMS 03 digest value within CMS-Signed-Data AVP Monjas
Issue #134 CMS 03 Several CMS-Encrypted-Data AVPs in a message Monjas
Issue #135 CMS 03 contentType instead of eContentType in CMS-Encrypted-Data Monjas
Issue #136 CMS 03 Proxy's DSAR on behalf of a client Monjas
Issue #137 CMS 03 CMS Proxy's DSAAs Monjas
Issue #138 CMS 03 Signed DSA messages Monjas
Issue #139 CMS 03 Key Management chapter rephrasing Monjas
Issue #140 Base 08 Can Answer be rejected? Julien
Issue #141 CMS 03 OCSP Response request additional text Monjas
Issue #142 CMS 03 CEKMaxDecrypts value vs DSA length Monjas
Issue #143 CMS 03 Editorial changes in CMS #4 Monjas
Issue #144 CMS 03 OSCP Support Monjas
Issue #145 CMS 03 Order in CMS-proxy messages Monjas
Issue #146 NASREQ 08 CHAP Algorithm Missing Calhoun
Issue #147 NASREQ 08 NASREQ Loose ends Calhoun
Issue #148 Mobile IP 08 Change section 5-6 in MIP app to relect Johansson
Issue #149 CMS 03 Revalidation of certificates in cache Monjas
Issue #150 CMS 03 S/MIME precisions Monjas
Issue #151 Base 08 8.1 Authorization Session State Machine Johansson
Issue #152 CMS 03 Confusion between security services and techniques to achieve them Monjas
Issue #153 Rejected Key Length in CMS Security Application Monjas
Issue #154 Base 08 End-to-End Id in answer messages Constantin
Issue #155 Base 08 Small editorial comment on section 5.5.4 Loughney
Issue #156 CMS 03 DSA error codes Monjas
Issue #157 CMS 03 DSA error codes (cont) Monjas
Issue #158 CMS 03 DSA error codes (III) Monjas
Issue #159 CMS 03 Reference change in CMS-02 Monjas
Issue #160 CMS 03 Destination-Host in PDSR Monjas
Issue #161 CMS 03 Authorisation rejected in CMS Monjas
Issue #162 Base 08 Error replies to requests with no session id Arkko
Issue #163 CMS 03 Error codes (recap) Monjas
Issue #164 Rejected problems with Watch Dog Le
Issue #165 CMS 03 Expiration of DSAs on behalf of a client Monjas
Issue #166 Base 08 Ambiguity on Destination-Host AVP in Answer messages Poertner, Jiang
Issue #167 CMS 03 CMS-Cert in AVP occurrence table Monjas
Issue #168 CMS 03 DIAMETER_NO_COMMON_TRUST error Monjas
Issue #169 Base 08, CMS 03 Result-code with 'P' bit erroneous Monjas
Issue #170 CMS 03 Erroneous protection expectations Monjas
Issue #171 Base 08 missing realm protocol error Eklund
Issue #172 Base 08 The need for Float128 ? Johansson
Issue #173 Base 08 Transport failure algorithm differs between drafts Aboba
Issue #174 CMS 03 CMS Decryption Error Monjas
Issue #175 Base 08 Missing text in float definitions Eklund
Issue #176 Rejected Add clarifying App-Id text in CER/CEA sections Garcia
Issue #177 CMS 03 CMS proxy scenarios Monjas
Issue #178 CMS 03 Partial support of CMS Monjas
Issue #179 CMS 03 PDSA-Request without DSA-Target-Realm Monjas
Issue #180 CMS 03 AAA-Server-Certs Monjas
Issue #181 CMS 03 Digital encryption + signature in CMS-Sec Monjas
Issue #182 Mobile IP/NASREQ 08 Retain RADIUS attribute types for attributes 0-255 Kopacz
Issue #183 Base 08 Diameter hop-by-hop security Aboba
Issue #184 Base 08 CMS-Data AVPs in base protocol Monjas
Issue #185 CMS 03 CMS-protected AVPs outside a DSA Monjas
Issue #186 MIP 08 Decouple authorization and key generation Thomas
Issue #187 Mobile IP 08 Foreign-Home authentication extension doesn't exist Eklund
Issue #188 NASREQ 08 NAS-Key-Binding and Ciphersuite Negotiation Haverinen
Issue #189 NASREQ 08 NAS-Session-Key and Initialization Vectors Haverinen
Issue #190 NASREQ 08 NAS-Session-Key and Session Master Keys Haverinen
Issue #191 Base 08 How to know when to use TLS Johansson
Issue #192 Base 08 Missing Disconnect Cause Johansson
Issue #193 Base 08 Changes to Peer state machine in base-08-alpha Johansson
Issue #194 Base 08 Add Termination-Cause values for MIPv4 Thomas
Issue #195 MIP 08 Clarifications on key generation (mobileip-08) Jones
Issue #196 Base 08 How to use Diameter Accounting Hakala
Issue #197 Base 08 Missing Session Termination Cause in Section 8.15 Qing
Issue #198 MIP 08 MIP-FA-to-[HA|MN]-Key not needed in HAR Eklund
Issue #200 Base 08 Missing UserName AVP in table in section 10.2 Johansson
Issue #201 Rejected MIP-FA-to-MN-SPI and co-located servers Eklund
Issue #203 MIP 08 MIP-FA-to-HA being added to the AMA by the AAAF Eklund
Issue #205 Base 08 Should AVPs be ordered? Calhoun
Issue #206 Base 08 ABNF of non-proxiable commands incorrect Calhoun
Issue #207 Base 08 AAA URI inconsistent Calhoun
Issue #209 Rejected Authorization-Lifetime inconsistency Calhoun
Issue #210 MIP 08 Session-Timeout ABNF/Table inconsistency Calhoun
Issue #214 Base 08 Unknown-User Result-Code provides too much info Calhoun
Issue #216 MIP 08 Home Agent MUST support home address allocation Calhoun
Issue #217 MIP 08 typo in MIP section 3.2 Calhoun
Issue #218 Base 08, MIP 08, NASREQ 08, CMS 03 ABNF/Table inconsistencies Calhoun
Issue #219 MIP 08 AMA AVP issue when failure occurs on AAAH Calhoun


The following are the long form versions of the issues:

Issue 1: Make FAIR flags a part of Command-Code
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 18-May-2001
Reference:
Document: Base
Comment type: T
Priority: 2
Section: 3.0
Proprietary Tag: C
Rationale/Explanation of issue:

* Initially we only had different command-codes. I.E. ACA = 272,
and ACR = 271. We had to have a table of command codes and command
types. This wasn't good for proxy because a proxy should not have
to know what command type it is to properly proxy it.

* So flags were added to state what type it is. These represented
Indication, Request, Answer, Query, Response.

* Between draft 3 and draft 4 three things happened.
1. Query and Response were eliminated.
2. Failed was added.
3. Requests and Answers were combined to give us one code
ACA = ACR = 271 and the flags must be used to determine which type
it is.

This is good because it makes it easy to match a request with an
answer without even knowing what protocol it is.

This is bad because for known AVPs, you can no longer use a switch
statement to determine the attribute.

Requested change:

Go the next step. Use the top 8 bits of the Command-Code for attribute
type and the bottom 24 bits for the Command-Code. Now you have the best
of all worlds, a command that documents what type it is, you can easily
match requests with answers, and an ACA and an ACR can be distinguished
in a 32 bit value.

Resolution: Resolution of Issue: The command flags will be moved to the header as such:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Version     |           Message Length                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Hop-by-Hop Identifier                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      End-to-End Identifier                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |R|   Reserved    |       Command-Code                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Vendor-ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  AVPs ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-

The FAI flags were removed as a result of other changes.
The Message Length has been increased in the event that one day
something exceptionally large like fingerprint information is needed.
The flags have been moved into the Command Code itself.

The AVP will be also changed to have a 24 bit length to reflect
the larger Message Length.

Issue 2: Required Transports
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: May 20, 2001
Reference:

From: DSpence@Interlinknetworks.com
Date: May 20, 2001
Subject: Re: [AAA-WG]: transport MUSTs

Document: Base
Comment type: T
Priority: S
Section: 2.1
Proprietary Tag: C
Rationale/Explanation of issue:

The following sentence from section 2.1 is unclear:
"Diameter clients SHOULD support SCTP, but MUST support TCP if SCTP
is not available."
It appears to allow Diameter clients not to support TCP. This would be
contrary to past WG decision.

Requested change:
The sentence should read:
"Diameter clients MUST support TCP and MAY support SCTP."

Resolution:
The consensus reached at the May interim meeting on this issue is to
change the approach agreed to last February. The new position is
that clients MUST support either SCTP or TCP. This allows for
SCTP-only clients, TCP-only clients, or clients that support both.
Servers MUST support both SCTP and TCP. Transport negotiation is
simplified. Servers always connect to servers using SCTP unless
explicitly configured to do otherwise. For client-server
connections, the client initiates the connection using whichever
transport it supports or prefers.

The change in reasoning is as follows. We no longer care about the
firewall issue. Firewalls can be made to pass SCTP. If finer
grained control is needed, it will soon be offered by the firewall
vendors. Similarly, we are no longer concerned about operating
system support. The requirement is for servers to support SCTP. We
do not specify whether the support is provided in the application or
in the operating system. If the Diameter server application expects
operating system support, then that server can only fully support the
standard by running on an operating system that supports SCTP.

With regard to the security issue, we recognize that there are issues
running SCTP over IPsec and running TLS over SCTP. But we feel that
these issues must be urgently addressed. IPsec would have problems
with the multiple IP addresses supported by SCTP. However, Diameter
does not need multiple addresses, so it appears that IPsec can still
be used with Diameter/SCTP. TLS would have difficulty running over
multiple SCTP streams. Multiple streams are required to prevent head
of line blocking. We need to resolve this problem, but running
Diameter over TLS over a single SCTP stream would be no worse than
running Diameter over TLS over TCP, so there is no need to require
use of TCP with TLS.

The interoperability of SCTP with IPsec and TLS requires further
study, however, before Diameter goes to last call.

Issue #3: Bring Back UTF-8
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 18-May-2001
Reference:
Document: Base
Comment type: T
Priority: 2
Section: 4.3
Rationale/Explanation of issue:

First of all, sorry to drag up old issues. Here's the thoughts.

* At one time we had Data, Complex, and String formats

* When the datatypes were discussed in a meeting it was decided
that Data, Complex, and String were the same datatype. They
were combined to be Octetstring.

* Now, if something is actually UTF8 format, it will be Octetstring
with the text that it is in UTF8 format.

* Octetstring is defined as either some collection of data bytes,
or a message in UTF8 format.

* There is nothing to prevent one extension from defining an AVP
as UTF8 and another extension defining it as just bunch of bytes.

* The argument that an UTF8 formatted message is simply an Octetstring
is akin to saying that an Integer32 and an Unsigned32 are just a
two four byte numbers. Following that logic, those numbers should
be combined and the AVP definition should state that the number is
in signed format.

Requested change:
Add a new type of UTF8 and change all Octetstrings that say
they are UTF8 to this type.

Proposed Text: The proposed can be found at http://www.merit.edu/mail.archives/aaa-wg/msg01151.html

Issue 4: Extension Compliance wording confusion
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 18-May-2001
Reference:
Document: Base
Comment type: E
Priority: 2
Section: 2.4
Proprietary Tag: C
Rationale/Explanation of issue:

The paragraph

An implementation MAY support both a proprietary version of an
extension by requesting an IANA extension identifier (see section
16.3), while supporting the original extension. During the
capabilities exchange, a Diameter node can determine whether to
exchange messages using the proprietary or standard version of the
extension by inspecting the extensions advertised by the peer.

can be misinterpreted to say that there is a form of
capability negotiation. A slight wording change is requested.

Requested change:

Add the text between the (*)'s

An implementation MAY support both a proprietary version of an
extension by requesting an IANA extension identifier (see section
16.3), while supporting the original extension. During the
capabilities exchange, (* the Diameter nodes advertises all supported
extensions. After capabilities exchange, the *) Diameter node can
determine whether to exchange messages using the proprietary or
standard version of the extension by inspecting the extensions
(* that were *) advertised by the peer.

Resultion: It was agreed that this wording change was acceptable.

Issue 5: 3GPP2 Accounting Requirements
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: May 18, 2001
Reference: http://www.3gpp2.org/Public_html/specs/P.S0001-A-1.pdf
Document: Accounting, MobileIP
Comment type: T
Priority: ?
Section:
Rationale/Explanation of issue:

Is it an AAA WG requirement that we meet 3GPP2 requirements? If so,
then the following may be an issue.

3GPP2 document P.S0001-A-1, "Wireless IP Network Standard" specifies
use of a variety of public standards to realize wireless IP service.
Included in the document is a specification for how RADIUS should be
used. A number of RADIUS vendor-specific attributes are defined
including many accounting attributes.

The standard realizes version 1 of an architecture defined in 3GPP2
document P.R0001, "Wireless IP Architecture Based on IETF Protocols".
Version 2 of the architecture specified in this document goes on to
define a number of AAA requirements essentially all met by Diameter
with the exceptions described below.

The "Wireless IP Network Standard" defines quite a number of
vendor-specific accounting attributes, many of which report Radio
Network counters. When a wireless handoff takes place, the counts
collected at the old Radio Network need to be transmitted to the
accounting server. Thus, at the end of the Packet Data Session,
there may be multiple accounting sub-records. The standard specifies
two ways to handle this in RADIUS. The first is to bundle the
attributes of a subsession into an Accounting-Container attribute
(similar to a Grouped type AVP). This requires these attributes to
be held in the Packet Data Serving Node (PDSN -- the node that
contains the FA) until the end of the session and then they are all
sent to the AAA server in a single Accounting Stop message. To allow
subsession accounting data to be forwarded to the AAA servers as
generated, the standard specifies a second method. A vendor specific
Correlation-ID attribute is defined to supplement the RADIUS
Account-Session ID attribute. They also define a Session-Continue
attribute. Each time during the session that a PDSN has accounting
data to send, it generates an Accounting Stop message which includes
a Session-Contine attribute with a value of True. This is
immediately followed by an Accounting Start message with a new
Account-Session ID which begins the next sub-session. All accounting
messages sent for the Packet Data Session contain the same value of
the Correlation-ID attribute which then becomes the session
identifier that can be used to correlate accounting messages with
authentication messages. This is messy in RADIUS and would be worse
in Diameter.

Requested change:

1. Define all the 3GPP2 vendor specific accounting attributes as
Diameter AVPs in the MIP extension.

2. Invent a clean way to carry subsession accounting data in
Diameter, perhaps by inventing a Subsession-Identifier AVP and a
Subsession accounting message in the base protocol.

Resolution: Adopt the following text:
11.6 Correlation of Accounting Records

The Diameter protocol's Session-Id AVP, which is globally unique (see
section 10.3), is used during the authorization phase to identify a
particular session. Services that do not require any authorization
still use the Session-Id AVP to identify sessions.

However, there are certain applications that require multiple
accounting sub-sessions. Such applications would send messages with a
constant Session-Id AVP, but a different Accounting-Session-Id AVP.
In these cases, correlation is performed using the Session-Id.

Furthermore, there are certain applications where a user receives
service from different access devices (e.g. Mobile IP), each with
their own unique Session-Id. In such cases, the Accounting-Multi-
Session-Id AVP is used for correlation. During authorization, a
server that determines that a request is for an existing session,
SHOULD include the Accounting-Multi-Session-Id AVP, which the access
device MUST include in all subsequent accounting messages.

The Accounting-Multi-Session-Id AVP MAY include the value of the
original Session-Id. It's contents are implementation specific, but
MUST be globally unique across other Accounting-Multi-Session-Id, and
MUST NOT change during the life of a session.

A Diameter application document MUST define the exact concept of a
session that is being accounted, and MAY define the concept of a
multi-session. For instance, the NASREQ DIAMETER application treats a
single PPP connection to a Network Access Server as one session, and
a set of Multilink PPP sessions as one multi-session.

Issue 6: Server Identification
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: May 18, 2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: 5.1, 5.3, 8.4, 11.4.3, 11.7 and others
Proprietary Tag: C
Rationale/Explanation of issue:

There are various places in the base protocol specification that
assume that only one copy of a Diameter server can run on a host and
therefore that a Diameter server can be uniquely identified by an
FQDN or an IP address. It would be helpful to allow for multiple
server processes to run on a host. Some of the places where this
assumption is made are as follows:

1. DRI election process

There is a problem in the DRI election process, where a server is
identified solely by FQDN. The DRI election process resolves by
comparing FQDNs and assumes that they won't be the same.

2. Origin-FQDN AVP and Destination-FQDN AVP

The Origin-FQDN and Destination-FQDN AVPs are used for final hop
routing.

3. Route-Record AVP

The Route-Record AVP is also FQDN based and is used both for
routing and for loop detection.

This issue was actually raised in February on the mailing list.
(See Pat Calhoun email of Friday, February 23, 2001 8:30 AM.) The
thread died without resolution, but Pat's final question was
"whether multiple aaad processes on a single box is a
requirement?"

4. Error-Reporting-FQDN AVP

The Error-Reporting-FQDN AVP is also FQDN based and is used for
identifying a Diameter server.

There is one place where Diameter does accommodate multiple servers
per host. A redirect host is identified by a Redirect-Host grouped
AVP which contains an FQDN and a port.

Requested change:

Invent a general way to identify an instance of a Diameter server. A
combination of FQDN and TCP/SCTP port number is suggested. Use this
combination in each of the above AVPs.

Resolution: The complete fix can be found at http://www.merit.edu/mail.archives/aaa-wg/msg01053.html

Issue 7: Add extension-id to the Diameter Header
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 18-May-2001
Reference:
Document: Base
Comment type: T
Priority: 2
Section: 3.1
Rationale/Explanation of issue:

* The following don't require either the Auth-Extension-Id nor
the Acct-Extension-ID: STI STR STA DWR DWA DRI DSI

* The following commands have either the Auth-Extension-ID
or Acct-Extension-ID: ACA ACR API ASI AAA ACI AAR ESSR ESSA
AMA AMR HAA HAR

* In all likelyhood most commands in future extensions will require
an extension ID.

* Routing uses the extension ID and type (AA or Acct) to make
routing decisions.

* The second set of attributes will likely be 99% of diameter traffic.

Requested change:

1. Move the extension ID to be a part of the Diameter Header.
2. Add 0 extension for STI STR STA DWR DWA DRI DSI
3. Add an C flag to the Diameter Header to state that this is
an a(c)counting request. (If the FAIR flags move to the command
code, this should move too.)
This should eliminate two searches for the Extension-ID avps.
Resolution: Since you have to also search for the
Destination-Realm, Destination-FQDN, and Username when routing,
the efficiency added by moving the Acct-Extension-Id and
Auth-Extension-Id to the header was outweighed by the
inconsistency of having some routing information in the header
and some in AVPs.

This request was denied.

Issue 8: Routing of Indication messages
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
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)
Proprietary Tag: C
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.
Resolution: Indication messages are no longer supported. The group felt that simply making all messages become request/answer simplified the protocol. This means that the DRI becomes a request/answer message pair, which will impact the base protocol text and the state machine will have to make use of the new command names.

Issue 9: Proposal to modify STI
Submitter name: Paul Funk
Submitter email address: paul@funk.com
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)
Proprietary Tag: C
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:
The conclusion at the interim meeting was that notification by the access
device to the authorizing server that a session has ended (STR/STA) should
be treated independently from a session management sort of request by
some server (possibly the authorizing one) to the access device to abort
the session (STI).

In addition, since the interim meeting is proposing that one-way transactions
(Indications) should be eliminated, the abort request would be two-way, i.e.,
Request/Answer, rather than STI.

Other situations are also covered in the suggested language below,
such as sessions that never start and proxy interceptions.

Suggested language:

10.8  Session Termination

It is necessary for a Diameter server that authorized a session to be
notified when that session is no longer active, both for tracking purposes
as well as to allow the Diameter server to release any resources that it
may have provided for the user session.

When a user session that required Diameter authorization terminates, the
access device that provided the service MUST issue a Session-Termination-
Request (STR) message to the Diameter server that authorized the service,
to notify it that the session is no longer active. An STR MUST be issued
when a user session terminates for any reason, including user logoff,
expiration of Session-Timeout, administrative action, termination upon
receipt of an Abort-Session-Request (see below), orderly shutdown of the
access device, etc.

The access device also MUST issue an STR for a session that was
authorized but never actually started. This could occur, for example, due
to a sudden resource shortage in the access device, or because the
access device is unwilling to provide the type of service requested in the
authorization, or because the access device does not support a
mandatory AVP returned in the authorization, etc.

It is also possible that a session that was authorized is never actually
started due to action of a proxy. For example, a proxy may modify an
authorization answer, converting the result from success to failure, prior
to forwarding the message to the access device. A proxy that causes
an authorized session not to be started MUST issue an STR to the
Diameter server that authorized the session, since the access device has
no way of knowing that the session had been authorized.

A Diameter server that receives an STR message MUST clean up
resources (e.g., session state) associated with the Session-Id specified
in the STR, and return a Session-Termination-Answer.

A Diameter server also MUST clean up resources when the Session-
Timeout expires, or when the Authorization-Lifetime expires without
re-authorization, regardless of whether an STR for that session is
received. The access device is not expected to provide service beyond
the expiration of these timers; thus, expiration of either of these timers
implies that the access device may have unexpectedly shut down.

10.8.1  Session-Termination-Request

The Session-Termination-Request (STR), indicated by the Command-
Code set to 275 and the message flags' 'R' bit set, is sent by the access
device to inform the Diameter Server that an authenticated and/or
authorized session is being terminated.

Message Format

      <Session-Termination-Request>  ::= < Diameter Header: 275, R >
                                         < Session-Id >
                                         { Origin-FQDN }
                                         { Origin-Realm }
                                         { User-Name }
                                         { Destination-Realm }
                                         { Destination-FQDN }
                                         [ Max-Wait-Time ]
                                       * [ AVP ]
                                       * [ Proxy-Info ]
                                       * [ Route-Record ]
 

10.8.2  Session-Termination-Answer

The Session-Termination-Answer (STA), indicated by the Command-
Code set to 275 and the message flags' 'R' bit clear, is sent by the
Diameter Server to acknowledge the notification that the session has
been terminated. The Result-Code AVP MUST be present, and MAY
contain an indication that an error occurred while servicing the STR.

Upon sending or receipt of the STA, the Diameter Server MUST
release all resources for the session indicated by the Session-Id AVP.
Any intermediate server in the Proxy-Chain MAY also release any
resources, if necessary.

Message Format

      <Session-Termination-Answer>  ::= < Diameter Header: 275 >
                                        < Session-Id >
                                        { Result-Code }
                                        { Origin-FQDN }
                                        { Origin-Realm }
                                        { Destination-FQDN }
                                        { User-Name }
                                      * [ AVP ]
                                      * [ Proxy-Info ]
                                      * [ Route-Record ]

10.9  Aborting a Session

A Diameter server may request that the access device stop providing
service for a particular session by issuing an Abort-Session-Request
(ASR).

For example, the Diameter server that originally authorized the session
may be required to cause that session to be stopped for credit or other
reasons that were not anticipated when the session was first authorized.
Or, an operator may maintain a management server for the purpose of
issuing ASRs to administratively remove users from the network.

An access device that receives an ASR with Session-ID equal to a
currently active session MAY stop the session. Whether the access
device stops the session or not is implementation- and/or configuration-
dependent. For example, an access device may honor ASRs from
certain servers only. In any case, the access device MUST respond with
an Abort-Session-Answer, including a Result-Code AVP to indicate what
action it took.

Note that if the access device does stop the session upon receipt of an
ASR, it issues an STR to the authorizing server (which may or may not
be the server issuing the ASR) just as it would if the session were
terminated for any other reason.

10.9.1  Abort-Session-Request

The Abort-Session-Request (ASR), indicated by the Command-Code set
to [nnn] and the message flags' 'R' bit set, may be sent by any server to
the access device that is providing session service, to request that the
session identified by the Session-Id be stopped.

      <Abort-Session-Request>  ::= < Diameter Header: nnn, R >
                                   < Session-Id >
                                   { Origin-FQDN }
                                   { Origin-Realm }
                                   { Destination-Realm }
                                   { Destination-FQDN }
                                 * [ AVP ]
                                 * [ Proxy-Info ]
                                 * [ Route-Record ]

10.9.2  Abort-Session-Answer

The Abort-Session-Answer (ASA), indicated by the Command-Code set
to [nnn] and the message flags' 'R' bit clear, is sent in response to the
ASR. The Result-Code AVP MUST be present, and indicates the
disposition of the request.

If the session identified by Session-Id in the ASR was successfully
terminated, Result-Code is set to DIAMETER_SUCCESS. If the session
is not currently active, Result-Code is set to
DIAMETER_UNKNOWN_SESSION_ID. If the access device does not
stop the session for any other reason, Result-Code is set to [what?
should there be a generic failure result code?].

      <Abort-Session-Answer>  ::= < Diameter Header: nnn >
                                  < Session-Id >
                                  { Result-Code }
                                  { Origin-FQDN }
                                  { Origin-Realm }
                                  { Destination-FQDN }
                                * [ AVP ]
                                * [ Proxy-Info ]
                                * [ Route-Record ]

Resolution: Accept proposed text

Issue 10: Sessions that do not start
Submitter name: Paul Funk
Submitter email address: paul@funk.com
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
Proprietary Tag: C
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.

Resolution: Accept proposed text

Issue 11: Grouped AVP
Submitter name: Paul Funk, Dave Frascone
Submitter email address: paul@funk.com, dave@frascone.com
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
Proprietary Tag: C
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.
Suggested language:

4.4 Grouped AVP Values

The Diameter protocol allows AVP values of type 'Grouped.' This implies
that the Data field comprises one or more AVPs.

Every AVP defined to be of data type Grouped MUST include a corresponding
ABNF specification, which is used to define the permitted arrangements of AVPs
within the Group.

The format to be used follows the format for Command Code ABNF
specifications (3.2), with the following additional definition:

group-def = AVP-name "::=" [*fixed] [*required] [*optional] [*fixed]

It is possible to include an AVP with a Grouped type within a
Grouped type, that is, to nest them. AVPs within an AVP of type
Grouped have the same padding requirements as non-Grouped AVPs, as
defined in section 4.0.

Example:

group-def ::= example-avp
{Origin-FQDN}
{Host-IP-Address}
*[AVP]

Resolution: The following text has been added to the base protocol
specification:
4.4 Grouped AVP Values

The Diameter protocol allows AVP values of type 'Grouped.' This
implies that the Data field is actually a sequence of AVPs. It is
possible to include an AVP with a Grouped type within a Grouped type,
that is, to nest them. AVPs within an AVP of type Grouped have the
same padding requirements as non-Grouped AVPs, as defined in section
4.0.

Every Grouped AVP defined MUST include a corresponding grammar, using
ABNF [31] (with modifications), as defined below.

avp-def = name "::=" avp

name-fmt = ALPHA *(ALPHA / DIGIT / "-")

name = name-fmt
; The name has to be the name of an AVP,
; defined in the base or extended Diameter
; specifications.

avp = header [ *fixed] [ *required] [ *optional]
[ *fixed]

header = "
avpcode = 1*DIGIT
; The AVP Code assigned to the Grouped AVP

fixed = [qual] "<" avp-spec ">"

required = [qual] "{" avp-spec "}"

optional = [qual] "[" avp-name "]"
; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name which is included
; in a fixed or required rule.

qual = [min] "*" [max]
; See ABNF conventions, RFC 2234 section 6.6.
; The absence of any qualifiers implies that
; one and only one such AVP MUST be present.
;
; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above).
; These braces cannot be used to express
; optional fixed rules (such as an optional
; ICV at the end.) To do this, the convention
; is '0*1fixed'.

min = 1*DIGIT
; The minimum number of times the element may
; be present.

max = 1*DIGIT
; The maximum number of times the element may
; be present.

avp-spec = name-fmt
; The avp-spec has to be an AVP Name, defined
; in the base or extended Diameter
; specifications.

avp-name = avp-spec | "AVP"
; The string "AVP" stands for *any* arbitrary
; AVP Name, which does not conflict with the
; required or fixed position AVPs defined in
; the command code definition.
 

4.4.1 Example AVP with a Grouped Data type

The Example AVP (AVP Code 999999) is of type Grouped and is used to
clarify how Grouped AVP values work. The Grouped Data field has the
following ABNF grammar:

Example-AVP ::= < AVP Header: 999999 >
{ Origin-Host }
1*{ Session-Id }
*[ AVP ]

An Example AVP with Grouped Data follows.

The Origin-Host AVP is required. In this case:

Origin-Host = "example.com".

One or more Session-Ids must follow. Here there are two:

Session-Id =
"grump.example.com:33041;23432;893;0AF3B81"

Session-Id =
"grump.example.com:33054;23561;2358;0AF3B82"

optional AVPs included are

Recovery-Policy = 
2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92

Futuristic-Acct-Record = 
fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
d3427475e49968f841

The data for the optional AVPs is represented in hex since the format
of these AVPs is neither known at the time of definition of the
Example-AVP group, nor (likely) at the time when the example instance
of this AVP is interpreted - except by Diameter implementations which
support the same set of AVPs. The encoding example illustrates how
padding is used, how length fields are calculated and how AVPs do not
have to begin on 8 byte boundaries. Also note that AVPs may be
present in the Grouped AVP value which the receiver cannot interpret
(here, the Recover-Policy and Futuristic-Acct-Record AVPs).

This AVP would be encoded as follows:
 

0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
0 | Example AVP Header (AVP Code = 999999), Length = 468 |
+-------+-------+-------+-------+-------+-------+-------+-------+
8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 |
+-------+-------+-------+-------+-------+-------+-------+-------+
16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
+-------+-------+-------+-------+-------+-------+-------+-------+
24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
32 | (AVP Code = 263), Length = 50 | 'g' | 'r' | 'u' | 'm' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
64 | 'A' | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
68 | Session-Id AVP Header (AVP Code = 263), Length = 51 |
+-------+-------+-------+-------+-------+-------+-------+-------+
72 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
104 | '0' | 'A' | 'F' | '3' | 'B' | '8' | '2' |Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
112 | Recovery-Policy Header (AVP Code = 8341), Length = 223 |
+-------+-------+-------+-------+-------+-------+-------+-------+
120 | 0x21 | 0x63 | 0xbc | 0x1d | 0x0a | 0xd8 | 0x23 | 0x71 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
320 | 0x2f | 0xd7 | 0x96 | 0x6b | 0x8c | 0x7f | 0x92 |Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
328 | Futuristic-Acct-Record Header (AVP Code = 15930), Length = 137|
+-------+-------+-------+-------+-------+-------+-------+-------+
336 | 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
464 | 0x41 |Padding|Padding|Padding|
+-------+-------+-------+-------+

Issue 12: Boot Id
Submitter name: Paul Funk
Submitter email address: paul@funk.com
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
Proprietary Tag: C
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:

The interim group felt that, of the three proposals in the foot-fetish
thread, Paul's and Pat's should be adopted. Briefly, a Boot-Id is passed
in DRI to allow a server to determine when a peer has rebooted, and
Boot-Id is also passed in other messages, to allow downstream
servers more than one hop away to glean this information.

Randy suggested that the name of the AVP be changed from Boot-Id to
State-Id, since a server may retain state across reboots. Therefore,
a new id is really indicative of fresh state. I suggest we in fact
call it Origin-State-Id, to emphasize its relationship to Origin-FQDN.

Origin-State-Id will have to be added to the ABNF for DRI as well as all
other messages, as an optional AVP.

Suggested language:

[add the following somewhere in the DRI section:]

Origin-State-Id AVP

The Origin-State-Id AVP (AVP Code ?), of type Unsigned32, is a
monotonically increasing value that is advanced whenever a Diameter
entity restarts with loss of previous state, for example upon reboot.
Origin-State-Id MAY be included in any Diameter message, including
DRI.

A Diameter entity issuing this AVP MUST create a higher value for
this AVP each time its state is reset. A Diameter entity MAY set
Origin-State-Id to the time of startup, or it MAY use an incrementing
counter retained in non-volatile memory across restarts.

The Origin-State-Id, if present, MUST reflect the state of the
entity indicated by Origin-FQDN. If a proxy modifies Origin-FQDN,
it MUST either remove Origin-State-Id or modify it appropriately as
well.

Typically, Origin-State-Id is used by an access device that always
starts up with no active sessions; that is, any session active prior
to restart will have been been lost. By including Origin-State-Id in
a message, it allows other Diameter entities to infer that sessions
associated with a lower Origin-State-Id are no longer active. If an
access device does not intend for such inferences to be made, it
MUST either not include Origin-FQDN in any message, or set its value
to 0.

[add the following to the Session Termination section:]

10.10 Inferring Session Termination from Origin-State-Id

Origin-State-Id is used to allow rapid detection of terminated
sessions for which no STR would have been issued, due to unanticipated
shutdown of an access device.

By including Origin-State-Id in DRI messages, an access device allows
a next-hop server to determine immediately upon connection whether the
device has lost its sessions since the last connection.

By including Origin-State-Id in request messages, an access device
also allows a server with which it communicates via proxy to make
such a determination. However, a server that is not directly connected
with the access device will not discover that the access device has
been restarted unless and until it receives a new request from the
access device. Thus, use of this mechanism across proxies is
opportunistic rather than reliable, but useful nonetheless.

When a Diameter server receives a Origin-State-Id that is greater
than the Origin-State-Id previously received from the same issuer,
it may assume that the issuer has lost state since the previous
message and that all sessions that were active under the lower
Origin-State-Id have been terminated. The Diameter server MAY clean
up all session state associated with such lost sessions, and MAY also
issues STRs for all such lost sessions that were authorized on
downstream servers, to allow session state to be cleaned up globally.

Resolution: Accept proposed text

Issue 13: DSI
Submitter name: Paul Funk
Submitter email address: paul@funk.com
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
Proprietary Tag: C
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).

Resolution: The decision that was taken at the Interim meeting
was that the DSI would be replaced with a message that only has an
answer, and no request. Furthermore, all DSI-Events have been
moved to a special Result-Code category.
A complete description of the fix can be found at:
http://www.merit.edu/mail.archives/aaa-wg/msg00971.html

Issue 14: Watchdogs
Submitter name: Jonathan Wood
Submitter email address: jonwood@eng.sun.com
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

Resolution: Watchdogs are required, regardless of transport
keepalives.

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

Requested change:
Add clarifying text
Resolution: This message was in the base protocol because there is an equivalent RADIUS message. However, this message encourages the use of resource management using Accounting Messages, and this is frowned upon since such capabilities are provided in the auth portion of the protocol. Furthermore, in RADIUS is signals that a NAS is now available, and in Diameter this is done by opening a transport layer connection, and sending the DRI message. Therefore, it was decided that this message couldn't be justified, and will be removed from the protocol specification.

Issue 16: Redirect Server Certificates
Submitter name: Paul Funk
Submitter email address: paul@funk.com
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

Issue 17: Head of Line Blocking Prevention
Submitter name: Jonathan Wood
Submitter email address: jonwood@eng.sun.com
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
Proprietary Tag: C
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.

Resolution: Accept proposed text

Issue 18: Remove the Error-Reporting-FQDN
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
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)
Proprietary Tag: C
Rationale/Explanation of issue:
The Error-Reporting-FQDN is never any different from
the Origin-FQDN.

Requested change:
Remove the Error-Reporting-FQDN
Resolution: Since the Error-Report-FQDN is never different from the Origin-FQDN, it isn't necessary. However, the group did discuss that a proxy MAY alter the Result-Code AVP, and if it does, then the Error-Reporting-FQDN would become useful. So we will keep the Error-Reporting-FQDN, and state that it ONLY needs to be added if the host adding it is different from the one encoded in the Origin-FQDN.

Issue 19: Extensions that Diameter servers MUST support
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
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)
Proprietary Tag: C
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."

Resolution: Accept the proposed text above.

Issue 20: How to handle no common extensions
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 2001-06-05
Reference:
Document: Base
Comment type: C
Priority: 1
Section: 2.1
Rationale/Explanation of issue:

At the Interim meeting there were discussions on how to handle the
case where two peers connect, and realize that they have no common
applications (was extensions). My take on this is that they should
disconnect, since there will not be any further protocol exchanges,
but Paul preferred that they stay in communication.


Requested change:

None. Section 6.0 in the -06 draft currently states:

" A receiver of a Capabilities-Exchange-Req message which does not have any
applications in common with the sender MUST return a
Capabilities-Exchange-Answer with the Result-Code AVP set to
DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport layer
connection."

Resolution: New text is as follows:
A receiver of a Capabilities-Exchange-Req (CER) message which does not
have any applications in common with the sender MUST return a
Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to
DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport layer
connection. Note that receiving a CER or CEA from a peer advertising
itself as a Relay (see section 6.1) MUST be interpreted as having
common applications with the peer.

Issue 21: TLS & SCTP Streams
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: Base
Comment Type: Technical
Priority: S
Section: 2.2
Proprietary Tag: C
Rationale/Explanation of issue:
The base protocol currently requires that TLS be used by servers, and mandates the use of SCTP between servers. However, there is currently no specification that defines how SCTP streams can be handled by TLS.

Resolution: Use the following text: "Diameter implementations MUST support TLS, but the administrator MAY opt to configure IPSec instead of using TLS. Operating the Diameter protocol without any security mechanism is not recommended."

Issue 22: Create an Enum Data Type
Submitter name: Mark Jones
Submitter email address: mjones@bridgewatersystems.com
Date first submitted: May, 2001
Reference: Issue #22 on http://www.drizzle.com/~aboba/AAA/issues.html
Document: Base
Comment type: T
Priority: 1 or 2 (?)
Section: 4.3
Rationale/Explanation of issue:

At the interim meeting, a proposal for the introduction of a new data type
(or subtype) of Enumerated met with a favorable response so I am posting
it to the list for comments. As with Mark Eklund's suggestion for UTF8,
guidance is sought from SMI gurus on the most appropriate way to introduce
Enums into the base protocol.

Enumerated types are defined in the NASREQ extension already and are
different from the currently defined types in how they are validated,
encoded and allocated.

An enumerated type defines an explicit list of unsigned 32-bit integer
values that an AVP may take. This allows a Diameter peer to validate and
reject commands containing an enumerated AVP with an invalid value
(Result-Code = DIAMETER_INVALID_AVP_VALUE).

When encoding enumerated types there is a translation step from a name to
a corresponding integer value (either in the server itself or the
provisioning application). Service provisioning applications make use of
the enumerated type definition to validate data entry or offer a drop-down
list of possible names/values.

Enumerated types are also treated differently when it comes to allocating
the values in order to avoid overlapping values being used by different
implementations, e.g. NASREQ/RADIUS enumerated types are controlled by
IANA (see http://www.iana.org/assignments/radius-types). A similar
approach is required for the values of enumerated types defined in the
Diameter extensions. The values of vendor-specific Enumerated AVPs would
be controlled by the vendor themselves and not by IANA.

Requested change:

Add a new subtype of Unsigned32 as follows:

Unsigned32
32 bit unsigned value, in network byte order. The AVP Length
field MUST be set to 12 (16 if the 'V' bit is enabled).

Enumerated
32 bit unsigned value, in network byte order, where the
list of valid values and their interpretation is described
in the Diameter extension introducing the AVP. As with
Unsigned32, the AVP Length field MUST be set to 12
(16 if the 'V' bit is enabled).

Proposed Text: The proposed can be found at http://www.merit.edu/mail.archives/aaa-wg/msg01151.html

Issue 23: Make AVP Header consistent with Message Header
Submitter name: Paul Funk
Submitter email address: paul@funk.com
Date first submitted: May, 20001
Reference:
Document: Base
Comment Type: Technical
Priority: 2
Section: 4.1
Proprietary Tag: C
Rationale/Explanation of issue:
As long as we have 24 bit message length, how about 24 bit AVP length,
with similar positioning of length in low order bits?

Requested change:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           AVP Code                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|P| Reserved|                 AVP Length                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Vendor-ID (opt)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...
+-+-+-+-+-+-+-+-+

Resolution: Accept proposal

Issue 24: Transport Selection
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 2001-06-05
Reference:
Document: Base
Comment type: C
Priority: 1
Section: 2.1
Rationale/Explanation of issue:

At the Interim Meeting, Bernard stated that the base protocol should
describe how to connect to a peer in the case where more than one
transport is available, or the transport wasn't specified.

Requested change:

Add the following text to the end of section 2.1:
When connecting to a peer, and either zero or more transports are
specified, SCTP SHOULD be tried first, followed by TCP. Diameter
implementations SHOULD be able to interpret explicit network
notifications (such as ICMP messages) which indicate that a server is
not reachable, rather than relying solely on timeouts (e.g. connect()
returns ECONNREFUSED if the client could not connect to a server at
that address).

Issue 25: Support for multi-processes
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 25-May-2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: 8.0
Rationale/Explanation of issue:

* Issue #6, "Server Identification" changes the FQDN to be an identifier
  that allows more than one copy of a Diameter server on a host.

* If more than one server can exist on a platform, then you cannot
  do refuse a connection based on ip address.

Requested change:

Modify the Peer State Machine to not contain R-Snd-Conn-Nack.

Proposed Text: http://www.merit.edu/mail.archives/aaa-wg/msg01069.html

Issue 26: What to do if STR is sent to unavailable server?
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 24-May-2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

* The Session-Terminate-Request requires a Destination-FQDN

* There was going to be text added to state that the Destination-FQDN
  should be that of the last place you authenticated.

* What happens if that Destination-FQDN is down?  If this is a cluster
  of servers, there may still be a need for the STR to be sent to the
  realm.

Requested change:

One or more of the following changes:

1. Do nothing.  If the authenticating server goes down, either all the
   state data is lost, or session timeouts will cleanup any STRs missed.
   A statement as such should be added to the RFC reflecting this.

2. Make the Destination-FQDN optional.  If the client receives a
   DIAMETER_UNABLE_TO_DELIVER, the client may send the request without
   a Destination-FQDN.

3. #2 above, but allow a proxy to also do this.

4. Make the Destination-FQDN optional.  Add an STR-Destination AVP
   that is of type integer that is sent as a part of the authentication
   process.  This would contain the Destination-Realm and optionally
   the Destination-FQDN to which this should be sent.

Proposed Text: http://www.merit.edu/mail.archives/aaa-wg/msg01218.html

Resolution: Accept proposed text, with minor grammatical changes

Issue 28: Why have Max-Wait-Time?
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: Base
Comment Type: Technical
Priority: S
Section: 10.7 and a few other sections
Proprietary Tag: C
Rationale/Explanation of issue:
The base protocol currently defines Max-Wait-Time, but this AVP causes some problems. The main idea is that a peer can propose how long it is willing to wait for a request, and mandates that an error be returned prior to the expiration of the time proposed. However, in a proxy scenario, unless Max-Wait-Time is decremented at each proxy hop, the server closest to the NAS will return an error, then the next one and so one, causing unnecessary traffic. Either a reliable mechanism must be proposed to decrement Max-Wait-Time, or the AVP should be eliminated.

Resolution: The AVP is removed from the base specification.

Issue 29: IPv6 AVPs
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 2001-06-05
Reference:
Document: nasreq
Comment type: C
Priority: 1
Section: 7.2.5
Rationale/Explanation of issue:

At the Interim Meeting, Bernard stated that two RADIUS ipv6
attributes were missing from the NASREQ application, specifically
the Framed-Interface-Id, and the Framed-IPv6-Prefix.

Proposed Text:

7.2.5.4 Framed-Interface-Id AVP

The Framed-Interface-Id AVP (AVP Code TBD) is of type Unsigned64 and
contains the IPv6 interface identifier to be configured for the user.
It MAY be used in authorization requests as a hint to the server that
a specific interface id is desired, but the server is not required to
honor the hint in the corresponding response.


7.2.5.5 Framed-IPv6-Prefix AVP

The Framed-Interface-Id AVP (AVP Code TBD) is of type Address and
contains the IPv6 prefix to be configured for the user. It MAY be
used in authorization requests as a hint to the server that a
specific interface id is desired, but the server is not required to
honor the hint in the corresponding response.

Issue 30: Failed-AVP should be Grouped
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 24-May-2001
Reference:
Document: Base
Comment type: T
Priority: 2
Section:
Proprietary Tag: C
Rationale/Explanation of issue:
With the change of the grouped type AVP to allow ABNF in
the form of 1* {AVP}, the information held by the Failed-Vendor-Id
and Offending-AVP may sent by simply putting the failed AVP in the
Failed-AVP group.

Requested change:
Eliminate Offending-AVP and Failed-Vendor-Id, change
Failed-AVP to be of type grouped.

Resolution:

Section 9.3 will be changed to:

9.3 Failed-AVP AVP

The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
debugging information in cases where a request is rejected or not
fully processed due to erroneous information in a specific AVP. The
value of the Result-Code AVP will provide information on the reason
for the Failed-AVP AVP.

The possible reasons for this AVP are the presence of an improperly
constructed AVP, an unsupported or unrecognized AVP, an invalid AVP
value, the omission of a required AVP, the presence of an explicitly
excluded AVP (see table 13.0), or the presence of two or more
occurrences of an AVP which table 15.1 restricts to 0, 1, or 0-1
occurrences.

A Diameter message MAY contain one Failed-AVP AVP, containing
the entire AVP that could not be processed successfully.
If the failure reason is omission of a required AVP, an AVP with
the missing AVP code, the missing vendor id, and a zero filled
payload of the minimum required length for the ommitted AVP will be
added.

AVP format:
::= (AVP Code = 279)
1* {AVP}

Resolution: Accept proposed text

Issue 31: Increase randomness of Session-Id to 64 bits
Submitter name: Paul Funk
Submitter email address: paul@funk.com
Date first submitted: May, 20001
Reference:
Document: Base
Comment Type: Technical
Priority: ?
Section: 10.3
Proprietary Tag: C
Rationale/Explanation of issue:

A 32 bit monotonically increasing value is not sufficient to guarantee
uniqueness of Session-Id, especially if a starting value is randomly
selected at startup. Also, Session-Id ought to be unique for longer
than the lifetime of the session, since it will have to be used to match
up historical authorization and accounting information.

Requested change:

Basically, make the monotonically increasing value 64 bits rather
than 32 bits.

Note that I went beyond what was discussed at the interim meeting in
the language below, specifying that the FQDN part of Session-ID is a
MUST, rather than a SHOULD. Session-Ids generated by different
devices have to be distinguishable, hence the MUST. I also added
semicolon delimiters, to guarantee that ambiguity cannot result from
FQDN followed immediately by some numeric value.

Suggested language:

The Session-Id MUST be globally and eternally unique, as it is meant
to uniquely identify a user session without reference to any other
information, and may be needed to correlate historical authentication
information with accounting information. The Session-Id includes a
mandatory portion and an implementation-defined portion; a recommended
format for the implementation-defined portion is outlined below.

The Session-Id MUST begin with the client FQDN. If the client uses a
non-standard authorization port, the FQDN MUST be followed by a colon
(:) and the port number. The next character MUST be a semicolon (;).
The remainder of the Session-Id MAY be any sequence that the client can
guarantee to be eternally unique; however, the following format is
recommended, (square brackets [] indicate an optional element):

<client FQDN>[:<port>];<high 32 bits>;<low 32 bits>[;<optional value>]

<high 32 bits> and <low 32 bits> are decimal representations of the high
and low 32 bits of a monotonically increasing 64-bit value. The 64-bit
value is rendered in two part to simplify formatting by 32-bit processors.
At startup, the high 32 bits of the 64-bit value MAY be initialized to the
time, and the low 32 bits MAY be initialized to 0. This will for
practical purposes eliminate the possibility of overlapping Session-Ids
after a reboot, assuming the reboot process takes longer than a second.
Alternatively, an implementation MAY keep track of the increasing value
in non-volatile memory.

<optional value> is implementation specific but may include a modem's
device Id, a layer 2 address, timestamp, etc.

Example, in which the standard port is used and there is no optional
value:

accesspoint7.acme.com;1876543210;523

Example, in which a non-standard port is used and there is an optional
value:

accesspoint7.acme.com:831;1876543210;523;mobile@200.1.1.88

Resolution: Accept proposed text

Issue 32: NASREQ extension includes Indication messages
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: NASREQ
Comment Type: Technical
Priority: S
Section: 3.1.3 & 4.2.3
Proprietary Tag: C
Rationale/Explanation of issue:
Now that Indication messages have been removed from the base protocol spec, the NASREQ extension must be fixed to remove indication messages.
Resolution: A new Result-Code in the 1xxx class will be created. When the AAA or DEA is received with this new result code, a new AAR or DER is sent. So the functionality is not removed, but the AAA or DEA is used instead of the AAI and DEI.

Issue 33: Is API message considered useful?
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: Base
Comment Type: Technical
Priority: 2
Section: 13.3
Rationale/Explanation of issue:
The API message is used to poll a particular access device for an accounting record. Currently, it would require that the server in question knows the session identifier, but I believe that the original intent was to allow a server to ask for all accounting records.
Resolution: The text in 13.3 implies that this feature is useful for resource management, and we have determined that we do not want to provide accounting resource management since the auth portion provides that functionality. There is desire to delete this functionality, but the 3GPP2 P.S0001 requires such functionality. Pat Calhoun is looking into this.

Issue 34: DRI should only be sent on connection establishment
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: Base
Comment Type: Editorial
Priority: S
Section: 6.2
Proprietary Tag: C
Rationale/Explanation of issue:
The base protocol spec states "The Device-Reboot-Ind (DRI), indicated by the Command-Code set to 257 and the message flags' 'I' bit set, is sent to inform a peer that a reboot has, or will, occur."
Resolution: The spec muts be reworded to state "... inform a peer that a reboot has occurred."

Issue 35: Device-Reboot-Ind isn't an appropriate name
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: Base
Comment Type: Editorial
Priority: S
Section: 6.2
Proprietary Tag: C
Rationale/Explanation of issue:
The name of the DRI, which is now DRR and DRA, isn't really appropriate
now that the protocol is run over a reliable transport.
Resolution: The decision at the Interim Meeting was to change
the name from Device-Reboot-* to Capabilities-Exchange, or CER and CEA.

Issue 36: KDC support in NASREQ Extension
Submitter name: Sioninen
Submitter email address: ?
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.
Resolution: Adopt text as proposed. Pat will make necessary modifications to ensure consistency.

Issue 37: Home State Blob
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: June 15 20001
Reference:
Document: Base
Comment Type: Technical
Priority: 2
Section: new section 10.16
Rationale/Explanation of issue:
The RADIUS protocol defines the Class attribute, which allows for home
servers to return some state information to the NAS. The Class attribute
must be present in subsequent messages for the session.

Requested change:
Add following text in section 10:
10.16 Class AVP

The Class AVP (AVP Code 25) is of type OctetString and is used to by
Diameter servers to return state information to the access device.
When one or more Class AVPs are present in application-specific
authorization answer messages, they MUST be present in subsequent
re-authorization and accounting messages. Class AVPs found in a re-
authorization answer message override the ones found in any previous
authorization answer message.

Issue 38: Home should state whether the Destination-FQDN is present in follow-on messages
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: Base
Comment Type: Technical
Priority: 2
Section:
Rationale/Explanation of issue:
The current specification isn't clear on where a follow-on re-auth should be sent, and requires that the STR be sent to the Destination-FQDN of the authorizing server. In order to take advantage of implementations that have replicated, or clustered, servers, it would make sense for the auth response to include an AVP that states whether follow on messages for this session can be sent to any server within the realm, or to a particular server.

Proposed Text: http://www.merit.edu/mail.archives/aaa-wg/msg01218.html

Resolution: Accept proposed text, with minor grammatical changes

Issue 39: What does "Snd-Conn-Nack" Mean?
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 25-May-2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: 8.0
Proprietary Tag: C
Rationale/Explanation of issue:

R-Send-Conn-NACK assumes that the application has the ability to
refuse a connection before it is made.  The UNIX select doesn't
give this capability.  The application is not informed until after
the connection has been made.

Modify the Peer State Machine to not contain R-Snd-Conn-Nack.

Resolution: Replaced Snd-Conn-Nack with Disc.

Issue 40: Can an AVP Data have zero length?
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: Base
Comment Type: Editorial
Priority: S
Section: 4.3
Rationale/Explanation of issue:
The current base specification states that an AVP with zero data is
valid. The text reads:
"The Data field is zero or more octets and contains information
specific to the Attribute."
Resolution: Rejected. Zero octets is required for EAP.

Issue 41: 'M' bit clarification
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: Base
Comment Type: Editorial
Priority: S
Section: 4.1
Proprietary Tag: C
Rationale/Explanation of issue:
The current specification doesn't clearly state the cases of who is at fault when an AVP is received with the 'M' bit set and it is unrecognized.
Resolution: The base protocol will state the two cases where this could occur, and who is at fault in both cases.

Issue 42: Session-Timeout inconsistent with RADIUS spec
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 2001-06-05
Reference:
Document: NASREQ
Comment type: C
Priority: 1
Section: 3.1.2 and 4.2.2
Rationale/Explanation of issue:

At the Interim Meeting, Bernard stated that the use of Session-Timeout
in Diameter was inconsistent with RADIUS (RFC 2865). The only difference
that I can see is that in RADIUS, the Session-Timeout can be used in
an access-challenge (presumably to limit the amount of time a user can
respond). If this is the only change required, then the NASREQ AAA and
DEA commands would have to be updated.

Any other inconsistencies?

Issue 43: Requesting a non vendor-specific AVP Code as Specification Required
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: Base
Comment Type: Editorial
Priority: S
Section: 4.1
Proprietary Tag: C
Rationale/Explanation of issue:
The current base protocol states that AVP Code assignment requires designated expert, but this doesn't require a paper trail.
Resolution: The base protocol will state AVP codes assignment as Specification Required.

Issue 44: How does an implementation state it is compliant
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: Base
Comment Type: Editorial
Priority: S
Section: 4.1
Proprietary Tag: C
Rationale/Explanation of issue:
The specification requires that all servers support all implementations, but this seems unnecessary since this would increase the cost to the consumer, and limit certain products that only want to play in a given market segment.
Resolution: New language will be provided that will state that implementations that support a given extension can claim to be "Diameter NASREQ compliant" or "Diameter Mobile IP compliant", or both.

Issue 45: Allow for vendor-specific extensions
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: Base
Comment Type: Technical
Priority: S
Section: scattered in 6.0
Proprietary Tag: C
Rationale/Explanation of issue:
The base protocol doesn't allow for vendors to create their own extension, and must request that an extension number be assigned by IANA from the "standards" extension namespace.
Resolution: A new grouped AVP will be created to allow for vendor-specific extensions to be advertised.

Issue 46: Base protocol doesn't specify how to get Vendor Identifier
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: Base
Comment Type: Editorial
Priority: S
Section: 4.2
Rationale/Explanation of issue:
The base protocol doesn't specify how a vendor is to get a Vendor-Id assigned to it.
Resolution: the base protocol spec already states that vendor
identifiers are assigned via IANA.

Issue 47: Some AVPs in tables do not have 'V' bit as MUST NOT
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 24-May-2001
Reference:
Document: Base
Comment type: E
Priority: 1
Section: 4.5
Proprietary Tag: C
Rationale/Explanation of issue:

All AVPs defined will either be IETF or vendor specific.
In the current Drafts, everything is IETF. Hence the AVP
Flag 'V' should be in the MUST NOT column for all attributes.

Requested change:
Add the 'V' flag to the MUST NOT column.
Resolution: This will be done.

Issue 48: Destination-FQDN in re-auth Messages
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 25-May-2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

Note: The answer to this issue may be related to the answer for issue
26, "What to do if STR is sent to unavailable server" and issue 38,
"Home should state whether the Destination-FQDN is present in follow-on
messages"

* When a Diameter server re-authorizes, the Destination-FQDN
  is optional.

* There is no guidance as to how to use the Destination-FQDN.

* There are two types of authentication realms:
  Simple: A simple realm where the servers are ignorant of each other.
          Re-authorization MUST go to the same server.
  Linked: A linked realm where the servers are knowledgeable of each other.
          Re-authorization MAY go to any of the servers in that realm.

* There are two common causes of re-authorization
  Timeout: The Authorization-Lifetime may soon end and re-authorization
           is needed.
  Forced: A server sends a AA-Challenge-Ind

* So the Destination-FQDN will be set according to the following situations:
  Simple-Timeout: Re-authorization MUST go to the same server that
                  the previous authorization happened.
  Simple-Forced:  If the previous authorization server and the sender of the
                  Re-authorization are the same, send it to that server.
           If they are different, the re-authorization location
      has to be specified in the draft.
  Linked-Timeout: Either always use the Realm, or have a retry mechanism
    where it uses the previous authorization server and if
           that is unreachable, send to the Realm (no Destination-FQDN).
  Linked-Forced:  Combine Simple-Forced and Linked-Forced

* If you are using Destination-FQDN with re-authorization, and the server
  is down, do you send to the realm, assume Re-authorization was successful,
  or disconnect the user.

Requested Change:
 Option 1:
  * Only allow Re-authorization in Linked realms.
  * Destination-FQDN if used must be that of the server used for the most
    recent authentication.

  Something like this text should be added.

  If re-authorization is required by the server because of
  Authorization-Lifetime timeout or an AA-Challenge-Ind, all servers in
  the authorization realm (not just the one that did the authorization
  of that session) MUST be capable of re-authorization.  If the
  Destination-FQDN is included, it MUST contain the Origin-FQDN of the
  last server that authenticated the user.  If the request returns with
  the error DIAMETER_UNABLE_TO_DELIVER, the client MAY re-send the AAR
  without a Destination-FQDN.

 Option 2:
  * Assume realms are not linked.

  Something like this text should be added.

  Re-authorization MUST use as the Destination-FQDN the Origin-FQDN of
  the server that authenticated the session.  If the server is
  unreachable, the client MAY either assume authorization failure or
  success.  If success is assumed, a Diameter client SHOULD NOT expect
  payment for services rendered past the session expiration time.

 Option 3:
  * Expect ignorance, and allow for enlightenment.

  Something like this text should be added.

  Re-authorization MUST first use as the Destination-FQDN the
  Origin-FQDN of the server that previously authorized the session.  If
  the server is unreachable, the client MAY remove the Destination-FQDN
  and send the re-authorization request again.  The servers in the
  realm MAY handle a re-authorization request of a session that they
  did not authenticate in any way (for example database lookup, always
  fail, always succeed, or any other method).

 Option 4:
  * A combination of 2 and 3

  Something like this text should be added.

  Re-authorization MUST first use as the Destination-FQDN the
  Origin-FQDN of the server that previously authorized the session.  If
  the server is unreachable, the client MAY fail the authentication,
  pass the authentication, or remove the Destination-FQDN and send the
  re-authorization request again.  If success is assumed, a Diameter
  client SHOULD NOT expect payment for services rendered past the
  session expiration time.  If the request is sent again, servers in
  the realm MAY handle a re-authorization request of a session that
  they did not authenticate in any way (for example database lookup,
  always fail, always succeed, or any other method).

Proposed Text: http://www.merit.edu/mail.archives/aaa-wg/msg01218.html

Resolution: Accept proposed text, with minor grammatical changes

Issue 49: How to handle proxies that modify AVPs, and end-to-end security?
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: May 21, 20001
Reference:
Document: End-to-End
Comment Type: Editorial/Technical
Priority: S
Proprietary Tag: C
Section:
Rationale/Explanation of issue:
The end-to-end security specification doesn't discuss modifying proxies, and how E2E is handled through them.
Resolution: The decision is that a modifying proxy MUST NOT allow an ESSR to pass through it. If a proxy plans to modify any non-routing AVPs, it MUST reject any ESSR message passing through it with one of two new result codes. The first will state that the modifying proxy is willing to establish the ESSR with the requested peer on the requestor's behalf, and the second being that ESSR cannot be established through the modifying proxy. The decision was that as long as the access device knows that such proxies are in the network, and are honest about their intentions, the access device can make the appropriate decision on whether access will be provided or not.

Issue 50: Proxy Behavior
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: May 22, 20001
Reference:
Document: End-to-End
Comment Type: Editorial/Technical
Priority: S
Section:
Proprietary Tag: C
Rationale/Explanation of issue:
I'd note that pp. 10 of the aaa-issues-04 draft from November has an
action item to "properly define the terms proxy, broker, redirect server,
transparent and nontransparent proxy in the Diameter specifications and
describe how each type of device should function."

The current base draft defines "Proxy Server" as a routing proxy, and
re-direct is also defined, but other proxy types aren't. The proxy draft,
http://www.ietf.org/internet-drafts/draft-ietf-aaa-proxies-01.txt also
takes a shot at this, but the terminology is not consistent with the base
draft or the transport draft. So at a minimum we need to clean up the
terminology and definitions so that all drafts are consistent.

However, I think we should probably aim higher. The operation of proxies
is so basic that it is hard to understand the base spec without a mental
model of how they work. So I think that the proxy draft material needs to
be consolidated with the base Proxy material on pp. 59-61, and this should
probably be moved closer to the front of the base draft.

One interesting point made in the SIP spec is that types of proxy behavior
are situational, so that a proxy may act as a routing proxy for one type
of message, a re-direct for another, etc. I'm curious if this logical
applies to Diameter or not. This complicates the capabilities exchange
considerably, because it implies that a proxy's capabilities might vary
depending on the message type, destination realm, etc.

At various points in the base spec, it is hard for me to understand what
type of proxy is being referred to, or whether the text applies to *all*
proxy types as defined in the various drafts. Some examples:

1. pp. 21, base. "If such an AVP is received by a Proxy or Redirect
Server, the message MUST be forwarded to its logical destination and MUST
NOT be rejected." Do all proxy types defined in the proxy doc behave this
way, or just routing proxies? Might a policy proxy NOT forward such a
message?

2. pp. 27, base. "Proxies receiving messages that contain the
Destination-FQDN AVP MUST verify whether they are able to forward Diameter
messages to the host specified in the AVP, and if so, MUST forward the
message to the host in question." Again, do *all* proxy types behave this
way, or just routing proxies? Might a policy proxy not do this?

3. pp. 28, base. "A receiver of a DRI message which does not have any
extensions in common with the sender MUST return a DSI message to the
peer..." Would suggest we explicitly state how proxy types are expected to
behave with respect to a DRI message. It makes sense that a routing proxy
MUST advertise *, as would a re-direct. A policy proxy might not advertise
wildcard though, right? Is there ever a situation where a proxy might
implement different capabilities based on mesage type or the realm of the
request? So for mitton.com, proxy might handle MIP requests, but for
internaut.com I wouldn't ('cause he only paid for dialup)? Or is this
something I handle by not authorizing those types of access? Clarification
on the role of capabilities exchange versus authorization would be
helpful.

4. pp. 39. "An e2e error occurs when a Diameter entity sends a message and
either an intermediate proxy or the home server wishes to return a
failure." Term "intermediate proxy" is not defined in the glossary. Also,
I thought that e2e errors were removed based on discussion at IETF50.

5. pp. 44 "The Device-Status-Ind message MUST NOT be proxied, but MAY be
forwarded". If "proxy" means "routing proxy" as indicated in the glossary
you'd think these two actions would be equivalent. Obviously there is
some distinction here but it's not defined well, so it's hard to make out
what the difference is.

6. pp. 56. Section 11.1.1 talks about the realm-based routing table. Table
entries include Domain Name, Extension Identifier, Action. Making
forwarding decisions based on extension seems complicated to me, and I'd
prefer to do away with it if possible. I would assume that
re-directs and routing proxies always have wildcard in the extension
identifier, but they still need to track the extensions of their
downstream neighbors, right? This is one of the reasons why having a
server support all extensions would simplify things.

7. On pp. 57 it says "the local server MAY apply its local
policies to the message by including new AVPs prior to forwarding". This
doesn't seem like routing proxy behavior, more like a policy proxy, right?

8. pp. 57 "a message that does not contain any of the above AVPs MUST NOT
be routed". Not clear about the distinction been forwarding and routing
used here. Is this distinct from forwarding and proxying, and if so what
operations does routing include?

9. pp. 59. This section talks about behavior of stateless and stateful
proxies. I think that more detail on behavior of these types is needed
up front. Given that a stateful proxy maintains session
state, I think that more explicit guidance is needed on how this is done
in the face of reboot indications, network partitions, etc. It's not an
easy problem.

Resolution: The fixes can be found at http://www.merit.edu/mail.archives/aaa-wg/msg01012.html.

Issue 51: EAP Roundtrips
Submitter name: Henry Haverinen
Submitter email address: henry.haverinen@nokia.com
Date first submitted: 2001-05-25
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00974.html
Document: 
Comment type: T
Priority: 2
Section: 4.0, 4.2.1, 4.2.2
Rationale/Explanation of issue:

This issue is an optimization. In some EAP types, the last EAP-Response
from the authenticating peer to the Diameter server is just an
aknowledgement that doesn't contain any actual data. In these cases,
one NAS-AAA-NAS roundtrip can be saved if the AAA server is able to
indicate successful authentication in the Diameter command that
contains the last EAP-Request.

Requested change:

Section 4.0 on page 20 reads:
If the Result-Code AVP indicates success,
the EAP-Payload AVP MUST encapsulate an EAP-Success [25] payload,
and the NAS SHOULD successfully terminate the PPP authentication
phase.

Please replace that with:
If the Result-Code AVP indicates success, the EAP-Payload AVP MUST
encapsulate an EAP-Success or an EAP-Request [25] payload, and the
NAS SHOULD successfully terminate the PPP authentication phase.
Even if the payload encapsulates an EAP-Request, the authentication
has been successful. In these cases, the NAS successfully terminates
the PPP authentication phase by first sending the encapsulated
EAP-Request
to the authenticating peer. Then on receipt of the corresponding
EAP-Response,
the NAS SHOULD send an EAP-Success to the authenticating peer.
The NAS MUST NOT send the last EAP-Response to the Diameter server
but it MUST discard the EAP-Response.

Please add a new item in the list of Section 4.2.1:

5) A Diameter-EAP-Answer containing an EAP-Request encapsulated
within an EAP-Payload and a Result-Code indicating success.

Please include EAP-Request in the explanations of the first paragraph
of Section 4.2.2. Like this:

The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code
field set to 268 and the 'A' bit set in the message flags field, is
sent by the Diameter server to the client to indicate either a
successful or failed authentication. The Diameter-EAP-Answer message
SHOULD include an EAP payload of type EAP-Success, EAP-Request or
EAP-Failure encapsulated within an EAP-Payload AVP. The Result-Code AVP
MUST indicate a failure if the EAP-Failure payload is present, while the
AVP MUST indicate success if the EAP-Success or the EAP-Request payload
is present.

Issue 52: Multi-roundtrip Mobile IP authentication
Submitter name: Henry Haverinen
Submitter email address: henry.haverinen@nokia.com
Date first submitted: 2001-05-25
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00972.html
Document: 
Comment type: T
Priority: 1
Section: 2.2
Proprietary Tag: C
Rationale/Explanation of issue:

Some authentication mechanisms may take more than one
roundtrip to authenticate and authorize the user. An example
of such a mechanism is draft-haverinen-mobileip-gsmsim-02.txt,
but there may be others.
This is not supported in the current Diameter Mobile IP draft.

Requested change:
 

These mechanisms can easily be supported in the Diameter Mobile IP
draft if an unsuccessful AMA message can be used to convey authentication
data to the MN in a key distribution extension. So please
include the following text in Section 2.2:

An unsuccessful AMA message MAY include mobile node registration
key AVPs (Section 7.1) such as the MIP-MN-to-FA-Key AVP and
the MIP-MN-to-HA-Key AVP. If such an AVP is present in the AMA message,
then the foreign agent MUST include the corresponding Mobile IP key
distribution extension in the Registration Reply it sends to
the mobile node. This is to support multi-roundtrip authentication
mechanisms.

In addition, please include MIP-MN-to-FA-Key AVP in the
AA-Mobile-Node-Answer message format definition.

Resolution: I have added the following text to section 2.2:
" An AMA message with the Result-Code set to DIAMETER_ERROR_MULTI_ROUND_AUTH
MAY include mobile node registration key AVPs (see Section 6.1) such as
the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP
is present in the AMA message, the foreign agent MUST include the
corresponding Mobile IP key distribution extension in the Registration
Reply it sends to the mobile node. This is to support multi-roundtrip
authentication mechanisms. "

Proposed Text:http://www.merit.edu/mail.archives/aaa-wg/msg01066.html

Issue 53: What if the AAAL cannot reach the HA?
Submitter name: Henry Haverinen
Submitter email address: henry.haverinen@nokia.com
Date first submitted: 2001-05-25
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00972.html
Document: 
Comment type: T
Priority: 1
Section: 2.2
Rationale/Explanation of issue:

The AAAL may not be able to reach the home agent the mobile
node is using even if it was able to reach the AAAH. This may occur
for example if the home agent was allocated from a previously visited
network, or if the mobile node is authenticated and authorized using
a local gateway to a back end AAA server (see draft-haverinen-
mobileip-gsmsim-02.txt for an example). In these cases, the foreign
agent needs to forward the Registration Request to the home agent
itself.

Requested change:

Section 2.2 currently says: "A successful AMA message MUST include
the MIP-Home-Agent-Address, MIP-Home-Mobile-Node-Address AVP and
MIP-Reg-Reply AVPs." Please remove the MIP-Reg-Reply AVP from the list.
In addition, please include the following text in Section 2.2:

The AAAL may not always be able to reach the home agent even if was able
to authenticate and authorize the mobile node. Therefore, if a successful
AMA message does not include the MIP-Reg-Reply AVP, then then the foreign
agent MUST relay the Registration Request in question to the home agent
itself. An AMA message can only be successful and not include
the MIP-Reg-Reply AVP if the Registration Request includes a Home Agent
address and a Mobile-Home Authentication Extension. As required in
[MIPv4 base document], the foreign agent must remove any Extensions
following the Mobile-Home Authentication Extension before relaying
the Request to the home agent.

Issue 54: Replace the term extension to application
Submitter name: Pat Calhoun (via Randy Bush)
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 2001-05-29
Reference:
Document: All
Comment type: C
Priority: 1
Section:
Rationale/Explanation of issue:

The IESG has stated that they are concerned with the term extension,
and would prefer that the term application be used instead.

Requested change:

Make the necessary terminology changes throughout the specs.

Issue 55: Server-initiated re-auth
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: June 01, 2001
Reference:
Document: All
Comment type: C
Priority: 1
Section:
Rationale/Explanation of issue:

In the process of fixing Issue #32, the Indication messages have been removed from
the NASREQ extension. However, the specification also makes use of the indication
messages to allow a server to send an unsolicited request for re-auth.

Is this feature required? If so, is it specific to NASREQ, or could it be generalized
and defined in the base protocol specification?

Three options:
1. Delete the feature
2. Create a new message set in the nasreq specification that is sent by
a server to request that a user be re-auth.
3. Create a new message set in the base protocol that is sent by
a server to request that a user be re-auth.

Issue 56: Flag bit for start of conversation
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 30-May-2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

For use in load balancing, it can be important to easily discern
whether a request constitutes the beginning of a conversation or not.
For example, if EAP is in use, there could be many requests within a given
conversation, and if the request were to be sent to another server in
the middle, ongoing conversations could fail. It does not appear to me
that any of the existing flag bits can be used to determine this.

Requested change:
Addition of Flag bit to denote "start of conversation".

Additional Comments: It appears this feature is already supported
since a message that is bound for a particular server would already
include the Destination-Host AVP.

Resolution: Accept text proposed in http://www.merit.edu/mail.archives/aaa-wg/msg01212.html

Issue 57: Accounting-Record-Type and clarification
Submitter name: Jari Arkko (originally Yolanda Garcia-Serrano)
Submitter email address: jari.arkko@ericsson.fi
Date first submitted: 16-May-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00256.html
Document: Base
Comment type: C
Priority: 2
Section: 12.5
Rationale/Explanation of issue:

The current draft version seems to have unclarity with respect to the
use of the same session identity in several records, and the use of
different Accounting-Record-Types over the same session. This needs
to be clarified.

Requested change:

At the end of section 12.5, add the following text:

A particular value of Accounting-Session-Id MUST appear only
in one sequence of accounting records from a DIAMETER client,
except for the purposes of retransmission. Note that sometimes such
sequence of records is related to a higher-level session, possibly
spanning several DIAMETER clients. The linking of such record
sequences together MUST be performed using the Accounting-Multi-
Session-Id AVP. The extensions document MUST define
the exact concept of a session that is being accounted, and MAY
define the concept of a multi-session. For instance, the NASREQ
DIAMETER extension treats a single PPP connection to a
Network Access Server as one session, and a set of Multilink PPP
sessions as one multi-session.

The one sequence that is sent MUST be either one record with
Accounting-Record-Type AVP set to the value EVENT_RECORD,
or several records starting with one having the value
START_RECORD, followed by zero or more
INTERIM_RECORD, and a single STOP_RECORD. A
particular extensions document MUST define which kind of
sequences should be used for the particular application.

Resolution: accept the following text in section 11.5:
A particular value of Accounting-Session-Id MUST appear only in one
sequence of accounting records from a DIAMETER client, except for the
purposes of retransmission. The one sequence that is sent MUST be
either one record with Accounting-Record-Type AVP set to the value
EVENT_RECORD, or several records starting with one having the value
START_RECORD, followed by zero or more INTERIM_RECORD, and a single
STOP_RECORD. A particular Diameter application specification MUST
define the type of sequences that MUST be used.

and the following text added at the end of section 11.6:
A Diameter application document MUST define the exact concept of a
session that is being accounted, and MAY define the concept of a
multi-session. For instance, the NASREQ DIAMETER application treats a
single PPP connection to a Network Access Server as one session, and
a set of Multilink PPP sessions as one multi-session.

Issue 58: e2e draft essr/essa delay
Submitter name: Jari Arkko
Submitter email address: jari.arkko@ericsson.fi
Date first submitted: 17-May-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html
Document: e2e
Comment type: Technical
Priority: 1
Section: -
Rationale/Explanation of issue:

- 3.1, the ESSR&ESSA scheme: here I think lies
an issue that we should discuss in-depth and
make sure we make the right design choice for
DIAMETER. The way that the spec is written now,
it basically requires all DIAMETER nodes to
initiate the ESSR&ESSA handshake for all
new domains. Nodes that do not support e2e
will not be able to do this. Nodes that do
support e2e are forced to an additional roundtrip
delay even in the case that e2e wasn't really
necessary for the domain.

One way to deal with these kinds of situations is to
use an optimistic mechanisms which naks the use of
unsecured messages when e2e is required. However,
the drawback of that is that potentially some data
has already been revealed. But has it? It is hard
for me to see exactly what sensitive information
the first DIAMETER message versus the later ones
have... this may need further analysis. I also lack
a proposal how to handle the mixed security case
with the currently proposed ESSR&ESSA scheme,
i.e. who is responsible for doing the probing,
and what support is mandated for which nodes.

- The caching of ESSR&ESSA information isn't
discussed. Shouldn't it be?

- 5,0, the flow: what happens if the DRIs from the
proxy onwards indicated that e2e security is not
supported? Will the proxy return back a lower
level DIAMETER error, or a fake ESSA with an error
code?

Resolution: No concensus was found on this issue. An update can be
found at http://www.merit.edu/mail.archives/aaa-wg/msg01213.html

Issue 59: e2e mandatory status
Submitter name: Jari Arkko
Submitter email address: jari.arkko@ericsson.fi
Date first submitted: 17-May-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html
Document: e2e
Comment type: Technical
Priority: 1
Section: -
Rationale/Explanation of issue:

- Before Figure 3, you talk about the expensive
transformations and the need to have a mixed
security model in some cases. I agree, but
shouldn't we consider this also in the discussion
of where e2e extension is mandatory? I.e. not
make it a must for NASes...

Issue 60: e2e draft cert names
Submitter name: Jari Arkko
Submitter email address: jari.arkko@ericsson.fi
Date first submitted: 17-May-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html
Document: e2e
Comment type: Technical
Priority: 3
Section: -
Rationale/Explanation of issue:

- 3.1, the rfc822Address scheme: can we clarify the
reason why the host name must take a special form?
Is it because the CA might be the CA also for
other nodes, but we want only a subset of nodes
to be authorized to do DIAMETER. In other words,
we are using the name field as a poor man's
attribute certificate? I'm fine with it, just
want to know...

Issue 61: e2e cms and pki profiling
Submitter name: Jari Arkko
Submitter email address: jari.arkko@ericsson.fi
Date first submitted: 17-May-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html
Document: e2e
Comment type: Technical
Priority: 2
Section: -
Rationale/Explanation of issue:

- 3.2, I think it would be valuable indeed to
specify a more limited profile of both the
PKI and CMS parts! In my opinion this work
should perhaps take place now, before we
publish the DIAMETER RFCs... one way to do
this is to list exactly what is really required
from CMS for instance... my guess is that
we actually do need only a small fraction of
CMS and not all variants of encapsulations.

- 6.1, the S/MIME profile reuse. Doesn't this limit
the CMS to a fairly small subset? I lack sufficient
knowledge of the S/MIME & CMS details to say whether
something relevant is taken away, but perhaps you
would care to comment on this? Note that I *do*
want a small subset, but am just wondering if the
s/mime subset is the one that we want.

- 6.1 and 6.2, the CMS object ContentInfo. May I
suggest that we explicitly state here which one
of the various alternative ContentInfo representations
should be used? Perhaps we need just a single one,
which would simplify implementation and analysis.

- The protocol provides support (although as a MAY?)
for both CRLs and OCSP. Perhaps one would be enough.
Or maybe we should go even further and state that
if you want online or crl functionality, you must
provide these outside DIAMETER...

Issue 62: e2e unnecessary step via pkcs7-mime
Submitter name: Jari Arkko
Submitter email address: jari.arkko@ericsson.fi
Date first submitted: 17-May-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html
Document: e2e
Comment type: Technical
Priority: 2
Section: -
Rationale/Explanation of issue:

- In 6.1 you mention the signing of an encrypted
AVP to be done through the MIME type application/
pkcs7-mime. Is this really necessary, and doesn't
it introduce an unnecessary temporary (and large)
object creation? We couldn't we just state that the
signature applies to the BER result?

Issue 63: e2e unverified certs
Submitter name: Jari Arkko
Submitter email address: jari.arkko@ericsson.fi
Date first submitted: 17-May-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html
Document: e2e
Comment type: Technical
Priority: 2
Section: -
Rationale/Explanation of issue:

- I'm wondering about the SHOULD NOT in the
use of the PKI certs before they have been
verified. I also see the note later in the
doc. But nowhere you state what such other
mechanisms might be! I really wonder why
we need to do PKI schemes and then not use
them... if these special cases don't need
strong security, couldn't they live with
hop-by-hop security?

Resolution: The statement has been removed from the CMS draft.

Issue 64: e2e draft editorial issues
Submitter name: Jari Arkko
Submitter email address: jari.arkko@ericsson.fi
Date first submitted: 17-May-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00272.html
Document: e2e
Comment type: Editorial
Priority: 3
Section: -
Rationale/Explanation of issue:

- 1.0: "IPSec" => "IPsec" (elsewhere correct)

- Abstract refers to non-repudiation. I seem to
remember many discussions on the exact meaning
of non-repudiation, perhaps it would make sense
to change the text to be more specific. Like
this: "..., for making it possible to prove
the real sender of the data."

- Figure 1, maybe the example should number the
servers DIA1, DIA2, and DIA3.

- 1.2: I don't understand why a node that supports
e2e would not advertise this. Why not?

- 3.1: "digial" => "digital"

- 3.4, I would expect that the number of AVP
encryptions one can do with the same symmetric
key is fairly high, more like hours of use
rather than minutes or few sessions. Also,
perhaps the document would benefit from stating
that the symmetric key optimization isn't possible
for the signatures if non-repudiation is desires.
(Right?)

- I suppose for the example's sake you're only
signing NAS->home and only encrypting Home->NAS?
But still both are possible on both directions,
right?

- 6.5, I think it is better to keep the OCSP-desire
and the nonce together.

- 6.8, I think we should just drop the top CA
since that cert must be known by the initiator
anyway.

- Reference [4]: dash might be in the wrong place.

Issue 65: OctetString with NULL value
Submitter name: Paul Funk
Submitter email address: paul@funk.com
Date first submitted: May, 20001
Reference:
Document: Base
Comment Type: Technical
Priority: 2
Section: 4.3
Rationale/Explanation of issue:

The base draft calls for the value of an OctetString to be at least one
octet long (9 or 13 octets in entire AVP). This conflicts with the NASREQ
requirement for a NULL EAP-Payload to signify EAP-Start.

Either we must change NASREQ or we must change the definition of
OctetString.

Requested change:

Note that RADIUS also uses an empty EAP-Message attribute to signify
EAP-Start, and it would be wise to preserve that mechanism.

Presumably, the motivation for requiring at least one data octet is the
notion that if the value were empty the AVP shouldn't be present at all.
But there is clearly a use for a distinction between empty AVPs vs.
absent AVPs, as evidenced by EAP-Start.

I suggest we allow OctetString to have 0-length values, and say that
the AVP length must be at least 8 or 12.

Resolution: Being discussed

Issue 66: Server Discovery Text to change
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 2001-06-05
Reference:
Document: Base
Comment type: C
Priority: 1
Section: 2.6
Rationale/Explanation of issue:

At the Interim Meeting, Bernard stated that we should adopt the
procedures described in draft-ietf-sip-srv-02.txt.

Requested change:

I am not sure what Bernard had in mind. Should we replace the whole
section, including the proposal to use SLPv2, and just use the DNS SRV
proposed in the above draft, or just replace the one section that deals
with DNS SRVs?

Issue 67: How to deal with CER and CEA in the case of SCTP
Submitter name: Tony Johansson
Submitter email address: tony.johansson@ericsson.com
Date first submitted: 2001-06-06
Reference:
Document: Base
Comment type: T
Priority: 1
Section: 8.0
Rationale/Explanation of issue:

The text defined in 8.0 is obviously based on the TCP case (even though
its not explicitly stated) and there is no case described that covers
the SCTP case.

So, when we now have changed the DRI to CER and CEA, who will issue the
CER in the SCTP case? To my understanding, the SCTP protocol can't tell
the upper layer, which one of the the peers that first initiated the
connection request in the case that both peers issued a connection
establishment request almost at the same time. The SCTP protocol is a
peer-to-peer protocol, so this type of issue is resolved by various
mechanisms in the SCTP protocol itself. The upper layer is guaranteed to
always get one connection between the peers. So the I-connection and
R-connection, which are need in the TCP case doesn't make sense for SCTP
case and the problem right now is that the CER and CEA is based on the
I-xx and R-xx (which is determined from indications from the TCP
transport layer).

IMHO, I suggest that we go back and use something like the DRI. Because
as soon as we have one single transport connection established it
doesn't really matter, which peer that issues its capability exchange
message first. This would make the capability exchange flow independent
from specific indications from the transport layer which may or may not
be present depending on the transport layer in use.

Issue 68: Address Name and 20 byte IPV6 length
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 06-Jun-2001
Reference: http://www.ietf.org/rfc/rfc2851.txt
Document: Base
Comment type: T
Priority: 2
Section: 4.3 AVP Data Formats
Rationale/Explanation of issue:

Juergen Schoenwaelder suggested that we may want
to look into two related issues for the Address data format.

1. We may want to change the name to IpAddress to make it clearer
that this is restricted to IP addresses.

2. RFC 2851 also has a 20 byte IPv6 addresses. We may consider allowing
a 20 byte address.

Both of these issues need to be at least addressed (no pun intended)
on the mailing list.

Requested change:

1. I don't care either way if it is Address or IpAddress. I would
suggest it be IPAddress (capital P) if it is changed. This is
just because if we are capitalizing first letters of words,
I consider acronyms to be multiple words.

2. As far as I can tell, the extra four bytes in the 20 byte IPv6
address is to identify which interface the address is associated
with if more than one interface has an address. Since we never
did this for RADIUS and IPv4, I don't suggest we do it for IPv6.

Resolution: Accept sub-issue #1, but sub-issue #2 is denied. NASREQ
already has this functionality, and requires a new AVP to contain the
Interface identifier.

Issue 69: ABNF editorial changes
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 06-Jun-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01150.html
Document: Base
Comment type: E
Priority: 2
Section: 3.2 Command code ABNF specification
Rationale/Explanation of issue:
- "fixed" isn't defined. It seems to mean that it is required, but at a
specific position or in a specific order, but that's really unclear.
- the defaults for min & max in qual are not defined if only one of them is
present (i.e. no qual = 1*1, but what about *n or n*? I guess the latter
means n*infinity, but does *n mean 1*n or 0*n)?
- it says that it describes AVPs which MUST NOT be present, but that's not
part of the ABNF (it's implicit).

Requested change:

[add following text under definition of fixed]
; defines AVPs the position and order of which is fixed,
; either at the start or at the AVP list

[add following text under definition of min and associated comments]
; default is 0

[add following text under definition of max and associated comments]
; default is infinity

for resolution of the MUST NOT issue, either:
- replace MUST, MAY or MUST NOT by MUST or MAY in first paragraph
- add a specific notation:
forbidden = "%" avp-spec "%"
- or add text under qual:
; 0*0 means the AVP is not allowed in this command

Issue 70: Caching of redirects
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 06-Jun-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01150.html
Document: Base
Comment type: T
Priority: 2
Section: 2.5.3 Redirector Agents
Rationale/Explanation of issue:
jc> Can a server that received a redirect cache the result (e.g. based on
realm+application)?

pc> yes, and this should probably be discussed in the base draft.

jc> additional info: what should be the key for the cache?
realm+application only? What if the redirect was based on some other
information? What if the redirector acts as a load balancer? I'm personally
against caching (unless the redirector explicitly allows it maybe?). If
caching is allowed, there should be guidelines for expiration.

Requested change:
Text to be added for clarification.

Issue 71: Various editorial changes
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 11-Jun-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01150.html
Document: Base
Comment type: E
Priority: 2
Section: throughout
Rationale/Explanation of issue:

In 4.1 AVP Header:
- still mentions both 'r' and reserved bits
- says that unrecognized bits should be considered an error, but also that
r/reserved bits should be ignored.

In 4.3 AVP Data formats, max length of an OctetString is still 65504 (btw,
why was it 65504 and not 2^16-20=65516?)

In 5.1 Processing Local Messages, "the local host's identity is encoded in
the Origin-Host and Origin-Host AVPs" (double Origin-Host)

In 5.3 Message Routing, Diameter agents *MAY* have a list of locally
supported realms...

In 6.0, 6.1, minor editing.

In 7.2, remove unused RTO stuff.

Requested changes:

In 4.1, replace:
AVP Flags
The AVP Flags field informs the receiver how each attribute must
be handled. Note that subsequent Diameter applications MAY define
bits to be used within the AVP Header, and an unrecognized bit
should be considered an error. The 'r' and the reserved bits are
unused and should be set to 0 and ignored on receipt, while the
'P' bit is defined in [11].

With:
AVP Flags
The AVP Flags field informs the receiver how each attribute must
be handled. The 'r' (reserved) bits are unused and SHOULD be set
to 0. Note that subsequent Diameter applications MAY define
additional bits within the AVP Header, and an unrecognized bit
SHOULD be considered an error. The 'P' bit is defined in [11].

In 4.3, replace:
OctetString
The data contains arbitrary data of variable length. Unless
otherwise noted, the AVP Length field MUST be set to at least 8
(12 if the 'V' bit is enabled). Data used to transmit (human
readable) character string data uses the UTF-8 [24] character
set and is NOT NULL-terminated. The minimum Length field MUST
be 9, but can be set to any value up to 65504 bytes. AVP Values
of this type that do not align on a 32-bit boundary MUST have
the necessary padding.

With:
OctetString
The data contains arbitrary data of variable length. Unless
otherwise noted, the AVP Length field MUST be set to at least 8
(12 if the 'V' bit is enabled). Data used to transmit (human
readable) character string data uses the UTF-8 [24] character
set and is NOT NULL-terminated. The minimum Length field MUST
be 9, but can be set to any value up to 2^24-20=16777196 bytes.
AVP Values of this type that do not align on a 32-bit boundary
MUST have the necessary padding.

In 5.1, replace:
- The local host's identity is encoded in the Origin-Host and
Origin-Host AVPs.

With:
- The local host's identity is encoded in the Origin-Host AVPs.

In 5.3, replace:
Diameter agents have a list of locally supported realms, and MAY have
a list of externally supported realms. When a request is received
that includes a realm that is not locally supported, the message is
routed to the peer configured in the Domain Routing Table table (see
section 5.3.1).

With:
Diameter agents MAY have a list of locally supported realms, and MAY
have a list of externally supported realms. When a request is
received that includes a realm that is not locally supported, the
message is routed to the peer configured in the Domain Routing Table
table (see section 5.3.1).

In 6.0 Capabilities Exchange, replace:
When two Diameter peers establish a transport connection, they MUST
exchange the Device Reboot messages, as specified in the peer state
machine (see section 8.0). This message has two purposes. First it
allows a peer's identity to be discovered, and allows for
capabilities exchange, such as the supported protocol version number,
the locally supported Diameter applications, etc.

With:
When two Diameter peers establish a transport connection, they MUST
exchange the Capabilities Exchange messages, as specified in the peer
state machine (see section 8.0). This message allows the discovery of
both the peer's identity, and its capabilities, such as the supported
protocol version number, the locally supported Diameter applications,
etc.

In 6.1 Application Identifiers, replace:
Relay and redirect agents MUST advertise the Proxy application
identifier, while all other Diameter nodes MUST advertise locally
supported applications. The receiver of a Device Reboot message
advertising Relay service MUST assume that the sender supports all
current and future applications.

with:
Relay and redirect agents MUST advertise the Relay application
identifier, while all other Diameter nodes MUST advertise locally
supported applications. The receiver of a Capabilities Exchange
message advertising Relay service MUST assume that the sender
supports all current and future applications.

In 7.2 Device-Watchdog-Answer, remove:
A receiver of the DWA SHOULD
perform RTT calculation in the event that the transport RTO
information is not available.

Resolution: Accept proposed fixes

Issue 72: Downstream/upstream confusion
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 11-Jun-2001
Reference:
Document: Base
Comment type: E
Priority: 1
Section: throughout
Rationale/Explanation of issue:

The terms "upstream" and "downstream" are not used consistently. Even the
definitions seem contrary to logic: things usually flow from upstream to
downstream, so upstream should be towards the client, and downstream
towards the home server.

Requested changes:

In 1.3 Terminology, replace:
Downstream Server
Diameter Proxy servers identify a downstream server as one that is
providing routing services towards the Diameter client.

with:
Downstream Server
Diameter Proxy servers identify a downstream server as one that is
providing routing services towards the home server for a
particular message.

and replace:
Upstream Server
Diameter Proxy servers identify an upstream server as one that is
providing routing services towards the home server for a
particular message.

with:
Upstream Server
Diameter Proxy servers identify an upstream server as one that is
providing routing services towards the Diameter client.

In 2.5.2 Proxy Agents, replace:
Similarly to Relays, Proxy agents route Diameter messages using the
Diameter Routing Table. However, they differ since they modify
messages to implement policy enforcement. This requires that proxies
maintain the state of their downstream peers (e.g. access devices) to
enforce resource usage, provide admission control, and provisioning.

with:
Similarly to Relays, Proxy agents route Diameter messages using the
Diameter Routing Table. However, they differ since they modify
messages to implement policy enforcement. This requires that proxies
maintain the state of their upstream peers (e.g. access devices) to
enforce resource usage, provide admission control, and provisioning.

In 6.0 Capabilities Exchange, replace:
Since the CER/CEA messages cannot be proxied, it is still possible
that an upstream proxy receives a message for which it has no
available peers to handle the application that corresponds to the
Command-Code. In such instances, the Message-Reject-Answer message is
used (see Section 9.2.1) to inform the downstream to take action
(e.g. re-routing request to an alternate peer).

With:
Since the CER/CEA messages cannot be proxied, it is still possible
that a downstream proxy receives a message for which it has no
available peers to handle the application that corresponds to the
Command-Code. In such instances, the Message-Reject-Answer message is
used (see Section 9.2.1) to inform the upstream to take action
(e.g. re-routing request to an alternate peer).

In 9.0, Error Handling, replace:
Figure 4 provides an example of a message forwarded upstream by a
Diameter relay. When the message is received by Relay 2, and it
detects that it cannot forward the request to the home server, an MRA
message is returned with the Result-Code AVP set to
DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the
protocol error category, Relay 1 would take special action, and given
the error, attempt to route the message through its alternate Relay
3.

with:
Figure 4 provides an example of a message forwarded downstream by a
Diameter relay. When the message is received by Relay 2, and it
detects that it cannot forward the request to the home server, an MRA
message is returned with the Result-Code AVP set to
DIAMETER_UNABLE_TO_DELIVER. Given that this error falls within the
protocol error category, Relay 1 would take special action, and given
the error, attempt to route the message through its alternate Relay
3.

Alternatively, leave the definitions as they are (though I don't understand
them?) and fix down/upstream in 6.2 and 10.10.

Resolution: Fixed up text in 6.1 and 10.10 to ensure that the
terms are used consistently in the document.

Issue 73: Request & answer routing clarification
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 11-Jun-2001
Reference:
Document: Base
Comment type: E
Priority: 2
Section: throughout 5.x
Rationale/Explanation of issue:

It is necessary to clarify the use of Destination-Realm & Destination-Host
in Request routing.

If I finally got it right, Destination-Host is used only to target a
specific host within a number of servers serving a given realm. This is
achieved by sending to that host when said host is in the peer table,
otherwise Destination-Realm is used. When reading the draft, it looks like
it is used to talk directly from the client to the specified server.

Should be described early in 5.0, not be spread over 5.0, 5.1, 5.2.

This is also somewhat linked to the proposed text for issue 56 (flag bit
for start of conversation).

It is also necessary to clarify the following points for answer routing:
- it is completely different from request routing
- no Destination-Realm should be present

Other misc. changes:
- add default routing table entry description.
- change "Domain" to "Realm"
- clarify actions on origination and sending of message, including saving
pending requests

Requested change:

Sorry, a bit long. The important changes are:
- added overview in 5.1, with 3 cases for Destination-Realm & Destination-Host
- added sections 5.1.1 & 5.1.2 about originated and sending a request
- separated request (5.1.x) and answer (5.2.x) processing & routing
- used "request" rather than message where it is needed to clarify things
- moved answer generation to 5.2
- changed "domain" to "realm" in routing table
- added default routing table entry discussion

The rest is mainly renumbering and moving stuff around.

Replace sections 5.0 to 5.3.5 with:

5.0 Diameter message processing

This section describes how Diameter requests and answers are created
and processed.

5.1 Diameter request routing overview

A request is sent towards its final destination using a combination
of the Destination-Realm and Destination-Host AVPs, in one of these
three combinations:
- a request that is not proxiable (such as CER) MUST NOT contain
either Destination-Realm or Destination-Host AVPs.
- a request that needs to be sent to a home server serving a
specific realm, but not to a specific server (such as the first
request of a series of round-trips), MUST contain a
Destination-Realm AVP, but MUST NOT contain a Destination-Host
AVP.
- a request that needs to be sent to a specific home server among
those serving a given realm, MUST contain both the
Destination-Realm and Destination-Host AVPs.

The Destination-Host AVP is used as described above when the
destination of the request is fixed, which includes:
- Authentication requests that span multiple round trips
- A Diameter request that uses a security mechanism that makes use
of a pre-established session key shared between the source and
the final destination of the request.
- Server initiated requests that MUST be received by a specific
Diameter client (e.g. access device), such as the Abort-
Session-Request message, which is used to request that a
particular user's session be terminated.

Note that an agent can forward a request to a host described in the
Destination-Host AVP only if said host is included in its peer table
(see sections 5.1.4 and 5.1.5). Otherwise, the request is routed
based on the Destination-Realm only (see sections 5.1.6 and 5.1.7).

The Destination-Realm AVP MUST be present if the request is routable.
A request that MUST NOT be relayed, proxied or redirected MUST NOT
include the Destination-Realm in its ABNF. The value of the
Destination-Realm AVP MAY be extracted from the User-Name AVP, or
other application-specific methods.

When a request is received, the message is processed in the following
order:
1. If the request is destined for the local host, the procedures
listed in section 5.1.1 are followed.
2. If the request is intended for a Diameter peer with whom the
local host is able to directly communicate with, the procedures
listed in section 5.1.2 are followed. This is known as Message
Forwarding.
3. The procedures listed in section 5.1.4 are followed, which is
known as Message Routing.
4. If none of the above are successful, an answer is returned with
the Result-Code set to DIAMETER_UNABLE_TO_DELIVER.

Note the processing rules contained in this section are intended to
be used as general guidelines to Diameter developers. Certain
implementations MAY use different methods than the ones described
here, and still be in compliance with the protocol specification.


5.1.1 Originating a Request

When creating a request, on top of any other procedures described in
the application definition for that specific request, the following
procedures MUST be followed:
- the Command-Code should be set to the appropriate value
- the 'R' bit should be set
- the End-to-End Identifier should be set to a locally unique
value
- the Origin-Host and Origin-Realm AVPs MUST be set to the
appropriate values, used to identify the source of the message
- the Destination-Host and Destination-Realm AVPs MUST be set to
the appropriate values as described in section 5.1.


5.1.2 Sending a Request

When sending a request, either originated locally, or as the result
of a forwarding or routing operation, the following procedures MUST
be followed:
- the Hop-by-Hop Identifier should be set to a locally unique
value
- the message should be saved in the list of pending requests

Other actions to perform on the message based on the particular role
the agent is playing are described in the following sections.


5.1.3 Processing Local Requests

A request is known to be for local comsumption when one of the
following conditions occur:
- The Destination-Host AVP contains the local host's identity,
- The Destination-Host AVP is not present, the Destination-Realm
AVP contains a realm the server is configured to process
locally, and the Diameter application is locally supported, or
- The Destination-Realm AVP is not present.

When a request is locally processed, the rules in section 5.2 should
be used to generate the associated answer.


5.1.4 Request Forwarding

Request forwarding is done using the Diameter Peer Table. The
Diameter peer table contains all of the peers that the local node is
able to directly communicate with.

When a request is received, and the host encoded in the Destination-
Host AVP is one that is present in the peer table, the message SHOULD
be forwarded to the peer.


5.1.5 Peer Table

The Diameter Peer Table is used in message forwarding, and referenced
by the Domain Routing Table. A Peer Table entry contains the
following fields:
- Host descriptor, as defined in section 2.7. This MAY be resolved
locally, or known via the CER or CEA message.
- TLS Enabled. Specifies whether TLS is to be used when
communicating with the peer.
- Security informations (keys, certificates...) as appropriate.


5.1.6 Request Routing

Diameter request message routing is done via realms. A Diameter
message that is proxyable MUST include the target realm in the
Destination-Realm AVP. The realm MAY be retrieved from the User-Name
AVP, which is in the form of a Network Access Identifier (NAI). The
realm portion of the NAI is inserted in the Destination-Realm AVP.

Diameter agents have a list of locally supported realms, and MAY have
a list of externally supported realms. When a request is received
that includes a realm that is not locally supported, the message is
routed to the peer configured in the Domain Routing Table table (see
following section).


5.1.7 Realm-Based Routing Table

All Realm-Based routing lookups are performed against what is
commonly known as the Realm Routing Table (see section 16.0). A
Realm Routing Table Entry contains the following fields:
- Realm Name. This is the field that is typically used as a
primary key in the routing table lookups. Note that some
implementations perform their lookups based on longest-match-
from-the-right on the realm rather than requiring an exact
match.
- Application Identifier. It is possible for a routing entry to
have a different destination based on the Acct-Application-Id
(for accounting messages) or Auth-Application-Id (for non-
accounting messages) of the message. This field is typically
used as a secondary key field in routing table lookups.
- Local Action. The Local Action field is used to identify how a
message should be treated. The following actions are supported:
1. LOCAL - Diameter messages that resolve to a routing entry
with the Local Action set to Local can be satisfied
locally, and do not need to be routed to another server.
2. RELAY - All Diameter messages that fall within this
category MUST be routed to a next hop server, without
modifying any non-routing AVPs. See section 5.1.9 for
relaying guidelines
3. PROXY - All Diameter messages that fall within this
category MUST be routed to a next hop server. The local
server MAY apply its local policies to the message by
including new AVPs to the message prior to routing. See
section 5.1.9 for relaying guidelines.
4. REDIRECT - Diameter messages that fall within this
category MUST have the identity of the home Diameter
server(s) appended, and returned to the sender of the
message. See section 5.1.8 for redirect guidelines.
- Server Identifier - One or more servers the message is to be
routed to. These servers MUST also be present in the Peer
table. When the Local Action is set to RELAY or PROXY, this
field contains the identity of the server(s) the message must be
routed to. When the Local Action field is set to REDIRECT, this
field contains the identity of one or more servers the message
should be redirected to.

It is important to note that Diameter agents MUST support at least
one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents
do not need to support all modes of operation in order to conform
with the protocol specification, but MUST follow the protocol
compliance guidelines in section 2.0. Relay agents MUST NOT reorder
AVPs, and proxies SHOULD NOT reorder AVPs.

The routing table MAY include a default entry which MUST be used for
any requests not matching any of the other entries. The routing table
MAY consist of only such an entry.

When a request is routed, the target server MUST have advertised the
Application Identifier (see section 6.1) for the given message, or
have advertised itself as a relay or proxy agent.


5.1.8 Redirecting requests

[... unchanged from 5.3.2 in current draft ...]

5.1.9 Relaying and Proxying Requests

[... unchanged from 5.3.3 in current draft ...]

5.2 Diameter Answer Processing

When an request is locally processed, the following procedures MUST
be applied to create the associated answer, in addition to any
additional procedures that MAY be discussed in the Diameter
application defining the command:

- The same Hop-by-Hop identifier in the request is used in the
answer.
- The local host's identity is encoded in the Origin-Host AVP.
- The value of the Origin-Host AVP in the request is included in
the answer's Destination-Host AVP.
- There MUST NOT be any Destination-Realm AVP present in the
answer.
- The Result-Code AVP is added with its value indicating success
or failure.
- If the Session-Id is present in the request, it MUST be included
in the answer.
- Any Route-Record or Proxy-Info AVPs in the request MUST be added
to the answer message, in the same order they were present in
the request.


5.2.1 Processing received Answers

A diameter client or proxy MUST match the Hop-by-Hop Identifier in an
answer received against the list of pending requests. The
corresponding message should be removed from the list of pending
requests. It SHOULD ignore answers received that do not match a
known Hop-by-Hop Identifier.


5.2.2 Relaying and Proxying Answers

A relay or proxy agent MUST only process Answers whose last Route-
Record AVP matches one of its identities. Any answers that do not
conform to this rule MUST be dropped. The last Route-Record AVP MUST
be removed from the message before it is forwarded to the next hop,
which is identified by the second to last Route-Record AVP.

If the host in the Destination-Host AVP is in the peer table and
there are no Route-Record AVPs in the message, the message MUST be
forwarded to the peer.

If the last Proxy-Info AVP in the message is targeted to the local
Diameter server, the AVP MUST be removed.

If a relay or proxy agent receives an answer with a Result-Code AVP
indicating a failure, it MUST NOT modify the contents of the AVP. Any
additional local errors detected SHOULD be logged, but not reflected
in the Result-Code AVP. If the agent receives an answer message with
a Result-Code AVP indicating success, and it wishes to modify the AVP
to indicate an error, it MUST issue an STR on behalf of the access
device.

Prior to forwarding the answer, the agent MUST restore the original
value of the Diameter header's Hop-by-Hop Identifier field.


5.3 Hiding Network Topology

A Relay or Proxy agent routing messages outside of their
administrative domain MAY need to hide the internal Diameter
topology. This is done by removing all Route-Record AVPs in a
request, and later adding them back into the corresponding answer, in
the same order. Such agents MUST take care to not assume that the
absence of any Route-Record AVPs implies the message is for local
comsumption.

Resolution: Accepted proposed changes with slight grammatical changes.

Issue 74: Do not use Route-Record for answer routing
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 11-Jun-2001
Reference:
Document: Base
Comment type: T
Priority: 2
Section: 5.x
Rationale/Explanation of issue:

Currently, relays/proxies are supposed to use a combination of Route-Record
and Destination-Host to route answers back to the client. On the other
hand, they need to save pending requests, including the local Hop-by-Hop
identifier they assigned, and the original Hop-by-Hop identifier.

I propose to add the host the request was received from to the state
information. Then we can remove Route-Record AVPs from answers, and use
saved state information for answer routing. Route-Record AVPs would be used
only in requests to perform loop checking.

Note that both the original Hop-by-Hop Identifier and the host the request
was received from could be saved in a Proxy-State AVP, but since the whole
request needs to be saved in the pending request list, I'm not really sure
the Proxy-State AVP is useful at all?

Destination-Host would not be needed in answers either.

Requested changes:

[as this touches the same sections as the issue "Request & answer routing
clarification" I just sent, this is based on the changes I sent, not the
current draft]

In 5.1.9 Relaying and Proxying requests, add:
The host the request was received from is also saved.

after the "The Hop-by-Hop identifier in the request is saved...".

In Figure 6, remove the Destination-Host and Route-Record AVPs on the bottom.

In 5.2 Diameter Answer Processing, replace:
- The value of the Origin-Host AVP in the request is included in
the answer's Destination-Host AVP.
- There MUST NOT be any Destination-Realm AVP present in the
answer.
with:
- There MUST NOT be any Destination-Realm or Destination-Host AVPs
present in the answer.

and replace:
- Any Route-Record or Proxy-Info AVPs in the request MUST be added
to the answer message, in the same order they were present in
the request.
with:
- Any Proxy-Info AVPs in the request MUST be added to the answer
message, in the same order they were present in the request.

Replace:
5.2.2 Relaying and Proxying Answers

A relay or proxy agent MUST only process Answers whose last Route-
Record AVP matches one of its identities. Any answers that do not
conform to this rule MUST be dropped. The last Route-Record AVP MUST
be removed from the message before it is forwarded to the next hop,
which is identified by the second to last Route-Record AVP.

If the host in the Destination-Host AVP is in the peer table and
there are no Route-Record AVPs in the message, the message MUST be
forwarded to the peer.

If the last Proxy-Info AVP in the message is targeted to the local
Diameter server, the AVP MUST be removed.

If a relay or proxy agent receives an answer with a Result-Code AVP
indicating a failure, it MUST NOT modify the contents of the AVP. Any
additional local errors detected SHOULD be logged, but not reflected
in the Result-Code AVP. If the agent receives an answer message with
a Result-Code AVP indicating success, and it wishes to modify the AVP
to indicate an error, it MUST issue an STR on behalf of the access
device.

Prior to forwarding the answer, the agent MUST restore the original
value of the Diameter header's Hop-by-Hop Identifier field.

With:
5.2.2 Relaying and Proxying Answers

If the answer is for a request which was proxied or relayed, the agent
MUST restore the original value of the Diameter header's Hop-by-Hop
Identifier field.

If the last Proxy-Info AVP in the message is targeted to the local
Diameter server, the AVP MUST be removed before the answer is forwarded.

The agent MUST then send the answer to the host which it received the
original request from.

If a relay or proxy agent receives an answer with a Result-Code AVP
indicating a failure, it MUST NOT modify the contents of the AVP. Any
additional local errors detected SHOULD be logged, but not reflected
in the Result-Code AVP. If the agent receives an answer message with
a Result-Code AVP indicating success, and it wishes to modify the AVP
to indicate an error, it MUST issue an STR on behalf of the access
device.

Replace:
5.3 Hiding Network Topology

A Relay or Proxy agent routing messages outside of their
administrative domain MAY need to hide the internal Diameter
topology. This is done by removing all Route-Record AVPs in a
request, and later adding them back into the corresponding answer, in
the same order. Such agents MUST take care to not assume that the
absence of any Route-Record AVPs implies the message is for local
comsumption.

With:
5.3 Hiding Network Topology

A Relay or Proxy agent routing messages outside of their
administrative domain MAY need to hide the internal Diameter
topology. This is done by removing all Route-Record AVPs in a
request.

In 5.6 Destination-Host AVP, replace:
The Destination-Host AVP (AVP Code 293) is of type OctetString,
encoded in the UTF-8 [24] format, according to the Diameter identity
rules defined in section 2.7. This AVP MUST be present in all
unsolicited agent initiated messages, MAY be present in request
messages, and MUST be present in Answer messages. The value of the
Destination-Host AVP is set to the value of the Origin-Host AVP found
in a message from the intended target host.

with:
The Destination-Host AVP (AVP Code 293) is of type OctetString,
encoded in the UTF-8 [24] format, according to the Diameter identity
rules defined in section 2.7. This AVP MUST be present in all
unsolicited agent initiated messages, MAY be present in request
messages, and MUST NOT be present in Answer messages.

Other changes may be required in 14.1 and 14.2 to reflect this.

Issue 75: Unsolicited server-to-client requests
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 11-Jun-2001
Reference:
Document: Base
Comment type: T
Priority: 2
Section: 5.x
Rationale/Explanation of issue:

The draft is unclear about how unsolicited server-to-client requests are
routed. It says Destination-Host should be used, but does not say anything
about Destination-Realm.

I see the following options:
1. Use the Origin-Realm received in previous requests as the
Destination-Realm.
However, it raises the issue of asymmetrical routing, and thus proxies not
being able to track session state accurately

2. Do some kind of source-based routing (saving the Route-Records from a
previous request and using that to route the unsolicited request to the
client). Is a problem with network topology hiding proxies. Those might be
forced to be stateful and save route-records on a per-session basis.

3. Have the client send a certificate in the original request, so that
servers can then send unsolicited requests directly. It should then be
compulsory for the client to send requests towards the server to update
session state in the proxies if the server requests modifies state in any
way. Raises the issue of proxies that might want to "authorize"
server-to-client requests first, though.

Issue 76: Destination-Realm & proxies/relays
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 11-Jun-2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: 5.x
Rationale/Explanation of issue:

Destination-Realm is used to route messages towards the home server. In a
"normal" situation (i.e. authentication of a user with a NAI-formatted
User-Name), the realm is extracted from the User-Name by the NAS. However,
in some cases (e.g. authorization based on called/calling number), a proxy
might create the Destination-Realm AVP itself.

This is incompatible with the fact that a message without a
Destination-Realm should not be proxied.

Possible options:
1. Create a flag in the message header to specify that a message is not
proxiable.
2. Create different classes for "protocol" messages (all not proxiable?)
and for "application" messages.
3. Define a dummy realm to be included in messages where the "real" realm
is to be inserted later on?

It is also necessary to clarify the wording regarding where the
Destination-Realm is created and how.

Requested changes:
pending discussion and selection of one of the above options.

Issue 77: Implicit termination of an Auth session
Submitter name: Tony Johansson
Submitter email address: tony.johansson@ericsson.com
Date first submitted: 2001-06-11
Reference:
Document: Base
Comment type: T
Priority: 1
Section: 10
Rationale/Explanation of issue:
There may be cases where you don't need to store any session information
in the AAA. For example, there may be cases where the access device will
handle all seesion information. Thus, an access device may request
authentication as a one time thing and no further messages would be
needed between the access device and the AAA.

Proposal:
Perhaps a request from the access device SHOULD allow the
Authorization-Lifetime (as a hint to the server). A value of zero
implies that no state should be created, and no STR will be sent. A
value of zero is a one-shot thing (auth once, never hear from me again).

Issue 78: DiameterIdentity (host descriptor) matching & values
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 14-Jun-2001
Reference:
Document: Base
Comment type: T
Priority: 2
Section: throughout, but clarification to be added in 2.7
Rationale/Explanation of issue:

We need to clarify how two host descriptors are matched, e.g. in loop
matching. Options are:
- exact lexical match (strcmp)
- expand (add defaults such as diameter://, :port, and ;transport=sctp),
then exact lexical match (or match on protocol+name+port+transport)
- expand name to IP addresses, and match on protocol+IP+port+transport (if
name resolves to multiple IP addresses, any match between the two
expansions is a match)

First is possible only if any given process picks a unique identity at
startup, sends it in Origin-Host AVPs in all messages (including CER/CEAs,
which allows direct peers to learn that value), and uses that value in
Record-Route AVPs, and if other hosts use that value only for other
DiameterIdentity-based AVPs (such as Destination-Host).

Note that this works since server always put their identity themselves in
those AVPs. It would also work if a server can put a DiameterIdentity
received in CER/CEA in an AVP. It cannot work when the DiameterIdentity
comes from another source (e.g. from a configuration file listing peers).

At the moment, I don't think there is any problem with that one. It might
become a problem if we wanted to perform loop matching upon receipt of a
Redirect-Host, rather than forward blindly and expect the next host to do
the check.

Requested changes:

At the end of section 2.7, add:
The port and protocol listed above are those that a node uses to
listen for incoming connections.

When a process listens on multiple different addresses or ports or
using different
protocols, it should select a single combination of those, and always
use the same value as its identity for the lifetime of all
connections to peers. This value should be sent in Origin-Host in
CER/CEA and other messages, used in Route-Record AVPs, and any other
AVPs containing DiameterIdentity.

For the purposes of loop checking and other comparison purposes, two
DiameterIdentity values match if they are lexically identical (i.e.
the two strings are the same).

Issue 79: Error handling editorial changes
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 13-Jun-2001
Reference:
Document: Base
Comment type: E
Priority: 1
Section: throughout
Rationale/Explanation of issue:

Error handling
- In 9.0, in the result-code AVPs that require Failed-AVPs, need a
clarification whether this is done only by the home server, or by any
proxy/relay on the way
- In 9.0, what about errors regarding invalid length (packet or AVP)?
Especially for AVPs, since it will be difficult to include a correctly
formatted AVP if length is wrong anyway?
- In 5.3.2/9.1, DIAMETER_REDIRECT_INDICATION is not defined.
- clarify the difference between UNABLE_TO_DELIVER and NOT_SERVED? i.e. in
which case is which sent? -- "I know the domain, but cannot reach any
servers" vs "I don't know the domain".
- any specific messages for DNS errors (transient such as timeouts, or
permanent such as NXDOMAIN)? -- I'd prefer we not have any, buy if you feel
it is necessary, please propose some text.
- the difference between AUTHORIZATION_REJECTED and AUTHORIZATION_FAILED
is, er, unclear.
- NO_COMMON_APPLICATION and UNSUPPORTED_VERSION would be better off in
Protocol errors? -- except that protocol errors MUST only be used in MRA...
see the problem :)
- protocol errors should be usable in any non-'P' messages
- missing errors for message or AVP length errors
- missing errors for unknown not-proxiable commands?
- missing errors for incorrectly set proxiable/not-proxiable flag?
- missing errors for unknown application
- classification of transient/permanent/protocol errors to review

Issue 80: Editorial changes
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 14-Jun-2001
Reference:
Document: Base
Comment type: E
Priority: 2
Section: throughout
Rationale/Explanation of issue:

- in Definition of End-to-end identifier, included definition for locally
consumed incorrect. Reference appropriate section.
- 15.1.2 is not up to date (bit numbers)
- 15.4 does not include protocol errors
- In 10.3, update Session-ID format with full Diameter-Identity
- All AVPs share same scope/numbering space (even inside a Grouped-AVP)
- M AVP within a non-M grouped AVP
- in 10.3 second paragraph, remove reference to multiple Session-IDs.

This is just to formally open the issue. I will send in some text tomorrow.

Issue 81: Route-Record change
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 14-Jun-2001
Reference:
Document: Base
Comment type: T
Priority: 2
Section: throughout
Rationale/Explanation of issue:

Change route-record to include the host which we received the request from
rather than ourselves.
- removes need for checking Route-Record matches on receipt
- removes need to check Origin-Host for loops (or saves one hop in loops
involving origin-host)

Not 100% sure it is better, but it just feels so :-)

Issue 82: Reauthorization issues
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 14-Jun-2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: throughout
Rationale/Explanation of issue:

Reauth clarifications:
- In 10.7 (and elsewhere) clarify Authorization-Lifetime (means Reauth
should be performed) and Session-Timeout. Resources should be liberated
upon Session-Timeout only, not upon Authorization-Lifetime expiration.
- Change name of Authorization-Lifetime to Reauthorization-Timeout
- Authorization-Lifetime and Session-Timeout based from start of Session or
from receipt of message (in reauth)?
- In reauth, is it allowed to change authorization parameters (filters,
IPs...)?

Issue 83: Routing/forwarding clarifications
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 14-Jun-2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: throughout
Rationale/Explanation of issue:

- If multiple hosts listed for a given realm (redirect, relay, proxy), use
the same one for a given Session (either need to maintain Session state or
to use some hash function based on Session-ID) unless error occurs (and
then keep that one that works).
- Clarify if connections to peers are supposed to be opened at startup, or
when needed only.
- Clarify relationship of server discovery (SLP, DNS A, DNS SRV...) with
peer table and/or routing table.
- move peer and routing table description earlier in the doc (somewhere in
2.5 or 2.6).
- Clarify whether "on-demand" connections (e.g. Redirect-Host with
certificate) should timeout.
- refuse connection to oneself

Issue 84: Possibly editorial issues in cms-sec
Submitter name: Jari Arkko
Submitter email address: jari@arkko.com
Date first submitted: 14-June-2001
Reference:
Document: cmssec
Comment type: editorial (?)
Priority: 2
Section: 1 & 4
Proprietary Tag: C
Rationale/Explanation of issue:

- Figure 3 still uses ESSR term, should be DSAR. Search for
more instances just to make sure there are none...

- Last paragraph of 1.2, "Allowing the first hop agent to use
establish the DSA" seems to have some strange wording?
=> "... to be used to establish ... "?

- PDSA has the CMS-Signed-Data AVP which I believe
shouldn't be there. The security is from the proxy to the home,
so no signatures for the NAS in this case. Right? Same issue
for PDSA and Expected-*-AVP.

Issue 85: Cms-sec optimization for pdsr-case
Submitter name: Jari Arkko
Submitter email address: jari@arkko.com
Date first submitted: 14-June-2001
Reference:
Document: cmssec
Comment type: Technical
Priority: 2
Section: 4.3
Rationale/Explanation of issue:

If the DSAR-Target-Domain was optional instead of mandatory
in PDSR, then a NAS could give the proxy full responsibility to
handle the CMS security towards the home for all domains. Today,
the NAS has to initiate a PDSR-PDSA pair for each new domain
it sees. Even if the CMS security association already existed
between the local domain's proxy and the home... after all, it is
likely that an aggregation point would already have seen the
domain.

Issue 86: Diameter URI Changes
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: June 15 ,2001
Reference:
Document: base
Comment type: Technical
Priority: S
Section: 4.4
Rationale/Explanation of issue:

This issue contains changes that resulted from a review of
our current URI.
Proposed Text:
DiameterIdentity
The DiameterIdentity format is derived from the OctetString AVP
Base Format. It uses the UTF-8 encoding and has the same
requirements as the UTF8String. In addition, it must follow
the Uniform Resource Identifiers (URI) syntax [29] rules
specified below:

Diameter-Identity = [scheme-name] fqdn [ port ]
[ transport ]

scheme-name = "aaa://" aaa-protocol "/"
; If absent, the default BASE for relative URI references
; is aaa://diameter/

aaa-protocol = ( "diameter" | "radius" | "tacacs+" )

fqdn = Fully Qualified Host Name

port = ":" 1*DIGIT
; If absent, the default Diameter port (TBD) is assumed.

transport = ";transport=" ( "tcp" | "sctp" | "udp")
; If absent, the default SCTP [26] protocol is assumed.
; UDP is ONLY used when the protocol is set to RADIUS

The following are examples of valid Diameter host identities:

host.abc.com;transport=tcp
host.abc.com:6666;transport=tcp
aaa://diameter/host.abc.com
aaa://diameter/host.abc.com:6666
aaa://diameter/host.abc.com:6666;transport=tcp
aaa://radius/host.abc.com:1813;transport=udp

The first two forms are relative URI references, against the default
base of aaa://diameter/

Issue 87: Move filter-rule AVP to base
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: 14-Jun-2001
Reference:
Document: Base, NASREQ, Mobile IP
Comment type: E
Priority: 2
Section: NASREQ/2.12, Mobile IP/4.10, Base/4.6
Rationale/Explanation of issue:

The Filter-Rule AVP is present in both NASREQ and Mobile IP. It might be
moved to base as one of the standard types and AVPs.

Requested change:

In base, add:

4.6 Standard AVPs

Some AVPs are used in several different applications. To avoid
duplication, these
AVPs are defined here, even though they are not used in the base protocol.

And add NASREQ/2.1.2 here as 4.6.1

Issue 88: EAP Support Issues
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 14-June-2001
Reference:
Document: NASREQ
Comment type: T
Priority: 1
Section: 4.0
Rationale/Explanation of issue:

When using EAP, the NAS operates as a "pass through" and so NAS
behavior is determined by the Diameter message type, *not* by the
encapsulated EAP message.

For example:

a. It is not required that an Accept or Reject message contain
an EAP-Message AVP.
b. If an EAP-Message AVP is included, it is not required that it
correspond to the message type. For example, an EAP-Failure can
be encapsulated within an Access-Accept, and an EAP-Success can
be encapsulated within an Access-Reject.

To allow correct operation in these cases, the NAS behavior MUST
be determined by the Diameter message type alone. This means that a
Reject message must result in termination of the authentication
conversation, an Accept message must result in allowing
access, and a challenge results in continuing the conversation.

How the success/failure is communicated to the user is
a subject for RFC 2284 and potential updates (RFC 2284bis),
and need not concern us in specifying the Diameter behavior.

Note that there has been discussion as to whether an EAP-Success or
EAP-Failure may be encapsulated within a Challenge message. I believe
that the answer to this is NO. Reasoning:

Success and Failure messages are not ACK'd. Therefore the client
will not respond, and thus the NAS will not have material with
which to send another Request, unless it manufactures something
on its own, which goes against the "passthrough" spirit of EAP.

Thus, from a AAA perspective, an encapsulated EAP-Success or
Failure message ends the authentication conversation and thus
MUST be encapsulated within a final message (Accept or Reject)

It has also been asked whether multiple EAP methods may be used
to conduct a single authentication. This is really an EAP issue,
but with respect to AAA, I believe that the answer is that it is
not possible to encapsulate multiple EAP Success or Failure messages within
a single AAA conversation, because of the above reasoning. However,
it would be possible for a AAA server to conduct a conversation of
one type, then switch to another type, and finally, to send an
EAP Success or EAP Failure message at the end, encapsulated within
an Accept or Reject.

Requested change:

PPP-specific references to be removed (EAP can be used with IEEE 802 as
well).
Text to be added to Section 4.0 articulating the above.

Issue 89: Editorial comments - Mobile-IP draft-06
Submitter name: Martin Julien
Submitter email address: martin.julien@ericsson.com
Date first submitted: 25-Jun-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01446.html
Document: mobileip-06
Comment type: E
Priority: 1
Section: 2.1, 2.2, 2.3, 2.4, 3.1, 4.0, 4.7, 5.1, 6.0, 10.4
Rationale/Explanation of issue:

Requested change:

> > 1) Section 1.2, on top of page 7, I was wondering if it would be better
> > to use the DIAMETER_ERROR_AUTH_FAILURE defined in the MIP draft,
> > or to re-use the one already defined in the Base draft? The one in the
> > Base could possibly be more generic, what do you think?
>
> I agree, and an issue should be opened.

I think it would make more sense, since there is already an authentication
error in the Base that seems, at this point, only used for the NASREQ app.

> > 2) Section 2.1, I guess we could mention that the MN-AAA
> > Authentication Extension information is carried by the
> > (MIP-MN-AAA-Auth AVP), and that the Foreign Agent Challenge
> > Extension information by the (MIP-FA-Challenge AVP).
>
> that would be useful.
>
> > 5) Section 2.2, the command-code should be 260, instead of 261.
> >
> > 6) Section 2.2, in the message format, should the
> > MIP-HA-to-FA-Key AVP be included as [], in the case where the
> > the Multi-Round-Auth is used?
>
> hmmmm.... agreed.
>
> > 7) Section 2.3, could we add the [MIP-Feature-Vector] as a possible
> > AVP of the HAR message, since I see it very useful in the case where
> > the AAAF needs to allocate an Home Agent in the foreign domain?
>
> yes, I agree.
>
> > 8) Section 2.4, I don't think it is very clean, with regards to the
> > specification, to expect that the HA will be responsible of
> forwarding the
> > Session-Timeout, the Authorization-Lifetime, the
> MIP-FA-to-MN-Key and the
> > MIP-FA-to-HA-Key AVPs in the HAA. When I see those attributes
> in the HAA,
> > I always have to remind me that they are meaningless to the
> HAA, but only
> > meaningful to make easier the conversion of the HAA into a AMA in the
> AAAH,
> > which I consider not very useful anyway, since the AAAH still needs to
> check
> > that they have been included properly. Well, my opinion is that
> we should
> > remove them from there, since they are meaningless to the AAAH that
> receives
> > the HAA.
>
> ok. A few revisions of the base protocol base, less state was required on
> the AAAH. Nowadays, though, I agree that the AAAH can easily keep this
> state information (or add it to Proxy-State if it really wants to).
>
> > Also, note that the Session-Timeout AVP is {} in the HAA, but [] in the
> HAR,
> > which seems inconsistent. What the HA is supposed to put in there if not
> > received in the HAR?
>
> oops
>
> > 9) Section 2.4, the Filter-Rule and the MIP-Foreign-Agent-Host
> AVPs should
> > be removed from the message format. They are not useful at all.
> Maybe they
> > could be in the message as *[AVP], which would mean that their
> presence is
> > not a problem, but not useful neither.
>
> well, we could, but it is sort-of useful to the implementor to know what
> to expect in a message. I suspect that filters will unfortunately be more
> frequent than we want to admit :(

Yes, but why is it useful in the HAA? Can the HA return a different
Filter-Rule AVP than the one received in the HAR? If not, then I don't
see any added value of having that AVP in the HAA.

> > 10) Section 3.1, can the HA return the DIAMETER_ERROR_HA_NOT_AVAILABLE
> > when the can not provide the HA service? In that case, the AAAH, or
> > the AAAF, would be responsible for allocating an other HA, if it had
> > allocated it previously. That is the only reason why I would see the
> > DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE useful, since the AAAH changes
> > the DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE into a
> > DIAMETER_ERROR_HA_NOT_AVAILABLE when answering to the FA, as described
> > in page 12.
>
> I would much prefer that DIAMETER_TOO_BUSY be returned by an HA to state
> that it cannot handle the request, and an alternative should be assigned.
> The error in question should only be used when a specific server is
> requested, and it cannot be assigned.

OK, then could we add your last sentence in the description of the error?

> > 12) Section 4.0, the Filter-Rule AVP should be referenced to section
> > 4.11 instead of 4.10. It should also be of type UTF8String, instead of
> > OctetString. The thing is that there are 2 sections 4.10, which should
> > be corrected. Also, the MIP-Foreign-Agent-Host and MIP-Previous-FA-Host
> > AVPs should be of type DiameterIdentity, instead of OctetString.
>
> right, well Filter-Rule is now a sub-type, so this will change. The
> references, though, do need to be fixed.
>
> > 13) Section 4.7, the last paragraph, we should read "Only the AAAF may
> > set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network
> > flags to one."
>
> right.
>
> > 14) Section 5.1, 4th par. last word, should be HAA instead of AMA.
>
> correct.
>
> > 15) Section 6.0, the MIP-Algorithm-Type and MIP-Replay-Mode
> AVPs should be
> > of type Enumeratedm instead of Unsigned32.
>
> correct.
>
> > 17) Section 10.4 is no longer needed and should be completely deleted.
>
> correct

Issue 90: MIP-Previous-XXX AVP
Submitter name: Martin Julien
Submitter email address: martin.julien@ericsson.com
Date first submitted: 25-Jun-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01446.html
Document: mobileip-06
Comment type: T
Priority: 2
Section: 2.1, 4.5, 4.6,
Rationale/Explanation of issue:

Requested change:

> > 3) Section 2.1, I don't think the paragraph starting with
> > "If the MIP-Previous-FA-Host AVP...." is still applicable
> > in this draft. Can that AVP be useful at all in the current
> > solution proposed in the draft? At least, I don't see how
> > we could make use of that MIP-Previous-FA-Host AVP in the
> > AAAH and the AAAF. Is it for future considerations?
>
> I am not sure. Others?
>

Thomas Panagiotis commented: "MIP/Fast interdomain handoffs?"

I agree that it could be useful for that, but in the actual draft,
that is not supported, AFAIK. So, I think it should either be removed,
since there is no clear defined use for it at this point, or be
kept with some kind of explanations how it can be useful in the
AAAF or AAAH.

Based on the draft, the AAAF and AAAH already have
access to the User-Name, the MIP-Home-Agent-Address and
MIP-Mobile-Node-Address, which I think is enough to get access to
the stored MN-FA and FA-HA keys, if needed in the AAAF. Of course
that it means that the AAAF needs to be stateful, but is there any
other way of handling this?

One way we could be using the MIP-Previous-FA-Host AVP,
would possibly be to make the AAAF stateless, which could possibly invoke
the Session-Abort message towards the Previous-FA. Would it be a
valid interpretation of that AVP or not? Does it make any sense?

> > Furthermore, I thought we had agreed that the User-Name
> > was not enough for the purpose of retrieving keys in the AAAF,
> > but would rather require the User-Name, the Home-Address and
> > the Home-Agent?
>
> That rings a bell. I may have missed that one.
>
> > 4) Section 2.1, in the message format, I am questionning the
> > necessity of the MIP-Previous-FA-Host and MIP-Previous-FA-Addr AVPs.
>
> right, again, not sure. Perhaps this one should actually be a separate
> issue from the editorial ones.

Issue 91: MIP-SPI
Submitter name: Martin Julien
Submitter email address: martin.julien@ericsson.com
Date first submitted: 25-Jun-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01446.html
Document: mobileip-06
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

Requested change:

> > 18) Section 6.2.7, should the SHA-1 algorithm be also added, as in the
> > aaa-key-06 draft? BTW, would it be better that the values assigned to
> > those algorithms match between the 2 drafts? The last comment also
> > applies to the Replay-Mode.
>
> yes, but it really don't matter if there isn't a match. If you think it
> would be useful, include it in your issue.

Not really, it was only a comment. The thing is that since the values in
the Diameter MIP-06 draft are based on the ones defined in the other
document, I thought it would be better to keep the values consistent,
but of course, it does not have to be like this, strictly speaking.

> > 11) If there is a problem in the HA or FA with the SPI generated by
> > the AAAH or AAAF, how could that be reported?
>
> reported by whom? The HA? Or one of the AAA servers?
>
> > 16) Whenever no MIP-*-Preferred-SPI AVP is included in the AMR, can we
> > assume that the SPI generated by the AAAH or AAAF can be completely
> > random or not? Why can't the HA decide the SPI itself?
>
> There's no reason why, really :(

I'm still not quite sure to get the complete picture of how the SPI should
be
handled in the AAA servers. Are we expecting the AAA servers to use the
standard 0-255 SPI defined by IANA?, or are the AAA servers expected to
handle to concept of SA, which normally contains and defines their own
SPI values?

As defined in RFC 2002 (MIP):

Mobility Security Association
A collection of security contexts, between a pair
of nodes, which may be applied to Mobile IP protocol
messages exchanged between them. Each context indicates
an authentication algorithm and mode (Section 5.1), a
secret (a shared key, or appropriate public/private
key pair), and a style of replay protection in use
(Section 5.6).

Security Parameter Index (SPI)
An index identifying a security context between a pair
of nodes among the contexts available in the Mobility
Security Association. SPI values 0 through 255 are
reserved and MUST NOT be used in any Mobility Security
Association.

I believe that MIP is using the standard CHAP_SPI, when using RADIUS, right?
Should the Diameter server follow the same path or not? I guess not, since
the key AVPs would not contain the MIP-SPI, the algo and the Replay-Mode,
right?

The thing is
that if Diameter needs to support the concept of SA, then it seems to
be difficult for the AAA server to select an SPI on behalf of the MN, the HA
and the FA. Of course, the AAA can count on the Preferred-SPI from the FA
and the MN, in which case the AAA simply agrees with the value. However,
if there is no Preferred-SPI AVPs in the AMR, then the AAAH needs to
generate
them, at the risk that they might already be used in the SA defined between
the MN and the HA, or between the HA and the FA, or between the FA and the
MN.
I think that it makes more sense for the HA to select the required SPI
between
the HA-MN and HA-FA, if no Preferred-SPI is included in the AMR.

I guess that the MIP-Foreign-Agent-Host AVP could be useful for creating
the SPI within the SA defined between the HA and the FA.

> > Also, when a MIP-*-Preferred-SPI AVP is included in the AMR, I guess
> > that the FA has chosen a value that what not already already by any
> > of the SAs, right? The thing is that it might not know the HA yet,
> > i.e. the SA.
> >
> > 19) Section 6.1, could you please explain to me what "The Mobile IP key
> > described in [15] refers to the AAA SPI, which MUST be set to the value
> > the AAAH shares with the Mobile Node." Are we talking about a
> > pre-configured shared SPI, or a secret key? Can it dynamically change
> > or not? It is not clear to me how the AAA SPI can help in creating the
> > FA or HA Security Information. Could you please tell me more?
>
> I'd love to explain it, but that would require that I first
> understand it :(
>
> I believe that what I had originally intended to state here is that the
> values created are used in a particular field of the MIP AAA key in [15].
> This needs some major cleaning up.

Issue 92: Some editorials on Base-06
Submitter name: Jaakko Rajaniemi
Submitter email address: jaakko.rajaniemi@nokia.com
Date first submitted: 26-Jun-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01476.html
Document: base-06
Comment type: E
Priority: S
Section:
Rationale/Explanation of issue:

Editorial changes required in base protocol specification
Requested change:
> In the section 1.3, "Terminology", Session description, the last sentence
> "devices serving the same user." should be removed?

correct.

>
> In the section 2.5.3, "Redirector Agents", the 4th paragrapth, DRL instead
> of DLR.

yes.

>
> In the section 9.1.4, "Transient Failures", the error
> DIAMETER_UNSUPPORTED_VERSION 5013 describes that: "This error is
> returned when a CEA message is received, and the Diameter message is
> unsupported." Should this be instead "This error is returned when a CEA
> message is received, and the Diameter version is unsupported."? In this case
> the version field of the CEA message could indicate the highest Diameter
> base protocol version supported by the node. If this is not acceptable for
> the receiving node it terminates the connection.
yes the description is wrong, but I feel uncomfortable with your suggestion since
it implies that an implementation supports all previous versions. I think that an
implementation could just try to re-connect, and send a CER with a different
supported version number.

>
> In the section 10.0, "Diameter User Sessions", 3rd paragraph, it says that
> "Note that the Authorization-Lifetime AVP implies how long the Diameter
> server is willing to pay for the services rendered, therefore a Diameter
> client SHOULD NOT expect payment for services rendered past the session
> expiration time." Should this be instead "...a Diameter client SHOULD NOT
> expect payment for services rendered past the Authorization-Lifetime
> expiration."?

correct.

>
> In the section 10.1, "Authorization Session State Machine", the state
> machine description, should SKR/SKA be replaced by
> Abort-Session-Request/Answer (ASR/ASA)?

yup.

>
> In the section 10.11, "Termination-Cause AVP", The error
> DIAMETER_ADMINISTRATIVE 4 describes that "The user was not granted
> access, or was disconnected, due to administrative reasons, such as the
> receipt of a Session-Kill-Request message." Session-Kill-Request should be
> replace by the Abort-Session-Request?
Another one I missed :(

Issue 93: End-to-End Identifier
Submitter name: Fredrik Johansson
Submitter email address: fredrik@ipunplugged.com
Date first submitted: 28-Jun-2001
Reference:
Document: base-06
Comment type: T
Priority: S
Section: 3.0,
Rationale/Explanation of issue:

The end-to-end identifier is not monotonically increasing, thus it requires
a server to save all identifers on a per host basis to be able to see if the
message has been received before. Some describing text is also missing on
how a server should treat a message that it has received before.

Requested change:

Make the e-2-e identifier monotonically increasing and suggest that the
server stores the identifiers in the same manner as done in AH (section
3.4.3 in RFC 2402) but with a suggested value of 128 as default window.

Also, add some text describing what a server should do when the e-2-e
identifier has been seen before. e.g. discard it or reply with the same
answer as last time.

Issue 94: Typographical change to sec. 3.2 of draft-ietf-aaa-transport-04.txt
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: June 29, 2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01498.html
Document: draft-ietf-aaa-transport-04.txt
Comment type: E
Priority: 1
Section: 3.2
Rationale/Explanation of issue:

The following paragraph contains a typographical error and an instance of
awkward wording.

[3] After the the expiration of two watchdog timers without a response,
the AAA client SHOULD cause a transport reset or close to be done
on the connection. While the connection is in the closed state,
the AAA client MUST NOT attempt to send further watchdog messages
on the connection. However, after the connection is closed, the AAA
client continues to periodically attempt to re-open the connection.
The AAA client SHOULD wait for the transport layer to report
connection failure before attempting again, but MAY chose to limit
^^^^^ ^^^^^
choose bound
this wait time by the watchdog interval, Tw. If the connection is
successfully opened, then the watchdog message is sent. Once three
watchdog messages have been sent and responded to, the connection
is returned to service, and transactions are once again sent over
it. Connection validation via receipt of multiple watchdogs is not
required when a connection is initially brought up -- in this case,
the connection can immediately be put into service.

Requested change:

Change as indicated or alternatively, fix the awkward wording by replacing
the phrase "...to limit this wait time by the watchdog interval..." with the
phrase "...to limit this wait time not to exceed the watchdog interval...".

Issue 95: Problem with removing Route-Record AVPs
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: July 24, 2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01594.html
Document: Base
Comment type: T
Priority: S
Section: 6.3 and 6.1.9
Rationale/Explanation of issue:

If a proxy or relay agent hides the topology by removing the Route-Record
AVPs, how does a home-server produce the list of Source-Route
AVPs which he needs to subsequently send a reverse-request?

Pertinent sections of draft-ietf-aaa-diameter-07.txt follow:

6.1.9 Relaying and Proxying Server-Initiated Requests

Server-initiated messages MUST include the Source-Route AVPs, whose
contents are identical to the Record-Route AVPs received in requests
from the access device for the given session, but in the reverse
order.

6.3 Hiding Network Topology

A Relay or Proxy agent routing messages outside of their
administrative domain MAY need to hide the internal Diameter
topology. This is done by removing all Route-Record AVPs in a
request.

Another problem with removing Route-Record AVPs is that it can prevent
loop detection from working properly.

Requested change:

Delete section 6.3. Or because this section has been here for a while,
it may be safer to change 6.3 to state that an agent MUST NOT remove
Route-Record AVPs.

Issue 96: Change Record-Route to Route-Record
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: July 24, 2001
Reference:
Document: Base
Comment type: E
Priority: 1
Section: 6.1.9
Rationale/Explanation of issue:

Section 6.1.9 refers to "Record-Route AVPs". This is incorrect.

Requested change:

Change the text string "Record-Route" in sec. 6.1.9 to "Route-Record".

Issue 97: Proxies keeping a session-state
Submitter name: Martin Julien
Submitter email address: martin.julien@ericsson.com
Date first submitted: July 25, 2001
Reference:
Document: Base-07
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

It seems that the Source-Route AVP is mainly used to make
sure that a server-initiated request goes through the same
agents as the initial auth request from the client. The
reason for that is that agents might be keeping a session
state, in which case they need to be aware of what is being
exchanged between the client and the server. However, the
way it is defined now does not let us take advantage of it,
especially when the client can not even make sure that the
next message it sends to the server will go through the
same agents, since the load-balancing in relays could occur.
I guess this should be fixed so that the client can be
assured that all the requests for the given session will
go through the necessary proxies that keep a session-state.

Requested change:

A possible way of making sure that messages go through the same agents
between the different requests from the client, and also the server-
initiated requests from the server, would be to support another routing
AVPs called Agent-Route AVP, which would be added in the first request
to the server, and returned to the client in the answer message. Then,
the second request from the client would include that AVP, for making
sure that the message go through that agent. The server would also have
to keep that AVP for server-initiated request towards the client.

By doing so, we do not need the Source-Route AVP, and can come back to
a more generic way of routing request.

Issue 98: Peer role in Peer table?
Submitter name: Martin Julien
Submitter email address: martin.julien@ericsson.com
Date first submitted: July 25, 2001
Reference:
Document: Base-07
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

In section 5.1 of Base-07, referring to peer connections, what
is the difference between opening a connection to a primary or
to a secondary peer? Is that data expected to be configurable
or run-time dependent? My understanding is that it was intended
to be configurable by the system admin.

The thing is that I do not really see what the role of primary,
secondary and alternate means? It is said that a connection should
be openned with all primary and secondary peers, and optionnally
with alternate ones. What is the real difference between them?
Shouldn't we simply say that for a particular peer, a connection
should be maintain or not?

In fact, my confusion comes from the fact that I am not sure
if the secondary peer refers to the Alternate-Peer AVP or not?
The thing is that it is not possible to say if it is a secondary
or alternate peer with that Alternate-Peer AVP.

Could you please tell me what were your intentions with that
Peer role exactly?

Also, was the Alternate-Peer also good for routing answers
or not?, can it be used for upstream requests from the client
to the server when using the Destination-Host AVP?


Requested change:

Please clarify this so that it is clear.

Issue 99: New AVPs to NASREQ for Basic/Digest support
Submitter name: Srinivas, Chan, Sengodan, Costa-Requena
Submitter email address: bindignavile.srinivas@nokia.com,
tat.chan@nokia.com, senthil.sengodan@nokia.com,
jose.costa-requena@nokia.com
Date first submitted: July 25, 2001
Reference:
http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.txt
Document: Document Requiring change: nasreq
Comment type: 'T'echnical
Priority: '1'
Section: 3.1 and Introducing New Section 4.0
Rationale/Explanation of issue: Three new AVPs are introduced in NASREQ
in order to support Basic/Digest authentication. Detailed description is
found in the individual draft submission
http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.txt.

Proposal:
Section 3.1.1: Paragraph added before Message Format to read: "The
Resource and Response AVPs (defined in Section 4.0) MAY be present in
the AA-Request message when Basic or Digest authentication is to be
used."
Section 3.1.1: AAR Command modified to include [ Resource ] and [
Response ] AVPs.
Section 3.1.2: Paragraph added before Message Format to read: "The
Challenge AVP (defined in Section 4.0) MAY be present in the AA-Answer
message when Basic or Digest authentication is to be used."
Section 3.1.2: AAA Command modified to include [ Challenge ] AVPs.
Section 4.0 is introduced and includes the following text (while
original Section 4.0 changes to 5.0 and so on):
4.0 Basic/Digest Authentication Support
The Basic and Digest authentication schemes, described in [X], are two
well-known authentication methods. This section describes the AVPs that
are required for Basic/Digest authentication support within the Diameter
protocol. As seen in Section 3.0, the Resource AVP and Response AVP MAY
be used within the AA-Request Command, while the Challenge AVP MAY be
uesd within the AA-Answer Command.
4.1 Resource AVP
The Resource AVP (AVP Code xxx) is of type OctetString and is used to
convey a resource. It MAY be used by a DIAMETER client to convey to the
DIAMETER server the resource whose access needs authorization.
4.2 Challenge AVP
The Challenge AVP (AVP Code xxx) is of type OctetString and is used to
convey a challenge. It MAY be used by a DIAMETER server to convey a
challenge to the DIAMETER client.
4.3 Response AVP
The Response AVP (AVP Code xxx) is of type OctetString and is used to
convey a response. It MAY be used by a DIAMETER client to convey a
response to the DIAMETER server.

Comments/Discussion (not part of proposed text):
No separate command code has been proposed for Basic/Digest
authentication, and the AAR and AAA commands have been modified to
support the proposed AVPs. This implies that when a DIAMETER server
receives an AAR command from a DIAMETER client, it cannot determine
whether the authentication/authorization schemes are RADIUS based or
Basic/Digest based just by looking at the command code. Instead, the
AVPs have to be parsed to determine this. If this is seen as an issue,
then a new command code may have to be introduced for the purpose of
Basic/Digest authentication support. This would then be along the lines
of a new command code being introduced for the purpose of EAP
authentication support.

Issue 100: Editorial comments on base-07
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: July 25, 2001
Reference:
Document: Base-07
Comment type: E
Priority: 1
Section: throughout
Rationale/Explanation of issue:

In 3.0
- Commands flags, r(eserved): should state that an error must be generated
if a packet is received with such a bit set to one.

In 3.3:
- 1st paragraph: "Diameter commands typically start with an object name".
Not that sure :-)
- 2nd paragraph: "The corresponding answer MUST contain either a positive
or negative result code". What about multi-round trip messages, and redirects?

In 4.0:
- 1st paragraph: "Diameter AVPs carry specific authentication, accounting
and authorization information, security information as well as
configuration details..." They can also carry routing information (unless
that's what is meant by "configuration details".

In 4.1:
- AVP Code: "The first 256 AVP numbers are reserved for backward
compatibility with RADIUS". Even if Vendor-Id is non-zero?
- AVP Flags, "Note that subsequent Diameter applications MAY define
additional bits within the AVP Header, and an unrecognized bit SHOULD be
considered an error". Didn't find an error number for that one in 7.1.x.
- AVP Flags, 2nd paragraph, "If an unrecognized AVP with the 'M' bit set is
received by a Diameter node..." replace node with "client, server or
proxy". The client thing raises the issue stated in the 7.1.4/7.1.5 section
about errors in answers, though. Also, it should not be only if the AVP is
unrecognized, but also if the requested AVP or value is recognized, but the
node does not accept it.
- AVP Flags, 3rd paragraph, "In order to provide service to the user, the
node at fault MUST re-issue...". The client might decide that if the server
doesn't understand that AVP, it doesn't want to provide service to the
user. Make that explicit rather than implicit.
- AVP Flags, 4th paragraph, add a comma between "ABNF" and "is at fault".
- AVP Flags, 5th paragraph, "AVPs with the 'M' bit cleared are
informational only and a receiver that receives a message with such an AVP
that is not supported MAY simply ignore the AVP." The AVP might be
supported but not the value, and it could be ignored also, right? Same
thing if the AVP and value are supported but the node does not want to
honor that AVP or value.

In 4.3,
- the definitions for Float32, 64 and 128 are truncated: "'V' bit is
enabled)." is missing.

In 4.4,
- 1st paragraph, "In addition to the AVP Base Data Formats" -> "In addition
to *using* the AVP Base Data Formats".
- 1st paragraph, "New AVP Derived Data Formats MUST be registered with
IANA." How could they be registered? There is no "unique identifier" or
anything of the sort. And since the AVP contents are actually opaque to
those that are not involved, I don't quite see the need. They should just
be defined in any application that uses them. Also, if they must indeed be
registered, a section in 11.x is missing.
- 3rd paragraph, "AVP Derived DATA Formats" -> "AVP Derived Data Formats"
- IPAddress, what if an AVP must explicitly have an IPv4 or IPv6, and not
"any of those"?
- UTF8String, 1st paragraph, reference wrong [24] not [29] (it might be a
good thing to actually check all refs)
- UTF8String, 2nd and 8th paragraphs, no zeros mentionned twice
- DiameterIdentity, get aaa-protocol and protocol at the bottom (in the
same order they're used)
- DiameterIdentity, 2nd paragraph "The following..." is indented one notch
too much
- DiameterIdentity, 3rd paragraph, "Since multiple...", why "per host"?
It's rather "per process", or should be reworded to read "the
DiameterIdentity of any process is guaranteed to be unique."
- DiameterIdentity, 4th paragraph, "A Diameter node MAY advertise different
identities...". Glurgs! Certainly not! It MUST be the same identity on all
connections (unless the host is a gateway between two routing domains (e.g.
private and public)). Otherwise there's no way to detect duplicate
connections, loops, etc. consistently. Remember, the DiameterIdentity, as
used in CER/CEA and Route-Records is just considered as an opaque and
unique identifier.
- DiameterIdentity, 5th paragraph, this is not needed in duplicate
connection detection and loop avoidance, since the identifier is opaque. It
can save time, however, when one gets an external reference to another host
(via SLP, DNS, Redirect, Alternate-Host...) and one wants to check that
this new host doesn't match one it already knows/already is connected to.
But even if that's not done, a match would be detected upon connection to
the new host when the CER/CEAs are exchanged and the "real" (unique)
identity is discovered and can be matched against existing connections.
- IPFilterRule, 2nd to last paragraph, "An access device that is unable to
interpret or apply a deny rule MUST terminate the session." Shouldn't this
be dependent on whether the M bit is set or not? Ditto for the second
sentence (though it's probably not as important).
- QOSFilterRule: I thought the idea was to reference an IPFilterRule to
determine what traffic should be marked or metered?

In 4.5:
- 1st paragraph, swap the ' and the . in 'Grouped.'
- 3rd paragraph, "All AVPs included in a Grouped AVP Every Grouped AVP
defined...". Either something is missing before the Every, or the all
before the Every is not needed.
- in the ABNF spec, "header = "does one specify the Vendor-Id, if any?

In 4.5.1:
- in the paragraph starting with "The data for the optional AVPs...", why
is is stated that "AVPs do not have to begin on 8 byte boundaries"? It is
true, but I quite see why people would think it?
In 4.6:
- in the table, what if a flag is in neither column for a given AVP (e.g. P
is often absent)
- here also, what about renumbering everything in a contiguous space?
- checking section references would be a good idea, but I'm way to lazy for
that.

In 5.0:
- "This section describes how a Diameter nodes establish connections and
communicate with peers." Either remove the "a" or move everything to singular.

In 5.1:
- 1st paragraph, specify that this "per realm" rather than globally? Though
there is the issue of proxies that serve many many realms (with different
peers), and dynamically learned realms/peers.

In 5.2:
- 4th paragraph "2. The Diameter implementation uses SLPv2...", swap ) and
. in "agents.)".

in 5.3:
- 5th paragraph, "Since the CER/CEA messages...", replace "an upstream"
with "a". Also specify the Result-Code to be used in the error message.

In 6.8.1:
- "The identity added in this AVP MUST be the same as the one sent in the
Origin-Host of the Capabilities-Exchange-Request message". sent ->
received. Capabilities-Exchange-Request -> Capabilities Exchange.

In 7.1.2:
- DIAMETER_LIMITED_SUCCESS: "When returned, the request was successfully
completed, but additional processing is required by the application in
order to provide service to the user." Gni? What is that?

In 7.1.3:
- DIAMETER_INVALID_ROUTE_RECORD is no longer needed.
- DIAMETER_REDIRECT_INDICATION might be better off in the informational types?

In 7.1.4/7.1.5:
- I'm still not quite sure of the distinction between permanent and
transient. e.g. DIAMETER_AUTHENTICATION_REJECTED [which is transient, so
can be retried] means the request can be retried after asking the user for
its password again. So it's not actually the same request, right? On the
other hand, DIAMETER_AVP_UNSUPPORTED and DIAMETER_INVALID_AVP_VALUE [which
are permanent, so shouldn't be retried] imply that you can retry by
removing the AVP or changing the value [that's actually the
"content-negociation" part of Diameter].
Actually, we might be better off with some category that includes anything
that means neither Accepted nor Refused, but rather "more to come" (which
would include both the multi-round-trip auths and other capabilities
negociation messages).
Also, what if an error is detected on the answer rather than the request?
Ditto for capabilities negociation in that direction (e.g. if server says
"please set this feature to that value for that user" and client or proxy
want to say "don't know what you're talking about/don't want to do that").

Issue 101: Editorial changes concerning Destination-Host
Submitter name: Guenter Schaefer
Submitter email address: schaefer@ee.tu-berlin.de
Date first submitted: July 26, 2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01631.html
http://www.merit.edu/mail.archives/aaa-wg/msg01591.html
Document: Diameter Base Specification (I) and
Mobile IPv4 Application (II)
Comment type: ?
Priority: ?
Section: 6.6, 6.2, 5.3.2, 5.4.2, 5.5.2 in (I), 2.2, 2.4 in (II)
1.4, 2.1, 4.0. 4.5, 4.6, 8.1, 8.2 in (II)

Rationale/Explanation of issue:

- There is an inconsistency regarding the Destination-Host AVP
in the Diameter base protocol (I) and the Mobile IPv4
application (II)
("draft-ietf-aaa-diameter-07.txt",
"draft-ietf-aaa-diameter-mobileip-07.txt").
Sections 6.2 and 6.6 of the base protocol specify that the
Destination Host AVP MUST NOT be present in answer messages.

However, the base protocol requires this AVP in the DPA and DWA
messages and lists it as optional for the CEA message.
The Mobile IPv4 application requires this AVP in the AMA and HAA
messages.
[sections 6.6, 6.2 5.4.2, 5.5.2, 5.3.2 in (I),
2.2, 2.4, in (II)]

- The Mobile IPv4 application still mentions the AVPs
MIP-Previous-FA-Host and MIP-Previous-FA-Addr
even though fast handoff support has been postponed
for further study.
[sections 1.4, 2.1, 4.0. 4.5, 4.6, 8.1, 8.2 in (II)]

Requested change:

1. EITHER change section 6.6 in the diameter base specification to

"6.6 Destination-Host AVP

The Destination-Host AVP (AVP Code 293) is of type
DiameterIdentity. This AVP MUST be present in all unsolicited
agent initiated messages, MAY be present in request messages,
and MAY be present in Answer messages."

and change section 6.2 in the base specification accordingly,

OR

delete the Destination-Host AVP from
- the DPA, DWA and CEA messages in the base specification
[sections 5.4.2, 5.5.2, 5.3.2 in (I)]
- the AMA and HAA messages in the Mobile IPv4 application
[sections 2.2, 2.4 in (II)]

2. In the Mobile IPv4 application all paragraphs concerning
the AVPs MIP-Previous-FA-Host and MIP-Previous-FA-Addr
should be deleted in order to reflect postponing of
fast handoff support for further study.
[sections 1.4, 2.1, 4.0. 4.5, 4.6, 8.1, 8.2 in (II)]

Issue 102: More description on Session state machine
Submitter name: Yiwen Jiang
Submitter email address: Yiwen.Jiang@tic.siemens.ca
Date first submitted: July 27th, 2001
Reference: N/A
Document: base
Comment type: E
Priority: 1
Section: 8.1 and 8.2
Rationale/Explanation of issue:

In Section 8.1 and 8.2, there is only a description of the Authentication
state machine without any explaination on what the states actually means. In
addition, the last line of the state machine, "New State" was not specified.

Requested change:
Some text should be added in describing the individual states mentioned,
similar to the sections after the peer state machine.

Issue 103: Inconsistencies in AVP types used throughout base spec
Submitter name: Dave Frascone
Submitter email address: dave@frascone.com
Date first submitted: July 27th, 2001
Reference: N/A
Document: base
Comment type: E
Priority: 1
Section:
Rationale/Explanation of issue:

In section 4.6 of the base protocol draft, there is a table of all base
protocol AVPs. Most AVPs are only mentioned with their Base types (with
the exception of a few IPAddress's). But, further on when the AVPs are
described in detail, they mention their derived types. (i.e. section 5.3.7
Product-Id is called a UTF8String)

And finally, should Vendor-Id be considered Enumerated? In the Ethereal
packet dissector, I've switched it to enumerated, so it can attempt to
look up the vendor-id in it's VERY limited table.


Requested change:

Update the table in Section 4.6: (I *think* I found them all)

Accounting-Record-Number should be Unsigned32
Acct-Application-Id should be Unsigned32
Alternate-Peer should be DiameterIdentity
Auth-Application-Id should be Unsigned32
Destination-Host should be DiameterIdentity
Destination-Realm should be UTF8String
Error-Message should be UTF8String
Error-Reporting-Host should be DiameterIdentity
Origin-Host should be DiameterIdentity
Origin-Realm should be UTF8String
Product-Name should be UTF8String
Proxy-Host should be DiameterIdentity
Redirect-Host should be DiameterIdentity
Route-Record should be DiameterIdentity
Session-Id should be UTF8String
Source-Route should be DiameterIdentity

Also, since it seems like things are in alphabetical order,
Session-Binding should come before Session-Id

Issue 104: clarification on difference between session and peer connection
Submitter name: Jacques Caron, Yiwen Jiang
Submitter email address: Yiwen.Jiang@tic.siemens.ca
Date first submitted: July 27th, 2001
Reference: N/A
Document: base
Comment type: E
Priority: 1
Section:
Rationale/Explanation of issue:

The relationship between peer-to-peer connection vs. user session was not
specified in the base protocol.

Requested change:
(Below is my first attempt at modifying the initial email that Pat sent out
to clairfy such. Maybe we can added in section 8.0.)

While peer-to-peer connections is a transport level connection, a user
session is a logical concept at the application level. It exists over one or
many peer-to-peer connections.

+--------+ +-------+ +--------+
| Client | | Relay | | Server |
+--------+ +-------+ +--------+
<----------> <---------->
peer connection A peer connection B

<------------------------------>
User session x

In the above example, peer connection A is established between the Client
and its local Relay. Peer connection B is established between the Relay and
the Server. User session x spans from the Client via the Relay to the
Server. Each "user" of a service causes an auth request to be sent, with a
unique session identifier. Once accepted by the server, both the client and
the server are aware of the session. Because of this behaviour, all Diameter
clients will need to first initiate a peer-to-peer connection before it can
issue user requests to its immediate Diameter peer. All user sessions are
"multiplexed" through a single connection.

Issue 105: More editorial comments
Submitter name: Fredrik Johansson
Submitter email address: fredrik@ipunplugged.com
Date first submitted: July 30th, 2001
Reference: N/A
Document: base
Comment type: E
Priority: 1
Section:
Rationale/Explanation of issue:

Some of these comments may be duplicates of earlier posted issues, I've
tried to find them but might have missed a few.

Section 1.1 Last sentence
"An example of an unsolicited message would be for a request that the client
issues an accounting update"
If I'm not misstaken that feature was removed, if so, use another example
e.g. "... for a request that the client re-authenticate"

Section 1.3
Reference in the NAI should be 8 instead of 3.

Section 2.1
3rd paragraph, replies MAY any -> replies MAY be any

Section 2.3.2
"Note that new AVPS to be used with an existing application MUST NOT
be defined to have the 'M'andatory bit set."

is contradictory with section 2.4
"An implementation MAY add arbitrary AVPs to any command defined in an
application, including vendor-specific AVPs. However, implementations
that add such AVPs with the Mandatory 'M' bit set are not compliant,
and are at fault if the peer rejects the request."

remove sentence in 2.3.2

Section 2.6
- Status. This is the state of the peer entry, and MUST match one
of the values listed in section 5.6.

Do you mean the values in 5.5.3?

Section 3.0
E(error) - If set, the message contains a protocol error

Just a protocol error, why not any error?

Section 4.4

"If no rule matches, the packet is
dropped if the last rule evaluated was a permit, and passed if
the last rule was a deny."

To me it seems a bit strange that what to do with the packet should be
determined by the last rule evaluated even if it doesn't match that rule.
Even more strange when you decide to pass the packet based on the fact that
the last rule was a deny even if it didn't match.

But that might be the correct behavior for ipf, just wanted to point this
out to see if someone who perhaps knows more about this reacts to it.

Section 4.5
"All AVPs included in a Grouped AVP Every Grouped AVP defined MUST
include a corresponding grammar, using ABNF [31] (with
modifications), as defined below."

Strange sentence.

Section 6.1.4
"A request is known to be for local consumption when one of the
following conditions occur:
- The Destination-Host AVP contains the local host's identity,
- The Destination-Host AVP is not present, the Destination-Realm
AVP contains a realm the server is configured to process
locally, and the Diameter application is locally supported, or
- The Destination-Realm AVP is not present."

If the Destination-Host AVP contains a non local host identity and the
Destination-Realm AVP is missing this will evaluate to be a request for
local consumption. But on the other hand, a request with a Destiantion-Host
AVP and without a Destination-Realm AVP is considered wrong, right?!?

Section 6.3
Might want to clearify that the route records removed must be saved with the
pending request so that they can be restored when answering.

Section 7.0
"Figure 8 provides an example of a Diameter message that caused an
application error. When application errors occur, the Diameter entity
reporting the error clears the 'R' bit in the Command Flags, and adds
the Result-Code AVP with the proper value. Application errors do not
require any proxy or relay agent involvement, and therefore the
message would be forwarded back to the originator of the request.

Should one realy return the whole request but with the 'R'-bit cleared and a
result code AVP? Why not have the same abnf for all errors, the request that
caused the error is stored as pending anyway. Set the 'E'-bit and return the
abnf specified in section 7.2.

Section 7.2.

{Destination-Host AVP}

if I'm not misstaken, this avp should never be present in any answers.

Section 8.4
"
When a user session that required Diameter authorization terminates,
the access device that provided the service MUST issue a Session-
Termination- Request (STR) message to the Diameter server that
authorized the service, to notify it that the session is no longer
active. An STR MUST be issued when a user session terminates for any
reason, including user logoff, expiration of Session-Timeout,
administrative action, termination upon receipt of an Abort-Session-
Request (see below), orderly shutdown of the access device, etc."

add something like: "unless an Auth-Session-State AVP was received set to
'NO_STATE_MAINTAINED'."

Section 8.9
Authorization Lifetime is of type Unsigned32, i.e. it can never become a
negative number remove the (-1) or change the number.

Section 8.11
It's not clear that it's the answer from the server that should be applied,
even if it's stated in section 8.0

Section 10.1

Could you send a Class AVP in a DWR? it's marked as 0+ in the table.

Can't all answers have a Failed AVP?

Issue 106: More changes to table in section 4.6
Submitter name: Dave Frascone
Submitter email address: dave@frascone.com
Date first submitted: 31-JUL-2001
Reference:
Document: Base
Comment type: E
Priority: 1
Section: 4.6
Rationale/Explanation of issue:

Ok, I think this is the last of my complaints about Section 4.6 :)

I think all AVPS should have all flags defined in the table. For example,
since Acct-Application-Id no long has a P bit in the "may" column, should we
assume that it is a "must-not" now? I think the ambiguity needs to be cleaned
up and all three bits need to be present under a colum for all AVPs

Requested change:

Include all three bits under a column in the table.

Issue 107: More editorial comments
Submitter name: Tony Johansson
Submitter email address: tony.johansson@ericsson.com
Date first submitted: July 31th, 2001
Reference: N/A
Document: base
Comment type: E
Priority: 2
Section:
Rationale/Explanation of issue:

Page 12, section 2.0, 2nd paragraph:
“The CMS Diameter security application [11]…” should be The Diameter CMS
security application [11]….”

Page 16, section 2.5:
"The following Application Identifier values are defined:

NASREQ 1 [7]
End-to-End Security 2 [11]
Mobile-IP 4 [10]
Relay 0xffffffff"

For consistency the End-to-End Security should be changed to CMS
security.

Page 12, section 2.0, 2nd paragraph:
The two bullets say almost the same thing. So what about deleting the
first sentence in bullet 1 and start with “1. A set of AVPs are defined
to sign and encrypt AVPs…” and keep bullet 2 as is.

Page 68, section 6.2.2, 3rd and 4th paragraph:
“If the agent receives an answer message with a Result-Code AVP
indicating success, and it wishes to modify the AVP to indicate an
error, it MUST issue an STR on behalf of the access device. The agent
MUST then send the answer to the host which it received the original
request from.”

The above paragraph needs to better clarify what the relay/proxy agent
sends back to the access device.

Suggested change:
“If the agent receives an answer message with a Result-Code AVP
indicating success, and it wishes to modify the AVP to indicate an
error, it MUST issue an STR on behalf of the access device. The agent
MUST then send the answer to the access device with the modified
Result-Code AVP indicating the error and MUST also add the
Error-Reporting-Host AVP, which will contain the identity of this
agent.”

Page 78, section 7.1.5,4th paragraph from the bottom:
”DIAMETER_NO_COMMON_APPLICATION 5012
This error is returned when a CEA message…” should be “This error
is returned when a CER message…”

Issue 108: Errata in Mobile-IP Application
Submitter name: Dave Frascone
Submitter email address: dave@frascone.com
Date first submitted: 31-JUL-2001
Reference:
Document: Mobile-Ip
Comment type: E
Priority: 1
Section: 4.0, Throughout
Rationale/Explanation of issue:

Editorial erratta.

Requested change:

In Section 4.0:

MIP-Filter-Rule type should be IPFilterRule.
MIP-Foreign-Agent-Host type should be DiameterIdentity.
MIP-Previous-FA-Host type should be DiameterIdentity.

Throughout:
There is no "FilterRule" type. It should be "IPFilterRule"

Issue 109: Request for a new AVP called Missing-AVP
Submitter name: Tony Johansson
Submitter email address: tony.johansson@ericsson.com
Date first submitted: July 31th, 2001
Reference: N/A
Document: base
Comment type: T
Priority: 2
Section: 7.1.5
Rationale/Explanation of issue:

Page 77, section 7.1.5:
” DIAMETER_MISSING_AVP 5006
The request did not contain an AVP that is required by the
Command Code definition. If this value is sent in the Result-
Code AVP, a Failed-AVP AVP SHOULD be included in the message.
The Failed-AVP AVP MUST contain an example of the missing AVP”

To reduce the amount of processing in the event of a missing AVP it
would be better not have to create the "missing AVP" and add it in a
Failed-AVP. A simpler approach would be to define a new AVP called
Missing–AVP, which just includes the AVP code of the missing AVP.

Requested change:
7.6 Missing-AVP AVP
The Missing-AVP (AVP Code XXX) is of type unsigned32 and contains the
AVP code of the missing AVP. This AVP MUST be added in an answer where
the Result Code-AVP is set to DIAMETER_MISSING_AVP. There could be
multiple Missing-AVP AVPs added in an answer, in cases where more than
one AVP is missing.

Issue 110: MIPv4 comments
Submitter name: Fredrik Johansson
Submitter email address: Fredrik@ipunplugged.com
Date first submitted: Aug 1th, 2001
Reference: N/A
Document: draft-ietf-aaa-diameter-mobileip-07.txt
Comment type: E
Priority: S
Section:
Rationale/Explanation of issue:

Section 1.4
"Figure 7 shows the message flows for a Mobile Node requesting to keep
the Home Agent assigned in Foreign network 1 when it moves to foreign
network 2. Upon reception of the AMR in Foreign network 2, the AAAF
follows the procedures described earlier and forwards AMR to the
Mobile Node's home network, i.e. its AAAH. If the Mobile Node was
successfully authenticated the AAAH checks for the Origin-Host and
the MIP-Previous-FA-Host AVPs. If a AAAH deduces that the Mobile Node
has moved to a new domain, it must check whether the Mobile can still
use the previously assigned Home Agent."

The MIP-Previous-FA-Hoast AVP doesn't exist anymore. Remove it and perhaps
indicate that in order to determine if a mobile has moved the Origin-Host
need to be compared to the Origin-Host received in the previous request
(AMR). Or even better, it will look for the Origin-Realm AVP and compare it
to the Origin-Realm AVP received in the previous request to determine if the
Mobile Node has moved to a new domain.

Section 2.1
"If the MIP-Previous-FA-Host AVP is found in the request, the Diameter
client requests that the server return the registration key that was
assigned to the previous Foreign Agent for use with the Mobile Node
and Home Agent. The registration key is identified through the use of
the User-Name AVP."

Remove the whole paragraph, and also the MIP-Previous-XXXX AVPs from the
abnf code.

Section 2.2 and 2.4
Remove the Destination-Host AVP from the abnf

Section 4.0
Remove the MIP-Previous-XXXX AVPs from the table

Section 5.0

"AAA support for key distribution departs slightly from the existing
SPI usage, as described in [4]. The SPI values are used as key
identifiers, meaning that each registration key has its own SPI
value; nodes that share a key also share an SPI. The Mobile Node
proposes SPIs for use in computing the Mobile-Foreign and Mobile-Home
authentication extensions, via the Mobile IP AAA Key Request
extensions [15], while the Home Agent allocates the Mobile-Foreign,
Mobile-Home and Foreign-Home SPIs."

Does the SPI usage really depart from the one used in mobile ip?

Section 6.5

Is the MIP-Replay-Mode really needed between the Mn and the FA?

Section 6.x
Do we need to change this chapter to not refer to Session Key but to the Key
Material that is used instead?

Section 8.1
The Destination-Host should have 0 on AMA and HAA in the table.

remove MIP-Previous-FA-XXXX from the table

Issue 111: More editorial comments on base-07
Submitter name: Lucius Schmid

Submitter email address: lucius.schmid@innovation.siemens.ca
Date first submitted: Aug. 1. 2001
Reference: N/A
Document: base
Comment type: E
Priority: 1
Section: 5.6
Rationale/Explanation of issue:

Hi,

since there are Disconnect-Peer-x (DPR/DPA) commands codes I suggested to
change the event name "Peer-Disc" to "Rcv-DPR" and the action name
from "Disc" to "Snd-DPA".

Requested change:
pages 58/59, section 5.6: the peer state machine table
replace all "x-Peer-Disc" with "x-Rcv-DPR" and "x-Disc" with "x-Snd-DPA"

page 60, section 5.6.2: Events
replace "Peer-Disc" with "Rcv-DPR" (explanation remains)

page 61, section 5.6.3: Actions
replace "Disc" with "Snd-DPA" (explanation remains)

Issue 112: More editorial comments on base-07
Submitter name: Jacques Caron

Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: August 3, 2001
Reference:
Document: Base-07
Comment type: E
Priority: 1
Section: throughout
Rationale/Explanation of issue:

In 5.3.1:
- 1st paragraph, "...is sent to inform a peer that a reboot has occurred".
I think it's just sent whenever a connection is established, and is not
linked to reboots in any way (other than reboots imply a new connection,
but not the opposite). Might be handy to know a device has rebooted, though
(by including uptime in the CER/CEA messages for instance).

In 5.3.2:
- 1st paragraph, "The Capabilities-Exchange-Request (CEA)" -> "The
Capabilities-Exchange-Answer (CEA)" :-)

In 5.4:
- 1st paragraph, "...disconnects one *of* its transport connections..."

In 5.5.3:
- Status, "the level of confidence in the algorithm". Needs some rewording :-)
- Pending, "This boolean field is set to TRUE when there are no outstanding
unanswered requests". For logic's sake, it should be FALSE when there
aren't any, and TRUE when there are (and modify the rest accordingly --
actually, I think the rest actually thinks pending is true when there are
outstanding unanswered requests...)
- OnReceiveDWA, not sure the "if pcb->status = WAIT_DWA OR pcb->Status =
SUSPECT" is actually needed? It should happen also if status is OK. Also

note the capitalization of status is not constant.
- OnTimerElapsed, a "T = Tw" is missing in the OK block after the
SendWatchdog(pcb)

In 5.5.4:
- 2nd paragraph, "The Hop-by-Hop Identifier field MAY be used to match the
answer with the queued request". Errr, I don't see any other way?
- 3rd paragraph, "it is not possible for forward" -> "it is not possible
*to* forward".
- 4th paragraph, "request or answer" -> "requests or answers"

In 5.6:
- 2nd paragraph, "...a connection is initiated *from* MUST NOT be the port..."
- in the state machine, I still think that (a) two state machines, one for
receiving, one for initiating, would be a lot simpler -- the only place
where they have anything in common is the election after receiving a CEA or
CER, respectively; (b) the "R-Conn-CER" event is a bit too much of a
shortcut since it actually involves multiple sub-events and states.

In 5.6.1:
- 1st paragraph, "This is because the identity of a Diameter peer is
determined by host and port; and the source port of an incoming connection
is arbitrary" -> "This is because the identity of a Diameter peer is
determined by a specific protocol, transport, host and port the peer is
listening on; and the protocol, transport, source address and source port
of an incoming connection are arbitrary."
- 4th paragraph, "the state machine below" -> "the state machine above".

In 5.6 & 5.6.3:
- the state machine states that if a connection is received (R-Conn-CER)
once in Open state, then the new connection is rejected, i.e. disconnected.
A CEA MUST be sent before the connection is disconnected. This is to make
sure that if host A and B already talk to each other, and A finds out it
needs to talk to host C (DNS, SLP, Redirect-Host...), which is actually
another URI for host B, then A must know that C == B. Of course, the CEA
must contain some Result-Code that says there already is a connection and
that this one will be shut down.
- Also I'm not 100% convinced the state machine isn't subject to some race
conditions, though I didn't look into that in detail.

In 6.1:
- 5th paragraph "When a message is received...", references are incorrect:
6.1.1 -> 6.1.4; 6.1.2 -> 6.1.5; 6.1.5 -> 6.1.6.

In 6.1.8:
- in the figure, the Route-Record should be set to nas.mno.net, not
drl.mno.net.

In 6.1.9:
- 1st paragraph, if the AVPs are put in reverse order, then it should be
the FIRST Souce-Route AVP, not the last. Also, that AVP must be removed
after use :-)
- also, need to update 6.1 and 6.1.5 to include source-routing.

In 6.4:
- 1st paragraph, "or broker". I would suppose a broker would only operate
relays, proxies, or redirectors, and could thus never originate messages
(other than errors)? Otherwise, just state "This AVP identifies the node
which originated the Diameter message."
- 2nd paragraph, "The value of the Origin-Host AVP is guaranteed to be
unique within a single host". I would say it must be completely unique for
any given process.

In 6.5:
- not quite sure what the Origin-Realm is for, and not quite sure what the
"realm of the originator" might be. For me, realms are for users, not nodes.

In 6.6 (and other places in 6):
- 1st paragraph, "This AVP MUST be present in all unsolicited agent
initiated messages". Not sure why. The Source-Route AVPs should be enough.

In 6.7:
- maybe we need an AVP derived type for realms?
- "Diameter servers initiating a request message use the value of the
Origin-Realm AVP from a previous message received from the intended target
host (unless it is known a priori)". This is no longer used.

Issue 113: base draft 07 comments
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: August 3, 2001
Reference:
Document: Base-07
Comment type: E
Priority: 1
Section: throughout
Rationale/Explanation of issue:

This is just an older mail I hadn't formally filed as an issue...

In 1.1:
- second paragraph ("All data delivered by the protocol..."): "and AVPs
which are explicitly excluded are not included": there isn't anything in
the ABNF to state that AVPs are excluded.
- last paragraph, "(known as a proxy)" is not consistent with other
definitions in the draft. Should say "(known as a proxy or relay)".
- also, that paragraph defines a server as either a proxy/relay or as a
server. It should be called an agent, or the definition should be changed
to only include the real "server" function.

In 1.3:
- "Accounting record" def is incomplete (ends with "or accounting events
from several").
- the AVP definition is restrictive. It might include protocol-specific
data (e.g. routing information), not only pure AAA data.
- "Diameter node" suddenly mentions translation agents, while this is not
listed in the "Diameter agent" definition
- "Redirector": inconsistent use of "Redirect", "Redirector",
"Re-direct"... [also throughout the draft].
- the definitions of "Upstream server" and "Downstream server", other than
the fact that they are reversed ;-> are incorrect: it should be "nodes" and
not servers, and the definition should be something "a node that is closer
to the client [resp. home server] in the routing path, relative to a given
node". It might be the client [resp. home server] itself, so it does not
necessarily provide "routing services" towards it.

In 2.0
- 5th paragraph ("Diameter proxies..."), "in addition"->"In addition" :-)
- 8th paragraph ("Communication between Diameter peers..."): you mean
nodes, not peers, right?
- in the same paragraph, the last sentence implies that all messages are
related to a session (those messages would actually be exchanged between a
client and a server, not any random set of nodes/peers). This does not
apply to all the base protocol messages such as CER/CEA, DWR/DWA, etc.).
- in the last paragraph, the semantics of Authorization-Lifetime have not
been updated

In 2.1
- 3rd paragraph, "A Diameter node MAY initiate connections from any source
port" *except TBD*?
- same paragraph, "...MAY *be* any of a peer's valid IP addresses."
- where did the 4th paragraph "A given Diameter process SHOULD use the same
port number ..." come from? That's ugly and unnecessary, as the process
identity will be communicated in CER/CEA.
- 5th paragraph, there should be a provision for hosts marked "bad" for
some reason.
- 7th and last paragraph, there is a mix between the sockets API
(ECONNREFUSED) and TCP/ICMP packet exchanges. Should probably replace
"ECONNREFUSED (a reset from the transport)" with "a reset from the
transport" (I think most TCP stacks interpret the ICMP error messages
themselves and return ECONNREFUSED). Actually, this isn't that much the
Diameter implementation itself, but the platform it is using. To be clarified.

In 2.3.1:
- 1st paragraph, "Defining a new AVP value is the best approach when a new
application needs to make use of an existing Diameter application..." Isn't
that recursive? :-(
- last paragraph, "Furthermore, if the command code on which the AVP value
is to be used would require a different set of mandatory AVPs be present
*when the new AVP value is used*, the list of AVPs must accompany the
request." (needs some rewording)
- should reference something in 11.x, but I don't know what :-(

In 2.3.2:
- 1st paragraph, same application/application problem.
- 2nd paragraph, why MUST it be one of the listed types? Since AVPs are
opaque to those who don't use them and the AVP type is not included in the
packet...
- should reference 11.1.1

In 2.3.3
- should reference 11.3

In 2.4
- I guess the whole Acct-Application-Id thing with additional AVPs to
support in the same Accounting messages invalidates the whole ABNF
consistency thing...

In 2.5:
- I guess this is historical, but history in a not-yet-published RFC seems
weird... Why not move the Mobile-IP application to 3?
- I would also swap the E2E security app and NASREQ. The first one is more
like an extension of the base draft while the second (like Mobile-IP) are
real AAA apps.
- oh, by the way, it's CMS, not E2E now :-) [also happens in other places
in the draft]
- 3rd paragraph, "Relay and redirect agents MUST advertise...": what should
an agent that is a server for some requests (those for users in the local
domain) and a relay/redirector for others (users in remote domains) advertise?

In 2.6:
- the Host identity received in CER/CEA MUST be saved! I guess there should
actually be two values: one that is configured (or discovered using DNS,
SLP...) until the connection is established, and then the official unique
but consistent value advertised in CER/CEA. Actually, there might be
several of the configured/discovered identities if the node finds out that
multiple identities point to the same process.
- as discussed previously, I don't think the role belongs here: a peer
might be primary for a realm, secondary for another, alternate for yet
another...

In 2.7
- realm/domain inconsistencies (also throughout the draft), as already
pointed out by Marta.
- Application identifier: should clarify that accounting and auth messages
might actually be sent to different servers
- local action/proxy: "See section 6.1.8 for *proxying* guidelines."
- local action/redirect: why home server? Should just be "agent"...
- "Expiration time. Specifies the time which dynamically discovered a route
table entry expire." -> "Expiration time. Specifies the time which *a*
dynamically discovered route table entry expireS." ("a" moved, "s" added)
- 2nd paragraph "It is important to note...", "proxies SHOULD NOT reorder
AVPs": I would say they MUST NOT reorder AVPs of the same type.
- last paragraph: "When a request is routed, the target server MUST have
advertised the Application Identifier (see section 2.5) for the given
message, or have advertised itself as a relay or proxy agent."... Mmmm.
What if the local node has not connected to that agent (not server, btw)
yet, so doesn't know if it actually advertises the said application? Also,
what should it do if there's a mismatch here?

In 2.8
- 1st paragraph, translation agents are not defined in 1.3
- 4th paragraph "A stateful agent...", Authorized-Lifetime -> Session-Timeout

In 2.8.1
- 4th paragraph "The example provided...", the last part "which is routed
back to NAS using Diameter routing AVPs" is no longer true -> "which is
routed back to NAS using saved transaction state"

In 2.8.2
- 2nd and 5th paragraphs may be a bit too strong: CMS can be applied on
part of the AVPs only (those that would not be modified, e.g.). And CMS
will most certainly apply to AVPs that are not modified (i.e. authorization
answers and accounting requests)

In 3.0
- "r(eserved) - this flag bit is..." -> "these flag bits are..."
- Hop-by-Hop identifier, "The sender MUST ensure that the Hop-by-Hop
identifier in a request is locally unique (to the sender)". This might be
too strong: it actually needs to be unique on a per-connection basis only.
- End-to-End identifier, I guess the method described should only be a
recommendation, not part of the spec (which should state that it must be
unique for a given Origin-Host ID for the lifetime of the message)?
- same paragraph, should mention here that a server is supposed to answer
the same thing it did upon reception of a duplicate, and not take any
action that would affect state again?

In 3.1
- should renumber everything so that we have something consistent and
contiguous rather than this sparse table?

In 3.2
- diameter-name = ALPHA *(ALPHA / DIGIT / "-") should probably be
diameter-name = ALPHA *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)
(I suppose we don't want command names ending with a dash?)

In 5.3.*:
- I guess we should add some AVPs to advertise the local values of the
timers (Ti, Tr, Tw, Td...) so that incompatible values are detected
immediately and the connection torn down with a nice log (a la OSPF IIRC -
or is it IS-IS?)

In 11.3:
- All values, other than zero... -> All other values, except 0...

On a different subject, something I've been thinking about some time ago,
but didn't check against the docs: in a roaming environment, what is
important to an ISP is not that the accounting data from the original
client be signed by that client (it might not know the client at all, and
doesn't care). What they care about is that the accounting data be signed
by their roaming "peer" (partner), i.e. the one that will pay them.
Actually, if the accounting data includes money (you know, $$$), proxies
might change that amount on the way (to reflect margins of brokers), but it
should nevertheless be signed at some point... Some AVPs might actually
have multiple signatures, or be signed, then checked, then modified (old
sig removed), and resigned multiple times on the way.

Issue 114: DiameterIdentity
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: August 5, 2001
Reference:
Document: Base-07
Comment type: T
Priority: 1
Section: throughout
Rationale/Explanation of issue:

There apparently is a lot of confusion surrounding DiameterIdentity, due to
its two very different uses:
1. as a way to designate some way to access a Diameter agent, by (implicity
or explicitly) specifying a FQDN, port, protocol and transport. This shall
be used in configuration files, Alternate-Host and Redirect-Host AVPs, etc.
Note that there might be *a lot* of different DiameterIdentity values that
actually designate the same Diameter agent (as an agent might listen on
multiple ports and addresses, using multiple protocols, and there might be
many FQDNs pointing to any of those addresses).

2. as a way to uniquely identify a given agent for the purposes of
duplicate connection detection, loop detection, etc. In this case, the
identifier must be unique, and should be considered completely opaque by
other servers that should do a pure binary comparison.

To alleviate this confusion, I propose to separate the current
DiameterIdentity derived AVP format into two different formats:

1. the DiameterURI format, using the existing syntax. Used in config files,
Alternate-Host and Redirect-Host AVPs...

2. the DiameterIdentity format, using a new syntax, the only purpose of
which is to make sure it is unique (and as a side effect, a lot shorter,
which should help a lot in Route-Record and Source-Route AVPs).

Proposed changes:

In 2.6, replace the Host identity section with:
- Host URI, following the conventions described for the
DiameterURI derived AVP data format in section 4.4. This MAY be
found by static configuration, or dynamically updated via any of
the methods described in section 5.2. Note that there might be
multiple DiameterURIs resolving to the same peer.
- Host Identity. Following the conventions described for the
DiameterIdentity derived AVP data format in section 4.4. This
is copied from the Origin-Host AVP of the CER or CEA message
received from the peer.

In 4.4, replace the DiameterIdentity section with:

DiameterURI
The DiameterURI format is derived from the OctetString AVP
Base Format. It uses the UTF-8 encoding and has the same
requirements as the UTF8String. In addition, it must follow
the Uniform Resource Identifiers (URI) syntax [29] rules
specified below:

Diameter-URI = fqdn [ port ] [ transport ]
[ protocol ]

aaa-protocol = ( "diameter" | "radius" | "tacacs+" )

protocol = ";protocol=" aaa-protocol
; If absent, the default AAA protocol
; is diameter.

fqdn = Fully Qualified Host Name

port = ":" 1*DIGIT
; One of the ports used to listen for
; incoming connections. ; If absent,
; the default Diameter port (TBD) is
; assumed.

transport-protocol = ( "tcp" | "sctp" | "udp" )

transport = ";transport=" transport-protocol

; One of the transports used to listen
; for incoming connections. If absent,
; the default SCTP [26] protocol is
; assumed. UDP MUST NOT be used when
; the aaa-protocol field is set to
; diameter.

The following are examples of valid Diameter host
identities:

host.abc.com;transport=tcp
host.abc.com:6666;transport=tcp
aaa://host.abc.com;protocol=diameter
aaa://host.abc.com:6666;protocol=diameter
aaa://host.abc.com:6666;transport=tcp;protocol=diameter
aaa://host.abc.com:1813;transport=udp;protocol=radius

A DiameterURI describes a way to connect to any Diameter agent.
It shall be used in configuration files, Alternate-Host and
Redirect-Host AVPs, etc.

DiameterIdentity
The DiameterIdentity format is derived from the OctetString AVP
Base Format. It uniquely identifies a Diameter agent, for the
purposes of loop and duplication connection detection. Upon
startup, the agent must select one specific (address,
transport, port) tuple it is listening on for new connections,
and encode the associated information in one of the formats
described below. Since only one single process can be listening
on a given (address, transport, port) tuple, the identity is
guaranteed to be unique (see below for non-unique addresses).

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved(0) | Protocol | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This format is used for agents listening on IPv4 addresses
only. Protocol is the protocol number of the transport used,
i.e. XXX for TCP or XXX for SCTP. The 'Port' and 'IPv4 Address'
fields contain the port and IPv4 address selected,
respectively, in network byte order.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved(0) | Protocol | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This format is used for agents listening on at least one unique
(i.e. not link-local, etc.) IPv6 address. If the agent is
listening on both IPv4 and IPv6 addresses, it should select a
tuple with an IPv6 address. 'IPv6 address' contains that value.
The other fields have the same meaning as above.

Note that these formats are guaranteed to be unique only for
hosts that have unique IP addresses, i.e. not for hosts that
use RFC1918 "private" IP addresses. Hosts using RFC1918
addresses MUST append a unique IP addresses (administratively
configurable) that is related to the routing domain they're
part of, such as the public IP address of the host acting as a
gateway to the public Internet.

A DiameterIdentity value is thus either 8, 20, 24, or 36 bytes
long, depending on the presence of one or two addresses, each
of which can be 4 bytes (IPv4) or 16 bytes (IPv6) long.

Other formats can be used, as long as the binary
reprensentation is globally unique for any given host. This
requires the use of values other than 0 for the "reserved"
field, which should then be registered with IANA.

Any use of AVPs using the DiameterIdentity format MUST consider
their contents as opaque. Any comparison MUST be purely binary
(i.e. two values are equal if they have the same length and all
bytes match; in all other cases they're not equal). An ordered
comparison is also defined in section 5.6.4.

In 5.3.8, s/Identity/URI/

In 6.4, remove 3rd paragraph.

Replace 6.8.1 with:
The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The
identity added in this AVP MUST be the same as the one received in the
Origin-Host of the CER or CEA message received from the peer.

In 6.12, s/Identity/URI/

In 8.8, either:
- s/Identity/URI/ + some wording to say it's one of the URIs designated the
host,
- or use decimal-encoded Identity
- or move to purely binary

Some other changes might be needed in the other drafts.

Issue 115: CHAP-Password is complex
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: August 6th, 2001
Reference:
Document: NASREQ 07
Comment type: T
Priority: S
Section: 3.1.1.2
Rationale/Explanation of issue:
The definition of the CHAP-Password AVP in -07 still shows up as being of
type complex. This needs to be changed to a Grouped AVP, and some
additional text on how RADIUS<->Diameter translation is needed.

Requested change:
Make the AVP Grouped

Issue 116: Accounting-Session-Id definition incorrect
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: August 6th, 2001
Reference:
Document: NASREQ 07
Comment type: T
Priority: S
Section: 9.8.4
Rationale/Explanation of issue:
The definition of the Accounting-Session-Id states that this AVP is
only used for RADIUS gateway purposes, but other text in the draft
shows that this AVP is used to identify Accounting subsessions.

Requested change:
Leave Accounting-Session-Id as-is, and create a new AVP called
Accounting-Sub-Session-Id, and change the necessary text.

Issue 117: Remove support for Source-Route
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: August 6th, 2001
Reference:
Document: NASREQ 07
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
Support for explicit paths for server-initiated messages was added in
-07. Discussions I have had with folks this week show that consensus
is that this feature is overly complex, and we should instead require
that the network is configured properly.

Requested change:
Go back to -06 way of server initiated messages.

Issue 118: Error processing/capabilities negotiation
Submitter name: Jacques Caron
Submitter email address: jacques_m_caron@yahoo.com
Date first submitted: August 6, 2001
Reference:
Document: Base-07
Comment type: E
Priority: 1
Section: throughout
Rationale/Explanation of issue:

In the current draft, there are many situations where any agent can return
an error when processing a message (e.g. when receiving an AVP tagged with
the 'M' bit that it doesn' accept). However, there are no provisions for
sending an error in response to an answer (an error is an answer, and can
only be sent in response to a request).

This makes it difficult to handle some cases, especially end-to-end
capabilities negotiation (e.g. server wants access device to set up some
filter, encryption, IP address, route..., but access devices cannot/will
not do it: there is no way for the access device to communicate this back
to the server).

I think the best approach is to move from the simple Request/Answer model
to a Transaction model possibly involving multiple round-trips until
everybody is satisfied. Another possibility is for access devices to
advertise their capabilities in advance in the initial request, but that
might be quite difficult.

Follows a (longish) description of one possible implementation using the
Transaction model. I think most people might find it waaaaaay too complex, but:
(a) it gives a clear understanding of the process and the several
round-trips, why they are needed, and when.
(b) there are hints at the end as to ways to simplify this A LOT :-)

Creativity welcome :-)

The following messages can be exchanged between two nodes:

Msg Dir Description Expects
------ ---- --------------------------------------- ---------------------------
REQ C->S request WMORE, AUTH, REJECT, ACCEPT
MORE C->S error or additional information WMORE, AUTH, REJECT, ACCEPT
NAUTH C->S auth not accepted, need new one AUTH, REJECT
ACK C->S auth accepted ACCEPT
ABORT C->S transaction abort REJECT

WMORE S->C request for more information MORE, ABORT
AUTH S->C authorization information ACK, NAUTH, ABORT
REJECT S->C reject connection/non-recoverable error (nothing)
ACCEPT S->C accept with negociated authorization (nothing)

"server" and "client" are defined here solely in the context of the given
transaction, the client being the node initiating the transaction, and the
server being the node that is supposed to provide an answer.

REQ is the first message of a transaction, including application, realm,
etc. It is routed according to the realm routing table towards the server
for regular access-device to home-server transactions, and using
source-routing for home-server to access-device transactions. Routing
information is collected on the way and stored in Route-Record AVPs.

MORE is sent whenever the client needs to send additional or modified
information in a transaction. It might be due to capabilities negociation
(e.g. the server didn't understand an 'M'-AVP) or a multi-round-trip auth
(e.g. EAP), that were signalled by the server using a WMORE message.

NAUTH is sent whenever the client received authorization information (AUTH)
for the transaction, but isn't satisfied with it (e.g. there is an 'M'-AVP
that it doesn't accept). It includes the usual AVP-related info (missing
AVP, bad AVP value, unrecognized AVP...), possibly with hints about
accepted values (I like very much the modem AT command set extensions such
as AT+command=? that give a list of allowed values, would be cool if we
could have something equivalent here).

ACK is sent once the client got authorization information for the
transaction (AUTH) from the server, and is satisfied with it.

ABORT is sent by the client if it got a WMORE message and cannot provide
any new or modified information (e.g. the server didn't accept an 'M'-AVP,
but the access device absolutely needs it), or got an AUTH message and
doesn't accept some of the values and doesn't want to negotiate them.

MORE, NAUTH, ACK, and ABORT are sent with Source-Route AVPs from the WMORE
or ANS message.

WMORE is sent by the server to the client if it needs the client to send
additional or modified information (using a MORE message). It includes info
about what it wants (e.g. further EAP messages, or modified AVPs).

AUTH is sent by the server when it has any authorization information it
wants to send the client.

ACCEPT is sent by the server to the client to give a final yes, either
directly after receiving info (REQ or MORE) if it only says "yes", or after
receiving an ACK accepting previous AUTH information.

REJECT is sent by the server to the client if the transaction was refused
or if there was an unrecoverable error, or if the server got a NAUTH to an
AUTH message and doesn't want to negotiate, or to confirm it got an ABORT.

All messages from server to client (WMORE, AUTH, ACCEPT, REJECT) are routed
using stored message state in proxies/relays. They also carry Route-Record
information to help routing of further messages from client to server.

Note that "authorization" (and of course AUTH and NAUTH) is an abuse, it's
actually any negotiable AVPs the server sends to the client, but the only
case I could think of is authorization information.

So, in the simplest case, the scenario would be:
REQ ->
<- ACCEPT

If there is any authorization information:
REQ ->
<- AUTH
ACK ->
<- ACCEPT

In a simple 2-round trip EAP auth, the scenario might be:
REQ ->
<- WMORE
MORE ->
<- AUTH
ACK ->
<- ACCEPT

In a simple one-round trip auth, but where the access devices doesn't agree
with the authorization parameters the first time, it would be:
REQ ->
<- AUTH
NAUTH ->
<- AUTH
ACK ->
<- ACCEPT

Server doesn't understand/accept an AVP the client sent, and the client
doesn't want to do without:
REQ ->
<- WMORE
ABORT ->
<- REJECT

Server thinks the access device is completely out of its mind, or knows
right away the user is not allowed:
REQ ->
<- REJECT

More generally, for a successful transaction:
REQ ->
[
<- WMORE
MORE ->
]*
[
<- AUTH
[
NAUTH ->
<- AUTH
]*
ACK ->
]?
<- ACCEPT

Note that it may require adding a transaction identifier. Alternatively,
the session identifier may be enough?

On a final note, it might be possible to reduce the number of possible
message types (by using some other AVP, e.g. different ranges of
Result-Code), but it must be possible for relays/proxies to track a
transaction state, i.e. know when it ends (by either a REJECT or an
ACCEPT). All that is needed (as seen from the outside) are "Request"
(anything client to server), "Continue" or "Challenge" (WMORE, AUTH) and
"Answer" (REJECT, ACCEPT). This could be done by classifying correctly all
Result-Codes that require further exchanges in a different range than those
that don't. In particular, that means that any answer with negotiable AVPs
should be in the first category, since they need another request to either
accept them, or ask for changes.

Jacques-in-complex-mode.

Issue 119: E bit, P bit, and proxy-info
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 13-Aug-2001
Reference: N/A
Document: base
Comment type: T
Priority: 2
Section: 6.1.7, 6.2, and 7.2
Rationale/Explanation of issue:

1. Can a Diameter packet contain both a 'P' bit and a 'E'
bit in the packet header?

2. Will a Diameter packet with the 'P' bit set contain the
proxy-info data from the request?

Requested change:

A diameter error packet with an 'E' bit set MUST have the
required AVPS listed in section 6.2, "Diameter Answer
Processing".

Modify section 6.2 to state that these requirements are valid
even if the 'E' bit is set.

Modify section 7.2 to list the answer-message as
::= < Diameter Header: code, ERR [PXY] >
and state that the 'P' bit will be set the same as the 'P'
bit in the request.

I'm not certain if we need to modify section 6.1.7. It will be
technically correct with the requested changes, but probably
could be made more clear.

Issue 120: Minor editorial changes in CMS Security Application
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-14
Reference:
Document: CMS-02
Comment type: E
Priority: 1
Section: 1.1, 1.2, 1.3, 2.0, 3.1, 3.2, 4.3, 5.0, 6.2
Rationale/Explanation of issue:
Minor editorial changes in draft

Requested change:

In 1.1, page 5 (fourth paragraph):
replace "...requires that the initiator issue a..." with "...requires
that the initiator issues a..."

In 1.2, figure 3:
replace "PDSR" with "PDSAR" and "PDSA" with "PDSAA"

In 1.3, page 7:
rephrase the first paragraph. Maybe the following proposal would be
enough:

When a redirect agent is used, allowing the access device, or first
hop relay or proxy agent, to communicate directly with the home
server, the hop-by-hop security mechanisms specified in the base
protocol MAY be sufficient.

In 1.3, page 7 (second paragraph):
replace "...signing of select Diameter..." with "...signing of
selected Diameter..."

In 1.3, page 7 (second paragraph):
replace "AVPS" with "AVPs"

In 2.0, page 9 (last paragraph):
replace "section 4.5 of [1]" with "section 4.6 of [1]"

In 3.1, page 11 (first item in second list):
replace "TTL for this SA" with "TTL for this DSA"

In 3.1, page 11 (first item in last list):
replace "the certificate chain selected is..." with "the certificate
chain provided [in the DSAA] is..."

In 3.1, page 12 (first paragraph):
replace all references to "Diameter node" with "Diameter initiator"

In 3.2, page 12 (first item of the list):
replace "Diamater" with "Diameter"

In 4.3, page 16:
replace "an Security Association" with "a Diameter Security
Association"

In 5.0, page 18:
replace all references to "proxy server" with "relay agent"

In 6.2, page 21 (second paragraph):
replace "CMSEnvelopedData" with "EnvelopedData"

In 6.2, page 21 (third paragraph):
replace "CMS-Data" with "CMS-Encrypted-Data"

Issue 121: More editorial changes in CMS
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-14
Reference:
Document: CMS-02
Comment type: E
Priority: 2
Section:
Rationale/Explanation of issue:
Sentences of the type "the x message must be signed" are confused
since not the whole message is signed but only the required AVPs

Requested change:
Change all occurrences of "the x message must/may/should be signed"
with "the x message must/may/should include (or carry) an appropriate
digital signature"

Issue 122: Editorial change in draft-ietf-aaa-diameter-07.txt
Submitter name: Martin Andersson
Submitter email address: martin.andersson@ipunplugged.com
Date first submitted: 2001-08-20
Reference:
Document: draft-ietf-aaa-diameter-07.txt
Comment type: E
Priority: 2
Section: 4.6 & 7.5
Rationale/Explanation of issue:

The table in section 4.6 states that Failed-Avp should be of type OctetString
while section 7.5 states it should be of type Grouped.


Requested change:
Change Section 4.6 to state that the Failed-Avp is of type Grouped

Issue 123: Use of Application Identifiers in routing
Submitter name: Srinivas Sreemanthula
Submitter email address: Srinivas.Sreemanthula@nokia.com
Date first submitted: August 16, 2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: 2.5 Last paragraph
Rationale/Explanation of issue:
In the first sentence, one may interpret the text that the use
of application identifiers in the routing is a necessary requirement.
We feel that the use of application identifiers while routing is
optional whereas the routing must be based on the destination realm
contained in the message. This would provide a flexible scenario
where proxies and relays always need to be able to route based on the
realm, and in addition, they may choose to route based on application
identifiers, as well. This would also allow for implementation
scenarios capable to hide the network topology or distribute the
server functions within a realm by use of a "gateway" diameter nodes
.

Requested Change:
Rephrase section 2.5 last paragraph, first sentence to:
"While the diameter relay and proxy agents MUST know how to
route messages based on the destination realm indicated in the
message, they MAY be able to route the messages also based on the
application identifiers of a particular message."

Issue 124: Inconsistency in OCSP-Request-Flags AVP
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-20
Reference:
Document: CMS-02
Comment type: T
Priority: S
Section: 3.1
Rationale/Explanation of issue:
The usage scenario chapter states that a DSAR message contains, among
other information:

- (optionally) a flag indicating that the originating Diameter
node wishes to receive certificate status information (using
OCSP messages) ...

So that, the OCSP flag (I suppose we're talking about
OCSP-Request-Flags AVP) is claimed as optional. However, the format of
the DSAR messages indicates that OCSP-Request-Flags are mandatory
(i.e. it's the nonce value what is optional, since it depends on the
requestes OCSP response):

::= < Diameter-Header: 304, REQ, PXY >
...
{ OCSP-Request-Flags }
...
[ OCSP-Nonce ]
...

Requested change:
Replace the previous paragraph from usage scenario chapter (the whole
paragraph) with this one:

- a flag indicating wheter the originating Diameter
node wishes to receive certificate status information using
OCSP messages. If this flag requires a fresh OCSP response,
a nonce to be used by the destination Diameter node in OCSP
requests MUST also be supplied.

Issue 125: Inconsistency in OCSP-Responses AVP
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-20
Reference:
Document: CMS-02
Comment type: T
Priority: S
Section: 3.1, 4.2
Rationale/Explanation of issue:
The usage scenario chapter states that a DSAA message contains, among
other information:

- (optionally, if nonce received and OCSP supported) a list of
OCSP responses for the certificates in question, each of which
contains the nonce from the DSAR message

However, the format of the DSAA messages indicates that OCSP-Response
AVP is mandatory:

::= < Diameter-Header: 304, PXY >
...
* { OCSP-Responses }
...
Furthermore, the chapter describing OCSP-Responses AVP says the
following:

The OCSP-Responses AVP [...] contains an OCSP response message from
an OCSP responder. If the OCSP-Request-Flags AVP indicating a
response was required in the corresponding request message, the
OCSP-Responses AVP MUST be present. Furthermore, the
OCSP-Request-Flags AVP MAY request a fresh OCSP response message,
which MUST also include the OCSP-Nonce AVP.

Which looks to suggest that if OCSP-Request-Flags AVP in DSAR was
OCSP_RESPONSE or OCSP_FRESH_RESPONSE (with an OCSP-Nonce associated)
there must be an OCSP-Response AVP. But not in the rest of the
possibilities (NO_OCSP_RESPONSE).

Requested change:
Replace the previous paragraph from usage scenario chapter (3.1) with
this one:

- (optionally, if OCSP response was required in the DSAR and OCSP
is supported) a list of OCSP responses for the certificates in
question. If a fresh response was required and a nonce value
was
included, each response will contain the nonce from the DSAR
message

Replace the mandatory field of DSAA in 4.2:

* { OCSP-Responses }

with an optional field

* [ OCSP-Responses ]

Issue 126: Clarification in certificate naming schema
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-20
Reference:
Document: CMS-02
Comment type: Technical
Priority: S
Section:
Rationale/Explanation of issue:

The naming schema of AAA servers certificates are spread among
different chapters in the specification.

In 1.5 it's said that "The realm of the participants is found in the
subjectAltName field of the Diameter server's X.509 certificate".

In 3.1, between the checks done by the DSA initiator when the DSAA is
received, it's said that:

- the realm part of the user's NAI must occur as a subjectAltName
(with the dNSName option) in the AAA server's certificate. This
dNSName MUST be of the form "Diameter-." where
is the FQDN's domain component and can be
anything (e.g. "Diameter-1.baltimore.com", "Diameter-
west.sun.com") chosen by the Diameter server administrator.

Finally, a whole chapter (3.2. Certificate Requirements) deals with
the same topic. Specifically, it's said that:

Certificates [...] MUST also include a Diameter node's FQDN, which
is typically added in the Host-Name AVP [1], as one of the values
of
the subjectAltName extension of the Certificate.

And

For Diameter nodes (capable of acting as recipients for
confidentiality), the FQDN MUST be of the form "Diameter-
.".

And last but not least

1. Where a Diameter node is verifying a signature it needs to be
able to compare the identity of the signer against the identity
in the Host-Name AVP.

Requested change:

The main purpose would be to clarify the whole topic. I'd suggest:

- Unifying the terminology. Using "realm" always or "domain" always.
- To switch the long explanation of chapter 3.1 to a more appropriate
place (chapter 3.2), including a reference to it in the item of 3.1
chapter.
- Explaining which AVP is Host-Name AVP


Additionally I'd like to receive a clarification about the realms
involved. I suppose that the "realm part of the user's NAI" is carried
by means of the Destination-Realm in the DSAR, but I'm not sure. BTW

Issue 127: Editorial changes in CMS
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-20
Reference:
Document: CMS-02
Comment type: E
Priority: 2
Section:
Rationale/Explanation of issue:
The name "Response" in OCSP-Responses is plural.

Requested change:
Change all occurrences of "OCSP-Response" with "OCSP-Responses"

Issue 128: duplicate packet detection in failure case
Submitter name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: August 20, 2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: In section 9.4 Fault Resilience,
Rationale/Explanation of issue:

The text in 9.4 may not be sufficient in failure cases. Some text is needed
to describe how to handle the failure case.

Requested Change:

Additional text should be added to discuss

The sending party sends the (maximal amount = the used send window size)
unacknowledged packets (after a link failure) to the next available
secondary/tertiary/etc. alternative recipient node (CG), with a mark that
they are potential duplicates, to wait there for a final decision.

After the original link comes up, the original sender tests with empty dummy
packets if the original recipient would acknowledge those packet numbers as
"already successfully handled" or "new".

Then the sender just announces the secondary node which waiting packets it
may release towards the final destination (like BS), and which waiting
potentially duplicated packets to cancel (since they had already been
successfully handled by the original recipient node just before its link
went down.

Issue 129: NASREQ unsolicited challenge requests
Submitter name: Kevin Purser
Submitter email address: kevin.purser@ericsson.com
Date first submitted: August 21, 2001
Reference: none
Document: NASREQ-07
Comment type: 'E'ditorial
Priority: 'S' Must fix
Section: 3.0
Rationale/Explanation of issue:
The last paragraph of this section describes the possibility for a AAA
server to "issue an unsolicited re-authentication and/or re-authorization by
issueing an AA-Challenge-Ind message to the NAS."

First and foremost, this kind of message no longer exists. Additionally,
submitted issue #32 handles the technical issues regarding the removal of
such messages.

Requested change:
Remove the last paragraph of section 3.0

Issue 130: Prescribed use of encryption in NASREQ
Submitter name: Kevin Purser
Submitter email address: kevin.purser@ericsson.com
Date first submitted: August 21, 2001
Reference: none
Document: NASREQ-07
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: 3.1.1.1
Rationale/Explanation of issue:=20
This section mentions that the User-Password AVP "MUST be encrypted =
using of the methods described in [2] or [13]," where [2] is the Base =
Protocol, and [13] is the CMS Security Application. Of the mechanisms =
described in the Base Protocol, neither IPsec or TLS deal with =
encrypting portions of a diameter message, but rather the entire message =
itself.

Requested change:=20
Remove the reference to [2], leaving only the reference to [13].

Issue 131: Use of Auth-Request-Type in NASREQ
Submitter name: Kevin Purser
Submitter email address: kevin.purser@ericsson.com
Date first submitted: August 21, 2001
Reference: none
Document: NASREQ-07
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 3.0
Rationale/Explanation of issue:
In the second paragraph, "...it is possible to send a request for =
authorization only. The type of service depends upon the =
Auth-Request-Type AVP." However, the use of this AVP is not mandatory =
in any of the messages defined in the NASREQ application, which may =
produce situations where the desired functionality (only =
re-authentication, only re-authorization, or both) is ambiguous.

Requested change:=20
Make the Auth-Request-Type AVP mandatory in the AAR and DER, and at =
least optional in the AAA and DEA to allow the AAA server to indicate =
the desired functionality (only re-authentication, only =
re-authorization, or both) expected.

Issue 132: Multiple signatures on a set of AVPs
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section: 6.1
Rationale/Explanation of issue:

In 6.1 it's stated that:

Multiple Diameter entities MAY add their signatures to an existing
CMS-Signed-Data AVP using the countersignature attribute, defined
in
section 11.4 of [3]. The countersignature attribute requires that
the
signatures occur sequentially, meaning that each signature covers
the
existing signatures in the CMS object.

May I assume that this is the only way to add multiple signatures? If
so, there will be only one singerInfo in a SignedData value (including
a message-digest attribute) and that multiple signatures will be
handled only like countersignature attributes (which allows not to
resign the whole set of AVPs)

Requested change:

If so, I'd change the previous paragraph to say:

Multiple Diameter entities MAY add their signatures to an existing
CMS-Signed-Data AVP. It MUST be done using the countersignature
Attribute (defined in section 11.4 of [3]) and not as additional
SignerInfo values. The countersignature attribute requires that the
signatures occur sequentially, meaning that each signature covers
the
existing signatures in the CMS object. This attribute MUST be
always
unsigned.

Issue 133: digest value within CMS-Signed-Data AVP
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: E
Priority: 1
Section: 6.1
Rationale/Explanation of issue:

In 6.1 (last sentence of page 20), it's stated that not the whole
content being signed but just a digest is inserted:

Instead, the digest value within the SignedData
structure contains the digest produced in the
signature process.

This paragraph isn't clear so that there isn't any digest value within
a SignedData structure. The correct name for it is message-digest
attribute type (as defined in [CMS, 11.2]). An attribute of this type
may be inserted into any of the SignerInfo values that comprises
Signed Data SignerInfos (take into account that this value would be
the same for all the SingerInfo value, so that only one digest
algorithm must be supported in [CMSSec]). However, this attribute is
only required (in [CMS, 11.2]) if any other attribute is present (if
present, message-digest is a SignedAttribute). As the [CMSSec]
specification allows countersignature operations, an attribute of this
type must be required.

Requested change:

I'd replace the previous sentence with:

Instead, the digest value of the AVPs produced in the
signature process MUST be included in the CMS-Signed-Data
AVP as a message-digest attribute in the SingerInfo value.
This attribute MUST be always signed.

Issue 134: Several CMS-Encrypted-Data AVPs in a message
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: E
Priority: 1
Section:
Rationale/Explanation of issue:

In 6.2 it's stated that:

CMS-Encrypted-Data MAY contain more than one CMS object, that is,
implementations MUST be able to add a new CMS-Encrypted-Data AVP
value and also MUST be able to decrypt all CMS-Encrypted-Data AVP
values which are encrypted for them.

This text isn't clear for me:

- The first sentence ("CMS-Encrypted-Data MAY contain more than one
CMS object") might suggest that it is possible to encrypt several AVPs
into a CMS-Encrypted-Data AVP (even if those AVPs are also
CMS-Encrypted-Data AVPs). That is, it might refer to nested
enveloping.

- However, the next sentence, which is a consequence of the previous
("implementations MUST be able to add a new CMS-Encrypted-Data AVP
value") isn't straightforward since it doesn't specify to what it can
be added (to the message or maybe to an AVP?). I mean, it might
suggest that an implementation MUST be able to add a new
CMS-Encrypted-Data AVP to a message.

- The last sentence ("also MUST be able to decrypt all
CMS-Encrypted-Data AVP values which are encrypted for them")
contradict my previous interpretation. If there're nested encryption,
just the "last" envelope could be opened, so that a nested envelope
couldn't be opened by the receiver unless he opened the external
envelopes. On the other hand, with different CMS-Encrypted-Data AVPs
inside the same message and with different recipients, any AVP would
be opened by the its intended recipient.

Another possibility is that the paragraph is trying to say that new
RecipientInfo values may be inserted. But that fact can't be true
since it would be necessary for an entity trying to do that to be a
recipient to be able to decrypt the CEK and reencrypt it with a new
key.

Requested change:

Replace the quoted paragraph (and maybe the next one) with a more
clear text.

Issue 135: contentType instead of eContentType in CMS-Encrypted-Data
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: E
Priority: S
Section:
Rationale/Explanation of issue:

In 6.2 it's stated that:

Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the
eContentType of the EncapsulatedContentInfo MUST be id-data [11].

However, EncapsulatedContentInfo is the type of the value
encapContentInfo inside the CMS SignedData type, not EncapsulatedData.

Requested change:

Replace the previous paragraph with:

Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the
contentType of the EncryptedContentInfo value MUST be
id-data [11].

Issue 136: Proxy's DSAR on behalf of a client
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

If the agent agrees on using the proxy, I assume that the proxy
establishes the DSA with the AAA server using some of the parameters
provided by the agent in the first DSAR. I think that, at least, same
TTL, Expected-Encrypted-AVP and Expected-Signed-AVP have to be used.
However, shouldn't this point deserve some kind of guideline? For
example, which AVPs values has to be just copied into the newly
created DSAR? Or, which AVPs can be changed?

Requested change:

Add clarifying text

Issue 137: CMS Proxy's DSAAs
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

When a proxy is involved in the establishment of a DSA, the proxy will
reject the DSA indicating to the agent that:

- it is not possible to establish a DSA (Result-Code is
DIAMETER_NO_CMS_THROUGH_PROXY)
- it can act as a CMS proxy on behalf of it (Result-Code is
DIAMETER_CAN_ACT_AS_CMS_PROXY). According to 1.2:

The DSAA MUST be signed by the proxy agent, and include its
certificate, to allow the access device to validate the
originator of the DSAA.

However, being the Result-Code a permanent failure code, the message
will have the 'E' bit set, so that the message will not conform to the
ABNF described for the command (DSAA). Then, on which AVPs is going to
be applied the digital signature?

Requested change:

Add clarifying text

Issue 138: Signed DSA messages
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

In some points of the specification, is stated that a DSA message
must/may be signed:

In 1.2:

The DSAA MUST be signed by the proxy agent, and include its
certificate, to allow the access device to validate the originator
of the DSAA.

In 1.3:

The CMS specification allows for Diameter AVPs to be
multiply-signed

In 3.1

- the DSAA message MUST be digitally signed and the signature
MUST be validated and the signer's certificate chain MUST
terminate as a CA mentioned in the DSAR message

and also

The DSAR MAY be signed. If the originating node has a private key
and protection expectations for AVPs are specified, then the DSAR
SHOULD be signed.

The DSAA MUST be signed by a Diameter agent or server within the
user's realm, to prevent an intermediate node from modifying the
protection expectations for AVPs.

Pat has agreed on changing that expression and saying that "...
(MAY|MUST) include the CMS-Signed-Data AVP".

However, I'm a little bit concerned when the presence of a
CMS-Signed-Data AVP is required. This AVP contains a digital signature
on other (or others) AVPs. Those protected AVPs must have the 'P' bit
set. But let's imagine that neither of the AVPs included in the
message have the 'P' bit set (maybe because the implementation does
not consider that they must be protected). I assume that the
implementation must detect those cases and, when a CMS-Signed-Data AVP
is required, set the 'P' bit of an AVP, maybe chosen randomly or maybe
fixed in the configuration (for example, the DSA-TTL AVP is always
present, so that the implementation might be configured to protect it
always when a digital signature is required). Is this issue up to the
implementation or should be specified in the specification?

Requested change:

Add clarifying text

Issue 139: Key Management chapter rephrasing
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-23
Reference:
Document: CMS-02
Comment type: E
Priority: 2
Section: 3.0
Rationale/Explanation of issue:

In 3.0 chapter a number of issues are listed in order to provide
solutions for them in the rest of 3.x chapters.

However, phrases like:

"a specific Diameter key distribution mechanism is defined here"
"Another issue that must be addressed..."
"This section describes..."

aren't lucky since there isn't a specific mention to which chapters
will actually address the issues.


Requested change:

Add clarifying phrases in order to state the chapters in which any
issue will be addressed.

Issue 140: Can Answer be rejected?
Submitter name: Martin Julien
Submitter email address: martin.julien@ericsson.com
Date first submitted: 23/08/01
Reference:
Document: Base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

It is not really clear in the draft whether or not answer
messages can be rejected. Should it be allowed or not?

That needs to be clarified in the draft.

Issue 141: OCSP Response request additional text
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: E
Priority: 2
Section: 3.1
Rationale/Explanation of issue:

An additional clarifying text might be added to depict the way in
which OCSP responses are required.


Requested change:

Replace the following paragraph:

If certificate status (revocation) is an issue for the Diameter
initiator, then the DSAR message MAY contain a nonce value. The
idea
is that the sender of the DSAA makes OCSP requests on behalf of the
Diameter initiator and returns the OCSP responses to the Diameter
initiator as part of the DSAR message. The use of the nonce value
ensures that the sender of the DSAA cannot return cached or
otherwise fake OCSP responses to the Diameter initiator.

with this one:

If certificate status is an issue for the Diameter initiator (it
has
been configured to check if the certificates has not been revoked),
then the DSAR message MUST contain a flag indicating that it wishes
to receive certificate status information. The DSAR message MAY
contain a nonce value (depending on whether the initiator wishes a
"fresh" response). The idea is that the sender of the DSAA makes
OCSP requests on behalf of the Diameter initiator and returns the
OCSP responses to the Diameter node as part of the DSAR message.
The
use of the nonce value ensures that the sender of the DSAA cannot
return cached or otherwise fake OCSP responses to the Diameter
node.
If the initiator indicated that no fresh response was required (so
that no nonce value was provided) it MAY accept a stale response.

Issue 142: CEKMaxDecrypts value vs DSA length
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-23
Reference:
Document: CMS-02
Comment type: T
Priority: S
Section: 3.4
Rationale/Explanation of issue:

As stated in 6.2, CEK reuse should be supported by Diameter nodes. The
description of the open issues left by the "Reuse of CMS CEKs" is done
in 3.4. When talking about the maximum number of decryptions allowed
it's said that may be higher than 1 (the default value).

But, which is the relationship between the maximum number of
decryptions and the length of the DSA? I mean, is it possible to reuse
a CEK even if the DSA has already expired?

Requested change:

Add clarifying text

Issue 143: Editorial changes in CMS #4
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-23
Reference:
Document: CMS-02
Comment type: E
Priority: 2
Section: 3.1, 3.2, 4.3, 6.2, 11.0
Rationale/Explanation of issue:

Requested change:

In 3.1 (last line):
replace "certicate" with "certificate"

In 3.2 (last point in page 12):
replace "certificiates" with "certificates"

In 3.2 (first item in page 13):
replace "certfificates" with "certificates"

In 4.3 (title)
replace "Assocation" with "Association"

In 6.2 (second last paragraph)
In order to maintain coherence, replace "content encryption key
re-use" with "content encryption key reuse"

In 11.0:
replace "S/MIME v2 Message Specification" with "S/MIME v2 Message
Specification"

Issue 144: OCSP Support
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-23
Reference: Issue 125 (Inconsistency in OCSP-Responses AVP)
Document: CMS-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

The specification doesn't mention which level of requirement OCSP has.

When reading the specification, I've found that OCSP may be used with
two different purposes:

- Certificate validation in order to decide if a certificate in cache
can be used or not.
- Certificate validation on behalf of other DSA participant.

Although the purposes is different, the implementation would be the
same. However, how mandatory is the OCSP support? The specification
itself only seems to talk about the first purpose (6.3) by saying:

Optionally, the Diameter node MAY check the status of
certificates using another mechanism, such as Online Certificate
Status Protocol (OCSP) [9].

According to this paragraph, OCSP support is optional. However, when
discussing about issue 125, we reached an agreement by which
OCSP-Responses AVP in DSAA is optional.

I've got two concerns:

- Does a Diameter implementation supporting CMS Sec have to support
online and CRL validation functionality? Is it mandatory to support
one, both? Is it optional?
- What happens when after a DSAR requesting an OCSP response arrives
to a Diameter node that doesn't support OCSP? I suppose than no
OCSP-Responses AVP is included in the DSAA, so that the iniciator
deduces that OCSP isn't supported.

Requested change:

Including a paragraph stating which certificate validation mechanisms
must support a CMS-compliant and how mandatory they are.

Adding a sentence to the first paragraph of page 12 (3.1) saying
something like:

If the sender of the DSAA does not support OCSP, it would simply
return a DSAA without any OCSP-Responses AVP.

Issue 145: Order in CMS-proxy messages
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-24
Reference:
Document: Base-07, CMS-02
Comment type: T
Priority: S
Section: (base) 2.7, (CMS) 6.2
Rationale/Explanation of issue:

As stated in (base) 2.7:

Relay agents MUST NOT reorder AVPs, and proxies SHOULD NOT
reorder AVPs.

However, in (CMS) 6.2:

All AVPs to be encrypted are concatenated, and the encryptor is
free to order AVPs in whatever way it chooses.

My deduction is that the encryption of AVPs in a proxy acting as a CMS
proxy on behalf of a client would break the requirement in (base) 2.7
since the receiver would never know which order was the original (of
course that route-related AVPs are not encryptable, so that its order
would never change).

Requested change:

To rephrase the requirement in (base) 2.7 in order to take into
account what is stated in (CMS) 6.2

Issue 146: CHAP Algorithm missing
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 2001-08-27
Reference:
Document: NASREQ-07
Comment type: T
Priority: S
Section: 3.1.1.x
Rationale/Explanation of issue:

The current NASREQ specification doesn't allow for CHAP extensibility
which RFC 1994 allows.

Requested change:

Introduce a new CHAP-Algorithm AVP

Issue 147: CHAP Algorithm missing
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 2001-08-27
Reference:
Document: NASREQ-07
Comment type: T
Priority: S
Section: 2.1.6, 7.2.5.4, 7.2.5.5, 7.2.5.6, 7.2.5.7
Rationale/Explanation of issue:

The NASREQ specification requires the following changes:

- Replace TBD for IPv6 RADIUS attribute numbers to the values found
in RFC 3162.
- Remove AES as a possible key type in section 2.1.6
- Change WEP2 to WEP-128 as a possible key type in section 2.1.6
- Include a reference to WEP.

Issue 148: Change section 5-6 in MIP app to relect
Submitter name: Fredrik Johansson
Submitter email address: fredrik@ipunplugged.com
Date first submitted: August 13, 2001
Reference:
Document: MIP-07
Comment type: T
Priority: 1
Section: 5-6
Rationale/Explanation of issue:

I'm re-submitting a part of issue 110 that wasn't a editorial issue.

Section 5-6 has to be rewritten to be in line with
draft-ietf-mobileip-aaa-key-08.txt

Today these sections talks about how keys should be distributed, as the
aaa-key draft has changed to distribute key-material, this section has to be
updated to reflect that.

I'v had a try to change the sections to reflect the changes. A new AVP is
also defined called MIP-Key-Material AVP.

/Fredrik


5.0 Key Distribution Center

The mobile node and mobility agents use registration keys to compute
authentication extensions applied to registration messages, as
defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If
registration keys are requested the AAA server(s) MUST create key-
material after the Mobile Node is successfully authenticated and
authorized.

If the AAAH does not communicate directly with the foreign agent, and
it does not wish for intermediate proxies to have access to the
session keys, they SHOULD be protected using the CMS security
application [9].

The Authorization-Lifetime AVP contains the number of seconds before
registration keys destined for the Home Agent and/or Foreign Agent
expire. A value of zero indicates infinity (no timeout).

The SPI values are used as key identifiers, meaning that each
registration key has its own SPI value; nodes that share a key also
share an SPI. The Mobile Node proposes SPIs for use in computing the
Mobile-Foreign and Mobile-Home authentication extensions, via the
Mobile IP AAA Key Request extensions [15], while the Home Agent
allocates the Mobile-Foreign, Mobile-Home and Foreign-Home SPIs.

Once the registration keys have been distributed, subsequent Mobile
IP registrations need not invoke the AAA infrastructure until the
keys expire. These registrations MUST include the Mobile-Home
authentication extension. In addition, subsequent registrations MUST
also include Mobile-Foreign authentication extension if the Mobile-
Foreign key was generated and distributed by AAA; similarly for
subsequent use of the Foreign-Home authentication extensions.

Each registration key that is generated by AAA will generally be
distributed to two parties; for instance, a Mobile-Foreign key goes
to both a mobile node and a foreign agent. To the mobile node it is
sent as key material and to the foreign agent as en encoded key. The
methods by which the key is encoded will depend upon the security
associations available to the AAA server and each recipient of the
key. These methods will often be different for the two recipients,
so that the registration key under consideration has to be encoded
twice.

See sections 6.0 for details about the format of the AVPs used to
transport the registration keys.


5.1 Distributing the Mobile-Home Registration Key

If the mobile node does not have a Mobile-Home registration key, then
the AAAH is likely to be the only entity trusted that is available to
the mobile node. Thus, the AAAH has to generate the Mobile-Home
registration key, and encode it for eventual consumption by the
mobile node and home agent.

If the home agent is in the home domain, then AAAH can directly
encode the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP
and include that AVP in the HAR message for delivery to the home
agent.

If, on the other hand, the home agent is to be allocated in the
visited domain, the AAAH does not transmit the HAR to the home agent,
but instead transmits the HAR to the AAAF. When the AAAF receives the
HAR, it first allocates a home agent, and then issues the HAR for
that home agent.

The AAAH also has to arrange for the key to be delivered to the
mobile node. Unfortunately, the AAA server only knows about Diameter
messages and AVPs, and the mobile node only knows about Mobile IP
messages and extensions [4]. For this purpose, AAAH includes the
Mobile-Home registration key-material into a MIP-MN-to-HA-Key AVP,
which is added to the HAR message, and delivered either to a local
home agent, or to the AAAF in the case where the home agent is in the
visited network. The AAAH has to rely on the home agent (that also
understands Diameter) to transfer the keying information into a Mobile
IP Generalized MN-HA Key Reply extension [15] in the Registration Reply
message, using the SPI proposed by the Mobile Node in the MN-HA Key
Request From AAA Subtype extension. The home agent can format the Reply
message and extensions correctly for eventual delivery to the mobile
node. The resulting Registration Reply is added to the HAA's
MIP-Reg-Reply AVP.

After the HAA message is parsed by the AAAH, and transformed into an
AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually
be received by the the foreign agent. The foreign agent can then use
that AVP to recreate a Registration Reply message, containing the
Generalized MN-HA Key Reply extension, for delivery to the mobile
node.

In summary, the AAAH generates the Mobile-Home key material. Using the
key material it calculates the key as defined in [4] and encodes it
into a MIP-HA-to-MN-Key AVP. The key material is also included in the
MIP-MN-to-HA-Key AVP.
These AVPs are delivered to a home agent by including them in a HAR
message sent from either AAAH or AAAF. The home agent decodes the key
for its own use. The home agent also copies the key material from
the MIP-MN-to-HA-Key AVP into a Generalized MN-HA Key Reply
extension appended to the Mobile IP Registration Reply message. This
Registration Reply message MUST also include the Mobile-Home
authentication extension, created using the newly allocated Mobile-
Home registration key. The home agent then encodes the Registration
Reply message and extensions into a MIP-Reg-Reply AVP included as
part of the HAA message to be sent back to the AAA server.


5.2 Distributing the Mobile-Foreign Registration Key

The Mobile-Foreign registration key material is also generated by
AAAH (upon request), so that it can be added into a
MIP-MN-to-FA-Key AVP, which is added to the HAR, and copied by the
home agent into a Generalized MN-FA Key Reply Extension [15] to the
Mobile IP Registration Reply message, using the SPI proposed by the
Mobile Node in the MN-FA Key Request From AAA Subtype extension.
Further, the home agent includes the SPI in the HAA's
MIP-FA-to-MN-SPI AVP. Most of the considerations for distributing the
Mobile-Foreign registration key are similar to the distribution of the
Mobile-Home Registration Key.

Upon receipt of the HAA, if MN-FA keying was requested the AAAH
creates the MIP-FA-to-MN-Key AVP, using the SPI in the MIP-FA-to-MN-
SPI, and includes the AVP in the AMA. The key is calculated using the
same method as defined in the MIP-MN-to-FA-Key. If the
MIP-FA-to-MN-Key AVP was present in the AMA, the foreign agent MUST
include the Mobile-Foreign authentication extension in the Registration
Reply, using the newly distributed key.


5.3 Distributing the Foreign-Home Registration Key

If the home agent is in the home domain, then AAAH has to generate
the Foreign-Home registration key. Otherwise, it is generated by
AAAF.

In either case, the AAA server encodes the registration key into a
MIP-HA-to-FA-Key AVP and includes that AVP as part of the HAR message
sent to the home agent, and waits for the HAA message to be returned.

Upon receipt of the HAR, the home agent recovers the Foreign-Home
registration key, allocates an SPI to be used with the key, and uses
this key to create a Foreign-Home authentication extension to the
Registration Reply message. The allocated SPI is included in the
HAA's MIP-FA-to-HA SPI AVP.

Upon receipt of the HAA, the Diameter server responsible for key
allocation adds the MIP-FA-to-HA Key AVP, using the SPI in the MIP-
FA-to-HA-SPI, and includes the AVP in the AMA.


5.4 Key Distribution Example

Figure 9 provides an example of subsequent Mobile IP message
exchange, assuming that AAAH distributed registration keys for all
three MN-FA, FA-HA and HA-MN authentication extensions.

Mobile Node Foreign Agent Home Agent
----------- ------------- ----------

Reg-Req(MN-HA-Auth, MN-FA-Auth)-------->

Reg-Req(MN-HA-Auth, FA-HA-Auth)-------->

<--------Reg-Rep(MN-HA-Auth, FA-HA-Auth)

<--------Reg-Rep(MN-HA-Auth, MN-FA-Auth)

Figure 9: Mobile IP Message Exchange

6.0 Key Distribution Center (KDC) AVPs

The Mobile-IP protocol defines a set of security associations shared
between the Mobile Node, Foreign Agent and Home Agents. These three
security associations (Mobile-Home, Mobile-Foreign, and Foreign-
Home), can be dynamically created by the AAAH. This requires that the
AAAH create Mobile-IP Registration Keys, and that these keys be
distributed to the three mobile entities, via the Diameter Protocol.
AAA servers supporting the Diameter Mobile IP Application MUST
implement the KDC AVPs defined in this document. In other words, AAA
servers MUST be able to create three registration keys: the Mobile-
Home, Mobile-Foreign, and Foreign-Home keys.

The names of the KDC AVPs indicate the two entities sharing the
security association defined by the encrypted key material; the
intended receiver of the AVP is the first named entity. So, for
instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key
encrypted in a way that allows it to be recovered by the mobile node.

If strong authentication and confidentiality of the registration keys
is required, it is recommended that the CMS security application [9]
be used.

The following table describes the Diameter AVPs defined in the Mobile
IP application, their AVP Code values, types, possible flag values
and whether the AVP MAY be encrypted.


+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-Algorithm- 345 6.9 Enumerated | M | P | | V | Y |
Type | | | | | |
MIP-FA-to-HA-Key 328 6.2 Grouped | M | P | | V | Y |
MIP-FA-to-HA-SPI 318 6.13 Unsigned32 | M | P | | V | Y |
MIP-FA-to-MN-Key 326 6.1 Grouped | M | P | | V | Y |
MIP-FA-to-MN-SPI 319 6.12 Unsigned32 | M | P | | V | Y |
MIP-HA-to-FA-Key 329 6.3 Grouped | M | P | | V | Y |
MIP-HA-to-MN-Key 332 6.4 Grouped | M | P | | V | Y |
MIP-MN-to-FA-Key 325 6.5 OctetString| M | P | | V | Y |
MIP-MN-to-HA-Key 331 6.6 OctetString| M | P | | V | Y |
MIP-Peer-SPI 342 6.7 Unsigned32 | M | P | | V | Y |
MIP-Replay-Mode 346 6.11 Enumerated | M | P | | V | Y |
MIP-Session-Key 343 6.8 OctetString| M | P | | V | Y |
MIP-Key-Material TBD 6.9 OctetString| M | P | | V | Y |


6.1 MIP-FA-to-MN-Key AVP

The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and
contains the Foreign Agent's session key, which it shares with the
Mobile Node. Its Data field has the following ABNF grammar:

MIP-FA-to-MN-Key ::= < AVP Header: 326 >
{ MIP-Peer-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]


6.2 MIP-FA-to-HA-Key AVP

The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and
contains the Foreign Agent's session key, which it shares with the
Home Agent. Its Data field has the following ABNF grammar:

MIP-FA-to-HA-Key ::= < AVP Header: 328 >
{ MIP-Peer-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]


6.3 MIP-HA-to-FA-Key AVP

The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and
contains the Home Agent's session key, which it shares with the
Foreign Agent. Its Data field has the following ABNF grammar:

MIP-HA-to-FA-Key ::= < AVP Header: 329 >
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP ]


6.4 MIP-HA-to-MN-Key AVP

The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and
contains the Home Agent's session key, which it shares with the
Mobile Node. Its Data field has the following ABNF grammar:

MIP-HA-to-MN-Key ::= < AVP Header: 332 >
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP ]


6.5 MIP-MN-to-FA-Key AVP

The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and
contains the Mobile Node's session key, which it shares with the
Foreign Agent. The Home Agent uses this AVP in the construction of
the Mobile IP "Unsolicted MN-FA Key from AAA Subtype" extension [15].
The SPI in the extension's FA SPI field is allocated by the Home
Agent, but it SHOULD take into consideration the SPI requested by the
Mobile Node in the "MN-FA Key Request From AAA Subtype" extension.

MIP-MN-to-FA-Key ::= < AVP Header: 325 >
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Key-Material }
* [ AVP ]


6.6 MIP-MN-to-HA-Key AVP

The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and
contains the Mobile Node's session key, which it shares with the Home
Agent. The Home Agent uses this AVP in the construction of the Mobile
IP "Unsolicted MN-HA Key from AAA Subtype" extension [15]. The SPI in
the extension's HA SPI field is allocated by the Home Agent, but it
SHOULD take into consideration the SPI requested by the Mobile Node
in the "MN-HA Key Request From AAA Subtype" extension.

MIP-MN-to-FA-Key ::= < AVP Header: 331 >
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Key-Material }
* [ AVP ]


6.7 MIP-Peer-SPI AVP

The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and
contains the Security Parameter Index to use to reference the key in
the associated MIP-Session-Key AVP. The SPI created MUST NOT be a
value between zero (0) and 255, which is the reserved namespace
defined in [4].


6.8 MIP-Session-Key AVP

The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and
contains the Session Key to be used between two Mobile IP entities.

6.9 MIP-Key-Material AVP

The MIP-Key-Material AVP (AVP Code TBD) is of type
OctetString and contains the Session Key Material to be used to
calculate the Session Key between two Mobile IP entities.

6.10 MIP-Algorithm-Type AVP

The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and
contains the Algorithm identifier used to generate the associated
Mobile IP authentication extension. The following values are
currently defined:

1 Prefix+Suffix MD5 [4]
2 HMAC-MD5 [13]
3 SHA-1 [17]


6.11 MIP-Replay-Mode AVP

The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and
contains the replay mode the Home Agent should use when
authenticating the Mobile Node.

The following values are supported (see [4] for more information):

0 None
1 Timestamps
2 Nonces

6.12 MIP-FA-to-MN-SPI AVP

The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and
contains the Security Parameter Index the Foreign Agent is to use to
refer to the session key it shares with the Mobile Node. The SPI
created MUST NOT be a value between zero (0) and 255, which is the
reserved namespace defined in [4]. This AVP MAY be added in the HAA
message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP of
the MIP-FA-to-MN-Key AVP.


6.13 MIP-FA-to-HA-SPI AVP

The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and
contains the Security Parameter Index the Foreign Agent is to use to
refer to the session key it shares with the Home Agent. The SPI
created MUST NOT be a value between zero (0) and 255, which is the
reserved namespace defined in [4]. This AVP MAY be added in the HAA
message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP of
the MIP-FA-to-HA-Key AVP.

Issue 149: Revalidation of certificates in cache
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-27
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00083.html and
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00101.html
Document: CMS-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

According to the CMS draft (3.1, Usage Scenario), the implementations
of CMS may cache DSA setup information. Also, they must honor the TTL
setting and re-validate certificates before using cached data. The
draft looks a little bit confused, so that Stephen Farrel proposed and
additional text in order to make it clear (see
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00101.html).

His basic statement was the following: Depending on the parameters of
the certificates belonging to the certificate chain (or belongint to
the OCSP response or the CRL), a "safe" period with no revocation
checks will be computed (I assume that if this safe period is smaller
than the length of the DSA, a revocation check must be done once the
safe period ends; but in the other hand, if the safe period is bigger
than the DSA length, the revalidation must be done once the DSA
expires). Additional checks might be done depending on the local PKI
policy.

However, from my humble point of view, the text just partially solved
the problem since its approach was very PKI-centric.

I'll explain my approach with some figures. This is the scenario as
far as I understood it:

____________________________________________
DSA |
================================== |
| | | |
beginning of | | |
the DSA t1 (any special time | |
in which a message | |
is issued) | |
end of |
the DSA |
t2 (other
issued message)

What I wanted to assure is that in t1, the implementation may choose
not to revalidate the certificates. But in t2, the implementation must
revalidate the certificates. This statement wasn't clear (in my
oppinion), and I wanted to make it more explicit.

Requested change:

The following paragraph must be changed:

Implementations MAY cache the information required to establish a
DSA, but MUST honor time-to-live settings and MUST re-validate
certificates (possibly including revocation checks) before using
cached data.

With this paragraph (which includes Stephen's contributions):

Implementations MAY cache the information required to establish a
DSA. However, they MUST honor time-to-live settings so that
certificates MUST re-validated (possibly including revocation
checks) once the DSA has expired.

Revalidations MIGHT also occur before the DSA expires according to
PKI policies. During the process of certificate path validation
some implementations will calculate a duration for which the
certificate path may be considered "safe". For example, if an
implementation did not support certificate revocation checks, then
the "safe" period would be from the time of initial validation
until the earliest notAfter time in the set of certificates in the
path. An implementation which does support certificate revocation
checks will typically be able to calculate a "safe" period based
additionally on the earliest nextUpdate field in a CRL or OCSP
response. Basically, the safe period is from the time of
certificate validation to the earliest value from the set of
notAfter and nextUpdate fields encountered during certificate
validation.

However, implemetors should note that CAs MAY issue additional
CRLs before the nextUpdate period. Generally it is a matter of
local PKI policy as to whether an implementation will make
additional checks even during the calculated "safe" period. For
the purposes of this specification implementations are NOT REQUIRED
to make such checks and MAY assume that no re-validation of
certificates is required during the "safe" period defined above.

Issue 150: S/MIME precisions
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-27
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

S/MIME is used as the "encoding" scheme within Diameter CMS Security
Application. However, I miss an explainatory chapter introducing
S/MIME (and CMS), saying which relationship there is bewteen them, why
the name of the specification is CMS Security and not S/MIME security,
and why it has been chosen (apparently the reason is darkly buried in
6.1 "This method of encapsulating AVPs allows existing S/MIME toolkits
to be used without changes in order to provide authentication within
the Diameter application layer.")

Besides, no mention about MIME encoding is made in 6.2
(CMS-Encrypted-Data AVP). The way in which several EnvelopedData
values are encoded in a single CSM-Enveloped-Data AVP isn't defined (I
assume that no nesting is employed since an "outside" envelope hides
all the content it's enveloping so that only the recipient of this
external envelope can extract the contents).

Requested change:

a) add an introductory chapter explaining the relationship between the
different standards involved (along with the reasons to use it and so
on)

b) add clarifying text to describe the MIME operations involved in CMS
Security application

Issue 151: 8.1 Authorization Session State Machine
Submitter name: Fredrik Johansson
Submitter email address: Fredrik@ipunplugged.com
Date first submitted: 2001-08-29
Reference:
Document: base
Comment type: E
Priority: 1
Section:
Rationale/Explanation of issue:

There are some missing states in the authorization session state machine.

1. It is optional to send a ASR when cleaning up a session on a home server,
however there is no indication on what state to go to when doing so. My
guess is that you should go to Disconnect and wait for a ASA. Since this is
an optional feature I'm not sure it should be in the state machine. However,
if you send an ASA there has to be a state indicating how to get from
Disconnect to Closed.

Requested Change:

Add the following state

Discon ASA Received Cleanup Closed
BTW, it might just be a cut'n past error, the
Open ASA Received Cleanup Closed
state should not exist, if you have sent an ASR you should not be in Open,
so replace the latter with the first state above.

2. There is no state where the home server can receive a service specific
auth. request and extend access and stay in open.

Requested Change:
Add a the following state:
Open Successful Service-Specific Extend Open
Authorization Request received Access

3. There is no state where the home server can receive a STR send a STA and
go to Closed

Requested Change:
Add the following state:
Open receive STR send STA Closed

4. According to the following state:
Open Authorization-Lifetime Send Open
expires on access device service
specific
auth req

It's not clear that an access device can not send a Service-Specific Auth.
request on Authorization-Lifetime expiration unless it has received a MIP
registration request or PPP request.

Requested Change:
Can it be made clearer that if no such message has been received it should
send a STR and go to Disconnect?

Issue 152: Confusion between security services and techniques to achieve them
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-29
Reference:
Document: CMS-02
Comment type: E
Priority: S
Section: abstract, 1.1, 3.1, 3.4, 5.0, 6.1, 6.2
Rationale/Explanation of issue:

The purpose of Diameter CMS Security Application is to achieve some
security services:

[1] (data origin) authentication
[2] confidentiality
[3] integrity
[4] non-repudiation (with proof of origin)

To achieve them, some techniques are used:

- digital signatures + digital certificates provide [1], [3] and [4]
(though to achieve only [3] maybe MAC would be enough)
- encryption (using asymmetric techniques to encrypt a content
encryption key and this CEK for bulk encryption) provides just [2]
- encryption + digital signatures + digital certificates provide [1],
[2], [3] and [4]

However, not all the security services are listed neither the specific
techniques are linked with the services.

Requested change:

Replace the second paragraph of the abstract with the following text:

This Diameter application describes how a security association is
established by two peers through agents, and how authentication
integrity, confidentiality and non-repudiation (with proof of
origin) are achieved using a mixture of symmetric and asymmetric
transforms, by encapsulating Cryptographic Message Syntax (CMS)
data within AVPs. CMS is also used to carry X.509 certificates.

Two main techniques are so that used. Digital signatures (along
with digital certificates) provide authentication, integrity and
non-repudiation. Encryption provides confidentiality (using
asymmetric techniques to encrypt a content encryption key and
this key for bulk encryption). Both techniques can be used
together to provide all the specified security services.

Replace the paragraph below the figure 2 (1.1) wiht the following:

This document defines the Diameter commands that are used to
establish a DSA through Diameter agents, and specifies how
encapsulating CMS objects [3] in Diameter AVPs can provide
authentication, integrity, confidentiality and non-repudiation.
The CMS object MAY also be used to transport X.509
certificates and revocation lists.

Replace the third paragraph in 3.1 with the following:

We use Diameter Security Association Request (DSAR) and Diameter
Security Association Answer (DSAA) messages to establish a DSA,
which
specifies which AVPs should be encrypted, signed, or both things,
as well as which public key(s) to use.

Replace the second last paragraph in 3.1 with the following:

Depending on the security technique required (digital
signature, encryption or both), then the originating node
prepares the CMS related AVPs as required.

Replace the second paragraph in 3.4 with the following:

Note that though the use of symmetric encryption might be used
to provide integrity or confidentiality but does not provide
non-repudiation with proof of origin.

Replace the second paragraph in 5.0 with the following:

Although the example doesn't specifically use bi-directional
digital signature and encryption, this feature is supported.

Replace the first sentence of second last paragraph in 6.1 with the
following:

The eContent field of the EncapsulatedContentInfo structure MUST be
absent since the digital signature covers data outside of the
object.

Replace the fourth paragraph in 6.2 with the following:

When AVPs are to be both encrypted and signed, the CMS-
Encrypted-Data AVP MUST be created first.

Issue 153: Key Length in CMS Security Application
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-29
Reference:
Document: CMS-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

Which key length is employed when RSA is used? I haven't seen any
negociation schema.

Requested change:

Add clarifying text

Issue 154: End-to-End Id in answer messages
Submitter name: Adrian Constantin
Submitter email address: adrian.constantin@nokia.com
Date first submitted:
Reference:
Document: Base 07
Comment type: E
Priority: 1
Section: 3.0 and 6.2
Rationale/Explanation of issue:

There is a consensus about copying the end-to-end id from the request in the
answer issued by a home server, but the specification doesn't clearly state
it.

Requested Change:

In section 3.0, End-to-End Identifier paragraph, change from

"Senders of request or answer messages MUST
insert a unique identifier on each message, by incrementing the
identifier by one (1)."

to:

"Senders of request messages MUST
insert a unique identifier on each message, by incrementing the
identifier by one (1). The originator of an Answer message
MUST ensure that the End-to-End Identifier field contains the same
value that was found in the corresponding request."


In section 6.2 add the following text:
"- The same End-to-End identifier in the request is used in the
answer."

Issue 155: Small editorial comment on section 5.5.4
Submitter name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: August 20, 2001
Reference:
Document: Base
Comment type: T
Priority: 1
Section: In section 5.5.4
Rationale/Explanation of issue:

A minor editorial nit, in section 5.5.4, 3rd paragraph, 2nd sentence:

When a transport failure is detected, all messages in the queue are
sent to an alternate agent, if possible. An example of a case where
it is not possible for forward the message to an alternate server is
when the message has a fixed destination, and the unavailable peer is
the message's final destination (see Destination-Host AVP).

The sentence isn't so clear - do you mean this (changed text in CAPS):

An example of a case where it is not possible TO forward the message to an
alternate server is when the message has a fixed destination,

- or it could be stated as:

An example of a case where it is not possible for FORWARDING the message to
an alternate server is when the message has a fixed destination,

Issue 156: DSA error codes
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-03
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02002.html
Document: Base-07, CMS-02
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

Apart from the error codes related to OCSP there are only two other
errors: DIAMETER_KEY_UNKNOWN and DIAMETER_INVALID_CMS_DATA.

The former is related to the locally stored encryption key (symmetric)
while the later talks about CMS-*-Data AVPs.

The Base Protocol draft (7.1.3) states:

DIAMETER_INVALID_CMS_DATA 3006
The Request did not contain a valid CMS-Data [11] AVP.

While in the CMS Security draft (7.2) it is said that:

DIAMETER_INVALID_CMS_DATA 5019
This error code is returned when a CMS-Data AVP is received
with an invalid ContentInfo object.

As stated in the reference mail, my first concern is about the
definition (which is slightly different) and the type of error (in the
base draft it's a protocol error while in the CMS draft it's a
permanent failure).

My second concern is about the error situations related to CMS. I can
foresee the following:

- In a DSA setup dialogue, the initiator can provide a set of "direct
trust" CA which isn't supported by the receiver. I understand that a
permanent failure code error must be issued.

- In a DSA setup dialogue, the initiator, once received the DSAA,
might fail to verify the conditions listed in section 3.1 of the CMS
draft. Like no ACK is foreseen in the specification, I understant that
when in a subsequent Diameter message, the initiator receives an AVP
related to CMS, this node should issue a permanent error. For example,
DIAMETER_NO_DSA_ESTABLISHED

- If a Diameter node receives a message with encrypted or signed AVPs
once the DSA has expired (or even with no previous DSA established),
the node should issue another error. Maybe, DIAMETER_DSA_EXPIRED (or
maybe making use of the former code suggested).

Requested change:

I suggest unifying the definition of DIAMETER_INVALID_CMS_DATA in both
drafts (or maybe dropping the mention of the error in base draft).

For the rest of concerns, I'd add some clarifying text in order to
state wheter those are really error situations or not.

Issue 157: DSA error codes (cont)
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-03
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02002.html,
http://www.merit.edu/mail.archives/aaa-wg/msg02022.html
Document: Base-07, CMS-02
Comment type: T
Priority: 1
Section: Base (7.1.3), CMS (6.2)
Rationale/Explanation of issue:

Apart from what I wrote in
http://www.merit.edu/mail.archives/aaa-wg/msg02022.html, I'd like to
add the following:

The Base Protocol draft (7.1.3) states:

DIAMETER_CMS_SECURITY 3008
A proxy has detected that CMS security has been applied to
portions of the Diameter message, and the proxy does not allow
this security mode since it needs to alter the message by
applying some local policies.

I suppose that this error code has been superseded by the error codes
defined in CMS-02 1.2 (Establishing Security Relationships through
proxy agents).

Also, the CMS-02 draft (section 6.1) says that:

If the signature cannot be verified correctly, a response with the
Result-Code AVP set to DIAMETER_INVALID_AUTH [1] MUST be returned.

I haven't found such a error code in Base-07

Requested change:

a) Drop error 3008 from base draft.
b) Correct which error code is issued when the signature isn't
properly verified.

Issue 158: DSA error codes (III)
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-04
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section: 6.2
Rationale/Explanation of issue:

In chapter 6.2 it's written down that:

When a conforming implementation receives a Diameter message which
contains encrypted AVPs within a CMS EnvelopedData, the recipient
MUST check to see if it is on the list of recipients specified in
the
RecipientInfos of the EnvelopedData. If not, the recipient MAY
choose
to process the message or indicate an error. If the recipient is in
the RecipientInfos and an error occurs during decryption, then the
recipient MUST indicate an error.

Two error situations are pointed:

- When the DSA recipient isn't in the list of recipients of
EnvelopedData.
- Being in the recipient list, an error occurs during decryption.

However, no Result-Code is provided in such situations.


Requested change:

a) create appropriate result codes (maybe DIAMETER_NO_DSA_RECIPIENT
and DIAMETER_DSA_DECRYPTION_FAILED)
b) clarify the previous paragraph including references to appropriate
result codes

Issue 159: Reference change in CMS-02
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-04
Reference:
Document: CMS-02
Comment type: E
Priority: S
Section: 3.1
Rationale/Explanation of issue:

The following item doesn't follow the convention to use references:

- the certificate chain selected is cryptographically correct,
passes the (relevant parts of the) rfc2459 path validation
algorithm and terminates at a CA mentioned in the DSAR message

The rest of references uses the form [x], where x is the number of the
reference in 11.0

Requested change:

Replace the quoted paragraph with the following:

- the certificate chain selected is cryptographically correct,
passes the (relevant parts of the)path validation algorithm
specified in [4] and terminates at a CA mentioned in the
DSAR message

Issue 160: Destination-Host in PDSR
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-04
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00229.html
Document: CMS-02
Comment type: T
Priority: 2
Section: 4.3
Rationale/Explanation of issue:

The establishment of DSAs through evil proxies is usually a tricky
task. As stated in our discussion about issue 136, two main scenarios
are considered:

- The access device does not have the cryptographic ability to
handle
the CMS functions locally, and therefore requests such services
from the local agent, such an an aggregating relay or proxy agent.
The NAS may have been configured to always issue a PDSR to its
local agent for CMS services. In such cases, the agent MUST select
the values for the DSA-TTL and provide the appropriate
Local-CA-Info and the expected OCSP response from the DSA peer.

- The access device has the cryptographic ability to perform the CMS
functions, but a proxy agent is in the route towards the home
server, and it returned a failure to the DSAR messages stating
that
it was not willing to allow the DSA to traverse through it. Such
agents MAY attempt to re-use the values from the initial DSAR sent
by the access device.

The ABNF grammar of a PDSR AVP is:

::= < Diameter-Header: 305, REQ, PXY >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
[ DSAR-Target-Domain ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

I'd like to focus in the second scenario. The agent has issued a DSAR
including the Destination-Realm AVP (let's use abc.com). An evil proxy
is in the route towards the home server, so that the evil proxy issues
a DSAA including the Origin-Host and the Origin-Realm AVPs (and a
DIAMETER_CAN_BE_A_COOL_CMS_PROXY result code). Following, the agent
issues a PDSR. Well, it will include again abc.com (but as
DSAR-Target-Domain) and the value of the Origin-Realm of the previous
DSAA as Destination-Realm of the PDSR.

However, it may happen that, once issued a PDSR with only a
Destination-Realm, it will be routed to other proxy in the same realm.
Maybe this proxy doesn't support CMS (so that it issues a
DIAMETER_AINT_CMS_PROXY). Or maybe it supports CMS but, not being the
same proxy it won't be able to reuse any of the previously sent
parameters (parameters sent in the previous DSAR).

I understand that, in this scenario, a Destination-Host AVP must be
included in the PDSR. So that an optional Destination-Host AVP must be
included in the ABNF grammar of PDSR.

Requested change:

a) Change the ABNF grammar of PDSR AVP including an optional field:

[ Destination-Host ]

b) Add explanatory text to 4.3

Issue 161: Authorisation rejected in CMS
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-05
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section: 1.5
Rationale/Explanation of issue:

In CMS-02 (section 1.5), it's stated that:

" one of participants
of a DSA (specifically the one in the home network) MUST belong to
the same realm as the user being authorized."

May I suppose that otherwise, a DIAMETER_AUTHORIZATION_REJECTED result
code is issued (or it should be a newly defined CMS-Sec specific
error)

Requested change:

Include a specific mention to DIAMETER_AUTHORIZATION_REJECTED or
defining a new result code.

Issue 162: Error replies to requests with no session id
Submitter name: Jari Arkko
Submitter email address: jari.arkko@ericsson.fi
Date first submitted: September 6, 2001
Reference: -
Document:base
Comment type: T
Priority: 1
Section: 7.2
Rationale/Explanation of issue:

Diameter has a couple of messages such as Device-Watchdog-
Request that do not include a session id in the request.
Yet section 7.2 requires that error replies to request
have the session id. How can we make an error reply
to Device-Watchdog-Request, for instance? And section
6.2 then talks about answers, and says that Session-Id
must be copied where it exists. Perhaps this is the
right approach, but should the BNF in 7.2 be changed
then?

Other messages without Session-Id are Capabilities-
Exchange-Req and Disconnect-Peer-Request.

Requested change:

Perhaps the BNF in 7.2 should be changed, or at
least words added. I'm not sure how to change the
BNF, given that we can't indicate a fixed position
AVP that is optional...

If added words is enough, then put in at the end
of 7.2: "Note also that the Session-Id should be
present if and only if the corresponding request
contained it."

Issue 163: Error codes (recap)
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-08-22
Reference:
Document: CMS-02
Comment type: T|E
Priority: S|1|2
Section:
Rationale/Explanation of issue:

Some errors and its result codes (not exhaustive):

1. A Diameter message with a CMS-Signed-Data AVP including a digital
signature and no AVP with its 'P' bit set:
DIAMETER_AVP_NOT_ALLOWED (existing in base draft)

2. A Diameter message without any CMS-Signed-Data AVP and some AVPs
with its 'P' bit set:
DIAMETER_MISSING_AVP (existing in base draft)

3. A Diameter message including CMS Security Application AVPs with no
DSA established:
DIAMETER_NO_DSA_ESTABLISHED (existing in CMS-03)

4. A Diameter node not being able to set up a DSA upon receiving a
DSA-Request due to problems different from digital signature
verification
DIAMETER_NO_DSA_ESTABLISHED (existing in CMS-03)

5. A Diameter node not being able to set up a DSA upon receiving a
DSA-Answer due to any problem
DIAMETER_NO_DSA_ESTABLISHED (in subsequent Diameter messages if a
CMS-related message is received) (existing in CMS-03)

6. A Diameter node not supporting certificate revocation checks has
calculated a safe period based on the expiration dates of the
certificates. Once this safe period has finishing, a CMS-Signed-Data
arrives without any certificate
??

7. A Diameter message including CMS Security Application AVPs with the
DSA expired (only if the Diameter node can "remember" past DSAs)
DIAMETER_DSA_EXPIRED (existing in CMS-03)

8. A Diameter message containing a CMS-Signed-Data AVP but with a
different set of AVPs with its 'P' bit set to the ones chosen in the
DSA establishment.
??

9. A Diameter message containing a CMS-Signed-Data AVP that doesn't
include any digital signature made by the node included in the
Origin-Host AVP
DIAMETER_CONTRADICTING_AVPS?? (existing in base draft)

10. A Diameter message containing a CMS-Signed-Data AVP. No
appropriate digital certificate (regarding the identity included in
the Origin-Host AVP) is available, neither included in the Diameter
message as CMS-Cert AVP nor available in the local cache.
DIAMETER_INVALID_AUTH?? (existing in CMS-03)

11. A Diameter message containing a CMS-Signed-Data AVP. The digital
signature is invalid.
DIAMETER_INVALID_AUTH (existing in CMS-03)

12. The DSA participant in the home network doesn't belong to the same
realm as the user being authorized.
DIAMETER_AUTHORIZATION_REJECTED?? (existing in base draft)

13. An OCSP response is requested. The Diameter server supports OCSP
querying. However, the OCSP responder isn't available (the server gets
a timeout)
DIAMETER_OCSP_NOT_SUPPORTED?? (existing in CMS-03)

14. A Diameter message containing a CMS-Encrypted-Data AVP. The
recipient isn't on the list of recipients specified in the
RecipientInfos of the EnvelopedData and decides to indicate an error.
DIAMETER_NO_DSA_RECIPIENT??

15. A Diameter message containing a CMS-Encrypted-Data AVP. An error
occurs during decryption
DIAMETER_DSA_DECRYPTION_FAILED??

Requested change:

a) Decide if all the situations quoted in which no error code is
mentioned needs a new error code (if so create them)
b) Decide whether the suggested result codes are correct
c) Once decided the result code for any situation, include a mention
of such result code (or the section) in the proper place.
d) Clarify what happens when a DSA can't be established because the
initiator (once received the DSAA) fails to check the conditions
listed in 3.1. Is is necessary to issue a NAK containing a
DIAMETER_NO_DSA_ESTABLISHED? Or it sufficient to issue such result
code only when another CMS-related AVP is inserted in subsequent
messages? It's important to take into account that the following
paragraph (from 6.1) states that a Diameter message must be issued
after any failed verification of a digital signature:

If the signature cannot be verified correctly, a response with the
Result-Code AVP set to DIAMETER_INVALID_AUTH MUST be returned.

e) Clarify the meaning of the following paragraph in 6.1

If a receiver detects that the contents of the CMS-Signed-Data AVP
are invalid, it SHOULD return the new Result-Code AVP value defined
in section 7.0.

Which contents are we talking about (maybe 9 above)? Because, if it
isn't the condition, a DIAMETER_INVALID... should be the appropriate
result code.

Issue 164: problems with Watch Dog
Submitter name: Yanqun Le
Submitter email address: yanqun.e@nokia.com
Date first submitted: 2001-09-06
Reference:
Document: Base-07
Comment type: T
Priority: 2
Section: 5.5.3 and 5.1
Rationale/Explanation of issue:

In section 5.1, it said:
three watchdog messages are exchanged with accepted round trip times, and
the connection to the peer is considered stablized.
The Problem is:

In SUSPECT state, if a DWA is received, which action should it take?
1) send another DWR, then which timer should it start? Tw or Tr/Tw? which
state should it change to? Still remain in SUSPECT and waiting for sending
another DWR or change to WAIT_DWA?
2) just change to OKAY?

I think draft 07 doesn't state clearly on it.

Issue 165: Expiration of DSAs on behalf of a client
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-06
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00246.html
Document: CMS-02
Comment type: T
Priority: S
Section: 1.2, 4.4, 6.14
Rationale/Explanation of issue:

When a CMS proxy establishes a DSA on behalf of a client, it uses its
own parameters (or maybe some of the provided by the client in a
previous DSA attempt). Once established, it issues a PDSAA to inform
the client about the status of the DSA. But, what happens once the DSA
has expired? It may receive a message of the same client with AVPs
that it (the proxy) would have protected while the DSA existed.

Does it have to try to establish a new DSA (transparently for the
client)? Or has to warn the client issuing a Diameter message with an
appropriate Result-Code (so that the client issues a PDSAR again)?

My idea is that the proxy should include the TTL of its established
DSA in the PDSAA in order to inform the client when it has to reissue
a PDSAR to make the proxy establish a new DSA.

Requested change:

Add the following text to the proposed text for issue 136:

The PDSAA MUST contain the TTL setting agreed by the proxy agent
for its DSA. This information will allow the access device to
re-issue a PDSAR when the proxy's DSA has expired.

Change the ABNF grammar of the PDSAA AVP (4.4), being the result:

::= < Diameter-Header: 305, PXY >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id }
{ DSA-TTL }
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

Add the followig text to the description of a DSA-TTL AVP in 6.14:

A DSA-TTL AVP MUST also be included in the PDSAA in order to
provide information about the lenght of the DSA established by
the proxy on behalf of the access device.

Issue 166: Ambiguity on Destination-Host AVP in Answer messages
Submitter name: Dirk Poertner, Yiwen Jiang
Submitter email address: Dirk.Poertner@icn.siemens.de,
yiwen.jiang@tic.siemens.ca
Date first submitted: 2001-9-6
Reference:
Document: Base-07, MobileIP-07, NASREQ-07, CMS-02
Comment type: E
Priority: 2
Section: Throughout
Rationale/Explanation of issue:

There are inconsistencies/ambiguities regarding Destination-Host AVP
throughout the document. In older versions (< -05), it actually said that
Destination-Host MUST be present in answers. Is this area missed in the
cleanup process, or??

For example, in Base-07:

In Section 6.1,
" - a request that is not proxiable (such as CER) MUST NOT contain
either Destination-Realm or Destination-Host AVPs."
But the ABNF format of CER and CEA listed the Destination-Host as optional.

In Section 6.2,
" - The Destination-Host and Destination-Realm AVPs MUST NOT be
present in the answer message."
But the ABNF formats of DPA and DWA listed the Destination-Host as
mandatory.

In the three application latest versions, Destination-Host AVP is included
in various Answer messages.

Requested change:

Cleanup these areas to make it consistent.

Issue 167: CMS-Cert in AVP occurrence table
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-06
Reference:
Document: CMS-02
Comment type: E-T
Priority: S
Section: 8.0
Rationale/Explanation of issue:

a) When issuing a DSA-Request, a digital signature (by means of a
CMS-Signed-Data AVP) may be included. If so, an appropriate CMS-Cert
must be included (unless the certificate is included within the
SignedData estructure).

b) In a DSA-Answer, I understand that the digital signature can be
verified by means of the certificates in the AAA-Server-Certs, so that
a CMS-Cert isn't necessary

Requested change:

a) Replace the row in the AVP occurrence table regarding CMS-Cert

+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | DSAR| DSAA| PDSR| PDSA|
------------------------------|-----+-----+-----+-----+
CMS-Cert | 0-1 | 0 | 0 | 0 |

b) Clarify if a CMS-Cert is necessary in a DSAA or if it's superseded
by a certificate present in AAA-Server-Cert

BTW, shouldn't be present Key-Hash AVP in the AVP occurrence table?

Issue 168: DIAMETER_NO_COMMON_TRUST error
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-06
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00300.html
Document: CMS-02
Comment type: T
Priority: 2
Section: 1.2
Rationale/Explanation of issue:

DIAMETER_NO_COMMON_TRUST error is introduced in section 7.2 of
CMS-Sec. However, no explicit mention to it is done in the text. The
definition is as follows:

This error code is returned when a receiver receives a PDSR for
which it has no common trust with the sender, which is required
to establish the DSA.

What seems to suggest that when a proxy receives a PDSAR from a client
when there no exist "common trust" between them.

In which situations is considered that there's common trust?

Requested change:

Add clarifying text

Issue 169: Result-code with 'P' bit erroneous
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-07
Reference:
Document: Base-07|CMS-02
Comment type: T
Priority: S
Section: 7.1.5|7.2, CMS-02 2.0
Rationale/Explanation of issue:

There's no defined error code for situations in which a node receives
an AVP with its 'P' bit set not being authorised to have its 'P' bit
set

Requested change:

Add in the appropriate place (7.1.5 in Base-07 or 7.2 in CMS-02) a new
error code:

DIAMETER_INVALID_AVP_P_BIT 50xx
The request contained an AVP with an invalid value in its 'P'
bit. A Diameter message indicating this error MUST include
the offending AVPs within a Failed-AVP AVP.

Add at the end of the section 2.0 in CMS-02:

Diameter implementations MUST check whether AVPs with its 'P' bit
set are allowed to use it. If not, an appropriate error message
MUST be issued containing DIAMETER_INVALID_AVP_P_BIT result code.


Update:
I agree with this issue as such. I would suggest however slightly
more general error code, and it to be put to the base. This
way we could handle any illegal bit-AVP combinations:

DIAMETER_INVALID_AVP_BIT_COMBINATION 50xx
The request contained an AVP with which is not allowed
to have the given value in the AVP Flags field. A Diameter message
indicating this error MUST include the offending AVPs
within a Failed-AVP AVP.

and then:

Diameter implementations MUST check whether AVPs with its 'P' bit
set are allowed to use it. If not, an appropriate error message
MUST be issued containing DIAMETER_INVALID_AVP_BIT_COMBINATION
result code.

Issue 170: Erroneous protection expectations
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-07
Reference:
Document: CMS-02
Comment type: T
Priority: S
Section: 3.1, 6.9, 6.10, 7.2
Rationale/Explanation of issue:

A Diameter node can request protection on certain AVPs that are not
allowed (i.e. requested as signed an AVP which can't set its 'P' bit
or as encrypted an AVP which can't be encrypted). No check nor error
code has been defined.

Requested change:

Add the following paragraph to 3.1 (after the list of components of
the DSAR):

The destination node MUST check that the provided elements of
the DSAR are valid. It MUST check, at least, that:

- Its local policy allows it to provide a TTL compatible with
the value provided in the request.
- One of the CAs provided is suitable of being the top of a
CA certificate chain that will assure the certificates of
the servers in the Home Domain.

If these conditions can not be verified, the destination node MUST
return a DSAA with the Result-Code AVP set to
DIAMETER_NO_DSA_ESTABLISHED.

The destination node MUST also verify that the protection
expectations are valid. If it is requested as signed an AVP
which may not set its 'P' bit or as encrypted an AVP which may
not be encrypted, the destination node MUST return a DSAA with the
Result-Code AVP set to DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS.


In the event....

Add the following paragraph to 6.9:

If the AVP code specified in the Expected-Signed-AVP is not
valid (that it, that AVP is not allowed to set its 'P' bit), the
implementation MUST issue an error message containing the
DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS result code

Add the following paragraph to 6.10:

If the AVP code specified in the Expected-Encrypted-AVP is not
valid (that it, that AVP is not allowed to be encrypted), the
implementation MUST issue an error message containing the
DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS result code

Add the following error code to 7.2:

DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS 50xx
The protection expectations stated in the Expected-Signed-AVP
or Expected-Encrypted-AVP are invalid. A Diameter message
indicating this error MUST include the offending AVPs within
a Failed-AVP AVP.

Update:
I agree with the parts of this issue. However, I would
suggest that instead of creating a new error code we
could simply use DIAMETER_INVALID_AVP_VALUE.
Otherwise we end up creating a special error code for
all AVPs.

Also, I would suggest we don't list all the checks explicitly
because, essentially, the destination node must check
ALL sent parameters according to the policies. I've reformulated
the text slightly to be a bit more general in this respect.

Edited change request below.

Jari

> Add the following paragraph to 3.1 (after the list of components of
> the DSAR):
>
> The destination node MUST check that the provided elements of
> the DSAR are valid. It MUST check, at least, that:
>
> - Its local policy allows the given TTL, realm, AVP protection
> expectations, certification status, and other parameters.
> - A common "top" of the certificate chain can be found between
> the home and foreign domains.
>
> If these conditions can not be verified, the destination node MUST
> return a DSAA with the Result-Code AVP set to
> DIAMETER_NO_DSA_ESTABLISHED.
>
> The destination node MUST also verify that the protection
> expectations are valid. If it is requested as signed an AVP
> which may not set its 'P' bit or as encrypted an AVP which may
> not be encrypted, the destination node MUST return a DSAA with the
> Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE.
>
>
> In the event....
>
> Add the following paragraph to 6.9:
>
> If the AVP code specified in the Expected-Signed-AVP is not
> valid (that it, that AVP is not allowed to set its 'P' bit), the
> implementation MUST issue an error message containing the
> DIAMETER_INVALID_AVP_VALUE result code
>
> Add the following paragraph to 6.10:
>
> If the AVP code specified in the Expected-Encrypted-AVP is not
> valid (that it, that AVP is not allowed to be encrypted), the
> implementation MUST issue an error message containing the
> DIAMETER_INVALID_AVP_VALUE result code

Issue 171: missing realm protocol error
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 2001-09-07
Reference:
Document: Base-07
Comment type: T
Priority: 1
Section: 7.1.3
Rationale/Explanation of issue:

Section 6.1 states that

- a request that needs to be sent to a specific home server among
those serving a given realm, MUST contain both the Destination-
Realm and Destination-Host AVPs.

If there is a Destination-Host, but no Destination-Realm, there
is no way to respond with a protocol error.

MISSING_AVP is not a protocol error, so you must use the correct
ABNF for the answer. This is not possible for a many proxy
situations if the proxy is not aware of a certain Application (a
simple relay agent for example).

DIAMETER_UNABLE_TO_DELIVER is used when the realm known,
but no hosts are available.

DIAMETER_REALM_NOT_SERVED is used when the realm is available,
but not served.

Requested change:

Either add a new DIAMETER_MISSING_DESTINATION_REALM protocol
error, or reword DIAMETER_UNABLE_TO_DELIVER or
DIAMETER_REALM_NOT_SERVED to include the above situation.

> Either add a new DIAMETER_MISSING_DESTINATION_REALM protocol
> error, or reword DIAMETER_UNABLE_TO_DELIVER or
> DIAMETER_REALM_NOT_SERVED to include the above situation.

Update:

Perhaps we should avoid again the explosion of new error
codes, and pick the second option. Here's a an attempt at the
rewording:

DIAMETER_UNABLE_TO_DELIVER 3003
This error is given when Diameter can not deliver
the message to the destination, either because
no host within the realm was available to process
the request, or because Destination-Host AVP was
given without the associated Destination-Realm AVP.

Issue 172: The need for Float128 ?
Submitter name: Tony Johansson
Submitter email address: tony.johansson@ericsson.com
Date first submitted: 2001-09-10
Reference:
Document: Base-07
Comment type: T
Priority: 1
Section: 4.3
Rationale/Explanation of issue:

Float128 is specified in the Base specification, but not int128 and u_int128. Is there a particular need for Float128?.

Furthermore, is Float128 even supported in most OSs?


Requested change:

Remove Float128 from the Base, unless somebody can tell that float128 is really needed and can be supported be the majority of known OSs.

Issue 173: Transport failure algorithm differs between drafts
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 9/13/01
Document: base-07, transport-04
Comment type: Technical
Priority: Must fix
Section: 5.5.3 (base), 3.2 (transport)
Explanation of issue: The transport failure algorithms described in the
two drafts differ substantially. For example, the transport draft
describes an algorithm that depends on a single timer, while the base
drafts algorithm includes multiple timers.
Requested change:
The drafts need to be aligned so that they describe the same transport
failure algorithm.

Issue 174: CMS Decryption Error
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-14
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02095.html
Document: CMS-02
Comment type: T
Priority: 2
Section: 6.2
Rationale/Explanation of issue:

In the list of errors provided in the reference message, the error
situation 19 states no error code:

> 19. A Diameter message arrives containing a CMS-Encrypted-Data AVP and
> an error occurs during decryption.
> Error code issued:
> Definition of the error:
> Included in CMS-02 draft: No
> Included in CMS-03 draft:
> Status: proposal needed.

After some reflexion time, I've noticed that there is no way to
distinguish between an error decryption and an error in the AVPs
extracted. As far as I know, the extracted AVPs are just a bit stream
that has to be parsed. If the CMS-Encrypted-Data AVP has been
modified, the only result is that the bit stream would be parsed since
the extracted AVPs would be invalid.

My proposal is that only a DIAMENTER_INVALID_AVP_VALUE would be
issued, including the CMS-Encrypted-Data AVP as Failed-AVP AVP.

Requested change:

Replace the following sentence in 6.2:

...and an error occurs during decryption, then the
recipient MUST indicate an error.

with the following:

...and an error occurs during decryption, then the
recipient MUST indicate an error by means of the
DIAMETER_INVALID_AVP_VALUE result code and including
the CMS-Encrypted-Data AVP as Failed-AVP AVP.

Issue 175: Missing text in float definitions
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 9/13/01
Document: base-07
Comment type: Editorial
Priority: Should fix
Section: 4.3
Explanation of issue:

The definitions of Float32, Float64, and Float128 in the base
draft all are missing the sentence fragment "if the 'V' big is
enabled)".

Requested change:

Add the text to the end of the four lines.

Issue 176: Add clarifying App-Id text in CER/CEA sections
Submitter name: Yolanda Garcia
Submitter email address: Yolanda.Garcia-Serrano@ece.ericsson.se
Date first submitted: 2001-09-14
Reference:
Document: Base-07
Comment type: T
Priority: S
Section: 2.5, 5.3, 6.9, 6.10
Rationale/Explanation of issue:

Diameter Nodes MUST advertise locally supported applications. This must be done
including at least an Auth-Application-Id AVP or an Acct-Application-Id AVPs in
CER and CEA messages, otherwise there is no way a receiver of a CER message detect
whether it has any application in common with the sender.

Requested change:

Add clariying text at least in sections 5.3.1 and 5.3.2

Issue 177: CMS proxy scenarios
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-14
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00229.html
Document: CMS-02
Comment type: T
Priority: 2
Section: 1.2, 4.3
Rationale/Explanation of issue:

As agreed in the discussion of issue 136, the description of two
scenarios regarding CMS proxies was introduced in the draft. These
scenarios are just examples, so that additional scenarios might be
considered. I've noticed that there might exist another scenario.

Let's consider a local AAA server that has to forward authentication
request from user that don't belong to its realm. It seems reasonable
that the AAA server establishes DSAs with other realms automatically
(that is, without any PDSA request from the clients). The local AAA
server would decide, accoding to its policies, with which realms it
must establish a DSA. This scenario seems reasonable since it puts the
intelligence of the system in the Diameter node and not in the client.

As a consecuence, at least three scenarios could be described. The two
escenarios also covered by the draft (as agreed on issue 136's
discussion):

- The access device does not have the cryptographic ability to
handle the CMS functions locally, and therefore requests such
services from the local agent, such an an aggregating relay or
proxy agent. The NAS may have been configured to always issue a
PDSR to its local agent for CMS services. In such cases, the
agent MUST select the values for the DSA-TTL and provide the
appropriate Local-CA-Info and the expected OCSP response from
the DSA peer.

- The access device has the cryptographic ability to perform the
CMS
functions, but a proxy agent is in the route towards the home
server, and it returned a failure to the DSAR messages stating
that it was not willing to allow the DSA to traverse through it.
Such agents MAY attempt to re-use the values from the initial
DSAR sent by the access device.

And an additional scenario (which IMHO could be even more common):

- The access device does not have the cryptographic ability to
handle the CMS functions locally but does not request such
services from the local agent. Instead, the local agent has
been configured to establish DSAs with certain realms in an
automatic way, so that the existence of DSAs is transparent
for the access device.

Requested change:

Add such scenario to the draft. However, as this new scenario doesn't
requires a previous PDSA request, it looks like that this scenario
shouldn't be added to section 4.3 but to section 1.2. And that's a
problem, since Pat already stated that in order to add the scenarios
to section 1.2 a major "surgery taks" might be necessary.

If Pat and the rest of the WG agrees on adding this issue, I'll be
able to carry out this task.

Issue 178: Partial support of CMS
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-14
Reference:
Document: CMS-02. ¿base?
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

One of the scenarios described in section 4.3 introduces the concept
of a client without cryptographic abilities but able to send a PDSA
request (and process a PDSA answer).

My concern is the following: does this client actually support CMS
(that is, can it include a value of '2' in the capabilities exchange?)
I don't think so. However, it must support the messages that are
needed to request a proxy a DSA on its behalf.

Requested change:

A clarifying text about it such clients can advertise that they
support CMS when they can't actually do it? As a consecuence, maybe it
would be more reasonable to move PDSAR and PDSAA to the base
specification, so that a base support would include such messages (I
don't really like this proposal, but IMHO it's the more coherent).

Issue 179: PDSA-Request without DSA-Target-Realm
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-14
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section: 1.2
Rationale/Explanation of issue:

The possibility of issueing a PDSA request without a DSA-Target-Realm
has been suggested as an optimized approach that allows to avoid a
explicit PDSA with any desired realm.

However, there are some points that remain unclear (IMHO):

- When does the proxy establish a DSA? As an initial establishment
with all the realms isn't possible, I suppose that every time the
client request an authorisation operation regarding a user, the proxy
must detect the operation and establish a DSA before forwarding the
authorisation message.

- Does the proxy has to establish a DSA with any realm? I don't think
so, since it may not be allowed by the proxy's local policies.

- What happens when one of such DSA fails? Or whether the proxy
doesn't support a DSA with the required realm? Or even whether there
is a another proxy on the route that issues a NOT_CMS_THROUGH_PROXY
result code? Do the proxy have to indicate it to the client, issuing
an appropriate answer with a given result-code (maybe
DIAMETER_NO_DSA_ESTABLISHED)? Or it must forward the message without
warning the client?

- Are all the clients equal? I mean, does the proxy have to record on
behalf of which client it is establishing a DSA (what might involve
several DSAs with the same realm on behalf of different clients)?

- What happens when the DSA expires? Does the proxy have to
re-establish it without any indication from the client. If so, the
third model suggested in one of my previous issues would be better (no
explicit PDSAR to begin a DSA but just local policies of the proxy).

Requested change:

a) Replace the following paragraph:

An optimized approach also allows the PDSR to be sent by the access
device without the DSAR-Target-Realm AVP. This message is used to
inform the proxy that it MUST establish a Diameter security
association for all realms it will be communicating with on behalf
of the access device.

with something like the following:

An optimized approach also allows the PDSAR to be sent by the
access
device without the DSAR-Target-Realm AVP. This message is used to
inform the proxy that it MUST establish a Diameter security
association for all realms it will be communicating with on behalf
of the access device. Such DSA MUST be established only first time
a message must be routed to a given realm.

It may happen that this DSA can not be established. For example,
the proxy might be configured not to establish DSAs with the
required
realm, the DSA setup migh fail or there is a proxy agent in the
route towards the home server, and it returned a failure to the
DSAR messages stating that it was not willing to allow the DSA to
traverse through it. In such situations, the proxy MUST reject the
message, but set the Result-Code AVP to
DIAMETER_NO_DSA_ESTABLISHED.

If several access device send a PDSAR without the DSAR-Target-Realm
AVP, only one DSA per realm MUST be established.

b) Add clarifying text regarding what happens when the DSA expires.

Issue 180: AAA-Server-Certs
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-14
Reference:
Document: CMS-02
Comment type: T
Priority: 2
Section: 6.6
Rationale/Explanation of issue:

It remains unclear for me the meaning of AAA-Server-Certs. As far as I
understand, a DSA is established between two Diameter agents (not
between an agent and a realm) so that no CMS-protected AVP can come
from a node "outside" the DSA. If this supposition is right, including
certificates of other home nodes is useless, since the initiator of
the DSA wouldn't accept CMS AVPs from a different node although
belonging also to the home realm.

Requested change:

Add clarifying text.

Issue 181: Digital encryption + signature in CMS-Sec
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-06
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section: 6.1, 6.2
Rationale/Explanation of issue:

When a set of AVPs is required also as encrypted and digitally signed,
the draft states (according to S/MIME RFC) that the encryption must be
done first. That's is coherent but can, in some occasions, be confused
for an implementation.

I'll try to explain it. Let's imagine that the Expected-Encrypted-AVP
states that AVPs A and B must be encrypted. So does the
Expected-Signed-AVP (including maybe another AVP, C). The
implementation will first create a CMS-Encrypted-AVP containing A and
B, that are subsequently dropped. When the signing process begin,
there's no A and B AVPs, so that it might sign only C. In order to
avoid this misbehaviour, I suggest stating explicitly that when
encryption and digital signature are required, it has to be treated as
an atomic operation, so that the implementation must "remember" that A
and B AVPs are also inside an encrypted AVP.

Requested change:

Add some paragraphs after (6.1):

When AVPs are to be both encrypted and signed, the
CMS-Encrypted-Data
AVP MUST be created first. The resulting CMS object MUST then be
MIME
encoded producing an application/pkcs7-mime MIME type which is then
used as the content of the EnvelopedData. This means that signing
is
"outside" encryption.

It might be something like the following:

Implementations MUST treat this process as an atomic process, so
that
one encrypted the set of AVPs required as so, the implementation
MUST
use the CMS-Encrypted-Data AVP (as well as any additional AVP
required
as only signed) as the input to the signing process (even if the
CMS-Encrypted-Data AVP was not required as digitally signed).

Where an implementation wants to receive a set of AVPs both
encrypted
and signed it MIGHT use a work around consisting of requiring the
set
of AVPs as encrypted and CMS-Encrypted-Data AVP as digitally
signed.

Where there are more AVPs required as encrypted than digitally
signed,
a CMS-Encrypted-Data AVP MUST be created including only the AVPs
that
has also to be digitally signed. This AVP will be the input to the
signing process. The rest of AVPs required as encrypted MUST be
done
as many as desired additional CMS-Encrypted-Data AVPs.

Replace the next paragraph in 6.2:

When AVPs are to be both encrypted and signed, the
CMS-Encrypted-Data
AVP MUST be created first.

with

When AVPs are to be both encrypted and signed, the
CMS-Encrypted-Data
AVP MUST be created first, according to the guidelines stated in
6.1.

Issue 182: Retain RADIUS attribute types for attributes 0-255
Submitter name: Bob Kopacz
Submitter email address: BKopacz@InterlinkNetworks.com
Date first submitted: September 18, 2001
Reference: None
Document: draft-ietf-aaa-diameter-mobileip-07
Comment type: T
Priority: 1
Section: 7.1, 7.2, 7.4, 7.5
Rationale/Explanation of issue:

The first 256 AVP numbers are reserved for compatibility with
RADIUS.

However, the type of four of them has been changed in the Diameter
draft. Accounting-Input-Octets, Accounting-Output-Octets,
Accounting-Input-Packets, and Accounting-Output-Packets are AVPs in
the RADIUS attribute space, but are 32-bit integers in RADIUS and
64-bit integers in Diameter.

This makes the dictionary implementation more difficult in servers
that support both RADIUS and Diameter.

For the first 256 attributes, we should retain full RADIUS
compatibility and retain the original RADIUS type. If Diameter
applications want 64-bit integer counters, then create
Diameter-specific AVPs for them.

Requested change:

(The AVP names are only a suggestion)

Rename Accounting-Input-Octets as Accounting-Input-Extended-Octets,
rename Accounting-Output-Octets as Accounting-Output-Extended-Octets,
rename Accounting-Input-Packets as Accounting-Input-Extended-Packets,
rename Accounting-Output-Packets as Accounting-Output-Extended-Packets,
let their values be 64-bit integers,
and assign them Diameter AVP numbers greater than 255.

Related to this issue, a similar problem exists in the nasreq-07 spec.
However, while sections 8.1-8.5 indicate that the AVPs in question should be
Unsigned64, the table in section 2.2 indicates that they are in fact
Unsigned32.

Issue 183: Diameter hop-by-hop security
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 9/19/01
Document: base-07
Comment type: Technical
Priority: Must fix
Section: 2.2 Securing Diameter Messages
Explanation of issue: There is a mismatch between security support
required on the client and on the server. Diameter clients MUST support
IPsec, and MAY support TLS. Yet, Diameter Servers MUST support TLS, and
MAY support IPsec. Thus, compliant Diameter clients & servers won't
necessarily interoperate.
Requested change:
Change text to: Diameter Servers MUST support TLS and IPsec.

Issue 184: CMS-Data AVPs in base protocol
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-24
Reference:
Document: Base
Comment type: T
Priority: S
Section: 9.5, 9.7.1
Rationale/Explanation of issue:

In base specification 9.5 it's quoted the term CMS-Data AVP:

In all accounting records the Session-Id and User-Name AVPs MUST
be present. If end-to-end authentication is required, as described
in [11], the CMS-Data AVP may be used to authenticate the
Accounting Data and Service Specific AVPs. It is not typically
necessary, nor recommended, that the end-to-end authentication
cover any additional AVPs since the Data and Service Specific AVP,
and associated CMS-Data, MAY need to be submitted to a third party.

Also in 9.7.1:

When the Accounting-Request is being submitted to a third party
(e.g. settlement service), and includes the CMS-Data AVP [11], the
CMS-Data AVP MUST be signed by both the local and home Diameter
server using the countersignature procedures described in [11].

However, this CMS-Data AVP doesn't actually exist.

Requested change:

Changing that term in both paragraphs. In the first paragraph,
CMS-Data should be changed by CMS-Signed-Data since it's
authentication the security service involved. However, in the last
sentence, the phrase "It is [...] not recommended that the end-to-end
authentication cover any additional AVPs..." looks wrong. As stated in
the discussion of issue 150, too much digital signature doesn't harm
and there's no problem if the signature covers other AVPs.

The result could be something like the following:

In all accounting records the Session-Id and User-Name AVPs MUST
be present. If end-to-end authentication is required, as described
in [11], the CMS-Signed-Data AVP may be used to authenticate the
Accounting Data and Service Specific AVPs. It is not typically
necessary, although nor harmful, that the digital signature carried
by the CMS-Signed-Data AVP covers any additional AVPs, even if the
since the Data and Service Specific AVP, and associated
CMS-Signed-Data, MAY need to be submitted to a third party.

In the second one, it also looks like CMS-Signed-Data is the right
option.

When the Accounting-Request is being submitted to a third party
(e.g. settlement service), and includes the CMS-Signed-Data AVP
[11], the CMS-Signed-Data AVP MUST be include digital signatures
by both the local and home Diameter server using the
countersignature
procedures described in [11].

Issue 185: CMS-protected AVPs outside a DSA
Submitter name: Miguel A. Monjas
Submitter email address: ecemaml@rioja.es.eu.ericsson.se
Date first submitted: 2001-09-24
Reference:
Document: CMS-02
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

The CMS application comprises two main "features" (as described in
section 2.0): the security feature, which comprises the messages
necessary for establishing security associations and the AVPs needed
to protect other AVPs; and the proxy feature, made up of the messages
that are used to ask a proxy to establish a security association.

On the other hand, the CMS draft begins by describing how a security
association can be established (sections 1.1 and 1.2). It might looks
like as if the CMS draft states that a security association is needed
to exchange protected AVPs. But it doesn't actually say it.

Another points:

- The definition of CMS-Signed-Data AVP (section 6.1) introduces the
concept of countersignatures. This attribute allows any Diameter peer
to add its own digital signature to an existing CMS-Signed-Data AVPs
(but always on the same set of AVPs, the ones with its protection bit
set). As far as I understand, this situation could happen when a
broker signs AVPs in given Diameter messages that traverse through it.
Section 1.3 also describes a "business model" in which two Diameter
nodes signs "in parallel" accounting AVPs. It is supposed that those
both parties are the participants of a DSA (according to figure 4).
The base specification also talks about AVPs being signed by two
parties (sections 9.5 and 9.7.1) usually to be forwarded to a third
party with settlement purposes (however, it isn't said whether those
AVPs would be forwarded using new Diameter messsages). Discussion on
issue #150 emphasizes that a digital signature has no actual receiver
(that is, a Diameter node can sign anything withour a explicit request
within the framework of an established DSA)

- The definition of CMS-Encrypted-Data AVP (section 6.2) reviews the
concept of RecipientInfo, an attribute of the CMS structure
EnvelopedData that allows to encrypt a given set of AVPs for different
receivers using an only CMS-Encrypted-Data AVP. Discussion on issue
#150 also introduces an example in which a Diameter node has to
encrypt some (different) AVPs to two different receivers. Section 6.2
(proposed) says that:

If the recipient is not specified in a RecipientInfo, it MAY
choose to process the message or return an answer with the
Result-Code AVP set to DIAMETER_NO_DSA_RECIPIENT"

that is, a node can receive a CMS-Encrypted-Data AVP with a receiver
different from itself.

- As a result of "Questions about AVPs ocurrence" series, it was
stated that "The DSAR message MUST NOT be used simply as a convenient
certificate distribution protocol without establishing a DSA" (section
4.1). What might imply that a DSA is necessary to include a CMS-Cert
AVP. However, section 6.1.7 in base protocol states that:

Redirector agents MAY also include the certificate of the servers
in
the Redirect-Host AVP(s). These certificates are encapsulated in a
CMS-Cert AVP [11].

and the same in section 1.3 of CMS:

the redirect agent to retrieve the necessary information for it to
communicate directly with the home server, which MAY include the
home server's certificates.


Requested change:

a) Clarifying whether CMS-* (that is, CMS-Signed-Data,
CMS-Encrypted-Data and CMS-Cert) may be exchanged without an
established DSA between the peers. If so, introducing a brief
description of scenarios in which no previous DSA is needed (that is,
that a node can sign of encrypt AVPs according only to its local
policy and not to an explicit DSA)

b) Whenever CMS is used in the base draft, describing that
functionality in the CMS draft.

Issue 186: Decouple authorization and key generation
Submitter name: Panos Thomas
Submitter email address: Panos.Thomas@motorola.com
Date first submitted: 9/25/01
Reference: N/A
Document: draft-ietf-aaa-diameter-mobileip-07.txt
Comment type: T
Priority: 2
Section: 5.0
Rationale/Explanation of issue:

3rd paragraph in Section 5.0:

"The Authorization-Lifetime AVP contains the number of seconds
before registration keys destined for the Home Agent and/or
Foreign Agent expire. A value of zero indicates infinity (no
timeout)."

Tying the Authorization-Lifetime and the key lifetimes couples
authorization and key generation. It may be desirable to allow
AAAH to set key lifetimes to any value (e.g. to a multiple of
the Authorization-Lifetime), so that it doesn't have to generate
new keys every time it re-authorizes the user.

Requested change:

Remove the 3rd paragraph in Section 5.0 and add a MIP-Lifetime
AVP to the MIP-XX-to-XX-Key AVPs in Sections 6.1 - 6.6.

Issue 187: Foreign-Home authentication extension doesn't exist
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 26-Sep-01
Reference:
Document: mobileip
Comment type: Editorial
Priority: '1' Should fix
Section: 5.3
Rationale/Explanation of issue:

According to 5.3:

Upon receipt of the HAR, the home agent recovers the Foreign-Home
registration key, allocates an SPI to be used with the key, and uses
this key to create a Foreign-Home authentication extension to the
Registration Reply message.

But according to draft-ietf-mobileip-aaa-key-01.txt there is no
such thing as a Foreign-Home authentication extension.

Requested change:

Since there is no need for the mobile node to know the
Foreign-Home key, this was probably a cut and paste
error. Please remove:

, and uses
this key to create a Foreign-Home authentication extension to the
Registration Reply message.

Issue 188: NAS-Key-Binding and Ciphersuite Negotiation
Submitter name: Henry Haverinen
Submitter email address: henry.haverinen@nokia.com
Date first submitted: 2001-09-27
Reference:
Document: nasreq
Comment type: T
Priority: S
Section: 2.1.6
Rationale/Explanation of issue:

The NAS-Key-Binding AVP specifies the purpose of the
session key. The AVP MUST be included if the NAS-Session-Key
AVP is included. The key binding specifies which ciphersuite
will be used between the NAS and the user. The problem is that
the ciphersuite may not have been selected yet.

In PPP, ECP is used to negotiate the ciphersuite and it occurs
between the user and the NAS after authentication.
In IEEE 802.11, the ciphesuite negotiation may as well
occur after authentication.

In addition, the NAS-Key-Binding AVP makes AAA servers
dependent on and aware of different ciphersuites, so they
need to be updated if a new ciphersuite is specified.

Even if the ciphersuite hasn't been selected, the AAA server
can still transport keying material to the NAS in the
NAS-Session-Key AVP. For example, it can include large
session keys which the NAS can truncate as necessary for use
with a given ciphersuite.

Requested change:

The NAS-Key-Binding AVP should not be mandatory even if the
NAS-Session-Key AVP is included. Do we need the NAS-Key-Binding
AVP at all?

Issue 189: NAS-Session-Key and Initialization Vectors
Submitter name: Henry Haverinen
Submitter email address: henry.haverinen@nokia.com
Date first submitted: 2001-09-27
Reference:
Document: nasreq
Comment type: S
Priority: 1
Section: 2.1.2 - 2.1.6
Rationale/Explanation of issue:

The NAS-Session-Key AVP as currently specified does not
include means to transport initialization vectors for
encryption.

Requested change:

One way to support IV's would be to have a new NAS-Key-Type
for them. This would make sense especially if the NAS
uses the received material as a master session key from
which the actual IV's are derived.

Alternatively, we could specify that the keying material
of cipher keys includes initialization vector material.

Issue 190: NAS-Session-Key and Session Master Keys
Submitter name: Henry Haverinen
Submitter email address: henry.haverinen@nokia.com
Date first submitted: 2001-09-27
Reference:
Document: nasreq
Comment type: S
Priority: 1
Section: 2.1.2 - 2.1.6
Rationale/Explanation of issue:

The NAS-Session-Key AVP, as currently specified, can only
be used to transport encryption and integrity keys.
However, a IEEE 802.11 access point may need session
master keys from which it derives the actual encryption
and authentication keys. (This is not certain yet.)

Requested change:

Perhaps the NASREQ document could simply say that the
CIPHER_KEY (or INTEGRITY_KEY) can alternatively be used as
a session master key from which the NAS derives the actual
cipher keys (integrity keys).

Issue 191: How to know when to use TLS
Submitter name: Fredrik Johansson
Submitter email address: fredrik@ipunplugged.com
Date first submitted: 2001-09-28
Reference:
Document: base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

How should a peer know if the other side is runnig TLS or not?

Requested change:

One possible solution could be to add two new values to the transport
attribute in the URI saying TLSoverTCP or TLSoverSCTP

Another solution would be to add it as an configurable attribute to a peer.
But maybe the URI solution is preferable.

Issue 192: Missing Disconnect Cause
Submitter name: Fredrik Johansson
Submitter email address: fredrik@ipunplugged.com
Date first submitted: 2001-10-01
Reference:
Document: base-08-alpha
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

What disconnect cause should be sent when disconnecting due to a lost
election.

Requested change:

Add new disconnect cause code, e.g.

ELECTION_LOST 3
Sent on the transport connection that has lost the election.

Issue 193: Changes to Peer state machine in base-08-alpha
Submitter name: Fredrik Johansson
Submitter email address: fredrik@ipunplugged.com
Date first submitted: 2001-10-01
Reference:
Document: base-08-alpha
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

Typos/errors in peer state machine

Requested change:

change:

Wait-I-CEA I-Rcv-CEA Process-CEA I-Open
R-Conn-CER R-Accept, Wait-Returns
Process-CER,
Elect
I-Peer-Disc I-Disc Closed
------> I-Rcv-DPR I-Snd-DPA,I-Disc Closed <-----
I-Rcv-Non-CEA Error ^^^^^^ Closed
Timeout Error Closed


I-Open Send-Message I-Snd-Message I-Open
I-Rcv-Message Process I-Open
WatchDog-Timer I-Snd-DWR I-Open
I-Rcv-DWR Process-DWR, I-Open
I-Snd-DWA
I-Rcv-DWA Process-DWA I-Open
R-Conn-CER R-Reject I-Open
------> Stop I-Snd-DPR Closing <------
I-Rcv-DPR I-Snd-DPA, Closed
I-Disc
I-Peer-Disc I-Disc Closed <-------
I-Rcv-CER Error Closed
I-Rcv-CEA Error Closed


and add:

Closing I-Rcv-DPA I-Disc Closed
R-Rcv-DPA R-Disc Closed
Timeout Error Closed
-----> I-Peer-Disc I-Disc Closed <-------
-----> R-Peer-Disc R-Disc Closed <-------

Issue 194: Add Termination-Cause values for MIPv4
Submitter name: Panos Thomas
Submitter email address: Panos.Thomas@motorola.com
Date first submitted: 2001-10-01
Reference: N/A
Document: base-08-alpha
Comment type: T
Priority: 1
Section: 8.15
Rationale/Explanation of issue:

In a MIPv4 scenario, when old-FA detects that the user has moved
to a new-FA, or when its Auth-Lifetime+Grace-Period timer expires,
it sends an STR to AAAH to terminate the (old-FA)-(AAAH) session.
What Termination-Cause value should the old-FA use in these cases?
DIAMETER_LOGOUT or DIAMETER_LINK_BROKEN may cause the AAAH to also
terminate the (AAAH)-(HA) session.

Requested change:

Add the following Termination-Cause AVP values in Section 8.15:

DIAMETER_AUTH_EXPIRED
This value is used when the Auth-Lifetime + Auth-Grace-Period
expires on access device.

DIAMETER_USER_MOVED
This value is used in a MIP scenario when the FA determines
that the user has moved to a new FA.

Issue 195: Clarifications on key generation (mobileip-08)
Submitter name: Mark Jones
Submitter email address: mjones@matrixmuse.com
Date first submitted: 2001-10-02
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02204.html
Document: mobileip-08, aaa-key-08
Comment type: 'E'
Priority: '1'
Section: 5.x, 6.0 of mobileip-08, 2 of aaa-key-08
Rationale/Explanation of issue:

1) The text in 5.x and 6.0 refers to the generation of Registration Keys.
The KDC AVP descriptions (sections 6.1 onwards) refer only to session keys.
These are one and the same so the naming should be consistent.

2) Section 5.3 entitled 'Distributing the Foreign-Home Registration Key'
does not give any details on how the key is derived.

3) The aaa-key-08 draft does not explicitly state that key material must be
distinct for each of the requested keys leaving the implementor the option
of using the same key material for deriving Mobile-Home, Mobile-Foreign and
Home-Foreign session key.

Requested change:

1) In section 5.x and 6.0, replace the term Registration Key(s) with
'Session Key(s)' for consistency.

2) Add the following text to the end of the first paragraph in section 5.3:
"The procedure for generation of key material and derivation of this session
key is identical to that for the Mobile-Home and Mobile-Foreign session keys
as specified in [15]."

3) In aaa-keys, modify the text in step 5 of section 2 (Scope of Protocol)
to read:

5. At the time the information within the MN-AAA Authentication
extension is verified by the AAA server, the AAA server also
generates distinct Key Material for each of the keys requested
by the mobile node, and causes insertion of the Key Material
fields along with the Registration Reply.

Issue 196: How to use Diameter Accounting
Submitter name: Harri Hakala
Submitter email address: Harri.Hakala@lmf.ericsson.se
Date first submitted: 10.10.2001
Reference:
Document: Base (draft-ietf-aaa-diameter-08-alpha01)
Comment type: T/E
Priority: 1
Section: 2.3 and 8
Rationale/Explanation of issue:

According to the section 8.0 Diameter can provide two different type of services to applications.
The first involves authentication and authorization, and can optionally make use of accounting.
The second only makes use of accounting.

There are certain applications, which needs only send the accounting information and
do not need the support of authentication and authorization.

The Accounting commands from the Diameter base protocol suits very well for this purpose.

In section 2.3 Diameter Protocol Extensibility it is described the ways how
the Diameter protocols can be extended.
Section 2.3.2 defines that when no existing AVP can be used appropriately to communicate some
service-specific information, a new AVP should be created.
By using the accounting commands and service-specific AVPs would be the perfect solutions
for the applications which only want to send the accounting information.

But it is not possible to use the Accounting commands with service specific AVPs without
creating a new application, because the accounting is not an application by itself
(no Application identifier defined).

This means that there is always need to create a new application before it is possible to use
the Diameter accounting commands.
Anyhow it is said in section 2.3.3 that the creation of a new application should be view as a
last resort.
In the same chapter it is also defined that the new Diameter application MUST define at least one
Command Code.
Does this mean that if a new application is created it still can use Commands from the base protocol without
creating a new Commands ?

Does this restrict the possibility to use Diameter protocol only for accounting purposes ?

Requested change:
Proposal

Even if the Accounting is part of the Base protocol it should be possible to use only the accounting part of
Diameter without creating each time a new application.

Application Id for accounting used for capabilities exchange.

Issue 197: Missing Session Termination Cause in Section 8.15
Submitter name: Liu Qing
Submitter email address: qing.roger.liu@nokia.com
Date first submitted: 2001-10-08
Reference:
Document: base-08-alpha
Comment type: T
Priority: 1
Section: 8.15
Rationale/Explanation of issue:

What termination cause should be sent when terminating a session due to the
"Session-Timeout expire on Access Device"?
(refer to the 8.1: "OPEN Session-Timeout Expires on Access Device send
STR Discon")

Requested change:

Add new termination cause code, e.g.

DIAMETER_SESSION_TIMEOUT 6
Access Device terminate the session when session-timeout expires.

Issue 198: MIP-FA-to-[HA|MN]-Key not needed in HAR
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 8-Oct-01
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00029.html
Document: mobileip
Comment type: Technical
Priority: 1
Section: 8.1
Rationale/Explanation of issue:
Since the home agent has no use for the MIP-FA-to-HA-Key or the
MIP-FA-to-MN-key, there is no need to send it to the home agent.

Requested change:
Change the 0-1 in the HAR column for rows MIP-FA-to-HA-Key and
MIP-FA-to-MN-key to 0.

Issue 199: wdRecoveryCount used for triggering failover procedures
Submitter name: Fredrik Johansson
Submitter email address: fredrik@ipunplugged.com
Date first submitted: 10-Oct-01
Reference:
Document: transport
Comment type: technical
Priority: 1
Section: 5.5.3
Rationale/Explanation of issue:
The wdRecoveryCount is used for both taking us from SUSPECT to OKAY and
for triggering failover procedures.

Requested change:
add new counter to trigger failover procedures

OnTimerElapsed(pcb)
{
if pcb->Status = OKAY
SendWatchdog(pcb)
pcb->Status = WAIT_DWA
T = Tw
else if pcb->Status = WAIT_DWA
pcb->Status = SUSPECT
T = Td
else if pcb->Status = SUSPECT
---->>> if pcb->noDWRSentInSuspect++ == 2
StopConnection(pcb)
FailoverProcedures(pcb)
else SendWatchdog(pcb)
}

Issue 200: Missing UserName AVP in table in section 10.2
Submitter name: Fredrik Johansson
Submitter email address: fredrik@ipunplugged.com
Date first submitted: 9-Oct-01
Reference:
Document: base-08-alpha
Comment type: editorial
Priority: 1
Section: 10.2
Rationale/Explanation of issue:
The User Name AVP is not available in the table in section 10.2, but it's
present in the ABNF for the accounting messages

Requested change:
Add User Name AVP

Issue 201: MIP-FA-to-MN-SPI and co-located servers
Submitter name: Mark Eklund
Submitter email address: meklund@diameter.org
Date first submitted: 12-Oct-01
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00101.html
Document: mobileip
Comment type: T
Priority: 1
Section: 6.0
Rationale/Explanation of issue:

This is a sub-issue of the issue, "Issue: Required AVPs in grouped
key AVPs" submitted earlier by me that requests changing to use the
Key ABNA as listed in the reference above.

The value for the MIP-FA-to-MN-SPI key is contained in the
registration request sent by the MN (and placed in the
MIP-Reg-Request by the FA). The HA normally extracts this and sends
it back to the AAAH as the MIP-FA-to-MN-SPI. The AAAH can then
place that in the MIP-FA-to-MN-Key and sent back to the FA.

A problem happens with a co-located server. When the AAAF gets an
AMR and the MN-to-FA key was requested, it sends an AMA back to the
FA that contains the MIP-FA-to-MN-Key and the MIP-MN-to-FA-Key. The
problem is that the AAAF doesn't speak mobileip and can't
extract the MIP-FA-to-MN-SPI from the registration request.

Requested change:
The currently suggested ABNF for the MIP-FA-to-MN-Key and the
MIP-MN-to-FA-Key is

MIP-FA-to-MN-Key ::= < AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
{ MIP-Key-Lifetime }
* [ AVP ]

MIP-MN-to-FA-Key ::= < AVP Header: 325 >
{ MIP-Algorithm-Type }
{ MIP-Key-Material }
{ MIP-Key-Lifetime }
{ AAA-SPI }
* [ AVP ]

Either make the MIP-FA-to-MN-SPI in the MIP-FA-to-MN-Key optional or
only require that the MIP-MN-to-FA-Key be sent back when the server
is co-located and add the MIP-Session-Key as an optional AVP. I.E.

MIP-MN-to-FA-Key ::= < AVP Header: 325 >
{ MIP-Algorithm-Type }
{ MIP-Key-Material }
{ MIP-Key-Lifetime }
{ AAA-SPI }
[ MIP-Session-Key ]
* [ AVP ]

Issue 202: Alternatives to the Command Code ABNF specification
Submitter name: Jaakko Rajaniemi
Submitter email address: jaakko.rajaniemi@nokia.com
Date first submitted: 2001-10-18
Document: base
Comment type: T
Priority: 1
Section: 3.2
Rationale/Explanation of issue:

The section 3.2 "Command Code ABNF specification" contains the ABNF
specification which must be followed when contructing Diameter Command
Codes. It does not contain a possibility to use the alternatives (see
RFC2243, section 3.2) when defining the AVPs included into the commands.
This is very restrictive and does not allow enough flexibility when defining
command codes and therefore it is proposed that the alternatives is
included.


Requested change:

Include following description to the avp-spec in the section 3.2:

avp-spec = diameter-name *("/" diameter-name)
; The avp-spec has to be an AVP Name,
; defined in the base or extended Diameter
; specifications. The avp-spec may contain AVP Names
; which are alternatives, see RFC 2234 section 3.2.

Issue 203: MIP-FA-to-HA being added to the AMA by the AAAF
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 25-Oct-01
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00031.html
Document: mobileip
Comment type: Technical
Priority: 1
Section: 2.4, 5.3, 8.1
Rationale/Explanation of issue:

When the HA is in the foreign network and a FA-HA key is requested,
the AAAF generates the key. The AAAF is then responsible for adding
the MIP-FA-to-HA Key to the AMA. This means that the AAAF must
maintain a list containing all MIP-FA-to-HA Key AVPs and their
matching Accounting-Multi-Session-Id AVPs. When each AMA is received,
the AAAF must then consult the list and when it finds a matching
Accounting-Multi-Session-Id, add the MIP-FA-to-HA Key AVP to the AMA.

Requested change:

Instead of requiring the AAAF to add the MIP-FA-to-HA Key AVP to the
AMA, send the MIP-FA-to-HA Key back in the HAA. The AAAH then can
move the MIP-FA-to-HA Key from the HAA to the AMA.

Add [MIP-FA-to-HA-Key] to the HAR ABNF in section 2.4.
Change MIP-Feature-Vector column HAR = 0-1 to section 8.1
Change MIP-FA-to-HA-Key column HAA = 0-1 to section 8.1

Change the final paragraph of section 5.3 to

Upon receipt of the HAA, the Diameter server responsible for key
allocation creates the MIP-FA-to-HA Key AVP, using the SPI in the
MIP-FA-to-HA-SPI. If the key is generated at the AAAF, it adds the
MIP-FA-to-HA Key AVP to the HAA and sends it to the AAAH.
Depending upon where the HA was located the AAAH either generates the
MIP-FA-to-HA Key AVP itself or extracts the AVP from the HAA sent
by the AAAF. The AAAH adds the MIP-FA-to-HA Key to the AMA.

Issue 204: How to handle CER from unknown peer
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section: 5.3, 7.1
Rationale/Explanation of issue:

If a CER is received from an unknown peer, the draft doesn't really specify
what should be done. A new Result-Code will handle this case (and the
necessary text in 5.3.

Issue 205: Should AVPs be ordered?
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 3
Section: 3.2
Rationale/Explanation of issue:

The base protocol spec command code ABNF doesn't specify that mandatory
AVPs don't necessarily need to appear before the optional ones. Add a
sentence making this clearer.

Issue 206: ABNF of non-proxiable commands incorrect
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section: various
Rationale/Explanation of issue:

Some non-proxyable command code's ABNFs include the Destination-Host and
Destination-Realm AVPs, which is invalid according to the definition of
these AVPs. The ABNFs need to be cleaned up.

Issue 207: AAA URI inconsistent
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section: various
Rationale/Explanation of issue:

Some examples of the URI in the spec does not include the aaa://
prefix. Add it to the examples.

The ABNF definition doesn't include the scheme name (aaa://). Add
that as well.

Issue 208: Peer State Machine incorrect in case of election
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section: 5.6, 7.1
Rationale/Explanation of issue:

The last state machine statement is incorrect.
Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open
I-Rcv-DPR I-Snd-DPA, R-Open
R-Snd-CEA
I-Rcv-CEA R-Snd-DPR I-Open

If a CEA is returned with the proper error code, there is no reason
to send a DPR. Add the Result-Code value, and remove the DPR here.

Issue 209: Authorization-Lifetime inconsistency
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base, MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

In the base draft, the Authorization-Lifetime set to 0 means immediate
re-auth. In the MIP draft 0 means infinity. Fix the MIP draft to be
consistent with the base draft.

Issue 210: Session-Timeout ABNF/Table inconsistency
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base, MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

In the MIP draft, the use of the Session-Timeout in the command code
ABNFs in inconsistent with the table.

Issue 211: When should Destination-Host be present in HAR?
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

In the MIP draft, it isn't really clear when the Destination-Host should
be present in the HAR when the HA is assigned in a foreign domain. The
text and figure need to be cleaned up.

Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

Once a mobile has been assigned a home agent, if a subsequent HAR is to
be sent, a new AAAH has no way to map the IP address in the registration
request to a Destination-Host AVP of the Home Agent.

Fix

The GNAIE ID is being updated to reflect comments of the IESG. In this
document we will specify that the HA may include its NAI in the
Registration Reply, and if so, the mobile node must include the same extension
in subsequent registration requests. This will require some Mobile IP WG
involvement.

Issue 213: MN-AAA SPI must be included in the HAR message
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

The Home Agent needs to have access to the MN-AAA SPI in order to create
the Mobile AAA key extensions. This information is not sent by the AAAH
to the home agent. Therefore the AAAH must include the MIP-MN-AAA-SPI
AVP in the HAR to the HA.

Issue 214: Unknown-User Result-Code provides too much info
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section: 7.1
Rationale/Explanation of issue:

Some text should be provided in the Result-Code value to state that
an alternative is to use Authentication-Failure. It is felt that Unknown
User provides too much info, and could lead to certain types of attacks.

Issue 215: Use of hmac-md5 is incorrect
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base, aaa-keys
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

Need to make use that the use of md5 and hmac-md5 is consistent across
both drafts. The latest aaa-keys uses hmac-md5, but uses the incorrect
function prototype (it uses hmac-md5 with a prefix+suffix mode).

Issue 216: Home Agent MUST support home address allocation
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section: 1.2
Rationale/Explanation of issue:

The draft doesn't actually state that the Home Agent MUST support
home address allocation, but the draft does state that the AAAH MAY
do it. The lack of a MUST can cause interoperability problems

Issue 217: typo in MIP section 3.2
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: MIP
Comment type: Technical
Priority: 4
Section: 3.2
Rationale/Explanation of issue:

In section 3.2, the term foreign agent should read foreign domain.

Issue 218: ABNF/Table inconsistencies
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: all
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

In some drafts, there are inconsistencies between the ABNF and the
command code tables at the end of the spec.

Issue 219: AMA AVP issue when failure occurs
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

If the mobile is not authenticated successfully (or some other error
occurs on AAAH), the ABNF requires some AVPs that may not be available.

Issue 220: Not possible to dynamically update capabilities
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

The draft does not allow a peer to update its capabilities. Some folks
believe this is problematic when the capabilities change over time.
Currently, it would require that the transport be disconnected and
re-established.

Fix

Allow a CER to be sent while in the open state.

Issue 221: Why require CMS to send its expected AVPs?
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: cms
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

Each Diameter application states which AVPs should be encrypted and which
can be signed. Since this is possible, why bother requiring that the DSAR
sender to include what AVPs it expects to have signed/encrypted? Isn't
the AVP definition sufficient?

Issue 222: Routing within a domain
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

In a hierarchical network (meaning that there are agents between the
access device and the destination) when all peers are in the same
administrative domain, routing isn't guaranteed to work.

Fix

When a hierarchy exists, a sub-domain should be used (e.g. sub.domain.com).
Just add text to make this clear in the routing section. With Longest-Match-
From-Right (already in the spec), this feature works fine.

Issue 223: How does CMS work if the HA is unknown and in foreign network
Submitter name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

The Mobile IP extension allows the foreign network to specify whether it
is willing to provide a home agent. However, if the AAAH wants to setup a
DSA with the Home Agent, how can it do that since it doesn't know the URI
of the HA.

Fix

When the AAAF states it is willing to allocate an HA in its domain, it
includes the URI in a new AVP, called Candidate-Home-Agent-Host.

Issue 224: Handling errors in the TCP stream
Submitter name: David Frascone
Submitter email address: dave@frascone.com
Date first submitted: 25-Oct-01
Reference:
Document: Base
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

Since TCP is stream oriented, an error in the stream is completely
un-recoverable. Therefore, when an error is detected in the stream, the
connection must be closed.

Errors can be detected by reserved bits being set, avp lengths being
less than the size of an AVP header, or greater than the diameter message
length.

There was no input on whether or not to first send a response. Since
an error can occur in a request or in an answer, I think closing the
connection without sending a response is acceptable.

Issue 225: Specify Statefulness/Statelessness Requirements
Submitter name: Bob Kopacz
Submitter email address: BKopacz@InterlinkNetworks.com
Date first submitted: October 26,2001
Reference: None
Document: draft-ietf-aaa-diameter-mobileip-08-alpha01
Comment type: T
Priority: 1
Section: 1, 1.2, 1.4
Rationale/Explanation of issue:

The Mobile-IP Diameter draft is fuzzy regarding
statefulness/statelessness requirements. Implementers are left to infer
the requirements. Some people have inferred that an AAA home server must
maintain session state, others have not made that inference.

Requested change:

Specify the statefulness/statelessness requirements.

If it is true that maintaining session-state is not required, then amend
the draft as follows:

1. Up front, somewhere in the "Introduction" section, add the following
text:

"A AAA home server which supports the Mobile-IP authentication
application MAY maintain session-state or MAY be session-stateless. A
AAA foreign server which supports the Mobile-IP authentication
application MAY maintain session-state or MAY be session-stateless. AAA
redirect agents and AAA relay agents MUST not maintain session-state.
AAA home and foreign servers, as well as AAA proxies and relays, MUST
maintain transaction state."

2. Section 1.2 "Inter-Domain Mobile IP", says:

"During the creation of the HAR, the AAAH MUST use a different session
identifier than the one used in the AMR/AMA (see figure 2). Of
course, the AAAH MUST use the same session identifier for all HARs
initiated on behalf of a given mobile node's session."

Remove the 2nd sentence, which begins "Of course ...".

3. Section 1.2 "Inter-Domain Mobile IP", also says:

"For new sessions, the AAAH MUST create an accounting session
identifier, which is added to the Accounting-Multi-Session-Id AVP in
the HAR message sent to the home agent."

Remove the phrase "For new sessions" from the first sentence, so that
the text reads:

"The AAAH MUST create an accounting session
identifier, which is added to the Accounting-Multi-Session-Id AVP in
the HAR message sent to the home agent."


4 Section 1.4 "Allocation of Home Agent in Foreign Network", says"

"Figure 7 shows the message flows for a Mobile Node requesting to keep
the Home Agent assigned in Foreign network 1 when it moves to foreign
network 2. [...]. If the Mobile Node was
successfully authenticated the AAAH checks for the Origin-Host and
the value of the Origin-Host of the previous request. If a AAAH
deduces that the Mobile Node has moved to a new realm, it must check
whether the Mobile can still use the previously assigned Home Agent."

Change the sentence

"If the Mobile Node was successfully authenticated the AAAH checks for
the Origin-Host and the value of the Origin-Host of the previous
request."

to

"If the Mobile Node was successfully authenticated, a session-stateful
AAAH checks for the Origin-Host and the value of the Origin-Host of the
previous request."

and add some text describing how a session-stateless AAAH server deduces
that the Mobile Node has moved to a new foreign realm.

Issue 226: Server-Initiated Re-Auth in Diameter MIPv4 not supported
Submitter name: Tony
Submitter email address: tony.johansson@ericsson.com
Date first submitted: 26-Oct-01
Reference:
Document: MIP alpha -08
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:

In section 8.3 Server-Initiated Re-Auth of the base protocol alpha -08
states the following:

"Each Diameter application MUST state whether service-initiated re-auth
is
supported, since some applications do not allow for access devices to
prompt the user for re-auth."

However, text is missing in the Diameter Mobile IPv4 application that
states that this Diameter application can not deal with Server initiated
re-auth.

Issue 227: End to end identifier
Submitter name: Kevin Purser
Submitter email address: kevin.purser@ericsson.com
Date first submitted: 10/30/01
Reference: none
Document: Base-08-alpha
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 3.0 Diameter Header
Rationale/Explanation of issue:

On diameter servers which may utilize multiple (and potentially many)
processors, forcing the end-to-end identifier to be monotonically increased
by one for every message sent will probably cause scalability issues. This
is due to the fact that this identifier would have to be in shared memory,
and would require mutually exclusive access amongst all processors in order
to update the value, thus slowing down all other diameter processes waiting
to send a message.

Requested change:
In the sentence below, remove the phrase "by incrementing the identifier by
one (1)." After all, the method of ensuring the uniqueness of an identifer
is probably more of an implementation issue anyway, right?

Senders of request or answer messages MUST
insert a unique identifier on each message, by incrementing the
identifier by one (1).

Issue 228: Remove Route_Record Avp in all the Answer message
Submitter name: Michael Chen
Submitter email address: cchen@erilab.com
Date first submitted: 5-Nov-01
Reference:
Document: base-08-alpha2, mobileip-08-alpha2, nasreq-08-alpha2
Comment type: editorial
Priority: 1
Section: Base: 8.3.2 8.4.2 8.5.2 9.7.2
Mobileip 2.2 2.4 8.1
Nasreq 3.1.2 4.2.2 10.1
Rationale/Explanation of issue:
Only Request Message include Route-Record Avp

Requested change:
Reove all the Route-Record Avp in all the ABNF Answer message
(Base: RAA, STA, ASA, ACA)
(Mobileip: AMA, HAA, Command Avp Table)
(Nasreq: AAA, DEA, Command Avp Table)

Issue 229: Remove MIP-PEER-SPI AVP
Submitter name: Michael Chen
Submitter email address: cchen@erilab.com
Date first submitted: 5-Nov-01
Reference:
Document: mobileip-08-alpha2
Comment type: editorial
Priority: 1
Section: Mobileip 6.1 6.2 6.7

Rationale/Explanation of issue:
Reuse the AVP which we have defined.

Requested change:
Remove 6.7 and replace Mip-Peer-Spi with
Mip-FA-to-MN-Spi/Mip-FA-to-HA-Spi.
In other words, see below

MIP-FA-to-MN-Key ::= < AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]

MIP-FA-to-HA-Key ::= < AVP Header: 328 >
{ MIP-FA-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]

Issue 230: Add Mip-Key-Lifetime AVP to ABNF and comand table
Submitter name: Michael Chen
Submitter email address: cchen@erilab.com
Date first submitted: 5-Nov-01
Reference:
Document: mobileip-08-alpha2
Comment type: editorial
Priority: 1
Section: Mobileip 2.2 2.3 8.1

Rationale/Explanation of issue:
We need show how to use MIP-Key-Lifetime Avp

Requested change:
Add [ MIP-Key-Lifetime ] to the ABNF of Home-Agent-MIP-Request
and AA-Mobile-Node-Answer
Add MIP-Key-Lifetime to Command Avp Table

+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
MIP-Key-Lifetime | 0 | 0-1 | 0-1 | 0 |

Issue 231: Home-Agent-In-Foreign-Network set by AAAF
Submitter name: Michael Chen
Submitter email address: cchen@erilab.com
Date first submitted: 5-Nov-01
Reference:
Document: mobileip-08-alpha2
Comment type: T
Priority: 1
Section: Mobileip 2.1

Rationale/Explanation of issue:
In session 4.5:
If the mobile node requests a home agent in the foreign network
either by setting the home address field to all ones, or by
specifying a home agent in the foreign network, and the AAAF
authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign-
Network bit to one.
So the FA MUST include MIP-Mobile-Node-Address AVP when the
mobile
node requests a home agent in the foreign network by setting the
home
address field to all ones, otherwise, AAAF doesn't know mobile node
is willing to be assigned a home agent in the foreign network

Requested change:
Add this sentence in session 2.1:
If the mobile node's home address is all ones, the foreign or home
agent
MUST include a MIP-Mobile-Node-Address AVP which is all ones in the
AMR.

Issue 232: Session Definition
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 5-Nov-01
Reference:
Document: base
Comment type: Editorial
Priority: 1
Section: 1.3
Rationale/Explanation of issue:

Past experience with dialup has shown that there are differing
opinions on the definition of a session. For example, some would
consider a session to begin after the user authenticated. Others
would consider the authentication a part of the session.

PROBLEM: The drafts are lacking a concise and unambiguous definition
of "session" that we can all systems-architect and code to. An
airtight definition is important to ensure predictable and consistent
interoperability among vendors' implementations of Diameter
applications.

Requested change:

Modify the wording of the definition of Session and add definitions
for Sub-session and Multi-session. These definitions are as follows:

Session
A session is a related progression of events devoted to a
particular activity. Each application SHOULD provide guidelines
as to when a session begins and ends. All Diameter packets with
the same Session-Identifier are considered to be part of the
same session.

Sub-session
A sub-session represents a logical break in the activity of a
single session. These changes in sessions are tracked with the
Accounting-Sub-Session-Id. An example of a session divided into
several sub-sessions would be a dial-up connection in which the
pre-authentication activity (call setup, resource allocation,
etc.), interactive login, and PPP communication would all be
sub-sessions.

Multi-session
A multi-session represents a logical linking of several parallel
sessions. Multi-sessions are tracked by using the
Accounting-Multi-Session-Id. An example of a multi-session
would be a MLP bundle. Each leg of the bundle would be a
session while the entire bundle would be a multi-session.

Issue 233: MIP-Candidate-Home-Agent-Host
Submitter name: Kevin Purser
Submitter email address: kevin.purser@ericsson.com
Date first submitted: 06-Nov-01
Reference:
Document: mobileip-08-alpha2
Comment type: T
Priority: 1
Section: 2.1
Explanation of issue:
In the event the AAAF is NOT willing to allocate a home agent in the visited
network, inclusion of the required MIP-Candidate-Home-Agent-Host AVP doesn't
make sense.

Requested change:
Make this AVP OPTIONAL in the AMR. Note this is already correctly reflected
in the AVP table of section 8.1