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
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 t