This page contains the list of open and resolved Diameter Issues.
A description in red implies that no issue has been submitted (if you are the owner of such a message, please send AAA Editors 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 AAA Editors .
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.
| BASE Open Issues Issue Number |
Status | Description | Owner |
| Issue #218 | Pending | ABNF/Table inconsistencies | Calhoun |
| Issue #303 | Possible Reject | Security model for peer discovery and redirect | David Spence |
| Issue #311 | No Discussion | Acct-Application-Id and Vendor-Specific-Application-Id in ACR | Johansson |
| Issue #315 | No Discussion | Bug in Acct state machine +
State machines should be split into client vs. server |
Pete McCann |
| Issue #318 | Possible Reject | Host-IP-Address AVP in CER and CEA is redundant | Venkata |
| Issue #319 | No Discussion | Accounting-Realtime-Required | Pete McCann |
| Issue #320 | No Discussion | Base-09 Nits | Arkko |
| Issue #321 | No Discussion | Normative references to CMS | Greg Weber |
| Transport Open Issues Issue Number |
Status | Description | Owner |
| MIP Open Issues Issue Number |
Status | Description | Owner |
| Issue #218 | Possible Reject | ABNF/Table inconsistencies | Calhoun |
| Issue #290 | No Discussion | Handling of Accounting-Multi-Session-Id AVP | Bob Kopacz |
| Issue #296 | No Discussion | Possible new AVP for MobileIPv4 | David Spence |
| Issue #298 | No Discussion | Minor corrections to mobileip-09 | Bob Kopacz |
| Issue #299 | No Discussion | Need more explanation about handling MN handoffs | Bob Kopacz |
| Issue #301 | No Discussion | Securing the AAAH-generated session keys | Bob Kopacz |
| Issue #305 | No Discussion | Purpose of MIP-Foreign-Agent-Host | Johan Johansson |
| Issue #306 | No Discussion | Session-Timeout vs
Authorization-Lifetime vs MIP-Key-Lifetime |
Johan Johansson |
| Issue #317 | No Discussion | HA-FA Key | Sramam |
| Issue #321 | No Discussion | Normative references to CMS | Greg Weber |
| NASREQ Open Issues Issue Number |
Status | Description | Owner |
| Issue #188 | Pending | NAS-Key-Binding and Ciphersuite Negotiation | Haverinen |
| Issue #189 | Pending | NAS-Session-Key and Initialization Vectors | Haverinen |
| Issue #190 | Pending | NAS-Session-Key and Session Master Keys | Haverinen |
| Issue #255 | Pending | Translation of RADIUS vendor-specific attributes | Aboba |
| Issue #294 | Pending | NASREQ Key Distribution insecure | Jesse Walker |
| Issue #295 | Pending | More NASREQ AVPs needed | David Spence |
| Issue #297 | Pending | NASREQ-specific values for Termination-Cause AVP | David Spence |
| Issue #300 | No Discussion | EAP corner conditions | Bernard Aboba |
| Issue #308 | No Discussion | Support for Originating-Line-Info AVP missing from NASREQ | Bernard Aboba |
| Issue #321 | No Discussion | Normative references to CMS | Greg Weber |
| CMS Open Issues Issue Number |
Status | Description | Owner |
| Issue #218 | Pending | ABNF/Table inconsistencies | Calhoun |
| Issue #278 | Pending | CMS Issues | Arkko |
| Issue #312 | No Discussion | Diameter CMS Security - Require AAA-Node-Cert in DSAR and DSAA | Don Zick |
| Issue #313 | Pending | CMS Security Questions | Stephen Farrell |
| Issue #316 | No Discussion | CMS Editorial Issues | Arkko
|
| Issue #321 | No Discussion | Normative references to CMS | Greg Weber |
The following table contains the issues that have already been resolved, and the fix included in a revision of a Diameter specification.
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 = " fixed = [qual] "<" avp-spec ">"
required = [qual] "{" avp-spec "}"
optional = [qual] "[" avp-name "]"
qual = [min] "*" [max]
min = 1*DIGIT
max = 1*DIGIT
avp-spec = name-fmt
avp-name = avp-spec | "AVP"
4.4.1 Example AVP with a Grouped Data type
The Example AVP (AVP Code 999999) is of type Grouped and is used to
Example-AVP ::= < AVP Header: 999999 >
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 =
Session-Id =
optional AVPs included are
Recovery-Policy = Futuristic-Acct-Record = The data for the optional AVPs is represented in hex since the format
This AVP would be encoded as follows:
0 1 2 3 4 5 6 7
Issue 12: Boot Id
Requested change:
The interim group felt that, of the three proposals in the foot-fetish
Randy suggested that the name of the AVP be changed from Boot-Id to
Origin-State-Id will have to be added to the ABNF for DRI as well as
all
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
A Diameter entity issuing this AVP MUST create a higher value for
The Origin-State-Id, if present, MUST reflect the state of the
Typically, Origin-State-Id is used by an access device that always
[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
By including Origin-State-Id in DRI messages, an access device allows
By including Origin-State-Id in request messages, an access device
When a Diameter server receives a Origin-State-Id that is greater
Resolution: Accept proposed text
Issue 13: DSI
Resolution: The decision that was taken at the Interim meeting
Issue 14: Watchdogs
Requested change:
Resolution: Watchdogs are required, regardless of transport
Issue 15: Where should ASI be sent?
Requested change:
Issue 16: Redirect Server Certificates
Requested change:
Issue 17: Head of Line Blocking Prevention
Requested change:
Resolution: Accept proposed text
Issue 18: Remove the Error-Reporting-FQDN
Requested change:
Issue 19: Extensions that Diameter servers MUST support
" Diameter servers MUST support the Base protocol, which includes
Requested change:
" Diameter home servers MUST support the Base protocol, which includes
Resolution: Accept the proposed text above.
Issue 20: How to handle no common extensions
Resolution: New text is as follows:
Issue 21: TLS & SCTP Streams
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
At the interim meeting, a proposal for the introduction of a new data
type
Enumerated types are defined in the NASREQ extension already and are
An enumerated type defines an explicit list of unsigned 32-bit integer
When encoding enumerated types there is a translation step from a name
to
Enumerated types are also treated differently when it comes to allocating
Requested change:
Add a new subtype of Unsigned32 as follows:
Unsigned32
Enumerated
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
Requested change:
0 1 2 3
Resolution: Accept proposal
Issue 24: Transport Selection
Issue 25: Support for multi-processes
* Issue #6, "Server Identification" changes the FQDN to be an identifier
* If more than one server can exist on a platform, then you cannot
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?
* The Session-Terminate-Request requires a Destination-FQDN
* There was going to be text added to state that the Destination-FQDN
* What happens if that Destination-FQDN is down? If this is a
cluster
Requested change:
One or more of the following changes:
1. Do nothing. If the authenticating server goes down, either
all the
2. Make the Destination-FQDN optional. If the client receives
a
3. #2 above, but allow a proxy to also do this.
4. Make the Destination-FQDN optional. Add an STR-Destination
AVP
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?
Resolution: The AVP is removed from the base specification.
Issue 29: IPv6 AVPs
Issue 30: Failed-AVP should be Grouped
Requested change:
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
The possible reasons for this AVP are the presence of an improperly
A Diameter message MAY contain one Failed-AVP AVP, containing
AVP format:
Resolution: Accept proposed text
Issue 31: Increase randomness of Session-Id to 64 bits
A 32 bit monotonically increasing value is not sufficient to guarantee
Requested change:
Basically, make the monotonically increasing value 64 bits rather
Note that I went beyond what was discussed at the interim meeting in
Suggested language:
The Session-Id MUST be globally and eternally unique, as it is meant
The Session-Id MUST begin with the client FQDN. If the client uses a
<client FQDN>[:<port>];<high 32 bits>;<low 32 bits>[;<optional
value>]
<high 32 bits> and <low 32 bits> are decimal representations of
the high
<optional value> is implementation specific but may include a modem's
Example, in which the standard port is used and there is no optional
accesspoint7.acme.com;1876543210;523
Example, in which a non-standard port is used and there is an optional
accesspoint7.acme.com:831;1876543210;523;mobile@200.1.1.88
Resolution: Accept proposed text
Issue 32: NASREQ extension includes Indication messages
Issue 33: Is API message considered useful?
Issue 34: DRI should only be sent on connection establishment
Issue 35: Device-Reboot-Ind isn't an appropriate name
Issue 36: KDC support in NASREQ Extension
Requested change:
Issue 37: Home State Blob
Requested change:
Issue 38: Home should state whether the Destination-FQDN
is present in follow-on messages
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?
R-Send-Conn-NACK assumes that the application has the ability to
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?
Issue 41: 'M' bit clarification
Issue 42: Session-Timeout inconsistent with RADIUS spec
Issue 43: Requesting a non vendor-specific AVP Code
as Specification Required
Issue 44: How does an implementation state it is compliant
Issue 45: Allow for vendor-specific extensions
Issue 46: Base protocol doesn't specify how to get
Vendor Identifier
Issue 47: Some AVPs in tables do not have 'V' bit as
MUST NOT
All AVPs defined will either be IETF or vendor specific.
Requested change:
Issue 48: Destination-FQDN in re-auth Messages
Note: The answer to this issue may be related to the answer for issue
* When a Diameter server re-authorizes, the Destination-FQDN
* There is no guidance as to how to use the Destination-FQDN.
* There are two types of authentication realms:
* There are two common causes of re-authorization
* So the Destination-FQDN will be set according to the following situations:
* If you are using Destination-FQDN with re-authorization, and the server
Requested Change:
Something like this text should be added.
If re-authorization is required by the server because of
Option 2:
Something like this text should be added.
Re-authorization MUST use as the Destination-FQDN the Origin-FQDN
of
Option 3:
Something like this text should be added.
Re-authorization MUST first use as the Destination-FQDN the
Option 4:
Something like this text should be added.
Re-authorization MUST first use as the Destination-FQDN the
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?
Issue 50: Proxy Behavior
The current base draft defines "Proxy Server" as a routing proxy, and
However, I think we should probably aim higher. The operation of proxies
One interesting point made in the SIP spec is that types of proxy behavior
At various points in the base spec, it is hard for me to understand
what
1. pp. 21, base. "If such an AVP is received by a Proxy or Redirect
2. pp. 27, base. "Proxies receiving messages that contain the
3. pp. 28, base. "A receiver of a DRI message which does not have any
4. pp. 39. "An e2e error occurs when a Diameter entity sends a message
and
5. pp. 44 "The Device-Status-Ind message MUST NOT be proxied, but MAY
be
6. pp. 56. Section 11.1.1 talks about the realm-based routing table.
Table
7. On pp. 57 it says "the local server MAY apply its local
8. pp. 57 "a message that does not contain any of the above AVPs MUST
NOT
9. pp. 59. This section talks about behavior of stateless and stateful
Resolution: The fixes can be found at http://www.merit.edu/mail.archives/aaa-wg/msg01012.html.
Issue 51: EAP Roundtrips
This issue is an optimization. In some EAP types, the last EAP-Response
Requested change:
Section 4.0 on page 20 reads:
Please replace that with:
Please add a new item in the list of Section 4.2.1:
5) A Diameter-EAP-Answer containing an EAP-Request encapsulated
Please include EAP-Request in the explanations of the first paragraph
The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code
Issue 52: Multi-roundtrip Mobile IP authentication
Some authentication mechanisms may take more than one
Requested change:
These mechanisms can easily be supported in the Diameter Mobile IP
An unsuccessful AMA message MAY include mobile node registration
In addition, please include MIP-MN-to-FA-Key AVP in the
Resolution: I have added the following text to section 2.2:
Proposed Text:http://www.merit.edu/mail.archives/aaa-wg/msg01066.html
Issue 53: What if the AAAL cannot reach the HA?
The AAAL may not be able to reach the home agent the mobile
Requested change:
Section 2.2 currently says: "A successful AMA message MUST include
The AAAL may not always be able to reach the home agent even if was
able
Issue 54: Replace the term extension to application
The IESG has stated that they are concerned with the term extension,
Requested change:
Make the necessary terminology changes throughout the specs.
Issue 55: Server-initiated re-auth
In the process of fixing Issue #32, the Indication messages have been
removed from
Is this feature required? If so, is it specific to NASREQ, or could
it be generalized
Three options:
Issue 56: Flag bit for start of conversation
For use in load balancing, it can be important to easily discern
Requested change:
Additional Comments: It appears this feature is already supported
Resolution: Accept text proposed in http://www.merit.edu/mail.archives/aaa-wg/msg01212.html
Issue 57: Accounting-Record-Type and clarification
Resolution: accept the following text in section 11.5:
Issue 58: e2e draft essr/essa delay
Resolution: No concensus was found on this issue. An update can be
Issue 59: e2e mandatory status
Issue 60: e2e draft cert names
Issue 61: e2e cms and pki profiling
Issue 62: e2e unnecessary step via pkcs7-mime
Issue 63: e2e unverified certs
Resolution: The statement has been removed from the CMS draft.
Issue 64: e2e draft editorial issues
Issue 65: OctetString with NULL value
Resolution: Being discussed
Issue 66: Server Discovery Text to change
Issue 67: How to deal with CER and CEA in the case of SCTP
Issue 68: Address Name and 20 byte IPV6 length
Resolution: Accept sub-issue #1, but sub-issue #2 is denied. NASREQ
Issue 69: ABNF editorial changes
Issue 70: Caching of redirects
Issue 71: Various editorial changes
Resolution: Accept proposed fixes
Issue 72: Downstream/upstream confusion
Resolution: Fixed up text in 6.1 and 10.10 to ensure that the
Issue 73: Request & answer routing clarification
Resolution: Accepted proposed changes with slight grammatical changes.
Issue 74: Do not use Route-Record for answer
routing
Issue 75: Unsolicited server-to-client requests
Issue 76: Destination-Realm & proxies/relays
Issue 77: Implicit termination of an Auth session
Issue 78: DiameterIdentity (host descriptor) matching & values
Issue 79: Error handling editorial changes
Issue 80: Editorial changes
Issue 81: Route-Record change
Issue 82: Reauthorization issues
Issue 83: Routing/forwarding clarifications
Issue 84: Possibly editorial issues in cms-sec
Issue 85: Cms-sec optimization for pdsr-case
Issue 86: Diameter URI Changes
Issue 87: Move filter-rule AVP to base
Issue 88: EAP Support Issues
Issue 89: Editorial comments - Mobile-IP draft-06
Issue 90: MIP-Previous-XXX AVP
Issue 91: MIP-SPI
Issue 92: Some editorials on Base-06
Issue 93: End-to-End Identifier
Issue 94: Typographical change to sec. 3.2 of draft-ietf-aaa-transport-04.txt
Issue 95: Problem with removing Route-Record AVPs
Issue 96: Change Record-Route to Route-Record
Issue 97: Proxies keeping a session-state
Issue 98: Peer role in Peer table?
Issue 99: New AVPs to NASREQ for Basic/Digest support
Issue 100: Editorial comments on base-07
Issue 101: Editorial changes concerning Destination-Host
Issue 102: More description on Session state machine
Issue 103: Inconsistencies in AVP types used throughout base spec
Issue 104: clarification on difference between session and peer connection
Issue 105: More editorial comments
Issue 106: More changes to table in section 4.6
Issue 107: More editorial comments
Issue 108: Errata in Mobile-IP Application
Issue 109: Request for a new AVP called Missing-AVP
Issue 110: MIPv4 comments
Issue 111: More editorial comments on base-07
Issue 112: More editorial comments on base-07
Issue 113: base draft 07 comments
Issue 114: DiameterIdentity
Issue 115: CHAP-Password is complex
Issue 116: Accounting-Session-Id definition incorrect
Issue 117: Remove support for Source-Route
Issue 118: Error processing/capabilities negotiation
Issue 119: E bit, P bit, and proxy-info
Issue 120: Minor editorial changes in CMS Security Application
Issue 121: More editorial changes in CMS
Issue 122: Editorial change in draft-ietf-aaa-diameter-07.txt
Issue 123: Use of Application Identifiers in routing
Issue 124: Inconsistency in OCSP-Request-Flags AVP
Issue 125: Inconsistency in OCSP-Responses AVP
Issue 126: Clarification in certificate naming schema
Issue 127: Editorial changes in CMS
Issue 128: duplicate packet detection in failure case
Issue 129: NASREQ unsolicited challenge requests
Issue 130: Prescribed use of encryption in NASREQ
Issue 131: Use of Auth-Request-Type in NASREQ
Issue 132: Multiple signatures on a set of AVPs
Issue 133: digest value within CMS-Signed-Data AVP
Issue 134: Several CMS-Encrypted-Data AVPs in a message
Issue 135: contentType instead of eContentType in CMS-Encrypted-Data
Issue 136: Proxy's DSAR on behalf of a client
Issue 137: CMS Proxy's DSAAs
Issue 138: Signed DSA messages
Issue 139: Key Management chapter rephrasing
Issue 140: Can Answer be rejected?
Issue 141: OCSP Response request additional text
Issue 142: CEKMaxDecrypts value vs DSA length
Issue 143: Editorial changes in CMS #4
Issue 144: OCSP Support
Issue 145: Order in CMS-proxy messages
Issue 146: CHAP Algorithm missing
Issue 147: CHAP Algorithm missing
Issue 148: Change section 5-6 in MIP app to relect
Issue 149: Revalidation of certificates in cache
Issue 150: S/MIME precisions
Issue 151: 8.1 Authorization Session State Machine
Issue 152: Confusion between security services and techniques to achieve them
Issue 153: Key Length in CMS Security Application
Issue 154: End-to-End Id in answer messages
Issue 155: Small editorial comment on section 5.5.4
Issue 156: DSA error codes
Issue 157: DSA error codes (cont)
Issue 158: DSA error codes (III)
Issue 159: Reference change in CMS-02
Issue 160: Destination-Host in PDSR
Issue 161: Authorisation rejected in CMS
Issue 162: Error replies to requests with no session id
Issue 163: Error codes (recap)
Issue 164: problems with Watch Dog
Issue 165: Expiration of DSAs on behalf of a client
Issue 166: Ambiguity on Destination-Host AVP in Answer messages
Issue 167: CMS-Cert in AVP occurrence table
Issue 168: DIAMETER_NO_COMMON_TRUST error
Issue 169: Result-code with 'P' bit erroneous
Issue 170: Erroneous protection expectations
Issue 171: missing realm protocol error
Issue 172: The need for Float128 ?
Issue 173: Transport failure algorithm differs between drafts
Issue 174: CMS Decryption Error
Issue 175: Missing text in float definitions
Issue 176: Add clarifying App-Id text in CER/CEA sections
Issue 177: CMS proxy scenarios
Issue 178: Partial support of CMS
Issue 179: PDSA-Request without DSA-Target-Realm
Issue 180: AAA-Server-Certs
Issue 181: Digital encryption + signature in CMS-Sec
Issue 182: Retain RADIUS attribute types for attributes 0-255
Issue 183: Diameter hop-by-hop security
Issue 184: CMS-Data AVPs in base protocol
Issue 185: CMS-protected AVPs outside a DSA
Issue 186: Decouple authorization and key generation
Issue 187: Foreign-Home authentication extension doesn't exist
Issue 188: NAS-Key-Binding and Ciphersuite Negotiation
Issue 189: NAS-Session-Key and Initialization Vectors
Issue 190: NAS-Session-Key and Session Master Keys
Issue 191: How to know when to use TLS
Issue 192: Missing Disconnect Cause
Issue 193: Changes to Peer state machine in base-08-alpha
Issue 194: Add Termination-Cause values for MIPv4
Issue 195: Clarifications on key generation (mobileip-08)
Issue 196: How to use Diameter Accounting
Issue 197: Missing Session Termination Cause in Section 8.15
Issue 198: MIP-FA-to-[HA|MN]-Key not needed in HAR
Issue 199: wdRecoveryCount used for triggering failover procedures
Resolution: This issue is believed to be fixed in Transport-05. If
has not been resolved, please reopen.
Issue 200: Missing UserName AVP in table in section 10.2
Issue 201: MIP-FA-to-MN-SPI and co-located servers
Issue 202: Alternatives to the Command Code ABNF specification
Issue 203: MIP-FA-to-HA being added to the AMA by the AAAF
Issue 204: How to handle CER from unknown peer
Issue 205: Should AVPs be ordered?
Issue 206: ABNF of non-proxiable commands incorrect
Issue 207: AAA URI inconsistent
Issue 208: Peer State Machine incorrect in case of election
Issue 209: Authorization-Lifetime inconsistency
Issue 210: Session-Timeout ABNF/Table inconsistency
Issue 211: When should Destination-Host be present in HAR?
Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?
Issue 213: MN-AAA SPI must be included in the HAR message
Issue 214: Unknown-User Result-Code provides too much info
Issue 215: Use of hmac-md5 is incorrect
Issue 216: Home Agent MUST support home address allocation
Issue 217: typo in MIP section 3.2
Issue 218: ABNF/Table inconsistencies
Issue 219: AMA AVP issue when failure occurs
Issue 220: Not possible to dynamically update capabilities
Issue 221: Why require CMS to send its expected AVPs?
Resolution: The resolution to issues #221 and 279 was to remove the
expected-* AVPs Issue 222: Routing within a domain
Issue 223: How does CMS work if the HA is unknown and in foreign network
Issue 224: Handling errors in the TCP stream
Issue 225: Specify Statefulness/Statelessness Requirements
Issue 226: Server-Initiated Re-Auth in Diameter MIPv4 not supported
Issue 227: End to end identifier
Issue 228: Remove Route_Record Avp in all the Answer message
Issue 229: Remove MIP-PEER-SPI AVP
Issue 230: Add Mip-Key-Lifetime AVP to ABNF and comand table
Issue 231: Home-Agent-In-Foreign-Network set by AAAF
Issue 232: Session Definition
Issue 233: MIP-Candidate-Home-Agent-Host
Issue 234: just a number of editorial nits....
Issue 235: Enabling efficient accounting record uniqueness checking
Issue 236: DiameterIdentity
Issue 237: Accounting-Multi-Session-Id AVP in the HAR
Issue 238: Mip-Feature-Vector AVP in ACR
Issue 239: Definition of Diameter agent
Issue 240: Time in end-to-end identifier
Issue 241: Accounting issues
Issue 242: Specifying Vendor in Command ABNF
Issue 243: Session State Machine for Diameter agents
Issue 244: ELECTION_LOST result code
Issue 245: User-Name avp in the RAR and RAA message
Issue 246: Accounting-*-Extended-Octets numbers are inconsistent
Issue 247: Inconsistencies between the base and transport drafts
Issue 248: Error messages: decimal or hex?
Proposed resolution to #248 -Mark Issue 249: Editorial nits in Diameter Base -08
Issue 250: Normative versus Informative references
Issue 251: References to ADIF in NASREQ-08
Issue 252: Granting Access via Accounting
Issue 253: Diameter Peer Discovery
Issue 254: More details needed on Diameter IPsec usage
Issue 255: Translation of RADIUS vendor-specific attributes
Issue 256: TLS Usage Issues
Issue 257: peer connection inconsistent between base08 and transport05
Issue 258: CER first or watchdog first when reopening a connection
Resolution: If a connection is CLOSED, and then re-opened, capabilities
exchange is indeed needed, so CER/CEA is handled first. Issue 259: Qualifier of Vendor-Specific-Application-Id in CEA
Issue 260: SNTP referencing
Issue 261: Peer discovery mechanism requirements
Issue 262: A Diameter node must use its own TLS certificate
Issue 263: Mandate required TLS cipher suites
Issue 264: User-Name in Answer messages
Issue 265: MIP-Reg-Reply AVP not required in AMA for Co-located MN
Issue 266: Returning AAAF-Generated FA-HA Key to FA
Issue 267: Minor corrections/clarifications to draft-mobileip-08
Issue 268: Diameter Extensibility
Issue 269: Diameter -07 introduction needs improvement
Issue 270: Sections 5.6.2 - Rcv-Message - add
DPR,DPA Issue 272: Separation of the prepaid and
postpaid accounting sessions Issue 273: DNS SRV text needs to be updated From: David Frascone Issue 274: Add AAA to terminology Issue 275: Changes to state machine for
ASR/ASA messages Issue 276 : Remove section 1.6 from the CMS appl Resolution: The section 1.6 that was in -03 is
removed from -04. (The -03 Issue 277: session-id & user-name AVPs; NASREQ inconsistancies Issue 278: CMS issues Comments from Stephen Farrell: This one contains a bunch of different
things: Issue 279: Base does not sufficiently explain what MAY encrypt means Issue 280: close of 277 Issue 281: transport state references Issue 282: allow redirect agents to have the option
of providing user to server address resolution. Issue 283: Usage of TLS vs. IPsec Issue 284: Possible modification to the Diameter Cost Control Application protocol Issue 285: Another accounting AVP issue... Issue 286: MIP-Home-Agent-Host AVP Issue 287: Overloaded URI Issue 288: Setting the M bit. Issue 289: Routing of session messages defined in base Issue 290: Handling of Accounting-Multi-Session-Id AVP Issue 291: Remove references to CMS-Cert in cms-sec-03 Resolution: The string
CMS-Cert doesn't occur in -04. Issue 292: Handling of Home-Agent-In-Foreign-Network flag Issue 293: Relax Service-Type from REQUIRED to RECOMMENDED in nasreq Issue 294: NASREQ Key Distribution Insecure Issue 295: More NASREQ AVPs needed Issue 296: Possible new AVP for MobileIPv4 Issue 297: NASREQ-specific values for Termination-Cause AVP Issue 298: Minor corrections to mobileip-09 Issue 299: Need more explanation about handling MN handoffs Issue 300: EAP corner conditions Issue 301: Securing the AAAH-generated session keys Further notes from Tony: Date: Sun,
24 Mar 2002 23:30:03 -0800 Issue 302: Combine occurrence rules tables with message ABNF Issue 303: Security model for peer discovery and redirect Issue 304: Allowance for temporary peer connections Issue 305: Purpose of MIP-Foreign-Agent-Host
Submitter name: Johan Johansson Issue 306: Session-Timeout vs
Authorization-Lifetime vs MIP-Key-Lifetime If the application doesn't use
Session-Timeout it should not be optional Issue 307:
Diameter CMS Security - Remove DSA-TTL from PDSA message Issue 308:
Support for Originating-Line-Info AVP missing from NASREQ Value p.s. 90-92 Unassigned Issue 309:Fix conflicting AVP codes in
NASREQ Issue 310:Ambiguities
in AVP Flag rules tables
Submitter name: David Spence Issue 311:Acct-Application-Id and
Vendor-Specific-Application-Id in ACR How do you specify the application Id in the ACR and ACA commands if you [Notes from Bernard Aboba follow] I think that this issue is in part engendered by a lack of clarity in the Every Diameter application specification MUST have an IANA assigned [Notes from Jari Arkko follow] Date: Thu, 28 Mar 2002 21:44:48 +0200 Issue 312:Diameter CMS Security - Require
AAA-Node-Cert in DSAR and DSAA Requested change: Issue 313:CMS Security Questions Don Zick wrote: So, I'd go for changing the avp occurrence rule and leaving the > > > 8. Section 6.3 provides some example encodings for encrypted and > 10. DSAA ABNF has Local-CA-info surrounded by curly brackets. I > 13.Some typos: Issue 314:Minor clarifications/corrections to
Base-09 To (four changes "A"... "or"... "agent"... "to"): 8.1 Authorization Session State Machine
CLIENT, STATEFUL
State Event Action New State
-------------------------------------------------------------
Idle Client or Device Requests send Pending
access service
specific
auth req
Pending Successful Service-specific Grant Open
authorization answer Access
received with default
Auth-Session-State value
Pending Successful Service-specific Sent STR Discon
authorization answer received
but service not provided
Pending Error processing successful Sent STR Discon
Service-specific authorization
answer
Pending Failed Service-specific Cleanup Idle
authorization answer received
Open user or client device send Open
requests access to service service
specific
auth req
Open Successful Service-specific Extend Open
authorization answer received Answer
Open Accounting message sent process Open
Open Failed Service-specific Discon. Idle
authorization answer user/device
received.
Open Session-Timeout Expires on send STR Discon
Access Device
Open ASR Received send ASA, Discon
STR
Open Authorization-Lifetime + send STR Discon
Auth-Grace-Period expires on
access device
Discon ASR Received None Discon
Discon STA Received Discon. Idle
user/device
The following state machine is observed by a server when it is
maintaining state for the session:
SERVER, STATEFUL
State Event Action New State
-------------------------------------------------------------
Idle Service-specific authorization send Open
request received, and successful
user is authorized serv.
specific answer
Idle Service-specific authorization send Idle
request received, and failed serv.
user is not authorized specific answer
Open Service-specific authorization send Open
request received, and user successful
is authorized serv. specific
answer
Open Service-specific authorization send Idle
request received, and user Failed serv.
is not authorized specific
answer,
Cleanup
Open Accounting message received process Open
Open Home server wants to send ASR Open
terminate the service
Open ASA Received Cleanup Idle
with Result-Code
= UNKNOWN-SESSION-ID
Open ASA Received None Open
with Result-Code (ignore)
not = UNKNOWN-SESSION-ID
Open Authorization-Lifetime (and Cleanup Discon
Auth-Grace-Period) expires
on home server.
Open Session-Timeout expires on Cleanup Discon
home server
Open STR Received Send STA Idle
Not ASA Received None No Change.
Open
Discon STR Received Send STA Idle
The following state machine is observed by a client when state is
not maintained on the server:
CLIENT, STATELESS
State Event Action New State
-------------------------------------------------------------
Idle Client or Device Requests send Pending
access service
specific
auth req
Pending Successful Service-specific Grant Open
authorization answer Access
received with Auth-Session-
State set to
NO_STATE_MAINTAINED
Pending Failed Service-specific Cleanup Idle
authorization answer
received
Open Accounting message sent process Open
Open Session-Timeout Expires on Discon. Idle
Access Device user/device
Open Service to user is terminated Discon. Idle
user/device
The following state machine is observed by a server when it is not
maintaining state for the session:
SERVER, STATELESS
State Event Action New State
-------------------------------------------------------------
Idle Service-specific authorization send serv. Open
request received, and specific
successfully processed answer
Open Accounting message received process Open
8.2 Accounting Session State Machine
For applications that only require accounting services, the following
state machines MUST be supported. The first is to be observed by
clients, the second by servers.
When a session is moved to the Idle state, any resources that were
allocated for the particular session must be released. Any event not
listed in the state machines MUST be considered as an error
condition, and an answer, if applicable, MUST be returned to the
originator of the message.
CLIENT, ACCOUNTING
State Event Action New State
-------------------------------------------------------------
Idle Client or device requests send PendingS
access accounting
start req.
Open Interim interval elapses send PendingI
accounting
interim
record
Idle Client or device requests send PendingE
a one-time service accounting
event req
Idle Records in storage Send PendingB
record
Open User service terminated send PendingL
accounting
stop req.
PendingS Successful accounting Open
start answer received
PendingS Failure to send and buffer Store Open
space available and realtime Start
not equal to DELIVER_AND_GRANT Record
PendingS Failure to send and no buffer Open
space available and realtime
equal to GRANT_AND_LOSE
PendingS Failure to send and no buffer Disconnect Idle
space available and realtime user/dev
PendingI Failure to send and (buffer Store Open
space available or old record Interim
can be overwritten) and Record
realtime not equal to
DELIVER_AND_GRANT
PendingI Failure to send and no buffer Open
space available and realtime
equal to GRANT_AND_LOSE
PendingI Failure to send and no buffer Disconnect Idle
space available and realtime user/dev
not equal to GRANT_AND_LOSE
PendingE Successful accounting Idle
event answer received
PendingE Failure to send and buffer Store Idle
space available Event
Record
PendingE Failure to send and no buffer Idle
space available
PendingB Successful accounting answer Delete Idle
received record
PendingB Failure to send Idle
PendingL Successful accounting Idle
stop answer received
PendingL Failure to send and buffer Store Idle
space available Stop
Record
PendingL Failure to send and no buffer Idle
space available
SERVER, ACCOUNTING
State Event Action New State
-------------------------------------------------------------
Idle Accounting start request send Open
received, and successfully accounting
processed. start
answer
Idle Accounting event request send Idle
received, and successfully accounting
processed. event
answer
Open Receive Interim Record send Open
accounting
answer
Open Accounting stop request send Idle
received, and successfully accounting
processed stop answer 20) section 4.I think CA-Chain should be a "*" instead of "0*1". THere
Issue 317:FA-HA Key
Issue 318:Host-IP-Address AVP in CER and CEA is
redundant
Issue 319:Accounting-Realtime-Required
Abstract:
2.1:
Issue 321:Normative references to CMS
Requested change:
From Bernard:
From Jari Arkko:
"The really crucial and useful piece of information is in the values in the
avpcode = 1*DIGIT
; The AVP Code assigned to the Grouped AVP
; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name which is included
; in a fixed or required rule.
; 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'.
; The minimum number of times the element may
; be present.
; The maximum number of times the element may
; be present.
; The avp-spec has to be an AVP Name, defined
; in the base or extended Diameter
; specifications.
; 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.
clarify how Grouped AVP values work. The Grouped Data field has the
following ABNF grammar:
{ Origin-Host }
1*{ Session-Id }
*[ AVP ]
"grump.example.com:33041;23432;893;0AF3B81"
"grump.example.com:33054;23561;2358;0AF3B82"
2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
d3427475e49968f841
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).
+-------+-------+-------+-------+-------+-------+-------+-------+
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|
+-------+-------+-------+-------+
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.
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.
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.
other messages, as an optional AVP.
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.
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.
entity indicated by Origin-FQDN. If a proxy modifies Origin-FQDN,
it MUST either remove Origin-State-Id or modify it appropriately as
well.
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.
sessions for which no STR would have been issued, due to unanticipated
shutdown of an access device.
a next-hop server to determine immediately upon connection whether
the
device has lost its sessions since the last connection.
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.
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.
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).
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
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?
Elimination of watchdogs
keepalives.
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?
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.
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?
Add clarifying text
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
See URL for proposed change.
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.
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.
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:
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."
Change the above paragraph to the following:
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."
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."
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.
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.
Submitter name: Mark Jones
Submitter email address: mjones@bridgewatersystems.com
Date first submitted: May, 2001
Reference: Issue #22 on http://www.diameter.org/issues.html
Document: Base
Comment type: T
Priority: 1 or 2 (?)
Section: 4.3
Rationale/Explanation of issue:
(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.
different from the currently defined types in how they are validated,
encoded and allocated.
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).
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.
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.
32 bit unsigned value, in network byte order. The AVP Length
field MUST be set to 12 (16 if the 'V' bit is enabled).
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).
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?
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 ...
+-+-+-+-+-+-+-+-+
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).
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:
that allows more than one copy of a Diameter server on a host.
do refuse a connection based on ip address.
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:
should be that of the last place you authenticated.
of servers, there may still be a need for the STR to be sent
to the
realm.
state data is lost, or session timeouts will cleanup any
STRs missed.
A statement as such should be added to the RFC reflecting
this.
DIAMETER_UNABLE_TO_DELIVER, the client may send the request
without
a Destination-FQDN.
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.
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.
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.
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.
Eliminate Offending-AVP and Failed-Vendor-Id, change
Failed-AVP to be of type grouped.
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.
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.
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.
1* {AVP}
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:
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.
than 32 bits.
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.
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.
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):
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.
device Id, a layer 2 address, timestamp, etc.
value:
value:
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.
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.
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."
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.
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.
Add text provided in URL above.
Resolution: Adopt text as proposed. Pat will make necessary
modifications to ensure consistency.
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.
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.
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.
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:
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.
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.
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.
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?
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.
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.
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.
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.
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:
In the current Drafts, everything is IETF. Hence the AVP
Flag 'V' should be in the MUST NOT column for all attributes.
Add the 'V' flag to the MUST NOT column.
Resolution: This will be done.
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:
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"
is optional.
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.
Timeout: The Authorization-Lifetime may soon end and re-authorization
is needed.
Forced: A server sends a AA-Challenge-Ind
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
is down, do you send to the realm, assume Re-authorization was
successful,
or disconnect the user.
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.
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.
* Assume realms are not linked.
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.
* Expect ignorance, and allow for enlightenment.
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).
* A combination of 2 and 3
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).
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.
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."
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.
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.
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.
type of proxy is being referred to, or whether the text applies to
*all*
proxy types as defined in the various drafts. Some examples:
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?
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?
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.
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.
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.
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.
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?
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?
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.
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:
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.
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.
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.
within an EAP-Payload and a Result-Code indicating success.
of Section 4.2.2. Like this:
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.
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:
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.
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:
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.
AA-Mobile-Node-Answer message format definition.
" 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. "
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:
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.
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:
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.
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:
and would prefer that the term application be used instead.
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:
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.
and defined in the base protocol specification?
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.
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:
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.
Addition of Flag bit to denote "start of conversation".
since a message that is bound for a particular server would already
include the Destination-Host AVP.
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.
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.
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?
found at http://www.merit.edu/mail.archives/aaa-wg/msg01213.html
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...
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...
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...
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?
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?
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.
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.
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?
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.
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
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.
already has this functionality, and requires a new AVP to contain the
Interface identifier.
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
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.
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.
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.
terms are used consistently in the document.
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.
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.
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.
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.
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).
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).
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
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.
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 :-)
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...)?
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
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.
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.
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/
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
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.
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
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.
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.
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 :(
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.
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...".
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.
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".
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.
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.
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.
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").
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)]
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.
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
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.
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?
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.
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…”
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"
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.
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
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)
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.
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.
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.
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
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.
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.
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.
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
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.
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"
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"
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
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."
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):
...
{ 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.
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:
...
* { 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 ]
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-
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
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"
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.
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
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].
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.
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.
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.
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.
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].
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
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
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
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.
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.
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.
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
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"
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.
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
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
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.
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.
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.
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
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?
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.
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
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."
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,
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.
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.
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
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
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:
{ 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
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.
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."
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.
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.
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:
{ 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.
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.
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?
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
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.
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
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.
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.
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.
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.
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.
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
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.
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).
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.
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.
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.
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.
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.
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].
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.
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.
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.
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?
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.
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).
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.
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.
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 <-------
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.
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.
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.
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.
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.
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)
}
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
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 ]
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
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?
from CMS, and change the defintion of "MAY Encr" in both base
and CMS. The agreed change in the CMS I-D is at the end
of section 3.1:
"Note: [BASE] includes the "MAY encr" column when describing AVPs. For
the originator "MAY encr" as used in [BASE] means that if a message
containing that AVP is to be sent via a proxy/agent (as opposed to
directly) then the message MUST NOT be sent unless there is a DSA
between the originator and the recipient OR the originator has
locally trusted configuration that indicates that CMS need not be
used."
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.
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.
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.
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.
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.
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).
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)
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 ]
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 |
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.
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.
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
Submitter name: Kevin Purser
Submitter email address: kevin.purser@ericsson.com
Date first submitted: 09-NOV-01
Reference: none
Document: base-08-alpha02
Comment type: 'E'ditorial
Priority: '1'
Section 1.3, Terminology,
-definition of Accounting record is incomplete (looks like a cut-and-paste
problem); looks like it should be completed with "diameter nodes" or
something to that effect.
Section 2.6, Connections vs. Sessions,
-figure is mangled
Section 7.1.3, Protocol Errors,
-the definition of DIAMETER_LOOP_DETECTED says:
An agent detected a loop while trying to get the message to the Home
Diameter server.
"the Home Diameter server" should be changed to something like "another
diameter agent" to reflect the possibility that the request message in
question may not be destined for the Home Diameter server (consider ASR,
RAR, etc).
Sections 8.4, 8.5, 9.7
-all of the ABNF definitions in these sections list the User-Name AVP as
mandatory. These should be changed to optional to reflect sessions which do
not have an associated User-Name (consider NASREQ messages).
Issue 235: Enabling efficient accounting record uniqueness checking
Submitter name: Basavaraj Patil
Submitter email address: Basavaraj.Patil@nokia.com
Date first submitted: November 9, 2001
Reference:
Document: Base-08
Comment type: T
Priority: 1
Section: 3.0, 9.4
Rationale/Explanation of issue:
If a Diameter server does not have any indicator in the received
Accounting Requests for the message being potentially duplicated,
the Diameter server (or a separate Accounting System) would have
to do a vast amount of unnecessary work just for the Accounting
Request uniqueness checking.
With more and more "hot billing" systems and prepaid billing for
packet data becoming prevalent it becomes a requirement for accounting
messages (records) to be sent far more frequently and also enabling
speedy evaluation for accuracy and uniqueness.
For accounting, the section 9.4 (Fault Resilence) defines
that duplication detection must be based on the
inspection of the Session-Id and Accounting-Record-Number
AVP pairs. The current draft text assumes that every
accounting message would be cross-checked with these identifiers against
the others, to detect duplicate accounting messages.
However it is far more efficient to o first check if the Accounting
Request sender has flagged the message to be a potential duplicate.
(Duplicate messages may be generated in the
exceptional cases when a communication link between
Diameter peers goes down. This could happen due to
the sending node failure or the receiving node failure or
the communication link itself failing. e.g. physically
damaged. When the sending node is redirecting the traffic
to an alternate peer or able to communicate again
after a temporary link failure to the primary peer,
it may send again messages that have not yet
been acknowledged by a recipient node.)
Duplicates are generated very seldom. (Typically
just a few packets, for eg. after a link failure case.)
Therefore duplicate checking all-against-all, by
seems a processing intensive work and one that is unnecessary to be
performed by accounting servers.
(by the Diameter server or a billing system).
The 'D' bit would be for all such accounting
requests that were pending an application layer ack
when the connection went down, whether they are
resent on a connection to the same peer or an alternate
peer.
In failover scenarios, duplicate checking may not necessarily
be done in the Diameter Server. It may alternatively
be done in a billing engine. In that case the
billing engine should get the 'D' bit information
from the Diameter header, as delivered together with
the payload.
(It should be noted that the potentially duplicated
accounting message may arrive earlier at the end system
than a non-marked original accounting message. This is
the case with any duplicate occurrence scenario, but
is not a problem as the end system should anyway have
some time buffer, e.g. 24h or 12h, for the received
accounting records to be checked for duplicates.)
The significant benefit achieved here
is the decrease of uniqueness checking processing
comparisons 1) from e.g. 77 octets to 1 bit and
2) from cross-comparing all accounting messages
in the time buffer against each other to comparing
just the very few potentially duplicated accounting messages to all
other accounting messages in the uniqueness checking time buffer.
The End-to-End Identifier could in theory be also
utilized by the uniqueness checkings in accounting
but has not been defined. Additionally,
the End-to-End Identifier has recently been considered
to be unique only during a very limited time period,
e.g. 4 minutes, which would not always be long enough
when e.g. a sending Diameter client node is in temporary
isolation due to a network failure for several hours.
The scheme proposed here does does not limit
the Diameter Server or billing engine to do the
uniqueness checking in any other way.
(eg. all accounting records checked against each other,
by the long AVP pair octet strings).
Requested change:
=================
In section 3.0 Diameter Header
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R P E r r r r r| Command-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
would be:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R P E D r r r r| Command-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and
E(rror) - If set, the message contains a protocol error,
and the message will not conform to the ABNF
described for this command. Messages with the
'E' bit set is commonly referred to as an error
message. This bit MUST NOT be set in request
messages. See section 7.2.
r(eserved) - these flag bits are reserved for future use, and
MUST be set to zero, otherwise an error MUST be
sent to the sender.
would get one new flag bit 'D':
E(rror) - If set, the message contains a protocol error,
and the message will not conform to the ABNF
described for this command. Messages with the
'E' bit set is commonly referred to as an error
message. This bit MUST NOT be set in request
messages. See section 7.2.
(possibly) D(uplicated)
- This bit is defined only for Accounting Requests,
sent by a Diameter node or proxy.
If set, the message is possibly a duplicate,
and must be later checked by a recipient node
if it really is a duplicate. If sending a
message for first time, this bit MUST be
cleared.
This bit MUST NOT be set if an answer message
(about e.g. a protocol error) has been got for
an earlier similar message. It can be used only
in cases where no answer has been got from the
primary agent for a message and the message is
sent again (e.g. due to a failover, to an
alternate agent or to a recovered primary peer
node).
r(eserved) - these flag bits are reserved for future use, and
MUST be set to zero, otherwise an error MUST be
sent to the sender.
and in section 9.4 Fault Resilience
====================================
...
Diameter peers acting as clients MUST implement the use of failover
to guard against server failures and certain network failures.
Diameter peers acting as agents or related off-line processing
systems MUST detect duplicate accounting records caused by the
sending of same record to several servers and duplication
of messages in transit. This detection MUST be based on the
inspection of the Session-Id and Accounting-Record-Number AVP pairs.
the above paragraph would get one sentence to its end:
The inspection MUST be performed at least for such records
that arrived at the Diameter peer specifically in accounting
messages which have the 'D' bit set.
Submitter name: Kevin Purser
Submitter email address: kevin.purser@ericsson.com
Date first submitted: 08-NOV-01
Reference: none
Document: base-08-alpha02
Comment type: 'E'ditorial
Priority: '1'
Section: 4.4 (Derived data formats)
Rationale/Explanation of issue:
A couple of editorial consistency checks dealing with the DiameterIdentity
Requested change:
(1)
The definition:
Diameter-Identity = "aaa://" fqdn [ port ] [ transport ]
[ protocol ] [ security ]
should be changed to:
Diameter-Identity = "aaa://" fqdn [ port ] [ transport ]
[ protocol ] [ transport-security ]
in order to reference the subsequent grammar rule;
(2)
The last bit of text:
For example, diameter-host.abc.com would be expanded to
aaa://diameter-
host.abc.com:TBD;protocol=diameter;transport=sctp.
should be changed to:
For example, diameter-host.abc.com would be expanded to
aaa://diameter-
host.abc.com:TBD;transport=sctp;protocol=diameter;transport-security=none.
To reflect the proper ordering of the options, as well as the default
for transport-security.
Submitter name: Michael Chen
Submitter email address: cchen@erilab.com
Date first submitted: 12-Nov-01
Reference:
Document: mobileip-08-alpha2
Comment type: editorial
Priority: 1
Section: Mobileip 1.2 2.3 2.4
Rationale/Explanation of issue:
In session 1.2 it state,
"The Accounting-Multi-Session-Id AVP in the HAR MUST be included in
the HAA,
which is then forwarded to the AAAH."
As we can see in Session 2.3 and 2.4 HAR, HAA ABNF format,
Accounting-Multi-Session-Id AVP is madatory in HAR but option in HAA
Requested change:
Change Accounting-Multi-Session-Id AVP as option in HAR ABNF Format
The text in Session 1.2 should be changed to something like
If the Accounting-Multi-Session-Id AVP is in the HAR, Home Agent
must include
this Avp in the HAA, which is then forwarded to the AAAH.
Submitter name: Michael Chen
Submitter email address: cchen@erilab.com
Date first submitted: 12-Nov-01
Reference:
Document: mobileip-08-alpha2
Comment type: editorial
Priority: 1
Section: Mobileip 8.2
Rationale/Explanation of issue:
As we can see, MIP_Feature_Vector is an option in HAR message so HA
don't know
how to include this avp in the ACR message in some case.
Requested change:
Add some text to explain why MIP_Feature_Vector is madatory in ACR or
remove this
Avp from Accounting Avp Table in session 8.2
Submitter name: Yoshihiro Ohba
Submitter email address: yohba@tari.toshiba.com
Date first submitted: November 12, 2001
Document: base
Comment type: E
Priority: 1
Section: 1.1, 1.3
Rationale/Explanation of issue:
In section 1.1, it is described that :
A Diameter agent is a node that does not authenticate and/or
authorize messages locally, such as proxies and relay agents. A
Diameter server is one that performs authentication and/or
authorization of the user based on some profile. A Diameter node
MAY act as an agent for certain requests while act as a server for
others.
According to section 1.1, a Diameter server IS NOT a Diameter agent.
On the other hand, in section 1.3 it is descibed that :
Diameter Agent
A Diameter Agent is a host that is providing either server, relay,
proxy, redirect or translation services.
According to section 1.3, a Diameter server IS a Diameter agent.
So it seems that there is an inconsistency on whether a Diameter
server is a Diameter agent or not, which should be fixed.
Requested change:
Excluding Diameter server from the definition of Diamer agent seems to
be consistent with remaining sections. So I would suggest the
following change in secttion 1.3:
Diameter Agent
A Diameter Agent is a host that is providing either relay,
proxy, redirect or translation services.
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 13-Nov-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00200.html
Document: base
Comment type: T
Priority: 1
Section: 3.2
Rationale/Explanation of issue:
Initializing the end-to-end identifier to contain 12 bits of time has
some problems.
1. If the diameter implementation can generate more than 1,048,575
transactions, it is possible to get duplicate records. Consider
a NAS that generates 2,097,152 that started generating at time t,
ran for 10 seconds, rebooted, and started generating again at t +
20. The last record would be t * 0x00100000 + 2,097,152 * 10 = t
* 0x00100000 + 0x1400000. The first record generated is (t + 20)
* 0x00100000 + 0 = t * 0xFFF00000 + 0x1400000. This is the same
as the last end-to-end before reboot. Note, I ignored the fact
that the bottom bits are random. This doesn't matter because
in the next second at 2M transactions per second, that random
number will be seen.
2. The clock on some embedded systems is reset to zero after reboot.
Thus, the time would always be the same.
3. NTP can actually make time go backwards while syncing.
Requested Change:
The 12 bit time initializer is good for most implementations. But
if another implementation needs to implement it differently (like
checkpointing the identifier), it shouldn't have to violate the RFC
to do it. So add a SHOULD to the description.
Upon reboot, the high order 12 bits SHOULD be initiated to contain
the low order 12 bits of current time, while the low order 20 bits
SHOULD be set to a random value.
Submitter name: Jaakko Rajaniemi
Submitter email address: jaakko.rajaniemi@nokia.com
Date first submitted: 2001-11-12
Document: base
Comment type: T
Priority: 1
Section: 9.6, 8.2, 9.3
Rationale/Explanation of issue:
It says in the section 9.6 "Correlation of Accounting Records" that the
correlation for accounting sub-sessions is performed using the Session-Id.
Is this correct? Aren't both the Accounting-Sub-Session-Id and Session-Id
used for the correlation?
I think that it is not possible to terminate one or several accounting
sub-session from the server side. Only all accounting sub-sessions can be
terminated by using the Abort-Session command. Is this left for each
application to handle or should this possibility be in the base protocol?
The accounting state machine in the section 8.2 describes that the
accounting session is terminated by the action where the accounting stop
request is sent. It is not totally clear what the accounting stop request
here can mean. I think that it only describes the case where the accounted
service is a one-time event (where EVENT_RECORD is sent and the ACA
terminates the session) and a measurable length accounting service (where
STOP_RECORD is sent to terminate the session). However, it seems to be
missing the server initiated termination by the Abort-Session command.
This application document requirements for accounting were discussed some
time ago and I proposed a change to the section 9.3 which got some support,
but not get to the base-08. The issue is that because it is possible that a
service makes only use of the Accounting portion of the Diameter application
then the application must clearly described in the application specification
which part contains the accounting portion. The current text describes in
the section 9.3 (Application document requirements) clearly how new
accounting AVPs must be described in new applications but it does not say
anything how new accounting command codes should be described. One way to
guarantee that this is clearly described in the new applications is to
modify the section 9.3 according to the changes proposed in the Requested
change part below.
Requested change:
The change to the section 9.3, the Application document requirements:
"Each Diameter application (e.g. NASREQ, MobileIP), MUST define their
Service-Specific accounting part in a section entitled "Accounting". Under
the section "Accounting" they MUST define their Service-Specific AVPs that
MUST be present in the Accounting-Request message in a section entitled
"Accounting AVPs" and their Service-Specific command codes if exists in a
section entitled "Accounting Command-Codes". The application MUST assume
that the AVPs described in this document will be present in all Accounting
messages, so only their respective service-specific AVPs need to be defined
in this section."
If the above change is adopted then it would require some minor editing to
the NASREQ and Mobile IP application.
For other question changes are still open.
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 13-Nov-2001
Reference:
Document: base
Comment type: E
Priority: 1
Section: 3.2
Rationale/Explanation of issue:
There is no way to specify the vendor id in the ABNF. Thus a vendor
specific command code cannot be specified.
Requested change:
Change the ABNF in section 3.2 to allow vendor. I give one suggestion
below, but am open to alternatives.
Change
header = "< Diameter-Header:" command-id [r-bit]
[p-bit] [e-bit] ">"
to
header = "< Diameter-Header:" [vendor-id]command-id [r-bit]
[p-bit] [e-bit] ">"
vendor-id = 1*DIGIT ":"
; the Vendor-ID field value
Submitter name: Yoshihiro Ohba
Submitter email address: yohba@tari.toshiba.com
Date first submitted: November 13, 2001
Document: base
Comment type: E
Priority: 1
Section: 8.1, 8.2
Rationale/Explanation of issue:
Authorization Session State Machine and Accounting Session State
Machine seem to define FSM for Diameter clients and servers but not
for Diameter agents (i.e., relay, proxy, redirect and translation
agents).
For example, in section 8.1, when a Service-specific authorization
request is received from a peer in Idle state, there is no action to
*forward* the received request to the next-hop peer of the session and
move to Pending state, which would be a normal action for relay
agents. Similarly, when a Service-specific authorization answer is
received from the next-hop peer of the session in Pending state, there
is no action to *return* the received answer to the previous-hop peer
of the session and move to Open state (in the case of stateful relay
agents) or Idle state (in the case of stateless relay agents), which
would also be a normal action for relay agents.
Requested change:
Additional state transitions need to be included in section 8.1 and
8.2 to support relay, proxy, redirect and translation agents.
Submitter name: Michael Chen
Submitter email address: cchen@erilab.com
Date first submitted: 19-Nov-01
Reference:
Document: base-08
Comment type: E
Priority: 1
Section: Base: 5.4.3
Rationale/Explanation of issue:
DPR is not sent to its peer when lost the election so ELECTION_LOST
result code is not used.
Requested change:
Remove this result code.
Submitter name: Michael Chen
Submitter email address: cchen@erilab.com
Date first submitted: 19-Nov-01
Reference:
Document: base-08
Comment type: E
Priority: 1
Section: Base: 8.3.1 8.3.2 10.1
Rationale/Explanation of issue:
User-Name avp should be option is the RAR and RAA message
There is typepo in the RAA which shows "RAR" in the ABNF
Requested change:
1. change User-Name Avp as option in the ABNF of RAR and RAA
2. change the RAR typepo to RAA
3. change the comand avp table according to this issue
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 21-Nov-01
Reference: Version 8
Document: nasreq
Comment type: E
Priority: 1
Section: 2.2, 8.*
Rationale/Explanation of issue:
The AVP numbers are inconsistent.
Section 2.2 8.0
Accounting-Input-Extended-Octets 42/Unsigned64 363/Unsigned64
Accounting-Input-Extended-Packets 57/Unsigned64 365/Unsigned64
Accounting-Output-Extended-Octets 43/Unsigned64 364/Unsigned64
Accounting-Output-Extended-Packets 48/Unsigned64 366/Unsigned64
Also, AVPs with values greater than 255 shouldn't be listed in section
2.2, "Legacy RADIUS Attributes".
Requested change:
Fix the numbers in section 2.2.
Move AVPs with values greater than 255 to section 2.1.
Submitter name: Jonathan Wood
Submitter email address: jonathan.wood@sun.com
Date first submitted: 21-Nov-01
Reference:
Document: base
Comment type: E
Priority: 1
Section: Base (version 8 alpha2), sections 5.6, 5.6.2, and 12
Rationale/Explanation of issue:
The transport draft and the base spec are in conflict about
sending watchdogs. The state machine in the base spec section 5.6
requires that watchdogs be sent on each expiration of the watchdog
timer. However, the transport draft requires that a watchdog be
send once on the first expiration of the watchdog timer. On the
next expiration of the watchdog timer, the connection is put in
the suspect state, and the connection is failed over.
Also, section 5.6 states
When the state machine below requests a
transport connection with the peer, the state machine in [52] is
invoked. Once the connection has been established, the state machine
in this section is followed.
This is not completely accurate. The state machine in the transport
draft should be followed throughout the life of the connection as
well to manage the connection.
There are also some leftover timer descriptions in section 12 that
are no longer relevant.
Requested change:
I recommend that text specifying how to control sending watchdogs and
management of the watchdog timer be stricken from the base spec, and
that the base spec refer to the transport draft on this matter.
Specifically:
5.6 Peer State Machine
(Modify 2nd paragraph)
This state machine is closely coupled with the state machine
described in [52], which is used to open, close, failover, probe,
and reopen transport connections. Note in particular that [52]
requires the use of watchdog messages to probe connections. For
Diameter, DWR and DWA messages are to be used.
Remove from R-Open:
WatchDog-Timer R-Snd-DWR R-Open
Remove from I-Open:
WatchDog-Timer I-Snd-DWR I-Open
Remove from section 5.6.2 Events:
WatchDog-Timer The Watchdog timer expired, indicating that a DWR
message is to be sent to the peer.
Rcv-DWR A DWR message was received.
Rcv-DWA A DWA message was received.
Section 12.0 Diameter protocol related configurable parameters
Recommend removing the following timers:
Td timer
The Td timer controls the termination of connections with peer
in the SUSPECT state. The recommended value is 5 seconds.
Ti timer
The Ti timer controls the frequency the watchdog messages are
to be sent to idle peers. The recommended value is 30 seconds.
Tr timer
The Tr timer controls the frequency the watchdog messages are
to be sent to peers when there are pending requests, but not
messages have been received from the peer. The recommended
value is 10 seconds.
Tw timer
The Tw timer controls the changing of a peer to the SUSPECT
state when no answer is received to a watchdog request. The
recommended value is 5 seconds.
What about the Tc timer?
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: base 08
Comment type:
Priority: 2
Section: 7.1
Rationale/Explanation of issue:
Diameter distinguishes error classes according to the DECIMAL value of
the Result-Code data field. This is widely used in protocols that
utilize ASCII encoding (SMTP, HTTP, etc.). But it doesn't make much
sense in a binary protocol such as Diameter. Shouldn't the HEX value
of the Result-Code data field be used instead?
For example:
Is an Informational error message 1000 - 1999 in DECIMAL? Or is it
10000000 - 1FFFFFFF in HEX?
From: Mark Eklund
Date: Fri Jan 25 00:32:49 2002
I was considering issue #248 which questions if the Result-Code AVP
values should be in decimal or hexadecimal. After considering the
pros and cons, I think we should leave it as decimal. I see two main
reasons to change this to Hexadecimal.
1. This allows for a bitmask to determine what type of error was sent.
2. In doing this we will also expand the range of codes for each
result and thus we can have over a 1000 protocol errors.
My thoughts are
1. Categorizing these errors in groups of 1000 is mostly a
documentation convenience. In essence to an application, the
Result-Code AVP is either Success, a few failures that it
handles specially and all the other failures. There is little need
to distinguish Transient Failures and Permanent Failures.
Protocol Errors will be in a packet with the 'E' bit set.
So being able to use a bitmask to determin what type of error was
sent is of little.
2. We have used less than 50 total Result-Codes. Yes, it is possible
that we will have used up an entire 1000 as some time. If that
happens, we can simply add another range of 1000 for that type of
error. Once again, these categorizations are simply a
documentation convenience.
3. This is a personal preference, but when I see a dump of a diameter
packet, I typically see the packet broken into information where
Unsigned32 values converted to decimal. This is a lame argument,
but I had to have one more than the arguments for hexadecimal :)
With all that said. If there is a want or push for Hexadecimal, now
is the time to fix it. Remember though that if this changes, everyone
that working diameter servers will have to go update their enums and
dictionaries :(
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: base 08
Comment type: Editorial
Priority: 1
Section:
Rationale/Explanation of issue:
Page 7, section 1.1, 3rd paragraph, last sentence:
Change
"AVPs are used by base Diameter" to "AVPs are used by the base Diameter"
Page 12, section 3.0-, 3rd paragraph:
"Diameter Servers must support the base protocol"
Shouldn't the must be capitalized?
Page 14, section 2.1, third and fourth paragraphs:
Change: "ICMP protocol and port unreachable messages" to "ICMP protocol
port unreachable messages".
"If Diameter receives data to from TCP that" to "If Diameter receives data
from TCP that"
Page 16, Section 2.3.4, first paragraph:
Change "Applications Identifiers is different from the ones" to
"Applications Identifiers are different from the ones"
Page 111, Section 11.1.1, second paragraph
Change:
"is set to a non-zero value, is for Private Use" to
"is set to a non-zero value, are for Private Use"
Same change in section 11.2.1 on page 111 also.
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email address: aboba@internaut.com
Date first submitted: 29-Dec-01
Reference:
Document: all
Comment type: Editorial
Priority: S
Section: References
Rationale/Explanation of issue:
RFC Editor has indicated that future RFCs will need to separate Normative
versus Informative references.
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: NASREQ 08
Comment type: Editorial
Priority: 1
Section: 7.3.4 and 7.4.4
Rationale/Explanation of issue:
Support for ADIF was removed a while back
In both sections it is stated "This AVP SHOULD Be included in the ADIF
Record of the corresponding Accounting-Request messages"
Suggestion: strike "the ADIF Record of"
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: base 08
Comment type: Technical
Priority: S
Section: 8.2
Rationale/Explanation of issue:
Access is not granted based on receipt of a successful
accounting start answer
Change:
In the state table on pp. 86, it states that in Pending state, receipt of
a Successful accounting start answer results in "grant access" and
movement to the Open state. Since access is granted within the
authentication/authorization state machine, this appears to be an error.
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: base 08
Comment type: Technical
Priority: 1
Section: 5.2
Rationale/Explanation of issue:
A6 RRs are now deprecated, and the text doesn't mention how to
discover TLS support on the peer.
Change:
3. The Diameter implementation uses DNS to request the SRV RR [33] for the
'_diameter._sctp' and/or '_diameter._tcp' server in a particular realm"
To:
3. The Diameter implementation uses DNS to request the SRV RR [33] for the
'_diameter-tls._sctp' and/or '_diameter-tls._tcp' in a particular realm,
as well as the '_diameter._sctp' and/or '_diameter._tcp' servers.
If records corresponding to the TLS ports are found, the Diameter peer is
assumed to support TLS.
Change:
"Address records include A RR's, AAAA RR's, A6 RR's or other similar"
To:
"Address records include A RRs, AAAA RRs or other similar"
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: base 08
Comment type: Technical
Priority: S
Section: 2.2
Rationale/Explanation of issue:
The IPsec mode is not specified. IPsec is also mispelled (do a global
replace of IPSec with IPsec).
Add:
"All Diameter implementations MUST support IPsec ESP [RFC2406] in transport
mode with a non-null transform to provide per-packet authentication,
integrity protection and confidentiality, and MUST
support the replay protection mechanisms of IPsec.
Diameter implemenations MUST support IKE
for peer authentication, negotiation of security associations, and
key management, using the IPsec DOI [RFC2407]. Manual keying MUST NOT
be used since it does not provide the necessary rekeying support.
Diameter implementations MUST support peer
authentication using a pre-shared key, and MAY support certificate-based
peer authentication using digital signatures. Peer authentication using
the public key encryption methods outlined in IKE's sections 5.2 and 5.3
[RFC2409] SHOULD NOT be used.
Conformant implementations MUST support both
IKE Main Mode and Aggressive Mode. When pre-shared keys are used for
authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode
SHOULD NOT be used. When digital signatures are used for
authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used.
In all cases, access to locally stored secret information (pre-shared
key, or private key for digital signing) must be suitably restricted,
since compromise of the secret information nullifies the security
properties of the IKE/IPsec protocols.
When digital signatures are used to achieve authentication, an IKE
negotiator SHOULD use IKE Certificate Request Payload(s) to specify the
certificate authority (or authorities) that are trusted in accordance
with its local policy. IKE negotiators SHOULD check the pertinent
Certificate Revocation List (CRL) before accepting a PKI certificate for
use in IKE's authentication procedures.
The Phase 2 Quick Mode exchanges used to negotiate protection for
Diameter connections MUST explicitly carry
the Identity Payload fields (IDci and IDcr). The DOI provides for
several types of identification data. However, when used in conformant
implementations, each ID Payload MUST carry a
single IP address and a single non-zero port number, and MUST NOT use
the IP Subnet or IP Address Range formats. This allows the Phase 2
security association to correspond to specific TCP and SCTP
connections.
Since IPsec acceleration hardware may only be able to handle a limited
number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent
for idle SAs, as a means of keeping the number of active Phase 2 SAs to
a minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be
interpreted as a reason for tearing down a Diameter connection.
Rather, it is preferable to leave the connection up, and if additional
traffic is sent on it, to bring up another IKE Phase 2 SA to protect it.
This avoids the potential for continually bringing connections up and
down.
If an IKE implementation receives a Phase 1 Delete message for a Phase 1
Security Association bound to one or more sessions, then it SHOULD
delete the associated IKE Phase 2 security associations."
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: nasreq 08
Comment type: Technical
Priority: S
Section: 9.1
Rationale/Explanation of issue:
There is no discussion of how RADIUS vendor-specific attributes are to be
translated to Diameter AVPs and vice-versa.
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: base 08
Comment type: Technical
Priority: S
Section: 2.2
Rationale/Explanation of issue:
There is no discussion of how TLS authentication is used with
Diameter. For example:
a. Are both peers required to support certificates?
b. If not, how is it decided which peer authenticates to who?
Proposed change:
Add:
"Diameter clients act as TLS clients according to [RFC2246], and Diameter
servers act as TLS servers. Diameter clients and servers implementing
TLS for security MUST mutually authenticate as part of TLS session
establishment. In order to ensure mutual authentication, Diameter servers
MUST request certificates from Diameter clients, and the client MUST be
prepared to supply a certificate on request."
Submitter name: yanqun le
Submitter email address: yanqun.le@nokia.com
Date first submitted: 30-Dec-01
Reference:
Document: Base -08, dratf-ietf-aaa-transport-05
Comment type: Technical
Priority: S
Section: Section 5.1 of Base- 08, Section 3.4.1 of Transport -05
Rationale/Explanation of issue:
The last third paragraphs in Section 5.1 is inconsistent with Section 3.
4.1 of transport-05.
Requested change:
The last third paragraphs in Section 5.1 should be changed to:
When a peer is deemed suspect, which could occur for various
reasons, including not receiving a DWA within an alloted timeframe, no
new requests should be forwarded to the peer, and failover procedures
should be invoked. When an active peer is moved to this mode, additional
connections SHOULD be established to ensure that the necessary number of
active connections exists.
There are two ways that a peer is removed from the suspect peer list:
1. the peer's watchdog timer has expired without a response,
causing a trasport reset or close to be done on the connection.
2. a response is received from the peer within the watchdog timer,
and the connection to the peer is considered stabilized.
In the event the peer being removed is either the primary or
secondary, an alternate peer SHOULD replace the deleted peer, and assume
the role of either primary or secondary.
Submitter name: yanqun le
Submitter email address: yanqun.le@nokia.com
Date first submitted: 30-Dec-01
Reference:
Document: dratf-ietf-aaa-transport-05
Comment type: Technical
Priority: S
Section: 3.4.1
Rationale/Explanation of issue:
In section3.4.1 [5] of draft-ietf-aaa-trasport-05, it said:
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.
I wonder:
When a connection to a peer comes up from DOWN status, i.e. reopen a
connction, does it need exchange capabilities again?
If capabilities exchange is needed does it send Watchdog first or
exchange CER/CEA first?
Submitter name: Miguel-Angel Pallares
Submitter email address: miguel-angel.pallares-lopez@ece.ericsson.se
Date first submitted: 02-Jan-02
Reference:
Document: Base 08
Comment type: Editorial
Priority: 1
Section: 5.3.2
Rationale/Explanation of issue:
The qualifier for Vendor-Specific-Application-Id AVP in CEA should be "*", as in CER.
Change in definition of CEA in 5.3.2, from:
[ Vendor-Specific-Application-Id ]
to:
* [ Vendor-Specific-Application-Id ]
Submitter name: Jari Arkko
Submitter email address: jari@arkko.com
Date first submitted: 02-Jan-02
Reference:
Document: Base 08
Comment type: Technical
Priority: S
Section:
Rationale/Explanation of issue:
Current text reads as follows:
The Time format is derived from the Unsigned32 AVP Base Format.
This is 32 bit unsigned value containing the four most
significant octets returned from NTP [18], in network byte
order.
This represent the number of seconds since 0h on 1 January 1900
with respect to the Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036 the time value will
overflow. NTP [18] describes a procedure to extend the time to
2104.
This has two problems. First, it is unclear whether NTP or SNTP
is meant and what format is really used. Second, we don't
mandate the extension to year 2104.
Also, I find it easier to explain the format issue if Time
is derived from OctetString, not Unsigned32. Bits on the wire
are not changed.
Proposed change:
The Time format is derived from the OctetString AVP Base
Format. The string MUST contain four octets, in the same
format as the four first bytes are in the NTP Timestamp
Format. The NTP Timestamp format is defined in Chapter 3 of
reference [18].
This represents the number of seconds since 0h on 1 January 1900
with respect to the Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036 the time value will
overflow. SNTP [18] describes a procedure to extend the time to
2104. This procedure MUST be used by all DIAMETER nodes.
Submitter name: Jari Arkko
Submitter email address: jari@arkko.com
Date first submitted: 02-Jan-02
Reference:
Document: Base 08
Comment type: Technical
Priority: S
Section: 5.2
Rationale/Explanation of issue:
Current text does not clearly enough specify
which peer discovery mechanisms are mandatory
and which are not.
There's two approaches to handling this issue.
One, (apparently the current approach) we stay
clear of using MUST/SHOULD/MAY in section 5.2
and therefore all of the text falls to Informative,
and nothing is really mandated.
The second approach is that we explicitly state
what DIAMETER nodes MUST/SHOULD/MAY be capable of
in this area. I favor the latter approach.
Proposed change:
Indicate in the list under 5.2 that the first
option (manual configuration) MUST be supported
by all DIAMETER nodes, while the latter two options
(SRVLOC and DNS SRV records) MAY be supported.
Submitter name: Don Zick
Submitter email address:
Date first submitted: 08-Jan-02
Reference:
Document: Base 08
Comment type: Technical
Priority: 1
Section: 2.2
Rationale/Explanation of issue:
The Diameter base draft does not address how to ensure that a Diameter
node is using its own TLS certificate. It is important to ensure that
a Diameter node is using its own TLS certificate so that if a single
Diameter node becomes compromised, it won't break security for all of
the other Diameter nodes.
It is a common practice with TLS to put a node's identity into the
certificate's subjectAltName dNSName field. The Diameter CMS Security
Application takes this approach. Below is a section from the Diameter
CMS Security Application draft 3:
>3.2 Certificate Requirements
>
> Certificates used for the purposes of Diameter MUST conform to the
> PKIX profile [4], and MUST also include a Diameter node's FQDN,
which
> is typically added in the Origin-Host AVP [1], as one of the values
> of the subjectAltName extension of the Certificate. The FQDN is to
> be encoded as a dNSName within the subjectAltName.
>
> For Diameter nodes (capable of acting as recipients for
> confidentiality), the FQDN MUST be of the form
> "Diameter-
> scheme. Note that this naming constraint is for PKI purposes only,
> and in no way restricts a Diameter's host name.
Requested change:
Make Diameter TLS have the same dNSName field requirements as the
Diameter CMS Security Application.
Submitter name: Don Zick
Submitter email address:
Date first submitted: 08-Jan-02
Reference:
Document: Base 08
Comment type: Technical
Priority: S
Section: 2.2
Rationale/Explanation of issue:
Diameter implementations should not be required to support all TLS
cipher suites listed in RFC 2246. Not all cipher suites are supported
by available TLS tool kits and one cipher suite contains the proprietary
IDEA encryption algorithm that you have to get permission to use.
Therefore, to ensure inter operability, it is necessary to specify which
cipher suites must be supported.
Requested change:
Add:
Diameter nodes MUST be able to negotiate the following TLS cipher
suites:
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Diameter nodes MAY negotiate other TLS cipher suites.
Submitter name: Bob Kopacz
Submitter email address: BKopacz@InterlinkNetworks.com
Date first submitted: 10-Jan-02
Reference:
Document: mobile-ip, nasreq 08
Comment type: Technical
Priority: 1
Section: Occurrence rules tables, and Message ABNFs
Rationale/Explanation of issue:
The rules for the inclusion of the User-Name AVP in Answer
messages are inconsistent. In draft-08:
The User-Name AVP MUST be echoed back (1 occurrence required)
in these Answer messages:
Re-Auth-Answer (base protocol)
Abort-Session-Answer (base protocol)
Session-Terminate-Answer (base protocol)
Accounting-Answer (base protocol)
The User-Name AVP MAY be echoed back (0-1 occurrence)
in these Answer messages:
AA-Answer (nasreq)
Diameter-EAP-Answer (nasreq)
The User-Name AVP MUST NOT be echoed back (0 occurrences required)
in these Answer messages (which caused conflicts at the recent
bakeoff):
AA-Mobile-Node-Answer (mobile ip)
Home-Agent-MIP-Answer (mobile ip)
Requested change:
Since it is natural and harmless for an implementation to echo back
the User-Name, allow but do not require the User-Name AVP to appear in
Answer messages, if present in the Request.
Submitter name: Bob Kopacz
Submitter email address: BKopacz@InterlinkNetworks.com
Date first submitted: 10-Jan-02
Reference:
Document: mobile-ip 08
Comment type: Technical
Priority: 1
Section: 2.2
Rationale/Explanation of issue:
Sesion 2.2 of the Mobile-IP draft-08 states that "An AMA message with
the Result-Code AVP set to DIAMETER_SUCCESS MUST include the [...]
MIP-Reg-Reply AVP."
In the case of a co-located MN, however, the AAAH would be sending the
AMA as a direct response to the AMR, with no HAR/HAA messages
involved, so in this case the AMA would not contain a MIP-Reg-Reply
AVP.
This was first noted by Siva Ramamurthy on the AAA-WG mailing list
on 11-28-2001.
The occurrence rule table and message ABNF are ok.
Requested change:
Change the first sentence of the second paragraph
From:
An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST
include the MIP-Home-Agent-Address, MIP-Home-Mobile-Node-Address and
MIP-Reg-Reply AVPs.
To:
An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST
include the MIP-Home-Agent-Address AVP, MUST include the
MIP-Home-Mobile-Node-Address AVP, and includes the MIP-Reg-Reply AVP
if and only if the Co-Located-Mobile-Node bit was not set in the
MIP-Feature-Vector AVP.
Submitter name: Bob Kopacz
Submitter email address: BKopacz@InterlinkNetworks.com
Date first submitted: 15-Jan-02
Reference:
Document: mobile-ip 08
Comment type: Technical
Priority: 1
Section: 2.2, 2.4, 5.4, 8.1, Issue#203
Rationale/Explanation of issue:
[The following is based on some issue#203-related emails
exchanged with Mark Eklund. The proposal I'm contributing here
is also Mark's, as I understand it]
When the HA is in the foreign network and a FA-HA key is
requested, the AAAF, rather than the AAAH, generates the key.
Here's the diagram of the issue:
amr-> amr->
FA --------> AAAF1 -------------> AAAH
<-ama <-ama |
| ^
| |
har | haa
| |
V |
|
<-har <-har |
HA <-------- AAAF2 <---------------/
haa-> haa->
In the above diagram, FA & HA & AAAF1 & AAAF2 are all in the same
visited network. AAAF1 and AAAF2 may be the same server, or may
be different servers.
In the above diagram, AAAF2 generates the FA-HA key.
The problem is that this key must somehow be returned to the FA
via AAAF1. The proposal here is to pass the key back to the FA
via the the HAA and AMA messages. AAAF2 may be concerned about
security, so may want the FA-HA key to be passed encrypted so
that AAAH and intervening servers can't figure it out, but AAAF1
can somehow decrypt it.
The details are:
1. A new HAA-to-AMA-Data AVP, of type octetstring, is created.
The purpose of this AVP is convey information from the HA's AAAF
(AAAF2) to the FA's AAAF (AAAF1). All AAAFs in that foreign
realm MUST have an agreed upon format and security method for
this AVP to be used. (It may be possible to use CMS security
to somehow encrypt this AVP, but it is unclear just how, as it
involves the AAAH copying a secure AVP from the HAA to the AMA,
and the AMA may carry both AAAH-FA and AAAF1-AAAF2 secured
AVPs)
2. When the FA-HA key is generated by AAAF2, this key must
somehow be conveyed to AAAF1. There are two ways to do this:
a. Use the MIP-HAA-to-AMA-Data AVP, or
b Have a common database among AAAFs in the foreign network,
wherein AAAF2 may deposit the FA-HA key, which is later retrieved
by AAAF1, in a proprietary manner not described in the Diameter
documents.
3. If the HAA-to-AMA-Data AVP is present in the HAA, the AAAH
treats it as opaque data and passes it in the AMA.
4, If AAAF1 receives the HAA-to-AMA-Data AVP in the AMA, AAAF1
will use this AVP to recreate the FA-HA key, and replace this AVP
by a MIP-FA-to-HA-Key AVP in the AMA sent to the FA.
Requested change:
This issues supercedes issue#203, which also addresses the
problem of returning an AAAF-Generated FA-HA Key to the FA, but
didn't quite work in the case where there was a 2nd AAAF
involved.
In section 2.2. Add [HAA-to-AMA-Data] to the AMA ABNF.
In section 2.4. Add [HAA-to-AMA-Data] to the HAA ABNF.
In section 6, define the following new AVP:
6.x HAA-to-AMA-Data AVP
The HAA-to-AMA-Data AVP (AVP Code TBD) is of type OctetString and
may be used, when the HA is allocated in the foreign network and
the HA's AAAF generates the FA-HA key, to convey the FA-HA key
information (in some proprietary format and security method which
is agreed-upon by all AAAF servers in the foreign network) back
to the FA's AAAF.
In section 8.1. Add a row for the new HAA-to-AMA-Data AVP, with these
occurrence rules: AMR 0, AMA 0-1, HAR 0, HAA 0-1.
Replace section 5.4 by
If the home agent is in the home realm, then AAAH has to generate
the Foreign-Home session key. Otherwise, it is generated by the
AAAF receiving the HAR.
If the AAAH generates the Foreign-Home session key, then the AAAH
includes the session key in the MIP-HA-to-FA-Key AVP, and
includes the AVP as part of the HAR message sent to the home
agent. The corresponding session key that is to be sent to the
foreign agent is cached on the AAAH until the HAA is received, at
which time the AAAH adds the MIP-FA-to-HA Key AVP to the AMA,
using the SPI in the MIP-FA-to-HA-SPI.
Upon receipt of the HAR, the home agent recovers the Foreign-Home
session key, allocates an SPI to be used with the key. The
allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP.
If the AAAH doesn't generate the Foreign-Home session key, then
upon receipt of the HAA, the AAAH extracts and passes the
MIP-FA-to-HA-SPI AVP (if present in the HAR) in the AMA, and
extracts and passes the HAA-to-AMA-Data AVP (if present in the
HAR) in the AMA.
If the AAAF receives an AMA which contains a HAA-to-AMA-Data AVP,
the AAAF will recreate the FA-HA key, generate a MIP-FA-to-HA-Key
AVP, and pass the MIP-FA-to-HA-Key AVP to the FA.
Alternatively, if the AAAF generates the Foreign-Home session
key, the AAAFs in the foreign network may have a common database
among AAAFs, wherein the HA's AAAF may deposit the FA-HA key,
which is later retrieved by the FA's AAAF, in a proprietary
manner not described in the Diameter documents.
Submitter name: Bob Kopacz
Submitter email address: BKopacz@InterlinkNetworks.com
Date first submitted: 17-Jan-02
Reference:
Document: mobile-ip 08
Comment type: Technical
Priority: 1
Section: 4.6.1, 6.8
Rationale/Explanation of issue:
Minor corrections/clarifications.
Requested change:
In section 4.6.1, 2nd line of 1st paragraph, change "algorithm"
to "algorithm and secret" What follows is the existing 4.6.1
> 4.6.1 MIP-MN-AAA-SPI AVP
>
> The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and
> indicates the algorithm by which the targeted AAA server (AAAH)
> should attempt to validate the Authenticator computed by the mobile
> node over the Registration Request data.
In section 6.8, change the name of the 3rd enumerated value
from "SHA-1" to "HMAC-SHA-1".
What follows is the current 4.6.1:
> 6.8 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]
[The following, taken from "AAA Registration Keys for Mobile IP",
(draft-ietf-mobileip-aaa-key-09.txt), refers to "HMAC-SHA-1"]
> 3. Dynamic Security Associations
>
> Mobility Security Associations between Mobile IP entities
> (mobile nodes, home agents, foreign agents) contain both the
> necessary cryptographic key information, and a way to identify
> the cryptographic algorithm which uses the key to produce the
> authentication information typically included in the Mobile Home
> Authentication extension or the Mobile Foreign Authentication
> extension. In order for the mobile node to make use of key material
> created by the AAA server, the mobile node also has to be able to
> select the appropriate cryptographic algorithm that uses the key
> to produce the authentication. The following table contains the
> supported algorithm identifiers.
>
> Algorithm Identifier Name Reference
> --------------------- ------------------ ------------
> 1 MD5/prefix+suffix RFC 2002 [11]
> 2 HMAC-MD5 RFC 2104 [6]
> 3 HMAC-SHA-1 RFC 2104 [6]
Submitter name: Randy Bush
Submitter email address: randy@psg.com
Date first submitted: 29-Dec-01
Reference:
Document: Base 08
Comment type: Technical
Priority: S
Section:
Rationale/Explanation of issue:
is eeems that the results of the discussion last may of vendor-specific
commands never made it into the documents. in specific.
---
25 of the base:
"The Command-Code field is three octets, and is used in order to
communicate the command associated with the message. The 24-bit address
space is managed by IANA (see section 11.2).
In the event that the Command-Code field contains a vendor specific
command, the four octet Vendor-ID field contains the IANA assigned "SMI
Network Management Private Enterprise Codes" [2] value. If the
Command-Code field contains an IETF standard Command, the Vendor-ID field
MUST be set to zero (0). Any vendor wishing to implement a vendor-specific
Diameter command MUST use their own Vendor-ID along with their privately
managed Command-Code address space, guaranteeing that they will not
collide with any other vnedor's vendor-specific command, nor with future
IETF applications."
---
as i said last april,
> as an engineer, i sympathize with the excitement that the protocol is
> very extensible. otoh, an architect might view that the protocol is
> merely a list of name/value tuples to indicate a lack of bounding and
> understanding of the problems and/or inability to make a real design for
> it.
>
> open loop extensibility is really worrying the iesg.
---
and we discussed again in may:
> So, the WG questioned whether the specs could be more relax on the
> IANA requirements for extensibility. Specifically, could a
> vendor-specific extension be created without Standards Action.
i can see arguments for relaxing to info but not iana-only. a
documentation trail is needed.
---
and a number of iesg members made quite clear, or at least tried to, that
any extensions, vendor or otherwise, must require previous documentation
in an rfc.
---
please consider this a bug report. my apologies for not knowing how to
get a bug number etc.
Submitter name: Randy Bush
Submitter email address: randy@psg.com
Date first submitted: 2001.09.03
Reference:
Document: base
Comment type: E
Priority: S
Section: 1.0, 1.1
Rationale/Explanation of issue:
The Introduction (section 1.0) talks about the history and motivation for
the development of Diameter. Section 1.1 talks about the basic building
blocks of Diameter. Section 2 provides an overview of protocol
concepts. What would be helpful is if a high-level introduction could
be provided within section 1. The material currently in section 1.1 might
be better moved to section 2.
Requested change:
To provide context, the following topics would be useful in the
Introduction:
a. An overview of the Diameter approach
1. Relationship of NASes, Servers and Intermediaries
2. Message routing concepts
3. Requests, Responses, Unsolicited messages
b. Important ways that Diameter differs from RADIUS
(Idea is to introduce the concepts, not go into
depth, but make clear what the feature is attempting
to achieve. Reference where details are provided.)
1. Peer-to-peer nature
2. Explicit support for intermediaries
3. Connection-oriented versus connectionless
4. Concept of extensions
5. Built-in failover support
6. Larger attribute space
7. Integrated accounting
8. Mandatory bit
9. Application-layer ACKs and error messages
10. Unsolicited server messages
11. Peer discovery
12. Capabilities negotiation (worth explaining why
this isn't e2e here)
c. Description of the Diameter document set and relationship
between the documents.
d. Approach to extensibility (this is in section 2.3, but might
be better consolidated into the Introduction)
From: Dilip
Date: Mon Dec 24 11:33:25 2001
Reference: http://www.angelfire.com/in/dilris
Hi
In the peer state machine section 5.6.2 Events.
The Rcv-Message Event states
"A message other than CER,CEA,DWR, or DWA was
received"
In THIS definition DPR & DPA is missed out.
suggestion
---------
Sections 5.6.2 Events should have
Rcv-Message " A message other than
CER,CEA,DPR,DPA,DWR, or DWA was received"
Regards
Dilip Patel
Issue 271: Sections 9.4 and 8.2 are in conflict.
Submitter: Jari Arkko <jari@arkko.com>
Date: January 3, 2002
Reference:
Document: BASE-08
Comment type: T
Priority: S
Section: 8.2
Rationale/Explanation of issue:
Sections 9.4 and 8.2 are in conflict.
The former requires clients to store acct
records during network outage, and the
latter requires immediate sending.
The specification is also silent on
how the client devices know whether
it should grant access during times
of network outages towards the accounting
server. I can imagine that in some
cases we would like to stop services if
we can't provide real-time accounting,
while in some other cases we would like
to continue.
Furthermore, the state machine in 8.2
(as well as the one that I just posted)
does not specify what to do when things
happen to the session faster than what it
takes for an ack to come back from the server.
For instance, what should we do if the session
is terminated while we are still waiting for
the start ack?
Proposed change:
An AVP similar to the Accounting-Interim-Interval
could be used to control whether access should be
granted or discontinued upon problems in sending
the accounting records.
The state machine must be modified to consider what
to do with session termination and interim record
generation while we are still waiting to send previous
data.
9.8.x. Accounting-Realtime-Required AVP
The Accounting-Realtime-Required AVP (AVP Code TBD) is of type
Enumerated and is sent from the Diameter home authorization server to
the Diameter client. The client uses information in this AVP to
decide what to do if the sending of accounting records to the
accounting server has been temporarily prevented due to,
for instance, a network problem.
DELIVER_AND_GRANT 1
The AVP with Value field set to DELIVER_AND_GRANT means
that the service MUST only be granted as long as there is
a connection to an accounting server. Note that the set
of alternative accounting servers are treated as one server
in this sense. Having to move the accounting record stream to a
backup server is not a reason to discontinue the service
to the user.
GRANT_AND_STORE 2
The AVP with Value field set to GRANT_AND_STORE means that
service SHOULD be granted if there is a connection, or as
long as records can still be stored as described in section
9.4.
This is the default behaviour if the AVP isn't included
in the reply from the authorization server.
GRANT_AND_LOSE 3
The AVP with Value field set to GRANT_AND_LOSE means
that service SHOULD be granted even if the records can
not be delivered or stored.
8.2. Accounting State Machine
Add the following new entries:
PendingE Failure to send and buffer Store Idle
space available Event
Record
PendingE Failure to send and no buffer Idle
space available
PendingS Failure to send and buffer Store Open
space available and realtime Start
not equal to DELIVER_AND_GRANT Record
PendingS Failure to send and no buffer Open
space available and realtime
equal to GRANT_AND_LOSE
PendingS Failure to send and no buffer Disconnect Idle
space available and realtime user/dev
not equal to GRANT_AND_LOSE
PendingI Failure to send and (buffer Store Open
space available or old record Interim
can be overwritten) and Record
realtime not equal to
DELIVER_AND_GRANT
PendingI Failure to send and no buffer Open
space available and realtime
equal to GRANT_AND_LOSE
PendingI Failure to send and no buffer Disconnect Idle
space available and realtime user/dev
not equal to GRANT_AND_LOSE
PendingD Failure to send and buffer Store Idle
space available Stop
Record
PendingD Failure to send and no buffer Idle
space available
Idle Records in storage Send PendingB
record
PendingB Successful accounting answer Delete Idle
received record
Submitter name: Juha-Pekka Koskinen
Submitter email address: juha-pekka.koskinen@nokia.com
Date first submitted: January 31, 2002
Reference: draft-hakala-diameter-credit-control-01.txt
Document: Base (draft-ietf-aaa-diameter-08.txt)
Comment type: T
Priority: 1
Section: 9.5 and 9.8.1
Rationale/Explanation of issue:
There are two different kind of accounting sessions used for charging purposes.
The postpaid accounting session is established to transfer CDRs (Charging Data
Records) from client to server. These CDRs are used for billing purposes,
typically once a month. The transfer of the CDRs is not critical task from the
communication session point of view. The CDRs could be transferred only when the
communication session has been disconnected, so the actual postpaid accounting
session doesn't need to be fully completed simultaneously with the communication
session.
The prepaid accounting session is established to transfer charging information
from client to server for rating purposes. The cost of the communication session
is calculated and according to these calculations money is reserved from
subcribers account. If there is no credit left in subscribers account or the
credit is used during the communication session, the prepaid accounting session
will be terminated. That termination will also cause the termination of the
communication session.
Requested change:
Proposal
As these two accounting sessions has different logic, it would be very useful to
specify new values used in Accounting-Record-Type AVP (Chapter 9.8.1):
EVENT_PREPAID 5
An Accounting Event Prepaid record is used to indicate that one-time prepaid
event has occured (meaning that the start and end of the event are
simultaneous). This record contains all information relevant to service and
granted threshold.
START_PREPAID 6
An Accounting Start Prepaid record is used to indicate that a prepaid service
will have measurable length. An Accounting Start Prepaid record is used to
initiate that money reservation will be needed for this session. This record
contains all information that is relevant to determine cost of the service and
granted threshold.
UPDATE_PREPAID 7
An Accounting Update Prepaid record is used to indicate that a prepaid service
will need more credit to continue. It is also used when service (client) need to
update itself tariff of the ongoing accounting session. This record contains all
information that is relevant to determine cost of the service and granted
threshold.
STOP_PREPAID 8
An Accounting Stop Prepaid record is sent to terminate and prepaid accounting
session. This record also contains unused amount of the granted threshold.
Also the chapter 9.5 should have following structure:
9.5 Accounting Records
In all accounting records the Session-Id and User-Name AVPs MUST be
present. If strong authentication across agents 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 that the CMS-Signed-Data AVP cover any additional
AVPs, but it is permitted as long as the AVPs protected are defined
to have their 'P' bit set.
9.5.1 Postpaid Accounting Records
Different types of postpaid accounting records are sent depending on the
actual type of accounted postpaid service and the accounting server's
directions for interim accounting. If the accounted postpaid service is a one-
time event, meaning that the start and stop of the event are
simultaneous, then the Accounting-Record-Type AVP MUST be present and
set to the value EVENT_RECORD.
If the postpaid accounted service is of a measurable length, then the AVP MUST
use the values START_RECORD, STOP_RECORD, and possibly,
INTERIM_RECORD. If the accounting server has directed interim
accounting to be enabled for the session, but no interim interval was
specified, two accounting records MUST be generated for each service
of type session. When the initial Accounting-Request is sent for a
given session is sent, the Accounting-Record-Type AVP MUST be set to
the value START_RECORD. When the last Accounting-Request is sent, the
value MUST be STOP_RECORD.
If a specified interim interval exists, the Diameter client MUST
produce additional records between the START_RECORD and STOP_RECORD,
marked INTERIM_RECORD. The production of these records is directed
both by Accounting-Interim-Interval as well as any re-authentication
or re-authorization of the session. The Diameter client MUST
overwrite any previous interim accounting records that are locally
stored for delivery, if a new record is being generated for the same
session. This ensures that only one pending interim record can exist
on an access device for any given session.
A particular value of Accounting-Sub-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.
9.5.2 Prepaid Accounting Records
Different types of prepaid accounting records are sent depending on the
actual type of accounted prepaid service and the accounting server's
directions for interim accounting. If the accounted prepaid service is a one-
time event, meaning that the start and stop of the event are
simultaneous, then the Accounting-Record-Type AVP MUST be present and
set to the value EVENT_PREPAID.
If the prepaid accounted service is of a measurable length, then the AVP MUST
use the values START_PREPAID, STOP_PREPAID, and possibly,
UPDATE_PREPAID. When the accounting server has granted threshold value
to used for the session, but the granted threshold is not used completely or the
client's tariff doesn't change, two accounting records MUST be generated for
each
service of type session. When the initial Accounting-Request for a
given session is sent, the Accounting-Record-Type AVP MUST be set to
the value START_PREPAID. When the last Accounting-Request is sent, the
value MUST be STOP_PREPAID.
When granted threshold value is used up or the client's tariff will change,
the Diameter client MUST produce additional records between the START_PREPAID
and
STOP_PREPAID records, marked UPDATE_PREPAID. The production of these records is
directed
both by Accounting-Interim-Interval, application specific AVP concerning granted
threshold as well as any re-authentication or re-authorization of the session.
The
Diameter client MUST produce UPDATE_PREPAID record when granted threshold is
used up.
A particular value of Accounting-Sub-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_PREPAID, or several records starting with one having the value
START_PREPAID, followed by zero or more UPDATE_PREPAID, and a single
STOP_PREPAID. A particular Diameter application specification MUST
define the type of sequences that MUST be used.
Submitter name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: 18 Feb 2002
Reference:
Document: Base
Comment type: T
Priority: 1
Section: 3
Rationale/Explanation of issue:
DNS SRV-related text in Base needs to be updated to reflect latest SIP
discovery draft.
Requested change:
Proposal
Review the current draft, draft-ietf-sip-srv-04.txt and summarize the text.
Proposed text forthcoming.
John
Date: Tue Feb 05 08:44:20 2002
In draft-ietf-aaa-diameter-08.txt, Section 5.2, item 3, it defines how to
use DNS SRV to lookup diameter peers.
However, there is no way to specify security when locating a peer. (And, you
need to know in advance if the peer is using TLS).
So, I prepose the following text be added to the base draft to clarify using
DNS SRV.
_diameter._tls_sctp.domain.org
_diameter._tls_tcp.domain.org
Right now, there is just:
_diameter._tcp.domain.org
_diameter._sctp.domain.org
I have not looked into CMS closely, but there might be more additions for
CMS.
Since IPSEC is done at the ip layer, I think we can ignore that. (The tunnel
has to be set up by administrators prior to any connections being made)
Later,
-Dave
From: David Frascone
Date: Tue Feb 05 16:03:34 2002
An EXTREMELY minor nit . . .
But . . .
AAA should be defined in the terminology sections of all drafts. (The acronym
is never broken down)
-Dave
Submitter name: Bob Kopacz
Submitter email address: BKopacz@InterlinkNetworks.com
Date first submitted: 02-06-2002
Reference:
Document: base-08
Comment type: Technical
Priority: 1
Section: 8.1
Rationale/Explanation of issue:
I believe there is an error in the "Authorization Session State
Machine", in section 8.1 of the base draft, in the 1st state machine
which represents the case where the server maintains session-state.
If, for a session in OPEN state, the server wants the session to be be
terminated, it sends an ASR and goes into DISCON state. When the ASA
is received, the server goes into IDLE state. The state/events I am
referring to are:
| The following state machine is used when state is maintained on the
| server:
|
| State Event Action New State
| -------------------------------------------------------------
|
| Open Home server wants to send ASR Discon
| terminate the service
|
| Discon ASA Received Cleanup Idle
This seems not quite right for a few reasons.
(1) When the server subsequently receives the follow-up STR from the
access device, the session will be either non-existent or in IDLE
state.
(2) An ASR is only a request to terminate a session. It doesn't
really go away until the session-timeout expires, the
authorization-lifetime expires, or the access device sends an STR. So
sending an ASR should not affect the server's state (OPEN), and
receiving an ASA should in general not affect the server's state
(OPEN).
(3) The state machine doesn't take into account the Result-Code
returned in the ASA. The draft indicates that an access device is not
required to honor an ASR, i.e. the access device can just reply with
"unable to comply" and not terminate the session. In this case the
server would have incorrectly terminated an active session when
receiving the negative ASA.
When an ASR is sent, the Result-Code values likely to be returned in
the ASA are:
SUCCESS -- This means that the access device will be following the
ASA with an STR, so the server can just wait for the STR.
UNABLE_TO_COMPLY -- The access device has no intention of terminating
the session.
UNKNOWN_SESSION_ID -- The access device doesn't know about this
session. Somehow the access device and server have gotten out of
sync. The server can go ahead an clean up this phantom session.
UNABLE_TO_DELIVER -- The ASR never made it to the access device, so
the access device won't be terminating this session, if it even
exists.
Requested change:
Replace the two entries:
| State Event Action New State
| -------------------------------------------------------------
|
| Open Home server wants to send ASR Discon
| terminate the service
|
| Discon ASA Received Cleanup Idle
With:
| State Event Action New State
| -------------------------------------------------------------
|
| Open Home server wants to send ASR Open
| terminate the service
|
| Open ASA Received Cleanup Idle
| with Result-Code
| = UNKNOWN-SESSION-ID
|
| Open ASA Received None Open
| with Result-Code (ignore)
| not = UNKNOWN-SESSION-ID
|
| Not ASA Received None No Change.
| Open
Notes on the above four entries (this is FYI, not part of draft):
Entry#1. The ASR doesn't do anything on its own, so just stay
in OPEN state and wait for the ASA.
Entry#2. This is the case where the server is out of sync with the access
device. This is a phantom session that the server can remove.
Entry#3. If SUCCESS, the access device will soon send an STR, which
will terminate the session. If not SUCCESS, the access device won't
be terminating the session, so it stays active.
Entry#4. Here something happened to the session between the time the
ASR was sent and the ASA was received.
Submitter name: Tony Johansson
Submitter email address: tony.Johansson@ericsson.com
Date first submitted: 02-07-2002
Reference:
Document: cms-03
Comment type: Technical/Editorial
Priority: 1
Section: 1.6
Rationale/Explanation of issue:
In the discussion and proposed solution to issue #266 - Returning
AAAF-Generated FA-HA Key to FA (please find detailed background info in
http://www.merit.edu/mail.archives/aaa-wg/msg02986.html message thread)
we have identified the need to be able to issue DSA messages between two
AAA(F) servers, where none of the nodes belong to the same realm as the
user being authorized.
This seems to be okay and straight forward according to the CMS
application except for what is stated in section 1.6.
“However, it is important to note 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 (the realm portion of the Network Access
Identifier found in the User-Name AVP), otherwise an answer is returned
with the Result-Code AVP set to DIAMETER_AUTHORIZATION_REJECTED.”
The CMS 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
CMS data within AVPs. Thus, the nature of this application deals with
servers and not users. Do really have to bring in user authorization as
described in section 1.6?
Requested change:
Remove section 1.6, so that the CMS application only talks about
security association establishment between peers, encryption of AVPs
between peers, etc.
1.7 is now 1.6, a new 1.7 was added to clarify something that
came up during editing.)
Submitter name: Jari Arkko (Sebastian Zander)
Submitter email address: jari@arkko.com
Date first submitted: Feb 10, 2002
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03001.html
Document: base, nasreq
Comment type: E
Priority: 2
Section: 9.5, 9.7.1, 9.7.2, nasreq 10.2
Rationale/Explanation of issue:
Section 9.5 of base-08 reads: "In all accounting records the
Session-Id and User-Name AVPs MUST be present.". However, the Diameter node
sending the accounting request may not know it. Still the target can use the
various
session-ID AVPs to correlate the records. There also seems to be some
inconsistency
in the draft and between base-08 and nasreq-08: In section 9.7.1 & 9.7.2
(ACR, ACA definition) User-Name AVP is marked as optional while in
section 10.2 it is again specified as MUST.
Proposed change:
I suggest modifying 9.5 so that it reads. "User-Name AVP MUST be present if
it is available to the Diameter client."
Then change the tables in 10.2 as follows:
User-Name | 0+ | 0+ |
Submitter name: Jari Arkko
Submitter email address: jari@arkko.com
Date first submitted: Feb 10, 2002
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03003.html
Document: cms
Comment type: E/T
Priority: 2
Section: 1, 1.3, 7.1
Rationale/Explanation of issue:
People who have read the CMS document do not clearly understand
that PDS mechanisms are not intended to create actual security
associations, but just to offload the computations to someone else.
Secondly, the document does not explain what to do in case
NO_CMS_THROUGH_PROXY is maliciously returned from somewhere
else than in our own domain.
Thirdly, there's some spelling problems.
Requested change:
Change
> This specification contains two different set of messages. The DSA
> messages are used to establish a security assocation, while the PDS
> messages are used to request that a security association be
> established by a third party.
to
This specification contains two different set of messages. The DSA
messages are used to establish a security assocation, while the PDS
messages are used to request that a security association be
established by a third party. The security association established using
DSA is used end-to-end for Diameter signaling, even through proxies that
may exist in between. In constrast, where PDS messages are used, Diameter
signaling is protected as usual only hop-by-hop between the client and
the proxy handling CMS security on its behalf. From there onwards to
the Diameter server, end-to-end protection is then used.
Also in 1.3, "recelived" => "received". And just before the end of
1.3, the last "MAY" => "might".
In 1.3, just before "If a DSA for a given realm cannot be established...",
add a new paragraph:
A proxy MAY both allow CMS security through itself and it
can offer CMS services to the clients connecting to it. This
would be useful in networks where some clients wish to use
CMS security themselves, and some others need the proxy to
assist them. However, it is necessary to prevent misconfigured
clients from inappropriately sending PDS messages to nodes
further onwards in the network, as this would leaeve the
Diameter messaging without CMS protection when it leaves the
proxy. For this reason, the DIAMETER_NO_CLEARTEXT_THROUGH_PROXY
MUST be returned for PDS messages where Destination-Realm
is not the proxy itself. This also ensures that rogue nodes
further onwards in the network can not return DIAMETER_NO_CMS_THROUGH_PROXY
in an attempt to bypass security mechanisms.
And then add to section 7.1:
DIAMETER_NO_CMS_THROUGH_PROXY 4014
This error code is returned when a non-transparent proxy
receives an PDSR message to Destination-Realm that is
not the proxy itself, and the proxy requires CMS security
to be applied for all traffic leaving it.
"People who have read the CMS document do not clearly understand
that PDS mechanisms are not intended to create actual security
associations, but just to offload the computations to someone else."
I tried to clarify the text in various places.
"Secondly, the document does not explain what to do in case
NO_CMS_THROUGH_PROXY is maliciously returned from somewhere
else than in our own domain."
I think that (some of?) the requested text was added prior
to me taking over as editor. I think that this is also affected
by the resolution of 221/291, but could well warrant additional
clarification.
"Thirdly, there's some spelling problems."
Dun doze:-)
Submitter name: Jari Arkko (Sebastian Zander)
Submitter email address: jari@arkko.com
Date first submitted: Feb 10, 2002
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03001.html
Document: cms, base
Comment type: E
Priority: 2
Section: base 4.6, cms 2.0, 3.1, 5.0
Rationale/Explanation of issue:
1) Base does not sufficiently explain what 'MAY encrypt' means in
the AVP tables. Does it mean that it where CMS is used for the
particular message, the AVPs MAY be encrypted, or does it mean
that if CMS is used, they MUST be encrypted?
2) CMS flow example in 5.0 is misleading as to how the
set of protected AVPs is decided.
3) There are several references to somehow negotiating
the AVPs to be signed/encrypted. We have removed such
functionality since this is really static information.
Proposed change:
1) Add to the end of the first paragraph in base 4.6: "If an
AVP MAY be encrypted, section 2.0 of the Diameter CMS security extension [11]
defines in which situations the encryption is actually employed."
Move the last paragraph of 3.1 to the end of 2.0, where I
think it would be easier to find.
In cms 3.1, change the text ", which specifies which AVPs
should be encrypted, signed or both, as well as which public
key(s) to use." to ", which specifies which public key(s)
to use for signing and encryption of AVPs."
Also, in cms 5.0, remove the last sentence of step (f). And
the last sentence of (g).
In step (h) change "which authenticates the AVPs that were
requested by the Home Server in the DSAA." to "which authenticates
the AVPs that MUST be authenticated as defined in section 2.0."
In step (i) change "whose contents include the AVPs that were
specified by the NAS in the DSAR." to "whose contents include the
AVPs that MUST be encrypted as defined in section 2.0."
Resolution: The resolution to both issues #221 and #279 was to remove the
expected-* AVPs
from CMS, and change the defintion of "MAY Encr" in both base and CMS. The
agreed change in the CMS I-D is at the end
of section 3.1:
"Note: [BASE] includes the "MAY encr" column when describing AVPs. For
the originator "MAY encr" as used in [BASE] means that if a message
containing that AVP is to be sent via a proxy/agent (as opposed to
directly) then the message MUST NOT be sent unless there is a DSA
between the originator and the recipient OR the originator has
locally trusted configuration that indicates that CMS need not be
used."
Submitter name: Sebastian Zander
Submitter email address: zander@fokus.fhg.de
Date first submitted: February 11th, 2002
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02998.html
Document: base-08
Comment type: T
Priority: 1
Section: 9.5, 10.2
Rationale/Explanation of issue:
Section 9.5 of base-08 reads:
"In all accounting records the Session-Id and User-Name AVPs MUST be present."
The Diameter client may not know the user's identity. Therefore there can not be
a
MUST for including it. Furthermore there is some inconsistency in the draft
since the
User-Name AVP is already marked optional in section 9.7.1 and 9.7.2 but
mandatory
in section 10.2.
Requested change:
Section 9.5 should be changed to:
"In all accounting records the Session-Id AVP MUST be present. The User-Name AVP
MUST be present if it is available to the Diameter client."
The table in section 10.2 should be changed so that User-Name is optional.
-- Sebastian
Submitter name: Kevin Purser
Submitter email address: kevin.purser@ericsson.com
Date first submitted: February 11th, 2002
Reference: none
Document: base-08alpha02
Comment type: Editorial
Priority: 1
Section: 5.6 "Peer State Machine"
Rationale/Explanation of issue:
There are a couple of references in this section to "the state machine
described in [52]". However, in the latest version of the transport draft,
such a state machine is not present.
Requested change:
Remove these references in the text.
Submitter name: Kevin Purser
Submitter email address: kevin.purser@ericsson.com
Date first submitted: February 14th, 2002
Reference: none
Document: base-08alpha02
Comment type: Technical
Priority: 1
Sections: 2.9.3, 6.12
Rationale/Explanation of issue:
Diameter redirect agents currently provide realm to server address
resolution. Within a single administrative domain, it could be useful to
allow redirect agents to have the option of providing user to server address
resolution.
Requested change:
* change the first paragraph of section 2.9.3 to read:
Redirect agents provide Realm to Server address resolution and MAY also
provide User to Server address resolution. These redirect agents would make
use of the Diameter routing table or optionally, a user table to determine
where a given request should be forwarded. When a request is received by a
redirect agent, a special answer is created, which includes the identity of
the Diameter server(s) the originator of the request should contact
directly.
* add the following enumerated value in section 6.12:
ALL_USER 6
All messages for the user requested MAY be sent to the
host specified in the Redirect-Host AVP.
Submitter name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: 18 Feb 2002
Reference:
Document: Base
Comment type: T
Priority: 1
Section: 2.2
Rationale/Explanation of issue:
Usage of TLS and IPsec. Aside from more detail on how to use TLS and
IPsec, it was noted that the drafts do not say that IPsec is for
Intra-domain use and TLS for inter-domain. In practice, IKE isn't very
interoperable when used with certs, and can't support the required cert
policies very well. TLS has this nailed. Should we say
that IPsec is primarily for use with pre-shared keys and only
intra-domain, and TLS is for cert usage and inter-domain? Should we
adjust the language (TLS as MUST on client, too?) Issue to be filed and
raised on the mailing list.
Requested change:
Proposal
Add the following text:
Diameter clients, such as Network Access Servers (NASes) and Mobility
Agents MUST support IP Security [SEC ARCH], and SHOULD support TLS [TLS].
Diameter servers MUST support TLS and IPSec. Operating the Diameter
protocol without any security mechanism is not recommended.
It is suggested that IPsec is primarily for use with pre-shared keys
and to protect intra-domain traffic. TLS is for certificate usage and
to project inter-domain traffic.
John
Submitter name: Paco Marin
Submitter email address: fmaring@airtel.es
Date first submitted: 02-18-2002
Reference:
Document: draft-hakala-diameter-credit-control-01.txt
Comment type: Technical
Hi all,
I've been taking look to the last version of the draft 'Diameter Credit Control
Application'
(draft-hakala-diameter-credit-control-01.txt). I've been thinking about common
services an operator
like my company needs to offer and the possibility of applying DIAMETER CCA to
the charging part.
Sorry if some of the following issues are obvious, but I think despite of the
most of the scenarios
being covered with the described protocol, however I did'nt find the way to use
this protocol to
cover two possible scenarios. The referred scenarios are the following:
1.- Check of balance.
Sometimes is necessary to check if there is enough balance to grant a service to
a subscriber.
Imagine a subscriber of a mobile comunications operator wants to download a
melody or a 'logo' from
the Internet on his mobile phone (using the Short Message Service of GSM). In
this scenario, there
are three parts: the subscriber, the network operator and a third party which is
the service
provider. The third party will charge the sent melody (or logo) to the network
operator just when
the network operator receives it, so it could be interesting to acknowledge the
Short Message
delivery from the third party only when the subscriber has enough credit. This
way the operator
avoids to pay for a message that will never be delivered because the final user
(the subscriber) has
no credit enough. I've been thinking about the possibility of using 'session
based credit control'.
However is hardly ineficient, the SM must be acknowledged immediately and the
short message could
wait several days to be delivered to the final user (the user could be out of
coverage), it implies
to keep the session opened until the SM is finally delivered.
2.- Increment of Credit
In some scenarios could be useful to add to the protocol the posibility to
increase the balance
instead of decrementing it. As an example, could be a way to motivate the user
access to
advertisement information in the internet or to receive adversiting Short
Messages from a third
party. In these scenarios could be interesting to be able to increment the
credit directly from the
client, as an example increase money on the user account or allow 1 free short
message every 5
advertisement Short Message received.
I think there is no way to make it with the current version of the draft
(please, please, please
correct me if I am wrong or confused).
The solution to these two scenarios should not be fundamental for the overall
working of the
Diameter CCA, however it would apply flexibility enough to ease the use of the
protocol to the
legacy architectures of the current network operators.
In my humble opinion a possible solution for both scenarios should be to include
a new AVP.
PROPOSAL OF SOLUTION
A new AVP to indicate an operation on the balance is going to be accomplished
could be added to the
proposed AVPs of the Diameter CCA protocol. This AVP could indicate if the
action to be carried out
is a decrement, check of balance or an increment. If this new AVP is not
included in the request,
the server should consider that the value of this one is '0', it will mean the
behaviour of the
protocol will be the one described up to now. The new AVP could be:
'Balance-Management-Indicator', it should be of tipe Unsigned32 and its values
could be:
'0': Decrement, the request and answer work as up to now. The
'Requested-Service-Unit' AVP
contains the unit to decrement, the 'Granted-Service-Unit' AVP contains the
service units granted.
This units will be decremented in that moment from the user account.
'1':Check of balance, the 'Requested-Service-Unit' AVP could contains the
service unit to check
if it is allowed to be carried out, the 'Granted-Service-Unit' AVP contains the
service units
allowed to be carried out. This units will NOT be decremented from the user
account.
'2': Increment, the request and answer work in a similar way as described for
the value '0'.
The 'Requested-Service-Unit' AVP contains the unit to increment, the
'Granted-Service-Unit' AVP
contains the service units incremented. This units will be incremented in that
moment in the user
account.
The accounted AVP table should be modified as follows:
+----------+
| Command |
| code |
+----+-----+
Attribute Name |ACR | ACA |
------------------------------+----+-----+
Balance-Management-Indicator |0-1 | 0 |
------------------------------+----+-----+
Maybe I'm confused..... correct me in that case.
Thanks a lot.
Paco.
From: Tony Johansson
Date: Tue Feb 19 14:30:15 2002
All,
In my efforts to update the Diameter MIPv4 application I have stumble on
the Accounting AVPs defined and realized that exactly the same AVPs are
defined also in the NASREQ application, see below.
Unless I have misunderstood something, I would suggest that we move
these AVPs to the Base, since they are used by both NASREQ and MIP.
Regards,
/Tony
In MIP:
"7.1 Accounting-Input-Extended-Octets AVP
The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type
Unsigned64, and contains the number of octets in IP packets received
from the user.
7.2 Accounting-Output-Extended-Octets AVP
The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type
Unsigned64, and contains the number of octets in IP packets sent to
the user.
7.3 Accounting-Session-Time AVP
The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32,
and indicates the length of the current session in seconds.
7.4 Accounting-Input-Extended-Packets AVP
The Accounting-Input-Extended-Packets (AVP Code 365) is of type
Unsigned64, and contains the number of IP packets received from the
user.
7.5 Accounting-Output-Extended-Packets AVP
The Accounting-Output-Extended-Packets (AVP Code 366) is of type
Unsigned64, and contains the number of IP packets sent to the user."
In NASREQ:
8.1 Accounting-Input-Extended-Octets AVP
The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type
Unsigned64, and contains the number of octets in IP packets received
by the user.
8.2 Accounting-Output-Extended-Octets AVP
The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type
Unsigned64, and contains the number of octets in IP packets sent to
the user.
8.3 Accounting-Session-Time AVP
The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32,
and indicates the length of the current session in seconds.
8.4 Accounting-Input-Extended-Packets AVP
The Accounting-Input-Extended-Packets (AVP Code 365) is of type
Unsigned64, and contains the number of IP packets received by the
user.
8.5 Accounting-Output-Extended-Packets AVP
The Accounting-Output-Extended-Packets (AVP Code 366) is of type
Unsigned64, and contains the number of IP packets sent to the user.
From: Tony Johansson
Date: Tue Feb 19 17:40:02 2002
All,
Section 4.11 in the Diameter MIPv4 appl. defines the MIP-Home-Agent-Host
AVP and contains the identity of the home agent requested by the mobile
node in its registration request. This AVP is used by the AAAH to
determine the destination of the HAR.
However, this AVP demands changes to the Mobile IP protocol and looking
back at the Issue 212 thread
(http://www.merit.edu/mail.archives/aaa-wg/2001-11/msg00062.html) the
consensus was to NOT make use of this AVP. The agreed solution for Issue
212 was instead to require that the new AAAH perform the Server
Discovery procedures (defined in the Base) to determine the URL of the
Home Agent.
So, I believe this AVP is an editorial mistake and should just be
removed. Any objections to this?
Regards,
/Tony
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: 2/21/02
Reference:
Document: Base
Comment type: T
Priority: S
Section: 4.4
Rationale/Explanation of issue:
Some Background
---------------
The AAA URI provides two different kinds of information.
1. It identifies a Diameter node. A Diameter node is a Diameter
process running on some host or device. It is possible to have
more than one Diameter process running on a host.
2. It provides information about how to connect to the Diameter node
-- what transport protocol to use, what transport level security
to use, and even what AAA protocol to use (although we are only
concerned about one, namely Diameter).
The AAA URI also serves two different purposes.
1. It is used in the peer-to-peer protocol to identify a peer and
indicate certain parameters concerning how to connect to that
peer. This use requires the full URI including the prefix, the
fqdn, the port number, and the options. A URI for this purpose
may be stored in a local configuration file or on a remote server
to enable dynamic peer discovery (see sec. 5.2).
2. It is used in the Diameter routing and forwarding decisions to
identify the Diameter node to which a Diameter message is
addressed. This use requires those portions of the URI that
identify the Diameter node but does not require (and can be
confused by) the information about how to connect to the node as a =
peer. This is the use made of the URI as transmitted in all AVPs
of type DiameterIdentity.
The Problem
-----------
The problem is that the URI format is currently defined in only one
place (sec. 4.4 under the "DiameterIdentity" type) and makes no
distinction between its use for the two different purposes described
above.
Operational Difficulties if the Problem Isn't Fixed
---------------------------------------------------
Section 4.4 states:
Unless a Diameter node is sitting on the border of two routing
domains (e.g. private and public), a Diameter node MUST
advertise the same identity on all connections, via the CER
and CEA's Origin-Host AVP.
Suppose a Diameter node has two peers. It connects to the first peer
using SCTP. It connects to the second peer using TCP. In order to
obey this requirement, the node would have to include the string
"transport=sctp" in the Origin-Host AVP it puts in its CER or CEA
message to the second peer even though it is using TCP to connect to
that peer. So the identity advertised is not the identity used.
This seems odd, but as we shall see, it is actually necessary in order
to make the routing mechanism work.
Section 4.4 goes on to state:
The same identity advertised in a connection's CER and CEA MUST
be used in any AVP of type DiameterIdentity sent on that
connection.
Now suppose an implementor misses the oddity required by the first
sentence and does the obvious thing -- suppose the implementation
always includes in the CER the parameters actually in use on the peer
connection. Then the implementation will have a very hard time
meeting this requirement too. It would have to know how it will
route the message at the time it generates the message, a horrible
violation of modularity. Supposing it does know how it will route
the message and sets the value of the Origin-Host AVP in the message
to the same value used in the CER or CEA sent to the peer to which it
will route it. Now suppose something goes wrong when sending the
message to this peer, and the message is subsequently retransmitted
to a backup peer. Oops. Now the Origin-Host AVP is wrong for that
connection and it can't be changed.
So we'll just have to assume that all implementors pick up on the
oddity. But wait -- we're still not out of the woods. Suppose, at
the time a session begins, the Diameter client supporting the session
uses TCP on its peer link. So it includes the string "transport=tcp"
in the auth request that begins the session. Suppose that several
hours later the session is still in progress, but the client has
reinitialized its peer link and is now using SCTP. Now suppose the
home server sends an Abort-Session-Request message to the client for
this session. The Abort-Session-Request will include a
Destination-Host AVP that contains the string "transport=tcp". The
message eventually reaches the peer connected to the client. The
peer matches the URI in the Destination-Host AVP with the ones in its
peer table. It finds no match because "transport=tcp" does not match
"transport=sctp". So it discards the message.
Interaction With Issue 273
--------------------------
Another issue urges that Diameter nodes not use different port
numbers for TLS versus non-TLS connections. I am guessing that issue
273 is the one that encompasses this change. The question of port
number use for TLS versus non-TLS was raised by Allison Mankin in:
http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00025.html
The outcome of issue 273 (if that is the issue that includes this
question) is critical to the resolution of this issue as well. The
reason is that we use the combination of fqdn and port number to
identify a diameter node. If more than one Diameter node (Diameter
daemon) runs on a host, they will use different port numbers. But if
a Diameter node listens on more than one port number, then it may use
two different URIs and there will be no way for a peer to know that
the URI from the Destination-Host AVP of a message it is routing
matches the URI of one of its peers if the port number differs.
John Loughney suggested use of aaa: vs. aaas: to indicate whether TLS
is used in:
http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00120.html
If this suggestion is adopted, then the "s" in aaas: will need to be
ignored when doing routing matches against entries in the peer table.
Requested change:
Define the format of the URI somewhere other than section 4.4. In
the definition of the DiameterIdentity type in section 4.4, specify
that only the prefix, fqdn, and port number portions of the URI are
included in AVP value fields of this type. The sentences cited above
may now be left in section 4.4 because they no longer cause a
problem.
If the resolution of issue 273 allows a Diameter node to listen on
different ports for TLS vs. non-TLS connections, then section 4.4
needs to emphasize that a single port number MUST be used in all AVPs
of type DiameterIdentity. If the resolution of 273 requires use of
the same port for TLS and non-TLS connections, then it would still be
a good idea to include text in section 4.4 following the first
sentence cited above that emphasizes that the same port number MUST
be used in all AVPs of type DiameterIdentity even if a peer
connection request was received on a different port.
If the URI prefix may either be aaa: or aaas: depending on transport
security, then text should be added to section 6 stating that when
matching URIs for routing purposes, the "s" in aaas: should be
dropped before the compare is made.
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: February 25, 2002
Reference:
Document: Base
Comment type: T
Priority: S
Section: 4.1
Rationale/Explanation of issue:
The AVP Flag rules tables in the various Diameter drafts specify in
which AVPs the 'M' bit MUST be set, in which AVPs it MUST NOT be set,
etc.
However section 4.1 of the base draft states:
A Diameter node that sets the 'M' bit in an AVP that is not
defined in a given message's ABNF is at fault if the message is
rejected.
In the next paragraph it states:
A Diameter node that rejects a message due to an unrecognized AVP
with the 'M' bit set, and the AVP in question is defined in the
message's ABNF, is at fault.
These sentences make the criterion for setting the 'M' bit be whether
or not the AVP is listed in the formal syntax for the message in
which it appears. This is in direct contradiction to the criterion
that the 'M' bit should be set according to the specification in the
AVP Flag rules table of the draft defining the AVP.
Life gets complicated, however, when an AVP defined in one Diameter
Application or a vendor-specific AVP gets included in a message
defined in another Diameter Application. This is allowed for most
Diameter messages because the "* [ AVP ]" construct appears in most
message specifications.
So what happens if the sender of the message considers such an AVP to
be critical to its intent, but the recipient of the message does not
understand the AVP? The answer is that an interoperability failure
happens. Some have argued (I have at times) that Diameter's
open-ended extensibility is actually one of its weaknesses.
At the AAA WG interim meeting in Santa Clara in May 2001, the
extensibility-is-good faction reached a compromise with the
interoperability-failures-are-bad faction that resulted in the at
fault rules that appear in section 4.1 of the base draft. The issue
here is that it is important to get the rules right.
Considering that a Diameter node may include non-standard AVPs, and
considering that it may be critical to the security or business
requirements of the parties involved to know whether or not such AVPs
are accepted and processed, and considering that interoperability
failures are not in the best interests of any of the parties
involved, I propose the following principles to govern setting of the
'M' bit:
1) AVP specifiers should be encouraged to require setting the 'M'
bit of any AVP for which the interest of any of the parties
would be hurt were the AVP to be ignored.
2) Implementors should be required to provide alternatives to
sending non-standard AVPs with the 'M' bit set. These may
include:
a) If a message is rejected because it contains a non-standard
AVP with the 'M' bit set, the implementation may resend the
message without the AVP, possibly inserting additional
standard AVPs instead.
b) A configuration option may be provided on a system wide, per
peer, or per realm basis that would allow/prevent particular
non-standard, Mandatory AVPs to be sent. Thus an
administrator could change the configuration to avoid
interoperability problems.
3) An implementation that does not comply with the above
requirements is not compliant with the Diameter standard.
Examples
--------
Example 1: If I were to define a vendor-specific
Interlink-Wowee-Zowee-Filter-Rule AVP, I would specify that the 'M'
bit MUST be set (I certainly don't want the filters to be ignored).
An implementation sending this AVP would be compliant if, upon
receiving a rejection for a message containing the AVP, it re-sent
the message with the NAS-Filter-Rule AVP in place of the
Interlink-Wowee-Zowee-Filter-Rule AVP. Alternatively, an
implementation could achieve compliance by offering a per-realm
configuration option to control what realms to send the
Interlink-Wowee-Zowee-Filter-Rule AVP to.
Example 2: NASCO NASes always include the NAS-Filter-Rule AVP in
Accounting-Request messages on the theory that inclusion of this AVP
in accounting records may be critical to some providers' auditing
requirements. NASCO is permitted to do this because the construct
"* [ AVP ]" appears in the formal syntax of the Accounting-Request
message. The 'M' bit is set because the table in section 2.1 of the
NASREQ standard requires it. ACME Accounting Servers do not
understand the NAS-Filter-Rule AVP. If they receive an Accounting
Request message for a NASREQ session that includes the
NAS-Filter-Rule AVP with the 'M' bit set, they reject the message.
Thus no accounting can ever happen between a NASCO NAS and an ACME
Accounting Server. Who is at fault? ACME argues that according to
Diameter-08, NASCO is at fault because neither of the tables in
section 10.2 of NASREQ list the NAS-Filter-Rule AVP.
Requested change:
Replace the at fault rules in section 4.1 with the following text.
(Note: the editor may decide to move this discussion to another, more
appropriate section of the draft.)
The 'M' bit MUST be set according to the rules defined for the AVP
containing it. In order to preserve interoperability, a Diameter
implementation MUST be able to exclude from a Diameter message any
Mandatory AVP which is neither defined in the base Diameter
standard nor in any of the Diameter Application specifications
governing the message in which it appears. It MAY do this in one
of the following ways:
1) If a message is rejected because it contains a Mandatory AVP
which is neither defined in the base Diameter standard nor in
any of the Diameter Application specifications governing the
message in which it appears, the implementation may resend the
message without the AVP, possibly inserting additional standard
AVPs instead.
2) A configuration option may be provided on a system wide, per
peer, or per realm basis that would allow/prevent particular
Mandatory AVPs to be sent. Thus an administrator could change
the configuration to avoid interoperability problems.
Diameter implementations are required to support all Mandatory
AVPs which are allowed by the message's formal syntax and defined
either in the base Diameter standard or in one of the Diameter
Application specifications governing the message.
Submitter name: Johan Johansson
Submitter email address: johanj@ipunplugged.com
Date first submitted: 2002-02-26
Reference:
Document: base
Comment type: T
Priority: 1
Section: 10.1, 6.8
Rationale/Explanation of issue:
STR and ASR messages do not belong to any specific application but
rather to all of them. This means that they will take *any* route to
a realm even if it is a dead end. They should contain
Auth-Application-Id avps.
Let the realm R be a realm with (separate) home servers N and M for
NASREQ and MIP and assume that from a given realm the normal route
passes through a node S that has one NASREQ route to R that will
make messages enter R via N and one MIP route that will make
messages enter R via M, e.g.
S----------------X------------X------------N
|
+------------X------------M
Since M and N have no common application they will not be peers.
Assume that there is an active MIP session at M that the access
device determines to terminate by sending an STR. There is nothing
that prevents S from routing the STR down the N path.
Requested changes:
6.8: I haven't thought of a good change to this section yet. But it
should state that messages regarding a session for a particular
application should contain the id of that application.
10.1: Change
+-----------------------------------------------+
| Command-Code |
|---+---+---+---+---+---+---+---+---+---+---+---+
Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------|---+---+---+---+---+---+---+---+---+---+---+---|
Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
to
+-----------------------------------------------+
| Command-Code |
|---+---+---+---+---+---+---+---+---+---+---+---+
Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------|---+---+---+---+---+---+---+---+---+---+---+---|
Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |
I guess the RAR messages should probably also have the
Auth-Application-Id for similar purposes but I'll leave that for
those who actually use it to comment on.
j
Submitter name: Bob Kopacz
Submitter email address: BKopacz@InterlinkNetworks.com
Date first submitted: 02-27-2002
Reference: http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00314.html
Document:draft-mobileip-08
Comment type: Technical
Priority:1
Section:
Rationale/Explanation of issue:
Changes to generation & handling of the Accounting-Multi-Session-Id AVP.
The following lines prefixed with "*" are extracted from
draft-mobileip-08. The lines are numbered to make them referencable
in the discussion.
*01 1.2 Inter-Realm Mobile IP
*02
*03 [...]
*04
*05 For new sessions, the AAAH MUST create an accounting session
*06 identifier, which is added to the Accounting-Multi-Session-Id AVP in
*07 the HAR message sent to the home agent.
*08
*09 During the creation of the HAR, the AAAH MUST use a different session
*10 identifier than the one used in the AMR/AMA (see figure 2). Of
*11 course, an AAAH MUST use the same session identifier for all HARs
*12 initiated on behalf of a given mobile node's session. [...]
*13
(1) According to the Introduction, an AAAH may be session-stateless. I
don't think a session-stateless AAAH can differentiate a new session
from a handoff of an existing session. Therefore a session-stateless
AAAH couldn't send the same session-id for handoffs, as stated in line *11.
*14 [...]
*15
*16 Upon receipt of the HAR, the Home Agent first processes the Diameter
*17 message. [...] The Accounting-Multi-Session-Id AVP in
*18 the HAR MUST be included in the HAA, which is then forwarded to the
*19 AAAH.
*20
(2) The last sentence is not quite right. While the HA does send an
Accounting-Multi-Session-Id AVP in the HAA, it may be a different one
than was received in the HAR. (see lines *44-*46).
*25 1.3 Support for Mobile IP Handoffs
*26
*27 [...]
*28
*29 Since the new AAAH in the home network MAY not have access to the
*30 session identifier that was used by the old AAAH, it is necessary for
*31 the resulting HAR received by the HA to be identified as a
*32 continuation of an existing session. If the HA receives an HAR for a
*33 mobile node, with a new session identifier, and the HA can guarantee
*34 that this request is to extend service for an existing service, then
*35 the HA MUST be able to modify its internal session state information
*36 to reflect the new AAAH and session identifier. The HA MUST also
*37 issue an STR message with the old session identifier to the AAAH it
*38 was communicating with when using the old session identifier.
*39
*40 It is necessary for accounting records to have some commonality
*41 across handoffs in order for correlation to occur. Therefore, in the
*42 event that a home agent receives an HAR with a different Accounting-
*43 Multi-Session-id AVP (and obviously a different Session-Id AVP), the
*44 home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP
*45 that was received by the AAAH in the first HAR for the mobile's
*46 session. This modified Accounting-Multi-Session-Id AVP will be
*47 returned to the foreign agent by the AAAH in the AMA. Both the
*48 foreign and home agents MUST include the Accounting-Multi-Session-Id
*49 in the accounting messages.
*50
(3) Since the AAAH must be prepared to have the AAAH-generated
Accounting-Multi-Session-Id overridden by the HA, the protocol should
change to just have the HA always specify the
Accounting-Multi-Session-Id.
The thinking is that the HA is constant over the MN's session, while the
AAAHs and AAAFs and FAs change. So the HA is in a position to specify a
constant Accounting-Multi-Session-Id, eliminating the extra
complications of a switcheroo.
The proposal is that the AAAH will not send a
Accounting-Multi-Session-Id in the HAR. The HA MUST send a
Accounting-Multi-Session-Id in the HAA. All of the messages for a
MN's session will have the same value for the
Accounting-Multi-Session-Id AVP.
(4) Since the AAAH may be session-stateless, the HA would send the STR
to the AAAH, as indicated in lines *36-*38, if and only if the AAAH
has changed.
Requested change:
In Section 1.2 Inter-Realm Mobile IP
Replace:
"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.
"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, an AAAH MUST use the same session identifier for all HARs
initiated on behalf of a given mobile node's session. [...]
With:
"During the creation of the HAR, the AAAH MUST use a different session
identifier than the one used in the AMR/AMA.
"If the AAAH is session-stateful, it should send the same session
identifier for all HARs initiated on behalf of a given mobile node's
session.
"If the AAAH is not session-stateful, it will manufacture a unique
session-id for every HAR. (Note--This will not cause a problem for
the HA, who must be able to recognize a handoff even if the AAAH
thinks the session is new; an AAAH may incorrectly view a session as
new when the handoff AMR goes to a different AAAH than the previous
AMR).
- - - -
In Section 1.2 Inter-Realm Mobile IP
Replace the last sentence of the following paragraph:
Upon receipt of the HAR, the Home Agent first processes the Diameter
message. [...] The Accounting-Multi-Session-Id AVP in
the HAR MUST be included in the HAA, which is then forwarded to the
AAAH.
With:
The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA
returned to the AAAH.
- - - -
In section 1.3 Support for Mobile IP Handoffs
Replace:
Since the new AAAH in the home network MAY not have access to the
session identifier that was used by the old AAAH, it is necessary for
the resulting HAR received by the HA to be identified as a
continuation of an existing session. If the HA receives an HAR for a
mobile node, with a new session identifier, and the HA can guarantee
that this request is to extend service for an existing service, then
the HA MUST be able to modify its internal session state information
to reflect the new AAAH and session identifier. The HA MUST also
issue an STR message with the old session identifier to the AAAH it
was communicating with when using the old session identifier.
It is necessary for accounting records to have some commonality
across handoffs in order for correlation to occur. Therefore, in the
event that a home agent receives an HAR with a different Accounting-
Multi-Session-id AVP (and obviously a different Session-Id AVP), the
home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP
that was received by the AAAH in the first HAR for the mobile's
session. This modified Accounting-Multi-Session-Id AVP will be
returned to the foreign agent by the AAAH in the AMA. Both the
foreign and home agents MUST include the Accounting-Multi-Session-Id
in the accounting messages.
With:
"Since the new AAAH in the home network MAY not have access to the
session identifier that was used by the old AAAH, or since the AAAH
may be session-stateless, it is necessary for the resulting HAR
received by the HA to be identified as a continuation of an existing
session.
"If the HA receives an HAR for a mobile node, with a new session
identifier, and the HA can guarantee that this request is to extend
service for an existing service, then the HA MUST be able to modify
its internal session state information to reflect the (possibly) new
AAAH and new session identifier.
"If the AAAH is new, the HA MUST also issue an STR message with the old
session identifier to the AAAH it was communicating with when using
the old session identifier.
"It is necessary for accounting records to have some commonality across
handoffs in order for correlation to occur. Therefore, the home agent
MUST send the same Accounting-Multi-Session-Id AVP value in all HAAs for
the mobile's session. That is, the HA generates a unique
Accounting-Multi-Session-Id when receiving an HAR for a new session, and
returns this same value in every HAA for the session.
"This Accounting-Multi-Session-Id AVP will be returned to the foreign
agent by the AAAH in the AMA. Both the foreign and home agents MUST
include the Accounting-Multi-Session-Id in the accounting messages."
- - - -
In Section 1.5 "Co-located Mobile Node"
Add the following sentence:
"The HA includes the Accounting-Multi-Session-Id AVP in the AMR sent to
the AAAH, as the AAAH may find this a useful piece of session-state or
log entry information."
- - - -
In section 2.3 Home-Agent-MIP-Request
Remove { Accounting-Multi-Session-Id } from the message ABNF.
- - - -
In section 2.4 Home-Agent-MIP-Answer
Change [ Accounting-Multi-Session-Id ] to { Accounting-Multi-Session-Id }
in the message ABNF.
- - - -
In section 8.1 Mobile IP Command AVP Table,
Add an entry for the Accounting-Multi-Session-Id AVP.
Attribute Name | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
Accounting-Multi-Session-Id | 0-1 | 1 | 0 | 1 |
- - - -
In section 8.2 Accounting AVP Table
Add an entry for the Accounting-Multi-Session-Id AVP.
Attribute Name | ACR | ACA |
------------------------------|-----+-----+
Accounting-Multi-Session-Id | 1 | 0-1 |
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: February 26, 2002
Reference:
Document: cms-sec
Comment type: E
Priority: S
Section: many
Rationale/Explanation of issue:
Cms-sec-02 defined an AVP called CMS-Cert.This AVP was removed in
cms-sec-03, however many references to it remain.
Requested change:
Remove all references to the CMS-Cert AVP.
Submitter name: Bob Kopacz
Submitter email address: BKopacz@InterlinkNetworks.com
Date first submitted: 02-27-2002
Reference:
Document: draft-mobileip-08
Comment type:Technical
Priority: 1
Section:
Rationale/Explanation of issue:
(1) It is difficult for the originating AAAF to correctly set the
Home-Agent-In-Foreign-Network flag. That is, suppose the MN sends a
"real" HA IP address (not all zeroes or all ones). The AAAF only sees
an IP address. The AAAF doesn't know just from the HA's IP address
whether that represents an HA in the home network, or an HA in another
foreign network. And maybe doesn't even know if the IP address is in
his own network.
The AAAF would have to call upon the DNS or other external resources
to make this "home-agent-is-in-a-foreign-network" determination. This
introduces unnecessary delay into the call setup by duplicating work
which the AAAH has to do anyway upon receiving the AMR. That is, when
the AAAH receives the AMR with a specified HA IP address, the AAAH has
to map this IP address into the HA's realm and HA's DiameterIdentity,
which will be used as the Destination-Realm and Destination-Host of
the HAR. Furthermore, the AAAH may be able to make this determination
more quickly than the AAAF, as a session-stateful AAAH may well have
this information at hand as part of his session state.
(2) The proposal here is to make the Home-Agent-In-Foreign-Network flag
one which is not set by the originating-AAAF, but is instead set by
the AAAH. This information will be returned to the originating-AAAF
and FA when the updated feature vector is returned in the AMA.
(3) It may be that the originating AAAF wants to disallow a foreign
HA, or allow a foreign HA but only if the foreign HA is in the
originating AAAF's domain. If this capability is desired, then two
new flags, settable by the originating AAAF, can be added to the
MIP-Feature-Vector:
Foreign-HA-Allowed-In-NonOriginating-Network
Foreign-HA-Allowed-In-Originating-Network
The AAAH, after examining the home agent's IP address and determining
whether the HA resides in the originating network, home network, or
some other foreign network, can examine the two new flags to enforce
the originating AAAF's policy on foreign HAs.
This way, the originating AAAF maintains the ability to place retrictions
on foreign HAs before the call is authorized.
(4) If (3) above is considered something an originating AAAF wouldn't care
about, then these two new flags can be removed from the proposal.
Requested change:
In section 1.2 Inter-Realm Mobile IP
Replace:
If the Mobile Node was successfully authenticated, the AAAH checks if
the Home Agent was located in the foreign realm, by checking the
Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If
the flag is enabled, then the Home Agent is located in the foreign
realm then AAAH sends an HAR message to AAAF which contains a MIP-
Reg-Request AVP.
With:
If the Mobile Node was successfully authenticated, the AAAH checks if
the Home Agent is located in a foreign realm. If so, the AAAH sets the
Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP.
Only the AAAH may set the Home-Agent-In-Foreign-Network flag.
If the Home Agent is located in a foreign realm other than the
originating realm, and the
Foreign-HA-Allowed-In-NonOriginating-Network flag is zero, then the
AAAH will return an AMA with a Result-Code of
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.
If the Home Agent is located in the originating foreign realm, and the
Foreign-HA-Allowed-In-Originating-Network flag is zero, then the AAAH
will return an AMA with a Result-Code of
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.
Otherwise, if the Home Agent is in a foreign network, and this is
allowed by both the originating AAAF and the AAAH, then the AAAH sends
an HAR message to foreign HA which contains a MIP-Reg-Request AVP.
- - -
In section 1.4 Allocation of Home Agent in Foreign Network
Remove this paragraph:
In the event that the mobile node requests a home agent in the
foreign network, and the AAAF authorizes its use, the AAAF MUST set
the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
This could happen when the AAA request is sent to "extend" a mobile
node's current session.
- - -
In section 4.5 MIP-Feature-Vector AVP
Replace:
The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and
is added with flag values set by the Foreign Agent or by the AAAF
owned by the same administrative domain as the Foreign Agent. The
Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR
message it sends to the AAAF.
With:
The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and
conveys flag values set by the Foreign Agent, the AAAF owned by the
same administrative domain as the Foreign Agent, and the AAAH. The
flags in the MIP-Feature-Vector are updated as the AMR makes it way to
the AAAH, and the updated MIP-Feature-Vector is returned in the AMA.
The Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR
message it sends to the AAAF.
- - -
In section 4.5 MIP-Feature-Vector AVP
To this list of flags:
Flag values currently defined include:
1Mobile-Node-Home-Address-Requested
2Home-Address-Allocatable-Only-in-Home-Realm
4Home-Agent-Requested
8Foreign-Home-Agent-Available
16 MN-HA-Key-Request
32 MN-FA-Key-Request
64 FA-HA-Key-Request
128 Home-Agent-In-Foreign-Network
256 Co-Located-Mobile-Node
Add:
512Foreign-HA-Allowed-In-NonOriginating-Network
1024 Foreign-HA-Allowed-In-Originating-Network
- - -
In section 4.5 MIP-Feature-Vector AVP
Replace:
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.
The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available, and
Home-Agent-In-Foreign-Network flag to one.
When the AAAF receives the AMR message, it MUST first verify that the
sender was an authorized Foreign Agent. The AAAF then takes any
actions indicated by the settings of the MIP-Feature-Vector AVP
flags. The AAAF then MAY set additional flags.Only the AAAF may set
the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network
flags to one. This is done according to local administrative policy.
When the AAAF has finished setting additional flags according to its
local policy, then the AAAF transmits the AMR with the possibly
modified MIP-Feature-Vector AVP to the AAAH.
With:
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 may restrict the HA to certain networks by setting the
Foreign-HA-Allowed-In-NonOriginating-Network and/or the
Foreign-HA-Allowed-In-Originating-Network flag.
The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available to one
and the Foreign-HA-Allowed-In-Originating-Network flag to zero.
When the AAAF receives the AMR message, it MUST first verify that the
sender was an authorized Foreign Agent. The AAAF then takes any
actions indicated by the settings of the MIP-Feature-Vector AVP flags.
The AAAF then MAY set additional flags. Only the AAAF may set the
Foreign-Home-Agent-Available, Foreign-HA-Allowed-In-Originating-
Network, and Foreign-HA-Allowed-In-NonOriginating-Network flags to
one. This is done according to local administrative policy. When the
AAAF has finished setting additional flags according to its local
policy, then the AAAF transmits the AMR with the possibly modified
MIP-Feature-Vector AVP to the AAAH.
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 1, 2002
Reference:
Document: NASREQ
Comment type: T
Priority: 1
Section: various
Rationale/Explanation of issue:
Although nasreq-08 is not entirely consistent on this, it seems to require
the Service-Type AVP to appear in all messages.Unfortunately, RADIUS does
not make this requirement.Therefore I am relaxing the requirement in
nasreq from MUST to SHOULD.The alternative would be to add an heuristic to
the RADIUS/Diameter gateway section explaining how a RADIUS to Diameter
gateway should infer the value of the Service-Type based on the attributes
present in the RADIUS message.Being lazy, I opt for relaxing the
requirement.
Requested change:
State that Service-Type SHOULD (rather than MUST) be included, change the
ABNF from "{ Service-Type }" to "[ Service-Type ]", and change the AVP
Ocurrence Tables from 1 to 0-1.
Submitter: Jesse Walker
Submitter email address: jesse.walker@intel.com
Date first submitted: March 2, 2002
Reference:
Document: NASREQ
Comment type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue:
Diameter keying AVPs cannot securely distribute a key for its intended
purpose. While they may be suitable for handing off a key between the
authentication server and the NAS/Access Point, intended for
communications between themselves alone, as constituted today they are
insecure for transferring a session key intended for use between the
NAS/AP and the client. To become secure, the key handoff has to be
enhanced to incorporate additional cryptographic state that can be
used to provide assurances to all these parties involved in the
transaction.
Examples of such state are the information communicated among the KDC and
the communicating parties in the Needham-Schroeder and Otway-Rees
protocols.
>Given that the AS and AP trust each other (assumed), why
>is a reasonable cryptographic protocol (such as CMS or even IPSec) is
>insufficient to protect the transfer of a STA-AP session key from the AS to
>the AP?
There has been in fact ample discussion around exactly these points. There
is, for instance, the whole key handoff discussion, of which AS-AP handoff
is a special case. As a second example, there is the flap around the
Arbaugh-Mishra 802.1X paper, which echos many of our key handoff
discussions, and which we have also discussed.
But even if we had never discussed these points before, we would be forced
to if the issue were raised; if someone perceives holes in our security,
then these have to be addressed, and making an appeal that this wasn't ever
an issue before doesn't help.
I don't buy the assumed trust argument, because it is not specific enough to
offer any useful insight. Let me respond to it by asking why should we
assume the AS and the AP trust each other, and, more to the point, for what
purpose should they trust each other? I think the correct assumptions are
something like
a. The AS and the AP share a key used for key distribution, and that both
parties can be trusted to use this key for no other purpose, and to expose
it to no other parties;
b. The AS can be trusted to distribute a fresh key whenever it distributes a
key.
Why should we assume substantially more about the AP-AS relationship? Each
assumption represents a new point of attack if compromised, so we would do
well to think about eliminating as many assumptions as possible.
Protocols exist that would allow us to reduce the number of assumptions we
make by incorporating explicit verification in place of trust assumptions.
It is feasible to add protocol state allowing the AS to verify that the key
distribution request really did originate with a legitimate station and not
as the result of a rogue AP or a rogue station. It is feasible for both the
AS and the station to verify that the key distribution is live, even though
they can't verify it is fresh (that's why we have to make the second trust
assumption). It is feasible for both the AP and the station to verify that
the AS intended to distribute this particular key to this particular <AP,
station> pair, i.e., that each is talking to the other intended recipient of
the key, and to no one else, and for the protocol to protect against either
the AP or the station cheating (except by exposing a key). The existing
method of throwing keys over the fence to the AP does not have any of these
guarantees built in, so we have to assume much more to use it. Each such
assumption may reasonable in a sufficiently constrained environment, but I
question whether together they are reasonable in a network as open as a
WLAN.
And I don't buy basing the security on mechanisms like IPsec. By definition,
IPsec provides bilateral security between the two parties sharing a security
association, and binds only the two together. A key distribution protocol of
the sort we are discussing is not a bilateral relationship. Key distribution
is a trilateral relationship among three parties--the AS, the AP, and the
station--and because of this will have to cryptographically bind the three
parties together somehow to be secure, i.e., to minimize points to attack.
You can replace IPsec by any other bilateral security protocol, and the same
argument obtains.
My position is that it would be prudent for us to look at adapting a key
distribution protocol that reduces our exposure by minimizing security
assumptions. I believe this because we are building systems that expose many
more attack points than in the past. Indeed, I think the burden of proof is
on the other foot: what leads us to think the special conditions and
circumstances and topologies that permitted security shortcuts in the past
are still applicable in the more fragile environments we are building today?
Why should the mechanisms that worked in more restricted environments still
be applicable unchanged when moved into new environments that, on the
surface at least, seem to violate many of the assumptions we made before?
Proposed change:
A three-way handshake should be incorporated so that key distribution and
confirmation can be dealt with uniformly across multiple environments.
These key distribution methods require active participation by three
parties instead of two.
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 4, 2002
Reference:
Document: NASREQ-09
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
There are a number of attributes defined in RADIUS RFCs that are
needed for the correct operation of the Diameter NASREQ application.
They are:
CODE NAME RFC
--------- ------------------ ----
29 Termination-Action 2865
41 Acct-Delay-Time 2866
51 Acct-Link-Count 2866
55 Event-Timestamp 2869
78 Configuration-Token 2869
85 Acct-Interim-Interval 2869
87 NAS-Port-Id 2869
88 Framed-Pool 2869
95 NAS-IPv6-Address 3162
98 Login-IPv6-Host 3162
Note: These AVPs were not added to nasreq-09, so this issue requires
more work in nasreq.
Requested change:
Add these attributes to nasreq as Diameter AVPs.
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 4, 2002
Reference:
Document: MobileIPv4
Comment type: T
Priority: 2
Section:
Rationale/Explanation of issue:
The following attribute is defined in RADIUS for use in accounting
messages.It might be useful in the MobileIPv4 application.
CODE NAME RFC
--------- ------------------ ----
55 Event-Timestamp 2869
Requested change:
Consider adding this attribute to MobileIPv4 as a Diameter AVP.
Note: This AVP will need to be defined in NASREQ for RADIUS
compatibility. See issue TBA.
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 4, 2002
Reference:
Document: NASREQ
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
The RADIUS Acct-Terminate-Cause attribute (#49) is superseded in
Diameter by the Termination-Cause AVP (#295).However, there are
many values defined for Acct-Terminate-Cause that have no counterpart
in Termination-Cause.Many of these values are nasreq-specific.
Requested change:
Define addional values in nasreq for the base draft's
Termination-Cause AVP to cover the semantics of the RADIUS
Acct-Terminate-Cause attribute.Ensure that all values
for Acct-Terminate-Cause listed in IANA's radius-types.txt are
covered.Specify the mapping between the Acct-Terminate-Cause
values and the Termination-Cause values so that a RADIUS/Diameter
gateway can translate between them.
Submitter name: Bob Kopacz
Submitter email address:bkopacz@interlinknetworks.com
Date first submitted: 03-04-2002
Reference:
Document: draft-mobileip-09
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Minor editing corrections.
Requested change:
The NASREQ draft has a section "Legacy RADIUS Attributes" with text
along the lines of "The Diameter protocol reserves the AVP Codes 0-255
for "legacy RADIUS" support.The following table contains the RADIUS
attributes supported by this Diameter application, their AVP code
values, types, possible flag values and whether the AVP MAY be
encrypted. RADIUS attributes not listed are not supported by the
Diameter protocol."
After section 4.0 Mandatory AVPs, create a similar section 4.1 which
says something like the following (to indicate the subset of RADIUS
attributes a Diameter Mobile-IP client/server requires in its
dictionary):
> 4.1 Supported Legacy RADIUS Attributes
>
> The Diameter protocol reserves the AVP Codes 0-255 for "legacy RADIUS"
> support.The base protocol defines the RADIUS attributes User-Name,
> Session-Timeout, Acct-Session-Time, Acct-Multi-Session-Id, Proxy-State,
> and Class, all supported by this Diameter application.This application
> supports these RADIUS attributes and no others.
- - -
In section 4.3MIP-Mobile-Node-Address AVP
> The Mobile-Node-Address AVP (AVP Code 333) is of type IPAddress and
^^^^^^^^^^^^^^^^^^^
Change to "MIP-Mobile-Node-Address"
- - -
In section 4.4MIP-Home-Agent-Address AVP
> The Home-Agent-Addess AVP (AVP Code 334) is of type IPAddress and
^^^^^^^^^^^^^^^^^
Change to "MIP-Home-Agent-Address"
- - -
In section 4.5MIP-Feature-Vector AVP
> Whenever the Foreign Agent sets either the Mobile-Node-Home-Address-
> Requested flag or the Home-Agent-Request flag to one, it MUST set the
^^^^^^^^^^^^^^^^^^
Change to "Home-Agent-Requested"
- - -
In the following, move the 5.5.1 section header down by one paragraph,
i.e.
Change:
> 5.5Distributing the Foreign-Home Session Key
>
> 5.5.1 Home Agent in the home network
>
> If the home agent is in the home realm, then the AAAH has to generate
> the Foreign-Home session key. Otherwise, it is generated by the AAAF.
>
> In the cases when the AAAH generates the Foreign-Home session key,
> ...
To:
> 5.5Distributing the Foreign-Home Session Key
>
> If the home agent is in the home realm, then the AAAH has to generate
> the Foreign-Home session key. Otherwise, it is generated by the AAAF.
>
> 5.5.1 Home Agent in the home network
>
> In the cases when the AAAH generates the Foreign-Home session key,
> ...
- - -
In section 6.6MIP-MN-to-HA-Key AVP
> * [ AVP ].fi
Remove ".fi"
- - -
In section 11.1Normative References
> [DIAMBASE]P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens,
> "Diameter Base Protocol", draft-ietf-aaa-diameter-08.txt,
> IETF work in progress, November 2001.
Change to draft-10 (or maybe draft-11 for the next revision)
> [MOBILEIP] C. Perkins, Editor. IP Mobility Support.
>RFC 2002, October 1996.
RFC2002 has been obsoleted by RFC3220, January 2002.
> [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security
> Application", draft-ietf-aaa-diameter-cms-sec-03.txt,
> IETF work in progress, November 2001.
Change to draft-ietf-aaa-diameter-cms-04.txt (or maybe -05 for next revision)
> [MIPKEYS]C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile
>IP", draft-ietf-mobileip-aaa-key-08.txt, IETF work in
>progress, July 2001.
The above has expired, but key-09, 26 February 2002, is out.
Submitter name: Bob Kopacz
Submitter email address:bkopacz@interlinknetworks.com
Date first submitted: 03-04-2002
Reference:
Document: draft-mobileip-09
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
I may be missing something significant here, but ...
This issue has to do with how an AAAF and AAAH, when given a Home
Agent's IP address, derive the domain/realm/DiameterIdentity
information needed by the Diameter AAA servers.
This issue may also have some bearing on the relationship between a
DiameterIdentity and a FQDN.
Unfortunately I don't have a good solution to present, so I'm
indicating what the problems are, as indicated by "-->".It may
be that the solution is to enhance the Mobile IP protocol to
provide more information in the Registration Request.
THE AAAF's PROBLEM:
------------------
Section 1.4. Allocation of Home Agent in Foreign Network, says
the following:
> 1.4Allocation of Home Agent in Foreign Network
>
> [...]
>
> In the event that the mobile node requests a home agent in the
> foreign network, and the AAAF authorizes its use, the AAAF MUST set
> the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
> This could happen when the AAA request is sent to "extend" a mobile
> node's current session.
>
-->(1) I think some text needs to be added to describe how the AAAF
determines if the HA is in a foreign network.
That is, I am guessing the method is along these lines:
Suppose a MN initially connects, is allocated an HA, and later
undergoes a handoff to a new FA and new AAAF.Depending on the MN's
new point of attachment, the new FA and AAAF may or may not be in
the same foreign domain as before, or the foreign domain may
be same but the AAAFs are different, or the handoff may involve
the same AAAF as before.
In the AMR, the new AAAF is provided with the MN user's NAI and the
HA's IP address.Say the MN user is "bob@donut.com" and the specified
HA IP address is 1.2.3.4.
The new AAAF does a reverse DNS lookup of tbe HA's IP address,
1.2.3.4, and the DNS response is that IP address 1.2.3.4 corresponds
to an FQDN of "homeagent86.westcoast.spinach.com".
Now the AAAF extracts the realm part of the NAI, "donut.com", and
pre-pends a dot, coming up with ".donut.com".The AAAF then checks
if this ".donut.com" string is a trailing substring of the
"homeagent86.westcoast.spinach.com" FQDN.It isn't, so the AAAF
concludes the HA is in a foreign network and sends the
Home-Agent-In-Foreign-Network flag with a value of one.If the tail
of the FQDN matched ".donut.com", the AAAF would conclude the HA was
in the home network.
-->(2) This may or may not be anywhere close to the AAAF's method.
At any rate, the method should be described in sufficient detail
for an AAAF implementation.
-->(3) If this DNS reverse lookup is indeed the AAAF's method to
make this "home-agent-is-in-a-foreign-network" determination, then
this introduces a delay into the handoff, and should probably be
noted.
THE AAAH's PROBLEM
------------------
Section 1.2 Inter-Realm Mobile IP, says the following:
>
> 1.2Inter-Realm Mobile IP
>
> [...]
>
> If the Mobile Node was successfully authenticated, the AAAH checks if
> the Home Agent was located in the foreign realm, by checking the
> Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP.If
> the flag is enabled, then the Home Agent is located in the foreign
> realm then AAAH sends an HAR message to AAAF which contains a MIP-
> Reg-Request AVP.
Continuing the example, suppose the AAAF has determined that the
HA is in a foreign network, and has forwarded the AMR to the home
realm.The AAAH receives the AMR, and the AMR indicates the HA's
address is 1.2.3.4, the Home-Agent-In-Foreign-Network flag is ON,
and the User-Name is "bob@donut.com".
-->(4) Now the AAAH wants to send an HAR to the HA.But Diameter
routes by Destination-Realm and Destination-Host, not by IP address,
so the AAAH has to somehow come up with the HA's DiameterIdentity
for the Destination-Host AVP of the HAR, and the HA's realm for the
Destination-Realm of the HAR.
AAAH's 1st Problem: How to discover the HA's DiameterIdentity:
If the AAAH maintains session-state, then this HA identity
information can be part of the cached session-state information,
and there may be no problem.But there is a problem if either
(a) the AAAH is not session-stateful, or (b) the AAAH is
session-stateful but has no session-state info because the handoff
AMR is received by a different AAAH than the AAAH which received
the original AMR for the session.
So if we have case (a) or (b), the hapless AAAH is holding the HA's
IP address, and needs to come up with the HA's realm and
DiameterIdentity.The method might be along these lines:
The AAAH can do a reverse lookup of the IP address 1.2.3.4, and
again DNS returns an FQDN of "homeagent86.westcoast.spinach.com"
*If* the DiameterIdentity is the same as the FQDN, then the AAAH
constructs the HAR's Destination-Host =
"homeagent86.westcoast.spinach.com". (An aside: I haven't kept up
with the recent DiameterIdentity thread, but I thought the
DiameterIdentity needed to be something like "FQDN+extra", so that
multiple Diameter applications could run on the same box.In
which case the FQDN isn't sufficient).
AAAH's 2nd Problem: How to discover the HA's Realm:
The AAAH still needs to derive the HAR's Destination-Realm, from
the FQDN.The realm is probably either "westcoast.spinach.com"
or "spinach.com".Does the AAAH have a way to know for sure, or
is the best-guess algorithm to say that the realm is what
follows the next-to-last dot of the FQDN, e.g. "spinach.com".
-->(5) Again, this may or may not be anywhere close to what the
AAAH needs to do to surmise the HA's realm and identity.At any
rate, the method should be described in sufficient detail to
implement an AAAH.
-->(6) If this DNS reverse lookup is indeed part of the AAAH's
method, then this introduces a delay (maybe a 2nd delay depending on
what the AAAF had to do) into the handoff, and should probably be
noted.
-->(7) It seems the AAAF and AAAH are both starting from scratch
with the HA's IP address, and duplicating efforts and delays. Maybe
the AAAF's DNS-lookup results (or whatever useful knowledge the AAAF
possesses) could be passed along to the AAAH.
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: March 5, 2002
Reference:
Document: NASREQ
Comment type: T
Priority: S
Section: 4.0
Rationale/Explanation of issue:
NASREQ has some corner conditions that have turned out to be a big
headache. These occur when the encapsulated EAP Message does not agree
with the Diameter message within which it is encapsulated. These problems
are inherited from RFC 2869.
NASREQ needs to make clear, as RFC 2865 does, that a NAS makes its
access decision based on the Diameter message alone (Accept or Reject),
*not* based on the contents of any enclosed attributes, including an
EAP-Message attribute. This makes sense, since the NAS acts as a
"passthrough" for EAP.
However, this makes for some interesting corner conditions, because
the following packets may be sent by the Diameter server:
a. Accept/EAP-Message/EAP-Failure
b. Reject/EAP-Message/EAP-Success
c. Accept/EAP-Message/Notification
d. Reject/EAP-Message/Notification
e. Accept (no EAP Message)
f. Reject (no EAP Message)
g. Accept/EAP-Message/EAP-Failure, Reply-Message
h. Accept/EAP-Message/EAP-Success, Reply-Message
i. Reject/EAP-Message/EAP-Failure, Reply-Message
j. Accept/EAP-Message/EAP-Success, Reply-Message
k. Challenge/EAP-Message/EAP-Success
l. Challenge/EAP-Message/EAP-Failure
There are probably more corner conditions than this, but my fingers are
getting tired :(
a. Message a is a problem because the Accept says "grant access" while the
Failure, if passed on to the EAP peer will make it think that
authentication has failed. If there are alternate indications of
success, one might argue that the peer will eventually figure it
out. For media in which there are no such indications (IEEE 802 and 802.11
are examples), a timeout will result.
b. Message b is a problem because the Reject says "no access" while the
EAP-Success passed to the peer makes it think it is successful.
If there are alternate indications of Failure on a given media, the peer
may eventually figure things out. On IEEE 802.11 a Disassociate from the
AP would put things right, as would an LCP-Terminate in PPP. On wired IEEE
802 there is no alternate indication of failure, so a timeout will result.
c-d. These are an issue since the peer receives a displayable
Notification, but no indication of Success/Failure. Alternate indications
might help, but for media in which they don't exist, a timeout will
result.
e-f. Ditto, except no notification.
g-j. These are a problem since it is not clear within NASREQ how a
Reply-Message is to be handled within an EAP conversation. Some NAS
implementations translate Reply-Mesage to an EAP-Notification, resulting
in the NAS having*two* EAP messages to send to the peer. Some NAS
implementations treat the Reply-Message as a terminal non-ACK'd message,
in which case the subsequent EAP-Message attributes are never sent. Which
interpretation is correct?
If you're in the "translate to Notification" camp, then presumably the
Notification has to be sent first, since the Success/Failure message
terminates the conversation and therefore nothing can be sent after
that. Note that the Reply-Message doesn't come with an Identifier field,
so presumably the NAS has to make one up. But since the Success/Failure
already has an Identifier field in it, what is the NAS/AP
supposed to do, particularly if the Identifier field is incremented
sequentially? The problems are obviously worse if the Reply-Message is
sent in the middle of the conversation, so that a simple Identifier swap
wouldn't work.
k-l. These are problematic because an Access-Challenge indicates a
continuing conversation, but an EAP-Success/EAP-Failure is a terminating
message. Therefore the Diameter Server will not receive a response to
these messages -- but the NAS will neither have granted nor rejected
access.
Proposed change:
Here are some possible ways to address the Reply-Message issue:
1. On the Reply-Message processing issue, we could suggest that the right
way to notify the EAP peer in an EAP conversation is to use
EAP-Notification instead of Reply-Message, and that Reply-Message is a
terminal message that is sent, and not translated to EAP-Motification.
2. Alternatively, we could specify that Reply Message is to be translated
to EAP-Notification by an EAP capable NAS (what about one which isn't EAP
capable?).
Here are some approaches to addressing the issue of a mismatch between the
RADIUS message (accept/reject) and the EAP-Message attribute:
1. "Dr., it hurts when I do this". This approach says: these corner
conditions are difficult to handle for media in which there are no
alternate failure/success indications, so that NASREQ should state
that Diameter servers SHOULD NOT (MUST NOT?) send these messages. Since an
Diameter server can be assumed not to send these messages, the NAS can
blithely decapsulate and send whatever is inside an
EAP-Message attribute, if one is present, then act on the Diameter message
(Accept/Reject). In this approach, NASREQ states that a
Challenge MUST NOT contain an EAP-Success/Failure message, and that
if a Reply-Message needs to be sent, then this should be encapsulated in
a packet with no EAP-Message attribute, adding an extra round-trip; the
Reply-Message is translated to EAP-Notification, and an
Access-Request/EAP-Message/Notification-Response is sent back to the
Diameter server, after which the EAP conversation continues.
2. "Mr. NAS will make it better". This approach says: the NAS should make
sure these corner conditions will not occur by "manufacturing" EAP
Success packets on receipt of an Access Accept, and "manufacturing" EAP
Failure packets on receipt of an Access Reject. This handles cases a-f,
but has some undesirable implications for cryptographically protected EAP.
In proposals to cryptographically protect EAP (such as EAP TTLS or PEAP),
it is desirable to have as much of the EAP conversation as possible be
protected. The idea of these protocols is to create an encrypted channel,
then complete the EAP conversation within that channel. That means that in
theory the final Success/Failure message is sent down the encrypted
channel.
Since EAP Success/Failure messages are not ACK'd, such a message, if sent,
must terminate the EAP conversation. This implies that they must be the
last message sent, and so if the NAS is to know the result of the
conversation, then they need to be sent within an Access Accept or Reject
message.
But if the "Mr. NAS will make it better" approach is taken, then the NAS
will swallow the encrypted Success/Failure packet and replace it with a
cleartext Success/Failure. This undermines the concept of protection,
which is to be able to authenticate and encrypt each packet in the EAP
conversation.
So it seems to me that, to address these issues in NASREQ, we
need to do one of two things:
1. If we adopt the "Dr., it hurts when I do this" approach, then we need
to suggest changes to the 802.1X state machine to conform to NASREQ. In
this approach, we would presumably leave the EAP
Success/Failure messages as they are in RFC 2284, forbid the bad messages,
and add some text on how Reply-Message attributes are to be processed
within an EAP conversation.
2. If we adopt the "Mr. NAS will make it better" approach, then we may
need to introduce new ACK'd Success and Failure messages within EAP. Doing
this will ensure a response to the success/failure indication, removing
the need for "alternative indications" and ensuring that the encrypted
Success/Failure indication gets through.
Submitter name: Bob Kopacz
Submitter email address:bkopacz@interlinknetworks.com
Date first submitted: 03-05-2002
Reference:
Document: draft-mobileip-09
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
The draft-mobileip-09 was updated per issue#266.Issue#266
addressed the case where the HA was in a foreign network, the
destination AAAF generated the FA-HA key, and the destination AAAF
wanted to use CMS to return the key to the FA in a secure manner.
Because the mobility agents may not support CMS (CMS is a SHOULD for
clients but a MUST for servers), the issue#266 solution was for the
destination AAAF (i.e. the HA's AAAF) to set up a DSA with the
originating AAAF (i.e. the FA's AAAF), and to pass the CMS-encrypted
FA-HA key to the originating AAAF within a CMS-Encrypted-Data AVP.
The key is thus hidden as it traverses the home domain and any
intermediary proxy/relay AAA servers.
Issue#266 was retricted to the case of CMS-securing the
AAAF-generated session key.There is a similar need to CMS-secure
the AAAH-generated session keys, if there are intervening proxy
networks between the home network and the mobility agent's network.
The proposal here is for an AAAH who wants to CMS-secure its
generated session keys, to set up a DSA with the mobility agent's
local AAAF, and to pass the CMS-secured keys to the AAAF a la
issue#266.
AAAH-generated keys destined for the FA: An AAAH-generated FA-MN key
(and maybe an AAAH-generated FA-HA key) is returned to the FA in the
AMA, which possibly traverses intermediary proxies.The AAAH can
CMS-secure these keys by setting up a DSA with the FA's local AAAF,
and passing the CMS-encrypted keys to the AAAF a la issue#266.The
AAAH knows the identity of the originating AAAF because this is
kindly provided in the AMR's MIP-Originating-Foreign-AAA AVP.
AAAH-generated keys destined for a foreign HA: The AAAH-generated
HA-MN key is forwarded in the HAR to the HA.If the HA resides in a
foreign network, the HAR may traverse intermediary proxies, and the
AAAH may want to CMS-secure this key.Unfortunately the AAAH
doesn't necessarily know who the destination AAAF is.The problem
here is that the AAAH wants to set up the DSA before forwarding the
HAR which carries the encrypted keys.In this case, I am currently
stuck and soliciting suggestions.(One goofy notion, whose only
virtue is that it works, is this: The AAAH sends a "half-baked" HAR
which doesn't contain the keys.The AAAF receives this half-baked
HAR, extracts the AAAH's identity from the half-baked HAR, sets up a
DSA with the AAAH, who resends a fully-baked HAR with the
CMS-encrypted keys.Unfortunately, this entails another round
trip.)
Requested change:
In section 5.0Key Distribution Center
> 5.0Key Distribution Center
>
> [...]
>
> 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 [CMS].
Change the first sentence to :
"If the AAAH does not communicate directly with one or both
mobility agents,..."
- - -
In section5.2Key Material vs. Session Key
> 5.2Key Material vs. Session Key
>
> [...]
>
> The session keys destined for mobility agents may be encoded using
> the security association available between the AAA server and the
> agents (e.g. IPSec, TLS, CMS).
Change the above sentence to:
"The session keys destined for mobility agents may be encoded using
the security association available between the AAA server and the
agents (e.g. IPSec, TLS, CMS), or, if the AAAH suspects a foreign
mobility agent doesn't support CMS, by using the security
association available between the AAAH and the AAA server hosting
the mobility agent."
- - -
In section 5.3Distributing the Mobile-Home Session Key
> 5.3Distributing the Mobile-Home Session Key
>
[Need some text here to address the case where the HA is in a foreign
network, the HA doesn't support CMS, and the AAAH wants to set up a
DSA with the destination AAAF, and pass the CMS-encrypted HA-MN key
to the destination AAAF.]
- - -
In section 5.4Distributing the Mobile-Foreign Session Key
> 5.4Distributing the Mobile-Foreign Session Key
>
> The Mobile-Foreign session key material is also generated by AAAH
> (upon request) and is added to the 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 [MIPKEYS] 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. The AAAH includes the
> session key in the MIP-FA-to-MN-Key AVP in the HAA, which contains
> the session key used by the foreign agent in the computation of the
> Mobile-Foreign authentication extension.
>
> 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 (home agent in
> foreign domain), 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.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.
Append the following paragraph:
"If the AAAH is returning an FA-HA or FA-MN key to the FA, and the
AAAH wants to secure these keys because the originating AAAF is not
a peer (there are intermediate proxies), the AAAH first sets up a
DSA with the originating AAAF, and passes the FA's key(s) within a
CMS-Encrypted-Data AVP in the AMA."
From: Tony Johansson <tony.johansson@ericsson.com>
To: aaa-wg <aaa-wg@merit.edu>
Cc: Bob Kopacz <BKopacz@InterlinkNetworks.com>, Fredrik Johansson
<fredrik.johansson@ipunplugged.com>,
Johan Johansson <johanj@ipunplugged.com>, David Spence
<DSpence@InterlinkNetworks.com>,
Pat R. Calhoun <pcalhoun@bstormnetworks.com>
Subject: [AAA-WG]: Issue #299 and #301
All,
During, the AAA working group meeting at IETF53 I presented the issues #299 and
#301 and two alternative ways in which we could workout a solution to the open
issues - see below:
Alt1: Clarifications / new requirements without any new dependencies to MIP.
------------------------------------------------------------------------------
AAAH
- Require that each subdomain of a realm is authorized/authenticated by exactly
one AAAH. So while a home network may have multiple AAAH's, each subdomain will
have exactly one AAAH.
- Or, require that, if the home realm has multiple AAA servers to which the same
user can be routed to, then there MUST be a synchronization
mechanism between the AAAH servers. However, the specific synchronization
mechanism is beyond the scope of this spec.
AAAF
- How to map HA IP address to HA FQDN is still open. Reverse DNS look up is not
at all a straightforward solution for this
Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft.
-----------------------------------------------------------------------------
AAAH
- Require that the MN support the GNAIE draft, updated to include the definition
of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI
would be included to guarantee that a registered user always ends up in the same
initial AAAH.
AAAF
- The mapping of the HA IP address and HA FQDN, Host and realm would be
automatically solved, since this would be included in the MIP RegReq as well.
There was a very clear and strong consensus that alternative 2 would be by far
the best solution. However, this means more work and dependencies
to the MIP working group and the goal is set to have the Diameter MIPv4 appl.
draft in working group last call by the April 2nd. Looking at the
GNAIE draft, I done see that much work needs to be done to make it fulfill our
needs, so to me it could easily be done in time, but the big
question is how quickly could it be pushed through the MIP working group and go
to last call? I have sent the question MIP wg and I hope to soon get answer
back.
Regards,
Tony
Submitter name: Bob Kopacz
Submitter email address:bkopacz@interlinknetworks.com
Date first submitted: 03-05-2002
Reference:
Document: all drafts
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
1. There are often conflicts between the message ABNF and the
[redundant] information in the occurrence rules tables.Combining
the message ABNF with the occurrence rules would create one location
for the message AVP occurrence information, and eliminate the
redundancies and neverending conflicts.
2. The current ABNF is a little tricky, in that the default number
of occurrences depends on the type of braces around the AVPs.So
replace the <nulls> and the *'s with the explicit counts as in the
occurrence rules, e.g. 0, 0+, 0-1, etc.Then we don't need both the
{}braces and the []braces, as the numeric counts indicate required
versus optional.
For example, the current ABNF for the AA-Mobile-Node-Request is:
> <AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY >
>< Session-Id >
>{ Auth-Application-Id }
>{ User-Name }
>{ Destination-Realm }
>{ Origin-Host }
>{ Origin-Realm }
>{ MIP-Reg-Request }
>{ MIP-MN-AAA-Auth }
>[ Destination-Host ]
>[ Origin-State-Id ]
>[ MIP-Mobile-Node-Address ]
>[ MIP-Home-Agent-Address ]
>[ MIP-Feature-Vector ]
>[ MIP-Originating-Foreign-AAA ]
>[ Authorization-Lifetime ]
>[ Auth-Grace-Period ]
>[ Auth-Session-State ]
>[ MIP-FA-Challenge ]
>[ MIP-Candidate-Home-Agent-Host ]
>* [ AVP ]
>* [ Proxy-Info ]
>* [ Route-Record ]
The occurrence rule tables could be absorbed into the message ABNF
(and eliminated), with a message ABNF that looks like:
> <AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY >
>1 < Session-Id >
>1 [ Auth-Application-Id ]
>1 [ Destination-Realm ]
>1 [ MIP-Reg-Request ]
>1 [ MIP-MN-AAA-Auth ]
>1 [ Origin-Host ]
>1 [ Origin-Realm ]
>1 [ User-Name ]
>0-1 [ Authorization-Lifetime ]
>0-1 [ Auth-Grace-Period ]
>0-1 [ Auth-Session-State ]
>0-1 [ Accounting-Multi-Session-Id ]
>0-1 [ Destination-Host ]
>0-1 [ MIP-Candidate-Home-Agent-Host ]
>0-1 [ MIP-Originating-Foreign-AAA ]
>0-1 [ MIP-FA-Challenge ]
>0-1 [ MIP-Feature-Vector ]
>0-1 [ MIP-Home-Agent-Address ]
>0-1 [ MIP-Mobile-Node-Address ]
>0-1 [ Original-State-Id ]
>0+[ Proxy-Info ]
>0+[ Route-Record ]
>0 [ Acct-Application-Id ]
>0 [ Error-Message ]
>0 [ Error-Reporting-Host ]
>0 [ MIP-FA-to-HA-Key ]
>0 [ MIP-FA-to-HA-SPI ]
>0 [ MIP-FA-to-MN-Key ]
>0 [ MIP-FA-to-MN-SPI ]
>0 [ MIP-Filter-Rule ]
>0 [ MIP-Foreign-Agent-Host ]
>0 [ MIP-HA-to-FA-Key ]
>0 [ MIP-HA-to-MN-Key ]
>0 [ MIP-Key-Lifetime ]
>0 [ MIP-MN-to-FA-Key ]
>0 [ MIP-MN-to-HA-Key ]
>0 [ MIP-Reg-Reply ]
>0 [ Redirect-Host ]
>0 [ Redirect-Host-Usage ]
>0 [ Redirect-Max-Cache-Time ]
>0 [ Result-Code ]
>0 [ Re-Auth-Request-Type ]
>0 [ Session-Timeout ]
>0+[ AVP ]
3. This is not a significant change to the drafts.
Requested Change:
Do this in all the Diameter drafts.
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 6, 2002
Reference:
Document: Base
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
While I haven't studied studied base-10 in great detail yet, I
believe there are still significant security issues with peer-to-peer
connections that need to be addressed.
Two of the models for using Diameter that I'm not particularly
thrilled with and admittedly haven't devoted a whole lot of thought
to in the past are the peer discovery and redirect models.
Nevertheless, it is extremely important that if we include these
models in Diameter, we need to make them work.The thing that both
of these models share is that peer-to-peer connections are created
dynamically.This raises two problems.The first is, what makes the
connection originator feel comfy about seeking to establish the
connection?The second is, what makes the connection recipient feel
comfy about accepting the connection?
Consider the redirect model.If Bob@donut.com dials in to
wondernet.net, the wondernet AAA server, aaaf.wondernet.net, sends an
authentication/ authorization request to his redirect agent,
aaa.omniscient.com.Aaa.omniscient.com redirects him to
aaah.donut.com.Aaaf.wondernet.net is comfy because he trusts
aaa.omniscient.com.Aaah.donut.com receives a CER from
aaaf.wondernet.net.Perhaps aaa.omniscient.com trusts
aaah.donut.com, too.But that doesn't help him because the CER has
nothing in it even claiming that the connection is being created
because of a redirect from aaa.omniscient.com, let alone proving it.
-->(1)A major weakness with the redirect model is that the recipient
does not even know who made the referral.
Now consider the server discovery model. Bob@donut.com dials in to
wondernet.net, and the wondernet AAA server, aaaf.wondernet.net, does
a DNS lookup to discover that the AAA server for donut.com is
aaah.donut.com.What good does that do aaaf.wondernet.net?How does
aaaf.wondernet.net even know whether wondernet and donut have a
business relationship?If they do have a business relationship, then
why is it so hard to configure aaah.donut.com into
aaaf.wondernet.net's peer table?So what good is peer discovery?
-->(2)A problem with peer discovery is that a server doing it must
have an independent means of knowing what realms it may make
peer connections to.
Assuming aaaf.wondernet.net does have enough configuration
information to feel comfy establishing a peer-to-peer connection with
aaah.donut.com, we still have the same problem with had with the
redirect model: How does aaah.donut.com know it's o.k. to receive a
connection from aaaf.wondernet.net?
In either model, if a Diameter server receives a CER from a Diameter
node that is not hard configured into its peer table, then we need to
ensure that some form of peer-to-peer security is in place.It
cannot assume that such a connection is IPsec protected.So it must
insist on TLS.But this is nowhere stated.
-->(3)A Diameter node receiving a CER request from another Diameter
node that is not hard configured into its peer table MUST
reject the CER if it does not arrive on a TLS-secured transport
connection.
Some may assume that the successful establishment of a TLS connection
provides sufficient warm fuzzies to both parties to the connection
for them to want to bring up a peer-to-peer link and transfer
Diameter messages over it.I am not convinced that that is a
reasonable assumption except perhaps in some very constrained cases.
These constraints need to be fully described in the security
considerations section.
-->(4)The limitations in the use of TLS to establish trust need to be
understood and clearly stated.
Requested change:
I think the usefulness of the redirect and server discovery models
ought to be reexamined in light of the security problems they
introduce.It may be that removing redirect and server discovery
from Diameter is the best solution.
If the working group believes that redirect and server discovery are
really needed and still useful when constrained to operate securely,
then their use needs to the subject of a genuine security analysis.
These capabilities are not present in RADIUS and they greatly
complicate peer-to-peer security.In RADIUS a node will only
exchange messages with other nodes with which it is configured to
communicate.If Diameter introduces dynamic peer-to-peer
connections, a new trust model must be created or else the entire AAA
infrastructure is at risk.
Submitter name: Ghadiyaram Venkata, David Spence
Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com,
DSpence@Interlinknetworks.com
Date first submitted: March 6, 2002
Reference:
Document: Base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue
A CER received from a previously unknown peer (such as would happen as a
result of peer discovery or a redirect) does not contain complete
information as to how the recipient could recreate the peer connection if it
is lost.
Requested change:
Add the following text:
"If a CER from and unknown peer is answered with a successful CEA, the
lifetime of the peer entry is equal to the lifetime of the transport
connection. In case of a transport failure, all the pending transactions
destined to the unknown peer can be discarded."
Submitter email address: johanj@ipunplugged.com
Date first submitted: March 10, 2002
Reference:
Document: Mip
Comment type: T
Priority: 2
Section: 4.8 + ABNFs and occurence rules
Rationale/Explanation of issue
The MIP-Foreign-Agent-Host avp is mandatory in both the HAR and the HAA.
The only text covering this avp is
The MIP-Foreign-Agent-Host AVP (AVP Code 330) is of type
DiameterIdentity and contains the identity of the foreign agent. This
AVP is copied from the value of the Origin-Host AVP in the AMR.
If we start with its presence in the HAA, this can't possibly serve any
purpose since the AAAH already knows the identity of the FA. It was
after all the one who sent it to the HA in the first place.
But why would the HA want it at all and badly enough for it to be
mandatory in the HAR at that? The avp is of type DiameterIdentity which
is a strong indication that it is for the consumption of a Diameter
entity and not a mobile ip entity. If the mobile node is supposed to
carry this information for some reason there is ample opportunity for
the FA to provide it directly to the mobile node.
The avp is not present in accounting messages.
I am quite ignorant about CMS, but it seems unlikely that the HA could
have a conceivable need to establish a DSA with the FA.
The avp must come from somewhere though since it must have been actively
introduced. Can someone please shed some light on why it was defined?
Requested change:
Explain the avp's use or remove it.
j
Submitter name: Johan Johansson
Submitter email address: johanj@ipunplugged.com
Date first submitted: March 11, 2002
Reference:
Document: Mobile IP
Comment type: T
Priority: 1
Section: 2.2, 2.3, 5.1, 8.1
Rationale/Explanation of issue:
If there is to be any hope for interoperability the use of
Session-Timeout must be defined in the MIP draft.
The base draft defines Session-Timeout as
8.13 Session-Timeout AVP
The Session-Timeout AVP (AVP Code 27) [RADIUS] is of type Unsigned32
and contains the maximum number of seconds of service to be provided
to the user before termination of the session. When both the Session-
Timeout and the Authorization-Lifetime AVPs are present in an answer
message, the former MUST be equal to or greater than the value of the
latter.
---
A Session-Timeout AVP MAY be present in a re-authorization message,
and contains the number of seconds from the beginning of the re-auth.
A value of zero, or the absence of this AVP, means that this session
has an unlimited number of seconds before termination.
Section 8.9 of the base draft has this to say about Authorization-Lifetime:
An Authorization-Lifetime AVP MAY be present in re-authorization
messages, and contains the number of seconds the user is authorized
to receive service from the time the re-auth answer message is
received by the access device.
The MIP draft contains no references to Session-Timeout beyond the
occurence rules and the ABNFs and they are contradictory.
The occurence rules of the MIP draft states
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
Session-Timeout | 0 | 1 | 1 | 0 |
The ABNFs for AMA and HAR list it as optional. Looking solely at the
base draft the ABNF would seem to be correct.
But this still does not settle the issue of the semantics of its
presence. Section 5.1 of the mip draft states
The Diameter Mobile IP application makes use of two timers - the
Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP.
The Authorization-Lifetime contains the number of seconds before the
Mobile Node must issue a subsequent MIP registration request. The
content of the Authorization-Lifetime AVP corresponds to the Lifetime
field in the MIP header [MOBILEIP].
The MIP-Key-Lifetime AVP contains the number of seconds before
session keys destined for the Mobility Agents and the Mobile Node
expire. A value of zero indicates infinity (no timeout). If not zero,
the value of the MIP-Key-Lifetime AVP MUST be at least equal to the
value in the Authorization Lifetime AVP.
or mandatory but banned. The section quoted above inevitably leads to
the the termination of the user session after at least
Authorization-Lifetime seconds and at most Authorization-Lifetime +
MIP-Key-Lifetime seconds.
Requested change:
Remove Session-Timeout from AMA and HAR.
Modify the first paragraph of section 5.1 to:
The Diameter Mobile IP application makes use of two timers - the
Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. The
Session-Timeout AVP [DIAMBASE] does not apply to this application.
Submitter name: Don Zick
Submitter email address: dzick@interlinknetworks.com
Date first submitted: March 11, 2002
Reference:
Document: cms
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue
A diameter agent may establish security associations on behalf of access
devices. The access devices issue the PDSR message to request this. It
is simpler for the access devices if they do not have to re-issue the
PDSR because of DSA-TTL expiry. Also, the diameter agent may make use of
the same DSA for more than one access device; in this case it doesn't
make much sense for multiple access devices to be responsible for
re-establishing the same DSA.
Requested change:
Replace text from section 1.3:
The PDSA MUST
contain the TTL setting agreed by the proxy agent for its DSA.
This information will allow the access device to re-issue a PDSR
prior to the proxy's DSA expiry if it needs the DSA to remain
active.
with this text:
The proxy agent is responsible for re-establishing the DSA
prior to expiration without any involvement by the access
device.
Also, remove DSA-TTL from PDSA ABNF definition.
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 2001-3-18
Reference:
Document: nasreq-09
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:
The Diameter NASREQ application currently does not support the
RADIUS Originating-Line-Info AVP, attribute #94. Below is information
provided by Nenad Trifunovic relating to the definition of that AVP.
1.0 Introduction
Signaling System 7 (SS7) network is used in Public Switched Telephone
Network (PSTN) for call management. SS7 messages carry a number of
information elements related to a particular circuit switched call.
The originating line information (OLI) information element indicates
the nature and/or characteristics of the line from which a call
originated (e.g. payphone, hotel, cellular). Telephone companies are
starting to offer OLI to their customers as an option over Primary
Rate Interface (PRI). Internet Service Providers (ISPs) can use OLI in
addition to Called-Station-Id and Calling-Station-Id attributes to
differentiate customer calls and define different services.
2.0 Originating-Line-Info Attribute
A summary of the Originating-Line-Info attribute format is shown
below. The fields are transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
94 for Originating-Line-Info.
Length
4
The Value field is two octets (00-99). ANSI T1.113 and
BELLCORE 394 can be used for additional information about
those values and their use.
this is my private copy for those values (i don't know how well
it matches ANSI T1.113 or BELLCORE 394 since i only found references
to them).
00 Plain Old Telephone Service (POTS) - non-coi service
requiring no special treatment with ANI identified.
01 Multiparty Line (more than 2) or Operator Number
Identification (ONI)
02 ANI Failure
03 ANI Observed
04 ONI Observed
05 ANI Failure Observed
06 Hotel/Motel without room identification
07 Coinless, Hospital, Inmate, etc.
08 InterLATA Restricted
09 Unassigned
10 Test Call
11 Unassigned
12-19 Not assignable - conflict with international outpulsing code
20 Automatic Identified Outward Dialing (AIOD)
21-22 Unassigned
23 Coin or non-coin (identified line) Line Status Unknown
24 800 Service Call
25-26 Unassigned
27 Coin
28 Unassigned
29 Prison/Inmate Service
30-32 Intercept.
30 Intercept (blank) - for calls to unassigned DN
31 Intercept (trouble) - for calls to DNs that have been
manually placed in trouble-busy state by Telco Personnel
32 Intercept (regular) - for calls to recently changed or
disconnect numbers
33 Unassigned
34 Telco Operator Handled Call
35-39 Unassigned
40-49 Unrestricted Use - locally determined by carrier
50-51 Unassigned
52 Outward Wide Area Telecommunications Service (OUTWATS)
53-59 Unassigned
60 Telecommunications Relay Service (TRS)
61 Cellular Service (Type 1)
62 Cellular Service (Type 2)
63 Cellular Service (Roaming)
64-65 Unassigned
66 Telecommunications Relay Services (TRS)
67 Telecommunications Relay Services (TRS)
68 InterLATA Restricted - Hotel Line
69 Unassigned
70 Private Pay-stations
71-77 Unassigned
78 InterLATA Restricted - Coinless Line, etc.
79 Unassigned
80-89 Reserved for Future Expansion
93 Access for private virtual network types of service
94 Unassigned
95 Test Call
96-99 Unassigned
---------- Forwarded message ----------
Date: Thu, 14 Mar 2002 09:25 -0800 (PST)
From: Nenad Trifunovic <nenad.trifunovic@wcom.com>
To: Bernard Aboba <aboba@internaut.com>
Subject: Re: Spec for the Originating-Line-Info AVP
Hello,
After some inquiry I got this pointer:
http://www.nanpa.com/number_resource_info/ani_ii_assignments.html.
so, people can synchronize to these secret numbers (although winning
lotto numbers seem to be much more in demand :-) ).
regards,
nenad
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: February 25, 2002
Reference:
Document: NASREQ
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
In NASREQ-08, AVP Code 409 is assigned to two different AVPs:
CHAP-Auth
NAS-Key-Lifetime
AVP Code 410 is also assigned to two different AVPs:
CHAP-Ident
NAS-IV
Requested change:
I have assigned a new AVP Code to NAS-Key-Lifetime: 413
I have assigned a new AVP Code to NAS-IV: 414
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: 2/22/02
Reference: http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00147.html
Document: base, cms-sec
Comment type: T
Priority: 1
Section: base sec. 4.6, cms-sec sec. 6.0
Rationale/Explanation of issue:
Several AVPs listed in the table in sec. 4.6 of the base draft do not
include all three flags in the AVP Flag rules columns. This leads to
ambiguities. For example, how should I set the 'M' flag in the
Error-Message AVP? 'M' is not listed in the MAY column so I guess I
can't set it, but then 'M' is not listed in the MUST NOT column so
perhaps I can set it.
In the AVP Flag rules table in sec. 6.0 of the cms-sec draft, in the
DSA-TTL row, the 'P' flag is listed twice. It appears in both the
MAY and MUST NOT columns.
Requested change:
The following rows in the table in sec. 4.6 of the base draft need to
be fixed:
Error-Message
Error-Reporting-Host
Product-Name
Redirect-Host
The following row in the table in sec 6.0 of the cms-sec draft needs
to be fixed:
DSA-TTL
Submitter name: Tony Johansson (originally Lollo Tonnesson)
Submitter email address: tony.johannson@ericsson.com
Date first submitted: March 13, 2002
Reference:
Document: Base
Comment type: E
Priority: 1
Section: 9.7.1 Accounting-Request
Rationale/Explanation of issue
Lollo Toennesson (QPK) wrote:
The usage of Acct-Application-Id and
Vendor-Specific-Application-Id for vendor specific
accounting application is unclear.
I'd like to specify a vendor specific accounting application
by using ACR and ACA commands in the Diameter Base Protocol
and add on some optional service specific AVPs.
are using a vendor specific accounting application? Should
Acct-Application-Id and/or Vendor-Specific-Application-Id be used?
1) Alternative 1:
<ACR> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{ Acct-Application-Id }
{ Origin-Host }
.......
Question: What Acct-Application-Id should be used?
2) Alternative 2:
<ACR> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{ Acct-Application-Id }
{ Vendor-Specific-Application-Id }
{ Origin-Host }
.......
Question: What Acct-Application-Id should be used?
3) Alternative 3:
<ACR> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{ Vendor-Specific-Application-Id }
{ Origin-Host }
.......
Question: Acct-Application-Id is defined as mandatory for ACR.
Is it appropriate to replace the mandatory
Acct-Application-Id with Vendor-Specific-Application-Id.
This is not explicitly stated anywhere in the draft (09).
According to 09 draft of the Diameter Base Protocol:
* 6.10 Vendor-Specific-Application-Id
AVP Format
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
1* [ Vendor-Id ]
0*1{ Auth-Application-Id }
0*1{ Acct-Application-Id }
The vendor-Id is assigned by IANA.
The Acct-Application-Id is defined by the vendor (private use).
*Is chapter 1.2.4, 2.4 applicable for vendor specific
accounting applications, i.e. that an Acct-Application-Id
should be assigned by IANA?
* According to e.g. chapter 6.10 in the base protocol, the
Vendor-Specific-Application-Id AVP should be used for advertise
support for vendor specific diameter applications, but this AVP
is not mentioned in the ACR or ACA, only for CER and CEA (table in 10.1, 10.2)
The only application Id AVP required for ACR and ACA are the
Acct-Application-Id.
??: Implication: During capability exchange (CER/CEA) you advertise
support for the vendor specific application but the vendor
specific application id is not included in the ACR/ACA commands.
Can this really be correct?
??: Should both the Acct-Application-Id and
Vendor-Specific-Application-Id be part of CER/CEA?
* Acct-Application-Id AVP is mandatory in ACR and ACA (9.7.1, 9.7.2, 10.2)
Best regards Lollo
Requested change:
Change the ABNF in 9.7.1 Accounting-Request
from:
<ACR> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{...}
{ Acct-Application-Id }
[...]
To:
<ACR> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{ ... }
[ Acct-Application-Id ]
[ ... ]
Since you may run only the base protocol, your own vendor specifc application
and no relay agent
support. In such a case your ACR messages will only include the
Vendor-Specific-Application-Id and
no Acct-Application-Id.
spec about when a new Acct-Application-Id is needed.
Accounting is somewhat different from Authentication in that in many cases
the accounting server only writes the AVPs to disk, and therefore doesn't
need to understand them. As a result, one can send vendor-specific AVPs to
an accounting server without the server needing to "support" them. Thus,
section 1.2.4 was written to try to discourage gratuitous use of new
Acct-Application-Ids:
1.2.4 Creating New Accounting Applications
There are services that only require the use of Diameter accounting.
Since such services need to define the service specific AVPs that
must be carried in the Accounting-Request/Answer messages, but do not
need to define command codes, the rules on allocation of Accounting
Application Identifiers is different from the ones defined in section
2.3.3.
When possible, a new Diameter accounting application SHOULD attempt
to re-use any existing Diameter AVP, in order to reduce the
possibility of having multiple AVPs that carry similar information.
Every Diameter accounting application specification MUST have an IANA
assigned Application Identifier (see section 2.4).
------------------------------------------
Note that section 1.2.4 says that rules on allocation of Accounting
Applications Identifiers [sic] is different, but doesn't say *how* it is
different. My understanding is that it is different because there is even
less reason to create a new Acct-Application-Id than a new Auth
Application. Thus, it would seem that adding Vendor-Specific AVPs may not
be a good enough reason to create a new Acct-Application-Id. To resolve
this issue, I think we need to specify when new Accounting Applications
are created in more detail.
Here is what section 2.3.3. says about Authentication Applications:
2.3.3 Creating New Auth Applications
Should a new application require Diameter support, but it cannot fit
within an existing application without requiring major changes to the
specification, it may be desirable to create a new Diameter
application. Major changes to an application include:
- Requiring a whole different set of mandatory AVPs to a command
- Requiring a command that has a different number of round trips
to satisfy a request (e.g. application foo has a command that
requires one round trip, but new application bar has a command
that requires two round trips to complete).
- The method used to authenticate the user is drastically
different from any existing application, and the authentication
information cannot be carried within the AVPs defined in the
application.
Note that the creation of a new application should be viewed as a
last resort.
New Diameter applications MUST define at least one Command Code, the
expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY
also define new AVPs. If the Diameter application has any accounting
requirements, it MUST also specify the AVPs that are to be present in
the Diameter Accounting messages (see section 9.3).
When possible, a new Diameter application SHOULD attempt to re-use
any existing Diameter AVP, in order to reduce the possibility of
having multiple AVPs that carry similar information.
Application Identifier (see section 2.4).
From: Jari Arkko <jari.arkko@kolumbus.fi>
To: john.loughney@nokia.com
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Issue 311:Acct-Application-Id and
Vendor-Specific-Application-Id in ACR
I have a somewhat modified proposal. Removing the acct-application-id
is a nice idea, but unfortunately it runs into trouble with the capability
discovery process and in particular with the contents of section 6.1. So,
I'm proposing we keep the acct application ids, but allow for vendor specific
values as well. This allows also at the same time that the accounting servers
will be able to know the application type immediately, without trying to infer
it from the AVPs.
My proposed solution contains the following changes:
1) Section 2.3.3 should be renumbered in base to 1.3.3. (!)
2) References to section 2.5 throughout the base are wrong, and should
probably point to 2.4
3) 2.5 Connections vs. Sessions is missing from the contents table.
(It seems like going through the whole contents table as well
as all references would make sense.)
4) Relay app id (0xffffffff) can be used also by "dumb" file writing accounting
servers. Add text to just before "while" in 2.4: ", accounting servers capable
of storing any records MUST advertise the Relay Application Identifier for
accounting".
5) Modify ANF for ACR as follows:
<ACR> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{ ... }
[ Acct-Application-Id ]
[ Vendor-Specific-Application-Id ]
[ ... ]
And add text: "One of Acct-Application-Id and Vendor-Specific-Application-Id
AVPs
MUST be present. If the Vendor-Specific-Application-Id grouped AVP is present,
it must have an Acct-Application-Id inside."
6) Similar modifications for ACA.
7) Don't touch 2.3.3 (i.e. 1.2.3), it is for authentication only.
8) Add replace the text in 1.2.4 with
Services that have an Application Identifier MUST use the same identifier
also to identify the service when Diameter accounting is used.
There are services that only require the use of Diameter accounting.
Such services need to define the service specific AVPs that must be
carried in the Accounting-Request/Answer messages, but do not need to
define command codes. Application Identifiers are, however, still required
for accounting due to the Diameter capability discovery process.
Every accounting application MUST have either an IANA allocated Application
Identifier, or a vendor specific Application Identifier.
When possible, a new Diameter accounting application SHOULD attempt
to re-use any existing Diameter AVP, in order to reduce the
possibility of having multiple AVPs that carry similar information.
9) Modify AVP occurrence tables appropriately.
10) 6.1.1 add Vendor-Specific-Application-Id to the list in the last bullet.
11) Add a new paragraph after the first paragraph of 11.3: "Both Application-Id
and Acct-Application-Id AVPs use the same Application Identifier space."
12) Also add to 11 that not just zero but also 0xffffffff are reserved values.
Submitter name: Don Zick
Submitter email address: dzick@interlinknetworks.com
Date first submitted: March 11, 2002
Reference:
Document: cms
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue
A single occurrence of the AAA-Node-Cert AVP should be required in the
DSAR and the DSAA.
The Diameter CMS Security draft states (in section 3):
In order to encrypt AVPs for a recipient, the originating Diameter
node must have a copy of the recipient's public key. There are many
well-known key retrieval schemes (e.g. LDAP [CERTLDAP]), but this
specification also allows for the transportation of certificates
within Diameter AVPs, which is expected to simplify implementations.
If inclusion of the AAA-Node-Cert AVP is optional then the expected
simplification in implementations is lost because compliant
implementations must be able to handle DSAR and DSAA messages that don't
include the AAA-Node-Cert AVPs.
Please update the occurrence rules table and the ABNF definitions for
the DSAR and DSAA to indicate that exactly 1 occurrence of the
AAA-Node-Cert must be present.
Submitter name: Stephen Farrell
Submitter email address: stephen.farrell@baltimore.ie
Date first submitted: March 14, 2002
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03431.html
Document: CMS
Comment type: T/E
Priority: 1
Section: various
Rationale/Explanation of issue:
>
> Hi Stephen,
>
> Before I go hog-wild submitting any more issues could you please address
> the following questions concerning the Diameter CMS Security draft?
>
> 1. In section 3.1, it states:
>
> 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, as well
> as
> which public key(s) to use.
>
> Now that the expected-signed and expected-encrypted AVPs have been
> removed, shouldn't the text "which specifies which AVPs should be
> encrypted, signed or both" be removed?
Yes. Will do.
>
> 2. The AVP occurrence rules table in section 8 shows that at most 1
> AAA-Node-Cert AVP may appear in a DSAR or a DSAA. However, the
> ABNF definition for the DSAR and DSAA indicate that any number
> of AAA-Node-Cert AVPs may appear. Is the AVP occurrene rules
> table correct? If so, shouldn't "public key(s)" mentioned in
> item 1 really be "public key"?
We do want to allow >1 certificate to be included (we're just
insisting they all be verifiable from a single CA-Chain).
text and abnf alone.
> 3. In section 3.1, it states:
>
> - Its local policy allows the given TTL, realm, AVP protection
> expectations, certification status, and other parameters.
>
> Now that the expected-signed and expected-encrypted AVPs have been
> removed, shouldn't the text "AVP protection expectations" be removed?
Yes.
> 4. In section 3.1 it states:
>
> ...the destination node returns the DSAA message which contains:
> ...
> - public key certificates for the Diameter servers in the
> realm...
>
> This goes back to question #2. Must a Diameter server know all of
> the certificates for all servers in its realm? Why is that useful
> when the Diameter node is only establishing a DSA with a single
> server?
Fixed with #2.
> 5. In section 3.1 it states:
>
> The DSAA MUST include the CMS-Signed-Data, signed by a Diameter
> agent
> or server within the user's realm, to prevent an intermediate node
> from modifying the protection expectations for AVPs.
>
> Shouldn't this requirement be removed now that expected-signed and
> expected-encrypted AVPs have been removed?
Hmm...That's a reasonable point, but I'd (somewhat less than entirely
convincingly) argue to stick with the DSAA MUST be signed position for
the following reasons:
- A node producing a DSAA really has to have a private key for anything
useful to subsequently happen, therefore requiring the signature
doesn't require any additional code or administration, just the few
additional CPU cycles required for signing this message.
- The signed AVPs from the DSAA (in particular the DSA-TTL) can't be
modified by intermediaies, though that's not much of a threat
compared to modifying expected-* AVPs, I agree.
- It provides some assurance that the originator of the message is
the entity that (the CA said) has the relevant private key. However,
for this to be better, a random challenge should be added to
the DSAR and (that or a digest of the DSAR) reflected back in
the DSAA as a signed AVP (I was thinking of proposing this as
an addition to -04 but didn't).
> 6. In section 3.2 it states:
>
> For multiple Diameter servers within a realm that share a public
> key,
> each server's identity is encoded in the subjectAltName extension.
> This allows any server within a realm to decrypt AVPs intended for
> that realm.
>
> Why would a server that is not part of the DSA ever decrypt AVPs?
Various forms of load-balancing I guess.
> Wouldn't there be potential problems with content encryption key
> reuse?
Yes. As with reboots, so nothing new there.
> 7. In section 4.4, the PDSR is defined. When an access device sends
> a PDSR to a local proxy, the local proxy will establish a DSA with
> a server in the DSAR-Target-Realm. If the access device sends an
> authentication request to the local proxy and the authentication
> request contains Destination-Realm but does not contain
> Destination-Host, must the local proxy add the Destination-Host
> AVP to the message to ensure that it is routed to the server in
> the Destination-Realm that has the DSA? If this is a requirement
> I think it should be stated explicitly.
I guess we do need more text here and will add that. I guess I
should change "authentication request" to "any Diameter message" in
the above though?
> signed AVPs. The examples indicate that different Diameter
> nodes can have different encryption and signing requirements.
> Aren't these examples misleading now that the expected-signed
> and expected-encrypted AVPs have been removed? (All Diameter
> nodes share the same encryption and signing requirements.)
The examples are based on requirements on AVPs which can be determined
from the RFC or by an astrologer. So I disagree that this is related
to the expected-* removal.
> 9. The AVP occurrence rules table and ABNF message definitions
> have some inconsistencies:
>
> DSAR ABNF DSAR Occurrence rules table
> AAA-Node-Cert * 0-1
Was the above meant to be in your mail?
> DSAA ABNF DSAA Occurrence rules table
> AAA-Node-Cert * 0-1
should be 0+
> OCSP-Responses * 1+
should be 0+
> Origin-Realm 0*1 1
> Redirect-Host not listed 0+
> Redirect-Host-Usage not listed 0-1
> Redirect-Max-
> Cache-Time not listed 0-1
I don't know what's right for these. Want to suggest
something?
> think square brackets are correct.
Disagree. Doesn't *{foo} mean "one or more", whereas *[foo] means
"zero or more". One or more is what's wanted.
>
> 11.Origin-State-Id listed as Original-State-Id in AVP occurrence table.
I'm guessing that Origin-State-Id is the right name?
> 12.Section 3.1 states:
>
> Once the DSA is in place, any Diameter messages created by a DSA
> peer
> that has a private key MUST contain a signature over all AVPs whose
>
> definition states that their 'P' bit MAY be set.
>
> I think the CMS-Encrypted-Data AVP is an exception to this rule. It
> only requires a signature if any of the encrypted AVPs contained in
> the CMS-Encrypted-Data AVP require signing.
Good point. I'll add text indicating this.
>
> Section 1: "two different set of messages"
> "two different sets of messages"
>
> Section 1.2 "DSA would the NAS"
> "DSA would be the NAS"
>
> "initiate an DSAR"
> "initiate a DSAR"
>
> Section 1.3 "such an an aggregating relay"
> "such as an aggregating relay"
>
> "recelived"
> "received"
>
> Section 3.1 "MUST re-validated"
> "MUST be re-validated"
>
> "implemetors"
> "implementors"
>
> Section 5 "CAA" (in diagram)
> "CEA"
>
> "issues an DSAR message"
> "issues a DSAR message"
>
> Section 6.11 "lenght"
> "length"
>
Thanks,
Stephen.
Submitter name: Bob Kopacz
Submitter email address:bkopacz@interlinknetworks.com
Date first submitted: 03-26-2002
Reference:
Document: draft-base-09
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Minor corrections/clarifications to base-10.
Requested change:
In section 1.1.1 Differences from Radius
Change "Radius" to all caps in the section title.
- - -
In section 6.1.8 Relaying and Proxying Requests
Change the first two lines of the following paragraph:
Relay and Proxy agents MAY include the Proxy-Info AVP in requests if
it requires access any local state information when the corresponding
response is received. Alternatively, it MAY simply use local storage
to store state information.
A Relay or Proxy agent MAY include the Proxy-Info AVP in requests if
it requires access to any local state information when the corresponding
response is received. Alternatively, it MAY simply use local storage
to store state information.
- - -
In section 7.1 Result-Code AVP
The Result-Code AVP (AVP Code 268) is of type Unsigned32 and
indicates whether a particular request was completed successfully or
whether an error occurred. All Diameter answer messages MUST include
one Result-Code AVP. A non-successful Result-Code AVP (one containing
a non 2xxx value) MUST include the Error-Reporting-Host AVP if the
host setting the Result-Code AVP is different from the identity
encoded in the Origin-Host AVP.
Change the parenthesized phrase in the preceding paragraph:
(one containing a non 2xxx value)
To:
(one containing a non 2xxx value other than DIAMETER_REDIRECT_INDICATION)
- - -
In section 8 DIAMETER USER SESSIONS
Services provided past the expiration of the Authorization-
Lifetime and Auth-Grace-Period AVPs is the responsibility of the
access device.
Change "is the responsibility" to "are the responsibility".
- - -
In section 8.4 Session Termination
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.
Change the last sentence of the preceding paragraph to:
If the answer did not contain an Auth-Session-State AVP with the value
NO_STATE_MAINTAINED, 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.
- - -
In section 8.12 Re-Auth-Request-Type AVP
Following this sentence:
The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and
is included in application-specific auth answers to inform the client
of the action expected upon expiration of the Authorization-Lifetime.
Add the following sentence:
If the answer message contains an Authorization-Lifetime AVP with a
positive value, the Re-Auth-Request-Type AVP MUST be present in an answer
message.
- - -
In section 8.13 Session-Timeout AVP
Change the following sentence:
A Session-Timeout AVP MAY be present in a re-authorization message,
and contains the number of seconds from the beginning of the re-auth.
To:
A Session-Timeout AVP MAY be present in a re-authorization answer message,
and contains the remaining number of seconds from the beginning of the
re-auth.
- - -
In section 8.17 Session-Binding AVP
Change:
ACCOUNTING 4
When set, all accounting messages for this session MUST NOT
include the Destination-Host AVP. When cleared, the default
value, the Destination-Host AVP MUST be present in all
accounting messages for this session.
To:
ACCOUNTING 4
When set, all accounting messages for this session MUST NOT
include the Destination-Host AVP. When cleared, the default
value, the Destination-Host AVP, if known, MUST be present in all
accounting messages for this session.
The reason for adding the "if known" phrase is this: The accounting server
may be different from the authentication server, and if so, probably isn't
known when the first accounting message is sent. For subsequent
accounting messages, the accounting server is known by the client and the
Destination-Host can be included from then on.
- - -
Throughout the document:
Change "Accounting-Multi-Session-Id" to "Acct-Multi-Session-Id". Since
this is an AVP inherited from RADIUS, it should retain the RADIUS name.
- - -
In section 10.1 Base Protocol Command AVP Table
Change:
Attribute Name |CER|CEA|...
--------------------|---+---+...
Supported-Vendor-Id |0+ |0 |...
To:
Attribute Name |CER|CEA|...
--------------------|---+---+...
Supported-Vendor-Id |0+ |0+ |...
- - -
In section 10.2 Accounting AVP Table
Change the sentence:
The table in this section is used to represent which AVPs defined in
this document are to be present in the Accounting messages.
To:
The table in this section is used to represent which AVPs defined in this
document are to be present in the Accounting messages. These AVP
occurrence requirements are guidelines which may be expanded and/or
overriden by application-specific requirements in the Diameter
applications documents.
- - -
In section 10.2 Accounting AVP Table
Add these entries:
Attribute Name | ACR | ACA |
------------------------------|-----+-----+
Auth-Application-Id | 0 | 0 |
Termination-Cause | 0-1 | 0-1 |
Event-Timestamp | 0-1 | 0-1 |
- - -
In section 10.2 Accounting AVP Table
Change:
Attribute Name | ACR | ACA |
------------------------------|-----+-----+
User-Name | 0+ | 0+ |
To:
Attribute Name | ACR | ACA |
------------------------------|-----+-----+
User-Name | 1 | 0-1 |
The thinking is, that since the Session-Id AVP requirement is "1", this
means the accounting message is for a specific session and hence for a
specific user, so the User-Name requirement is also "1". And the
User-Name is optionally echoed back in the ACA (per issue#264), hence the
"0-1".
- - -
Issue 315: Bug in Acct state machine + Split
State Machines into Client vs. Server
Submitter name: Pete McCann
Submitter email address: mccap@lucent.com
Date first submitted: 03-27-2002
Reference:
Document: diameter-base-09
Comment type: Technical
Priority: S
Section: 8.1, 8.2
Rationale:
Currently, there is no way to enter the PendingI state in the accounting state
machine. This is a bug.
The state machines given in the diameter base document are confusing
to read, because they mix client and server states.
Requested Change:
Split each machine in two, and replace 8.1 and 8.2 with the following
text. Note the addition of an event to the client accounting state
machine to enter the PendingI state:
This section contains a set of finite state machines, representing the life
cycle of Diameter sessions, and which MUST be observed by all Diameter
implementations that make use of the authentication and/or
authorization portion of a Diameter application. The term Service-
Specific below refers to a message defined in a Diameter application
(e.g. Mobile IP, NASREQ).
There are four different authorization session state machines
supported in the Diameter base protocol. The first two describe a
session in which the server is maintaining session state, indicated
by the value of the Auth-Session-State AVP (or its absence). One
describes the session from a client perspective, the other from a
server perspective. The second two state machines are used when
the server does not maintain session state. Here again, one
describes the session from a client perspective, the other from a
server perspective.
When a session is moved to the Idle state, any resources that were
allocated for the particular session must be released. Any event not
listed in the state machines MUST be considered as an error
condition, and an answer, if applicable, MUST be returned to the
originator of the message.
The following state machine is observed by a client when state is
maintained on the server:
Issue 316:CMS Editorial Issues
Submitter name: Jari Arkko
Submitter email address: jari@arkko.com
Date first submitted: 03-27-2002
Reference:
Document: cms-09, base-09
Comment type: Editorial
Priority: S
Section: CMS: Abs, ToC, 1, 2, 3, 4, 5, Base: 4.6
Rationale:
1) In the abstract "... perform message routing, and other
than routing AVPs, do not modify Diameter messages." =>
"... perform message routing and do not modify Diameter
messages beyond routing AVPs."
2) ToC and the document structure. I would suggest
the following modifications:
- Since terms generally need to introduced before they are
used, 1.1 needs to move to its own chapter before chapter 1.
- I would add a Terms section. See attached file for initial
text.
- I would name 2.0 "AVP Protection' and place current 2.0 under
it as '2.1. Format' and 1.7 under it as 2.3. Then I would
add some clarifying text on exactly what the CMS spec expects
nodes to do with AVPs (I couldn't find such text before this
point). See attached second file for initial text.
- I would name 5.0 "Example Message Flow"
3) Chapter 1. Doesn't really describe what the functionality
provided here is, just talks about how it is provided. Suggested
text to add before the third paragraph: "This specification
provides an additional security mechanism to protect transport of
Diameter AVPs through rogue Diameter agents."
4) Chapter 1. "Redirector agent" => "redirect agent" (the term
used in base).
5) Chapter 1.2 last paragraph only talks about signing. Why? I
suggest that we should talk about both signing and encryption.
Here's some proposed text to add at the end: "Similarly, participants
MAY apply encryption to protect one or more AVPs within a message."
6) Chapter 4.6 in base. This is related to the above issue. We
have now clarified very well what MAY ENCR means, but we haven't
done the same for 'MAY Set P Bit'. Essentially, isn't this the same
thing? Propose to add text after first paragraph of 4.6: "Similarly,
for the originator of a DIameter message, a "P" in the "MAY" column
means that if a message containing that AVP is to be sent
via a proxy/agent then the message MUST NOT be sent unless there
is a DSA between the originator and the recipient or the originator
has locally trusted configuration that indicates that
CMS need not be used."
7) Chapter 1.3 "reuse the values" -- what values? I think this
is still referring to the old Encrypted-AVPs AVP, or something like
that. Propose to delete the sentence.
8) 1.3, "does not request a DSAR to request a DSA" => "does not request
a DSA through sending a DSAR message"
9) 1.3, "the access device can then determine whether it is willing to
provide service, based on its local policy". I would simply say "The access
device can then determine whether to trust this notification, based
on local configuration i.e. the keys of trusted agents. If the access device
can not trust this notification, it MUST refuse the service in question."
10) 3.1, "... which AVPs should be encrypted, signed or both..." -- remove
this text, but keep the part about the public keys.
11) 3.1. DSA[RA] message contents, doesn't clearly show which AVPs are
used for which purpose, which makes the spec harder to read. Also,
misses some of the AVPs. Proposed text in the third attachment.
12) 4.2 Local-CA-Info appears to be unnecessary. Remove from this
message.
13) 3.2 "capable of acting as recipients for confidentiality" =>
"that support DSAs".
14) 3.3. AES. Replace the current text with "It is strongly recommended
that the AES algorithm is supported where it is available."
15) 4.1 delete the statement about the cert distribution protocol, I don't
think we need to state that.
16) 5.0 delete the text about the bidir signatures and encryption.
17) 5.0 step h,add to the end "Those AVPs that need to be kept confidential
are placed in CMS-Encrypted-AVP in encrypted form. Modify picture accordingly.
18) 5.0 step i. Add before the encryption part "The message includes the
CMS-Signed-AVP, which authenticates the AVPs that need it".
19) 5.0 step h. "that were requested by the Home Server in the DSAA." =>
"that need it".
may be zero chains, if the roots and the certs don't mix or if the peer
should already know the chain. But there can be multiple chains if several
roots are used.
CA
Certificate Authority, a trusted third party
that signs cryptographic certificates for other
nodes.
CMS
Cryptographic Message Syntax [CMS].
DSA
Diameter Security Association.
OCSP
Online Certificate Status Protocol [OCSP].
This specification allows both the encryption and signing of
AVPs. Encryption takes place through taking the AVPs that need
protection from the Diameter message and placing them, concatenated
and encrypted, in CMS-Encrypted-Data AVP. The original AVPs are not
retained in the message.
Signing takes place through signing contents of the protected AVPs,
and placing the signature in the CMS-Signed-Data AVP. The original
AVPs are retained in the message, except in the case where both
encryption and signatures are needed. In this case the CMS-Encrypted-Data
AVP is created first and this is then signed.
The originating node sends the DSAR message to a server in the
destination realm. The DSAR message contains:
- TTL for this DSA (seconds) in the DSA-TTL AVP.
- The realm part of the user's NAI in the Destination-Realm AVP.
- The list of direct trust CA's that the originating Diameter
node has configured into it for certificate validation. A
"direct trust" CA is one that the node is willing to use as the
"top" of a certificate chain, sometimes confusingly known as a
"root CA". The list is given in a sequence of Local-CA-Info
AVPs.
- Certificate chains from each direct trust CA, in a sequence
of CA-Chain AVPs. One AVP value is needed for each direct trust
CA. A value MAY be omitted when the peers know that the
relevant chains already exist at the other side.
- Public key certificates for the Diameter servers in the
sending realm, all of which MUST validate up to one of the
CAs above, via the chain of CA certificates above.
- A flag indicating whether 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. See [OCSP] for more details on the certificate status
protocol and messages. The flag is given in the OCSP-Request-Flags
AVP.
- Optional nonce for OCSP, in the OCSP-Nonce AVP.
- The DSAR message MAY include the CMS-Signed-Data AVP. If the
originating node has a private key, and it includes AVPs
whose 'P' bit are set, the CMS-Signed-Data AVP MUST be
present.
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,
certification status, and other parameters.
- A common "top" of the certificate chain can be found between the
home and foreign domains.
- This certificate chain is cryptographically correct, passes
the (relevant parts of the) path validation algorithm specified
in [CERTPROF] and terminates at a CA mentioned in the DSAR message
- The certificate chain between the "top" certificate and
the certificate in the AAA-Node-Cert AVP can be cryptographically
verified.
- The signature, if any, can be verified.
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.
In the event the DSAR requested OCSP validation, via the OCSP-
Request-Flags AVP, and OCSP is not locally supported, the DSAA MUST
be returned with the Result-Code AVP set to
DIAMETER_OCSP_NOT_SUPPORTED.
Otherwise, the destination node returns the DSAA message which
contains:
- TTL for this DSA (seconds), in the DSA-TTL AVP.
- One or more chains of certificates from the "top" CAs in the
DSAR message to the certificates of this node. Each chain
appears as a CA-Chain AVP.
- Public key certificates for the Diameter servers in the realm
that sends the DSAA message. All the certificates MUST
validate up to one of the CAs in the DSAR message, via the
chain of CA certificates above.
- Optionally, if OCSP an response was requested 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
- The DSAA MUST include the CMS-Signed-Data, signed by a
Diameter agent or server within the user's realm, to prevent
an intermediate node from falsely claiming that the DSA has
been established.
The originating Diameter node MUST check that the provided elements
of the DSAR are valid. Any failure results in silently discarding
the DSAA message, auditing the event and not sending the original
Diameter message that requested protection from a DSA. It MUST
check, at least, that:
- the certificate chain provided in the DSAA is cryptographically
correct, passes the (relevant parts of the) path validation
algorithm specified in [CERTPROF] and terminates at a CA
mentioned in the DSAR message
- the name in the certificate is consistent with the rules
detailed in section 3.2.
- the DSAA message MUST include the CMS-Signed-Data AVP, the
signature MUST be validated and the signer's certificate chain
MUST terminate as a CA mentioned in the DSAR message
- the expiration of the TTL MUST be less or equal to the earliest
expiration of all certificates in the message, encoded in the
notAfter field.
If the initiator's policy is such that certificate status is
required, it MAY indicate that it requires an OCSP response from the
DSA peer in the DSAA message, via the OCSP-Request-Flags AVP.
Further, the initiator MAY request that the OCSP response be fresh
(non-cached) via the OCSP-Request-Flags and OCSP-Nonce AVPs. Upon
receipt of a DSAR message requesting an OCSP response, the receiver
issues an OCSP request and returns the response within the DSAA
message's OCSP-Responses AVP. The sender of the DSAA MAY included a
cached OCSP response, unless the requestor specifically requested a
fresh response.
The nonce value is to be (the beginning of) the nonce in the OCSP
response. The reason for this is that the responder MAY add
additional bits to the nonce, but the nonce provided in the OSCP-
Nonce MUST be present at the beginning of the nonce of the OSCP
response.
If certificate revocation is enabled, anytime a certificate is used
from the local certificate cache, a revocation check MUST be
performed.
Submitter Name: Siva Ramamurthy
Submitter email address: sivasundar_ramamurthy@hp.com
Date first submitter: 3/27/2002
Document: Mobile IP
Comment Type: T
Priority: 1
Section: 4.5
Explanation of Issue:
Section 4.5 has text that says:
"If the FA's local policy allows it to receive AAA session Keys, and
it does not have any existing keys with the HA, it MAY set the
FA-HA-Key-Request flag".
the co-existance of the phrases "any existing keys" and "AAA session
keys" is confusing! Is the FA-HA key to be used only for the session
from which it was obtained, or can it be used with any other sessions
that require communciation between this FA and HA? In other words, is
the FA-HA key session specific or not?
Requested Change:
Please clarify, since different implementations at the FA and HA can
lead to needless FOR_HOME authentication failures.
Submitter name: Ghadiyaram Venkata Kishore
Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com,
Date first submitted: March 28, 2002
Reference:
Document: Base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue
When a peer receives a CER, the IPAddress(IPAddresses in case of SCTP) of the
host sending the message can be obtained
from the transport layer as this information is maintained by the transport
layer as part of TCP connection or SCTP
association. So sending this information as part of Diameter payload is
redundant.
If alternate peers have to be provided through CER/CEA then we need a list of
DiameterURIs, just the IPAddress of the
peers is of no use.
Requested change:
Remove Host-IP-Address AVP from the specification of CER and CEA (both in the
text and te ABNF).
Issue: Accounting-Realtime-Required should appear
in Section 9.7.2, and text in Section 9.8.7
should give its AVP Code
Submitter name: Pete McCann
Submitter email address: mccap@lucent.com
Date first submitted: 03-28-2002
Reference:
Document: diameter-base-09
Comment type: Editorial
Priority: 1
Section: 9.7.2, 9.8.7
Rationale:
The Accounting-Realtime-Required AVP is defined in Section 9.8.7, but
is not mentioned in the ABNF for Accounting-Answer messages in Section
9.7.2. Also, the description in Section 9.8.7 lists the AVP Code as
"TBD", but the table on page 50-51 lists the AVP with Code 483.
Requested Change:
Add the following line to 9.7.2,
after "[Accounting-Interim-Interval]":
[ Accounting-Realtime-Required ]
Change the first line of Section 9.8.7 to read:
The Accounting-Realtime-Required AVP (AVP Code 483) is of type
Issue 320:Base-09 Nits
Issue: Base-09 Nits
Submitter name: Jari Arkko
Submitter email address: jari.arkko@kolumbus.fi
Date first submitted: 03-28-2002
Reference:
Document: diameter-base-09
Comment type: Editorial
Priority: 1
- "The Diameter base protocol is intended to provide an AAA framework
for Mobile-IP, NASREQ and ROAMOPS." => "The Diameter base protocol is
intended to provide an AAA framework for applications such as network
access or IP mobility. Diameter is also intended to work both with local
AAA and roaming situations."
- Add accounting in the list of functions provided by the base protocol?
Put it before security services.
Table of contents:
- You already got my fix to this.
- Additionally, you could replace the slash in 5.5.4 with " and "
1.1:
- Add to the list "- Basic services necessary for applications, such
as handling of user sessions or accounting"
1.1.1:
- "Mandatory bit" => "Bit to indicate mandatory status of data"
1.1.2:
- "The CMS Security [CMS] application defines how security associations
are established between two peers and how authentication, integrity,
confidentiality and non-repudiation can be achieved." =>
"The CMS Security [CMS] application defines how security associations
are established even through Diameter agents, and how authentication,
integrity, confidentialy, and data-origin authentication can be
achieved.
1.2:
- "Creating a new Accounting Application" => "Creating new accounting
applications"
1.2.1:
- "If the new AVP value changes an existing command code's ABNF, the
IANA AVP value request MUST include the new ABNF itself.": I'm not
sure how a new AVP value for enumerated could ever change the ABNF.
Propose to remove this sentence.
1.4:
- "The Diameter protocol consists of a header followed by one or more
Attribute-Value-Pair (AVP)." Add an "s" after "Pair" and after "AVP".
- "A Diameter Agent is a host that is providing either relay, proxy,
redirect or translation services.". Replace "is providing" with
"provides"
- "MLP" => "Multi-link PPP"
- "Diameter implementations SHOULD be able to interpret ICMP protocol
port unreachable messages as explicit indications that the server is
not reachable, in addition to interpreting ECONNREFUSED (a reset from
the transport) and timed-out connection attempts."
=>
"Diameter implementations SHOULD be able to interpret ICMP protocol
port unreachable messages as explicit indications that the server is
not reachable, subject to security policy on trusting such messages.
Diameter implementations SHOULD also be able to interpret ECONNREFUSED
(a reset from the transport) and timed-out connection attempts."
2.5:
- figure 1 => Figure 1
- session x => session X
Description of issue: MIPv4 draft has dependencies on CMS
Submitter name: Greg Weber
Submitter email address: gdweber@cisco.com
Date first submitted: March 30, 2002
Reference: URL to e-mail describing problem, if available
http://www.merit.edu/mail.archives/aaa-wg/msg03519.html
Document: MIPv4
Comment type: E
Priority: S
Section: 5.0, 5.2, 5.5.2, 6.0, 10.0, 11.1
Rationale/Explanation of issue:
The MIPv4 draft has several normative references to the CMS
application draft. If the MIPv4 draft is to be submitted to
the IESG before the CMS draft is ready, then these references
should be removed.
"I would suggest that MIPv4 normative references to CMS be removed, if it
is expected that MIPv4 be approved for publication prior to when CMS is
ready."
MAY P and MAY Encr columns in AVP tables. I'd really hate to lose
this information. Possible ways to deal with this are:
1) Retain the information, but formulate the base text in 4.6 to
say "The originator MUST have local configuration which indicates
that this information can be sent to the given destination with
only hop-by-hop protection." Essentially, this limits the base diameter
into doing transactions with just a preconfigured set of hosts, but
allows later extension (CMS) to remove this restriction.
2) Move the information from the base/mip/nasreq specs on P/MAY Encr
to a normative appendix of the CMS spec. Essentially, everything stays
as it has been, but CMS introduces even the protection policies for
all AVPs already standardized at the time the CMS spec goes to the
RFC editor. This approach leaves more freedom than approach 1.
3) Move the information to a non-normative appendix of the base spec."