One document matched: draft-calhoun-aaa-diameter-comp-00.txt
INTERNET DRAFT Pat R. Calhoun
Category: Informational Sun Microsystems, Inc.
Title: draft-calhoun-aaa-diameter-comp-00.txt
Date: April 2000
Comparison of DIAMETER Against AAA Network Access Requirements
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
The AAA Working Group has completed a document that itemizes their
requirements for Network Access Applications (NASREQ, Mobile IP, and
ROAMOPS). This specification compares the DIAMETER protocol against
the requirements, and is provided to the AAA Working Group as an
official submission for an AAA protocol.
Calhoun expires October 2000 [Page 1]
INTERNET DRAFT April 2000
1.0 Introduction
The AAA Working Group has completed a document that itemizes their
requirements for Network Access Applications (NASREQ, Mobile IP, and
ROAMOPS). This specification compares the DIAMETER protocol against
the requirements, and is provided to the AAA Working Group as an
official submission for an AAA protocol.
1.1 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [1].
Please note that the requirements specified in this document are to
be used in evaluating AAA protocol submissions. As such, the
requirements language refers to capabilities of these protocols; the
protocol documents will specify whether these features are required,
recommended, or optional. For example, requiring that a protocol
support confidentiality is NOT the same thing as requiring that all
protocol traffic be encrypted.
A protocol submission is not compliant if it fails to satisfy one or
more of the MUST or MUST NOT requirements for the capabilities that
it implements. A protocol submission that satisfies all the MUST,
MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is
said to be "unconditionally compliant"; one that satisfies all the
MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT
requirements for its protocols is said to be "conditionally
compliant."
2.0 Requirements Summary
This section contains the same four sections as found in the AAA
Network Access requirements. Each section contains a new column,
named DIAMETER. For each requirement, it is noted whether the
DIAMETER protocol meets (T), Partially meets (P), or does not meet
(F) the stated requirement. Furthermore, each requirement has a
footnote, which contains additional justification.
Calhoun expires October 2000 [Page 2]
INTERNET DRAFT April 2000
2.1 General requirements
These requirements apply to all aspects of AAA and thus are
considered general requirements.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| General | NASREQ | ROAMOPS | MOBILE | DIAMETER |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Scalability | M | M | M | T |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Failover | M | | M | T |
| | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Mutual auth | M | | M | T |
| AAA client/server | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Transmission level | | M | S | T |
| security | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Data object | M | M | S | T |
| Confidentiality | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Data object | M | M | M | T |
| Integrity | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Certificate transport | M | | S | T |
| | | | | g |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun expires October 2000 [Page 3]
INTERNET DRAFT April 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Reliable AAA transport | M | | M | T |
| mechanism | | | | h |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Run Over IPv4 | M | M | M | T |
| | | | | i |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Run Over IPv6 | M | | S | T |
| | | | | j |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Support Proxy and | M | | M | T |
| Routing Brokers | | | | k |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Auditability | S | | | T |
| | | | | l |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Shared secret not | S | O | O/M | T |
| required | | | | m |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Ability to carry | M | | S | T |
| service-specific attr. | | | | n |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Calhoun expires October 2000 [Page 4]
INTERNET DRAFT April 2000
Clarifications
[a] The DIAMETER Base Protocol [3] has learned from RADIUS' defi-
ciencies and provides the following features that help scaling:
[1] Supports 2^32 pending requests
[2] reduces the number of servers necessary in a proxy environ-
ment, while increasing the robustness of the proxy chain
[3] does not require end-to-end application level acknowledge-
ment
[4] support for message forwarding and redirect servers
[b] All DIAMETER messages are routed based on the realm portion of
the Network Access Identifier (NAI) [10]. The DIAMETER Base Pro-
tocol [3] states that when a node receives a disconnect indica-
tion from a peer, all unacknowledged messages (at the transport
layer) MUST be forwarded to an alternative server that is capa-
ble of handling the realm in question. Unlike the RADIUS proto-
col, the Destination-NAI AVP allows a DIAMETER response to fol-
low a path that differs from the requests, which allows for a
more resilient service.
[c] The DIAMETER Base Protocol [3] defines three different authenti-
cation mechanisms:
[1] None - Used when an underlying security service is used,
such as IP Security.
[2] Hop-by-Hop - The DIAMETER Base Protocol [3] defines message
authentication, using symmetric transforms, which is used
to provide mutual authentication between two DIAMETER
nodes.
[3] End-to-End - Although not necessarily intended to provide
message authentication, the Strong Security extension [6]
provides object level authentication, which could cover all
AVPs in a DIAMETER message. Given the fairly intensive com-
putations necessary to generate an end-to-end objects, use
of this authentication mechanisms to should be restricted
to cases where strong authentication (e.g. Digital Signa-
tures) are necessary (e.g. Internet-Domain).
[d] The DIAMETER Base Protocol [3] provides message authentication,
integrity and confidentiality using hop-by-hop security.
Calhoun expires October 2000 [Page 5]
INTERNET DRAFT April 2000
[e] The DIAMETER Strong Security extension [6] defines the CMS-Data
AVP, which is used to carry Cryptographic Message Syntax (CMS)
[11] objects. The objects, as defined in [11], MAY be encrypted
using asymmetric encryption, where only the target host would be
able to retrieve the plaintext.
[f] The DIAMETER Strong Security extension defines the CMS-Data AVP,
which is used to carry Cryptographic Message Syntax (CMS) [11]
objects. The objects, as defined in [11], MAY be authenticated
using different levels of authentication transforms, including
asymmetric.
[g] The DIAMETER Strong Security extension defines the CMS-Data AVP,
which is used to carry Cryptographic Message Syntax (CMS) [11]
objects. The objects, as defined in [11], MAY be used to carry
X.509 certificates.
[h] The DIAMETER Base Protocol [3] is run over the Simple Control
Transport Protocol (SCTP) [12], which provides reliability,
quick failure detection, and addresses the AAA requirements.
[i] The DIAMETER Base Protocol [3] has no reliance on the underlying
IP version, and is capable of including IP version 4 addresses.
[j] The DIAMETER Base Protocol [3] has no reliance on the underlying
IP version, and is capable of including IP version 6 addresses.
[k] The DIAMETER Base Protocol [3] supports proxies and brokers in
both transparent forwarding, as well as in the redirect mode.
The former allows a server to simply forward a DIAMETER message
to a downstream server. The latter allows a server to provide
NAI-to-Address services, by returning information necessary for
a server to directly communicate with another DIAMETER server
handling a particular domain.
[l] The CMS-Data AVP [6] allows each DIAMETER entity in a proxy
chain to add its identity, and signature in a serial fashion,
which MAY be used to trace a DIAMETER message's path.
[m] The DIAMETER Base Protocol [3] does provide for no message
authentication, which is normally used when an underlying secu-
rity service is used, such as IP Security.
[n] The DIAMETER Base Protocol [3] is extensible, and allows third
parties to create service-specific extensions, such as the
Mobile IP [5] and NASREQ [8] extensions. Future extensions could
be added, by allocating an Extension Identifier [3], and the AVP
Values necessary for the objects needed, by IANA.
Calhoun expires October 2000 [Page 6]
INTERNET DRAFT April 2000
2.2 Authentication Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Authentication | NASREQ | ROAMOPS | MOBILE | DIAMETER |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| NAI Support | M | M | S | T |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| CHAP Support | M | M | O | T |
| | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| EAP Support | M | S | O | T |
| | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| PAP/Clear-Text Support | M | B | O | T |
| | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Re-authentication | M | | S | T |
| on demand | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Authorization Only | M | | O | T |
| without Authentication | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
Calhoun expires October 2000 [Page 7]
INTERNET DRAFT April 2000
F = Does Not Meet Requirement
Clarifications
[a] The DIAMETER Base Protocol [3] defines an AVP that is used to
carry a User-Name, which SHOULD be in an NAI format. Further-
more, [3] defines how DIAMETER message forwarding is performed
using the realm portion of the NAI.
[b] The DIAMETER NASREQ extension [8] defines the AVPs necessary to
request authentication of a PPP user using the CHAP authentica-
tion mechanism.
[c] The DIAMETER NASREQ extension [8] defines the AVPs necessary to
carry Extensible Authentication Protocol (EAP) payloads, and
defines a set of primitives to be used with the AVPs.
[d] The DIAMETER NASREQ extension [8] defines the AVPs necessary to
request authentication of a PPP user using the PAP authentica-
tion mechanism.
[e] The DIAMETER Base Protocol [3] specifies that an authenticated
user's session SHOULD expire in the number of seconds specified
in the Session-Timeout AVP. In order to renew a session, a re-
authentication MUST be submitted. Re-authentication MAY occur at
any time before the timeout expires.
[f] The DIAMETER NASREQ extension [8] states "Unlike the RADIUS pro-
tocol the DIAMETER protocol does not require authentication
information to be contained in a request from the client. There-
fore, it is possible to send a request for authorization only.
The type of service depends upon the Request-Type AVP. This
difference MAY cause operational issues in environments that
need RADIUS interoperability, and it MAY be necessary that pro-
tocol conversion gateways add some authentication information
when transmitting to a RADIUS server."
Calhoun expires October 2000 [Page 8]
INTERNET DRAFT April 2000
2.2 Authorization Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Authorization | NASREQ | ROAMOPS | MOBILE | DIAMETER |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static and Dynamic | | | | |
| IPv4/6 Address Assign. | M | M | M | T |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| RADIUS gateway | M | M | O | T |
| capability | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Reject | M | M | M | T |
| capability | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Precludes layer 2 | N | N | | T |
| tunneling | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Re-Authorization on | M | | S | T |
| demand | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Support for Access Rules,| M | | O | T |
| Restrictions, Filters | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| State Reconciliation | M | | | T |
| | | | | g |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Unsolicited Disconnect | M | | | T |
| | | | | h |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun expires October 2000 [Page 9]
INTERNET DRAFT April 2000
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] The DIAMETER NASREQ [8] and Mobile IP [5] extensions allows for
both static and dynamic address assignment. The DIAMETER Base
Protocol [3] allows AVPs of format "Address" to carry either IP
version 4 or 6 addresses.
[b] The DIAMETER protocol provides many features that makes the task
simpler for an AAA protocol bridge function. First, the protocol
reserves the first 256 Commands and AVPs to "Legacy" RADIUS. The
RADIUS attributes are defined in the NASREQ extension [8].
Further, the Implementation Guideline [9] specification provides
guidelines that MAY be followed when implementing a protocol
bridge, which would ensure complete protocol compatibility.
[c] A forwarding agent, be it a Proxy or Broker, MAY reject a
request by responding with a response, and the appropriate
Result Code. The identity of the rejecting host is known through
the Host-Name AVP [3].
[d] The DIAMETER NASREQ Extension [8] defines a set of AVPs that are
used to create compulsory tunnels, including Layer 2 tunnels.
[e] The DIAMETER Base Protocol [3] specifies that an authorized
user's session SHOULD expire in the number of seconds specified
in the Session-Timeout AVP. In order to renew a session, a re-
authorization MUST be submitted. Note that re-authorization MAY
occur at any time before the timeout occurs.
[f] The NASREQ Extension [8] specifies two methods of supporting
Filters and Access Rules. The first, is defined for Legacy
RADIUS compatibility, and allows a Filter Identifier to be car-
ried within an AVP. It is necessary for the NAS in question to
recognize the Identifier provided, and map the appropriate
filter rules to the user's access port. The second method is a
much more scalable solution, and allows filters to be encoded in
a standard AVP. Note that the RADIUS protocol has no equivalent
Calhoun expires October 2000 [Page 10]
INTERNET DRAFT April 2000
attribute, so use of this AVP SHOULD be reserved for networks
that do not include RADIUS-only devices.
[g] The AAA network access requirements describe State Reconcilia-
tion as requiring:
[1] Re-authorization capabilities - The DIAMETER Base Protocol
[3] provides the Session-Timeout AVP, which is used to
inform the NAS of the lifetime of a successful authoriza-
tion. The protocol states that the NAS MUST send a re-
authorization in order to extend the life of the session.
Re-authorization is service-specific, and is defined in
Mobile IP [5] and NASREQ [8].
[2] Session disconnect message - The DIAMETER Base Protocol [3]
defines the Session-Termination-Request message, which is
used by the NAS to inform the AAA server that an active
session has been terminated.
[3] Transport and application-layer reliability - The DIAMETER
Base Protocol [3] requires the use of SCTP [13] as the
reliable transport. Furthermore, the DIAMETER base proto-
col [3] defines what a node does in the event of a peer
failure, in order to provide application level reliability.
[4] An interim message - The DIAMETER Accounting extension [4]
defines the Accounting-Interim-Interval AVP, which is used
by DIAMETER nodes to inform their peer of the expected
interval between interim Accounting messages.
[5] A mechanism for the AAA server to retrieve state informa-
tion from the NAS. This mechanism will provide timely
information though a complete state dump may not be immedi-
ately available. - The DIAMETER Resource Management exten-
sion [15] provides a message set that allows a DIAMETER
node to request active session state information from its
peer.
[6] A NAS reboot message - The DIAMETER Base Protocol [3]
defines the Device-Reboot-Ind, which is used to communicate
to a peer of a reboot.
[7] Accounting On/Off messages - The DIAMETER Accounting exten-
sion [4] defines the Accounting-Status-Ind message, which
is used to communicate to a peer whether accounting has
been enabled or disabled.
[h] The DIAMETER Base Protocol [3] supports a set of Session
Calhoun expires October 2000 [Page 11]
INTERNET DRAFT April 2000
Termination messages. A client (NAS) uses the messages to inform
its server that an active session is being terminated. A server
uses the messages to request that the client terminate the ses-
sion. A session is identified through the Session-Id, which is
guaranteed to be globally unique.
Calhoun expires October 2000 [Page 12]
INTERNET DRAFT April 2000
2.3 Accounting Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Accounting | NASREQ | ROAMOPS | MOBILE | DIAMETER |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Real-time accounting | M | M | M | T |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Mandatory Compact | | M | M | T |
| Encoding | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Accounting Record | M | M | M | T |
| Extensibility | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Batch Accounting | S | | | T |
| | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Guaranteed Delivery | M | | M | T |
| | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Accounting Time Stamps | M | | S | T |
| | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Dynamic Accounting | M | | S | T |
| | | | | g |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
Calhoun expires October 2000 [Page 13]
INTERNET DRAFT April 2000
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] The DIAMETER Accounting extension [4] allows for both Real-Time
and batched accounting record transfer. The default mode is
real-time.
[b] The DIAMETER Accounting extension [4] defines the ADIF-Record
AVP, which is used to carry ADIF [13] records. The AAA Account-
ing Record and Attributes [14] specification states "[ROAM-ADIF]
proposes a standard accounting record format, the Accounting
Data Interchange Format (ADIF), which is designed to compactly
represent accounting data in a protocol-independent manner."
[c] The ADIF [13] Accounting Data Format MAY be extended by assign-
ing new keywords for new accounting data objects by IANA.
[d] The DIAMETER Accounting extension [4] allows for both Real-Time
and batched accounting record transfer. When batched mode is
desired, information on the frequency that records should be
provided (both in terms of time and bandwidth) is provided in a
set of defined AVPs.
[e] The DIAMETER server that is responsible for a specific realm
MUST acknowledge, at the application level, all Accounting
Requests. This allows the sender to have an acknowledgement,
which MAY be signed, of receipt and acceptance of one or more
Accounting Records.
[f] The DIAMETER Base Protocol [3] defines the Timestamp AVP, which
MUST be present in all Accounting [4] messages.
[g] The DIAMETER Accounting extension [4] allows for "interim"
accounting records, which MAY be sent periodically, and after a
re-authentication and/or re-authorization.
Calhoun expires October 2000 [Page 14]
INTERNET DRAFT April 2000
2.4 Unique Mobile IP requirements
In addition Mobile IP also has the following requirements:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Unique Mobile IP | NASREQ | ROAMOPS | MOBILE | DIAMETER |
| requirements | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Encoding of Mobile IP | | | M | T |
| registration messages | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Firewall friendly | | | M | T |
| | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Allocation of local Home | | | S/M | T |
| agent | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] The DIAMETER Mobile IP extension [5] defines the MIP-
Registration-Req and the MIP-Registration-Reply AVPs, which are
used to carry the Mobile IP Registration Requests as opaque
data.
[b] The DIAMETER Base Protocol [3] relies on SCTP, which is
currently not supported on firewalls, and therefore could not be
used with some firewalls. Furthermore, most NAT implementations
DO NOT support SCTP either. However, a firewall could easily
Calhoun expires October 2000 [Page 15]
INTERNET DRAFT April 2000
implement a DIAMETER proxy server, which would provide for
firewall penetration, as an application proxy and would probably
be more secure than punching holes through firewalls. It is
assumed that future firewall implementations will recognize the
SCTP protocol, and will allow such traffic to penetrate the
firewall.
[c] The DIAMETER Mobile IP extension [5] specifies how a Home Agent
within a foreign network could be allocated, and defines the
message flow as well as how the Key Distribution Center (KDC)
session keys are used in such a network.
3.0 Conclusion
The DIAMETER Base Protocol [3], and associated extensions [4, 5, 6,
8, 15] is unconditionally compliant with the AAA Network Access
requirements [2].
4.0 References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Aboba et al, "Network Access AAA Evaluation Criteria", IETF work
in progress, draft-ietf-aaa-na-reqts-02.txt, March 2000.
[3] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base
Protocol", draft-calhoun-diameter-14.txt, IETF work in progress,
April 2000.
[4] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "DIAMETER Accounting
Extension", draft-calhoun-diameter-accounting-05.txt, IETF work
in progress, April 2000.
[5] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft-
calhoun-diameter-mobileip-07.txt, IETF work in progress, April
2000.
[6] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security
Extension", draft-calhoun-diameter-strong-crypto-03.txt, IETF
work in progress, April 2000.
[7] P. Calhoun, G. Zorn, P. Pan, H. Akhtar, "DIAMETER Framework",
draft-calhoun-diameter-framework-07.txt, IETF work in progress,
April 2000
Calhoun expires October 2000 [Page 16]
INTERNET DRAFT April 2000
[8] P. Calhoun, W. Bulley, "DIAMETER NASREQ Extension", draft-
calhoun-diameter-nasreq-03.txt, IETF work in progress, April
2000.
[9] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J.
Haag, "DIAMETER Implementation Guidelines", draft-calhoun-
diameter-impl-guide-02.txt, IETF work in progress, April 2000
[10] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486.
January 1999.
[11] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999.
[12] R. Stewart et al., "Simple Control Transmission Protocol",
draft-ietf-sigtran-sctp-08.txt, IETF Work in Progress, April
2000.
[13] B. Aboba, D. Lidyard, "The Accounting Data Interchange Format
(ADIF)", IETF Work in Progress, draft-ietf-roamops-actng-07.txt,
September 1999.
[14] N. Brownlee, A. Blount, "Accounting Attributes and Record For-
mats", IETF Work in Progress, draft-ietf-aaa-accounting-
attributes-02.txt, March 2000.
[15] P. Calhoun, N. Greene, "DIAMETER Resource Management", draft-
calhoun-diameter-res-mgmt-03.txt, IETF Work in Progress, April
2000.
5.0 Security Considerations
This document, being a protocol evaluation document, does not have
any security concerns. The security requirements on protocols to be
evaluated using this document are described in the referenced docu-
ments.
6.0 IANA Considerations
This draft does not create any new number spaces for IANA administra-
tion.
7.0 Acknowledgements
Thanks to the various co-authors of the DIAMETER documents, which
have been very helpful in getting the protocol in the state that it
Calhoun expires October 2000 [Page 17]
INTERNET DRAFT April 2000
is today. The author would also like to thank the active DIAMETER
mailing list members, and some IESG members, for their valuable
input.
8.0 Authors Addresses
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, CA 94025
Phone: +1 650 786-7733
EMail: pcalhoun@eng.sun.com
9.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English. The lim-
ited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns. This document
and the information contained herein is provided on an "AS IS" basis
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
Calhoun expires October 2000 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-22 05:18:02 |