< draft-ietf-dime-rfc3588bis-16.txt   draft-ietf-dime-rfc3588bis-17.txt >
DIME V. Fajardo, Ed. DIME V. Fajardo, Ed.
Internet-Draft Toshiba America Research Internet-Draft Toshiba America Research
Obsoletes: 3588 (if approved) J. Arkko Obsoletes: 3588 (if approved) J. Arkko
Intended status: Standards Track Ericsson Research Intended status: Standards Track Ericsson Research
Expires: September 7, 2009 J. Loughney Expires: November 7, 2009 J. Loughney
Nokia Research Center Nokia Research Center
G. Zorn G. Zorn
NetCube NetCube
March 6, 2009 May 6, 2009
Diameter Base Protocol (Version 2) Diameter Base Protocol
draft-ietf-dime-rfc3588bis-16.txt draft-ietf-dime-rfc3588bis-17.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2009. This Internet-Draft will expire on November 7, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1.3. Approach to Extensibility . . . . . . . . . . . . . . . . 19 1.3. Approach to Extensibility . . . . . . . . . . . . . . . . 19
1.3.1. Defining New AVP Values . . . . . . . . . . . . . . 19 1.3.1. Defining New AVP Values . . . . . . . . . . . . . . 19
1.3.2. Creating New AVPs . . . . . . . . . . . . . . . . . 19 1.3.2. Creating New AVPs . . . . . . . . . . . . . . . . . 19
1.3.3. Creating New Commands . . . . . . . . . . . . . . . 20 1.3.3. Creating New Commands . . . . . . . . . . . . . . . 20
1.3.4. Creating New Diameter Applications . . . . . . . . . 20 1.3.4. Creating New Diameter Applications . . . . . . . . . 20
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 22 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 22
2.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1. SCTP Guidelines . . . . . . . . . . . . . . . . . . 24 2.1.1. SCTP Guidelines . . . . . . . . . . . . . . . . . . 24
2.2. Securing Diameter Messages . . . . . . . . . . . . . . . 24 2.2. Securing Diameter Messages . . . . . . . . . . . . . . . 24
2.3. Diameter Application Compliance . . . . . . . . . . . . . 24 2.3. Diameter Application Compliance . . . . . . . . . . . . . 24
2.4. Application Identifiers . . . . . . . . . . . . . . . . . 24 2.4. Application Identifiers . . . . . . . . . . . . . . . . . 25
2.5. Connections vs. Sessions . . . . . . . . . . . . . . . . 25 2.5. Connections vs. Sessions . . . . . . . . . . . . . . . . 25
2.6. Peer Table . . . . . . . . . . . . . . . . . . . . . . . 26 2.6. Peer Table . . . . . . . . . . . . . . . . . . . . . . . 26
2.7. Routing Table . . . . . . . . . . . . . . . . . . . . . . 27 2.7. Routing Table . . . . . . . . . . . . . . . . . . . . . . 27
2.8. Role of Diameter Agents . . . . . . . . . . . . . . . . . 29 2.8. Role of Diameter Agents . . . . . . . . . . . . . . . . . 29
2.8.1. Relay Agents . . . . . . . . . . . . . . . . . . . . 30 2.8.1. Relay Agents . . . . . . . . . . . . . . . . . . . . 30
2.8.2. Proxy Agents . . . . . . . . . . . . . . . . . . . . 31 2.8.2. Proxy Agents . . . . . . . . . . . . . . . . . . . . 31
2.8.3. Redirect Agents . . . . . . . . . . . . . . . . . . 31 2.8.3. Redirect Agents . . . . . . . . . . . . . . . . . . 31
2.8.4. Translation Agents . . . . . . . . . . . . . . . . . 32 2.8.4. Translation Agents . . . . . . . . . . . . . . . . . 32
2.9. Diameter Path Authorization . . . . . . . . . . . . . . . 33 2.9. Diameter Path Authorization . . . . . . . . . . . . . . . 33
3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 35 3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 35
skipping to change at page 3, line 12 skipping to change at page 3, line 12
4.2. Basic AVP Data Formats . . . . . . . . . . . . . . . . . 44 4.2. Basic AVP Data Formats . . . . . . . . . . . . . . . . . 44
4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 45 4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 45
4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 52 4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 52
4.4.1. Example AVP with a Grouped Data type . . . . . . . . 53 4.4.1. Example AVP with a Grouped Data type . . . . . . . . 53
4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 56 4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 56
5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 59 5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 59
5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 59 5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 59
5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 59 5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 59
5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 62 5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 62
5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 63 5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 63
5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 63 5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 64
5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 64 5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 65
5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 64 5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 65
5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 65 5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 65
5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 65 5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 65
5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 65 5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 65
5.4. Disconnecting Peer connections . . . . . . . . . . . . . 65 5.4. Disconnecting Peer connections . . . . . . . . . . . . . 66
5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 66 5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 66
5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 66 5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 66
5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 66 5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 67
5.5. Transport Failure Detection . . . . . . . . . . . . . . . 67 5.5. Transport Failure Detection . . . . . . . . . . . . . . . 67
5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 67 5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 67
5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 67 5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 68
5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 68 5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 68
5.5.4. Failover and Failback Procedures . . . . . . . . . . 68 5.5.4. Failover and Failback Procedures . . . . . . . . . . 68
5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 69 5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 69
5.6.1. Incoming connections . . . . . . . . . . . . . . . . 71 5.6.1. Incoming connections . . . . . . . . . . . . . . . . 72
5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 72 5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 72
5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 73 5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 73
5.6.4. The Election Process . . . . . . . . . . . . . . . . 75 5.6.4. The Election Process . . . . . . . . . . . . . . . . 75
6. Diameter message processing . . . . . . . . . . . . . . . . . 76 6. Diameter message processing . . . . . . . . . . . . . . . . . 76
6.1. Diameter Request Routing Overview . . . . . . . . . . . . 76 6.1. Diameter Request Routing Overview . . . . . . . . . . . . 76
6.1.1. Originating a Request . . . . . . . . . . . . . . . 77 6.1.1. Originating a Request . . . . . . . . . . . . . . . 77
6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 77 6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 77
6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 78 6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 78
6.1.4. Processing Local Requests . . . . . . . . . . . . . 78 6.1.4. Processing Local Requests . . . . . . . . . . . . . 78
6.1.5. Request Forwarding . . . . . . . . . . . . . . . . . 78 6.1.5. Request Forwarding . . . . . . . . . . . . . . . . . 78
skipping to change at page 4, line 22 skipping to change at page 4, line 22
6.13. Redirect-Host-Usage AVP . . . . . . . . . . . . . . . . . 87 6.13. Redirect-Host-Usage AVP . . . . . . . . . . . . . . . . . 87
6.14. Redirect-Max-Cache-Time AVP . . . . . . . . . . . . . . . 88 6.14. Redirect-Max-Cache-Time AVP . . . . . . . . . . . . . . . 88
7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 90 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 90
7.1. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 92 7.1. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 92
7.1.1. Informational . . . . . . . . . . . . . . . . . . . 92 7.1.1. Informational . . . . . . . . . . . . . . . . . . . 92
7.1.2. Success . . . . . . . . . . . . . . . . . . . . . . 93 7.1.2. Success . . . . . . . . . . . . . . . . . . . . . . 93
7.1.3. Protocol Errors . . . . . . . . . . . . . . . . . . 93 7.1.3. Protocol Errors . . . . . . . . . . . . . . . . . . 93
7.1.4. Transient Failures . . . . . . . . . . . . . . . . . 94 7.1.4. Transient Failures . . . . . . . . . . . . . . . . . 94
7.1.5. Permanent Failures . . . . . . . . . . . . . . . . . 95 7.1.5. Permanent Failures . . . . . . . . . . . . . . . . . 95
7.2. Error Bit . . . . . . . . . . . . . . . . . . . . . . . . 98 7.2. Error Bit . . . . . . . . . . . . . . . . . . . . . . . . 98
7.3. Error-Message AVP . . . . . . . . . . . . . . . . . . . . 98 7.3. Error-Message AVP . . . . . . . . . . . . . . . . . . . . 99
7.4. Error-Reporting-Host AVP . . . . . . . . . . . . . . . . 99 7.4. Error-Reporting-Host AVP . . . . . . . . . . . . . . . . 99
7.5. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . 99 7.5. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . 99
7.6. Experimental-Result AVP . . . . . . . . . . . . . . . . . 100 7.6. Experimental-Result AVP . . . . . . . . . . . . . . . . . 100
7.7. Experimental-Result-Code AVP . . . . . . . . . . . . . . 100 7.7. Experimental-Result-Code AVP . . . . . . . . . . . . . . 100
8. Diameter User Sessions . . . . . . . . . . . . . . . . . . . 101 8. Diameter User Sessions . . . . . . . . . . . . . . . . . . . 101
8.1. Authorization Session State Machine . . . . . . . . . . . 102 8.1. Authorization Session State Machine . . . . . . . . . . . 102
8.2. Accounting Session State Machine . . . . . . . . . . . . 107 8.2. Accounting Session State Machine . . . . . . . . . . . . 107
8.3. Server-Initiated Re-Auth . . . . . . . . . . . . . . . . 112 8.3. Server-Initiated Re-Auth . . . . . . . . . . . . . . . . 112
8.3.1. Re-Auth-Request . . . . . . . . . . . . . . . . . . 112 8.3.1. Re-Auth-Request . . . . . . . . . . . . . . . . . . 112
8.3.2. Re-Auth-Answer . . . . . . . . . . . . . . . . . . . 113 8.3.2. Re-Auth-Answer . . . . . . . . . . . . . . . . . . . 113
skipping to change at page 6, line 8 skipping to change at page 6, line 8
11.4.10. Auth-Session-State AVP Values . . . . . . . . . . . 144 11.4.10. Auth-Session-State AVP Values . . . . . . . . . . . 144
11.4.11. Re-Auth-Request-Type AVP Values . . . . . . . . . . 144 11.4.11. Re-Auth-Request-Type AVP Values . . . . . . . . . . 144
11.4.12. Accounting-Realtime-Required AVP Values . . . . . . 144 11.4.12. Accounting-Realtime-Required AVP Values . . . . . . 144
11.4.13. Inband-Security-Id AVP (code 299) . . . . . . . . . 144 11.4.13. Inband-Security-Id AVP (code 299) . . . . . . . . . 144
11.5. Diameter TCP, SCTP and TLS/TCP Port Numbers . . . . . . . 144 11.5. Diameter TCP, SCTP and TLS/TCP Port Numbers . . . . . . . 144
11.6. NAPTR Service Fields . . . . . . . . . . . . . . . . . . 144 11.6. NAPTR Service Fields . . . . . . . . . . . . . . . . . . 144
12. Diameter protocol related configurable parameters . . . . . . 146 12. Diameter protocol related configurable parameters . . . . . . 146
13. Security Considerations . . . . . . . . . . . . . . . . . . . 147 13. Security Considerations . . . . . . . . . . . . . . . . . . . 147
13.1. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 147 13.1. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 147
13.2. Peer-to-Peer Considerations . . . . . . . . . . . . . . . 147 13.2. Peer-to-Peer Considerations . . . . . . . . . . . . . . . 148
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 149 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 149
14.1. Normative References . . . . . . . . . . . . . . . . . . 149 14.1. Normative References . . . . . . . . . . . . . . . . . . 149
14.2. Informational References . . . . . . . . . . . . . . . . 151 14.2. Informational References . . . . . . . . . . . . . . . . 151
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 153 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 153
A.1. RFC3588bis . . . . . . . . . . . . . . . . . . . . . . . 153 A.1. RFC3588bis . . . . . . . . . . . . . . . . . . . . . . . 153
A.2. RFC3588 . . . . . . . . . . . . . . . . . . . . . . . . . 154 A.2. RFC3588 . . . . . . . . . . . . . . . . . . . . . . . . . 154
Appendix B. NAPTR Example . . . . . . . . . . . . . . . . . . . 155 Appendix B. NAPTR Example . . . . . . . . . . . . . . . . . . . 155
Appendix C. Duplicate Detection . . . . . . . . . . . . . . . . 156 Appendix C. Duplicate Detection . . . . . . . . . . . . . . . . 156
Appendix D. Internationalized Domain Names . . . . . . . . . . . 158 Appendix D. Internationalized Domain Names . . . . . . . . . . . 158
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159
skipping to change at page 12, line 12 skipping to change at page 12, line 12
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.1.3. Changes from RFC3588 1.1.3. Changes from RFC3588
This document deprecates [RFC3588] but is fully backward compatible This document deprecates [RFC3588] but is fully backward compatible
with that document. The changes introduced in this document focuses with that document. The changes introduced in this document focuses
on fixing issues that have surfaced during implementation of on fixing issues that have surfaced during implementation of
[RFC3588]. An overview of some the major changes are shown below. [RFC3588]. An overview of some the major changes are shown below.
o Incremented the version number of the Diameter header to version
2. Many features of [RFC3588] has been changed or deprecated in
this version. Some of these changes are not backward compatible
with [RFC3588] and therefore it has become necessary to increment
the version number to aid in differentiating between revisions.
o Deprecated the use of Inband-Security AVP for negotiating o Deprecated the use of Inband-Security AVP for negotiating
transport layer security. It has been generally considered that transport layer security. It has been generally considered that
bootstrapping of TLS via Inband-Security AVP exposes certain bootstrapping of TLS via Inband-Security AVP exposes certain
security risk because it does not completely protect the security risk because it does not completely protect the
information carried in the CER/CEA. This version of Diameter information carried in the CER/CEA. This version of Diameter
adopted a common approach of defining a well-known secured port adopted a common approach of defining a well-known secured port
that peers must use when communicating via TLS. that peers should use when communicating via TLS. This new
approach augments the existing Inband-Security negotiation but
does not completely replace it. The old method is kept for
backwards compatibility reasons.
o Deprecated the exchange of CER/CEA message in the open state. o Deprecated the exchange of CER/CEA messages in the open state.
This feature is no longer supported in order to simplify the This feature was implied in the peer state machine table of
context and use of Application Id AVPs in the CER/CEA messages. [RFC3588] but it was not clearly defined anywhere else in that
The multiplicity of meaning and use of Application Id AVPs in the document. As work on this document progressed, it became clear
CER/CEA messages (and the messages themselves) is seen as an abuse that the multiplicity of meaning and use of Application Id AVPs in
of the Diameter extensibility rules and required simplification. the CER/CEA messages (and the messages themselves) is seen as an
It is assumed that the capabilities exchange in the open state abuse of the Diameter extensibility rules and thus required
will be re-introduced in a separate documents which clearly simplification. It is assumed that the capabilities exchange in
defines new commands for this specific feature. the open state will be re-introduced in a separate specification
which clearly defines new commands for this feature.
o Simplified Security Requirements. The use of a secured transport o Simplified Security Requirements. The use of a secured transport
for exchanging Diameter messages remains mandatory. However, TLS for exchanging Diameter messages remains mandatory. However, TLS
has become the primary method of securing Diameter and IPsec is a has become the primary method of securing Diameter and IPsec is a
secondary alternative. See Section 13 for details. The support secondary alternative. See Section 13 for details. The support
for the End-to-End security framework (E2ESequence AVP and 'P'-bit for the End-to-End security framework (E2ESequence AVP and 'P'-bit
in the AVP header) has also been deprecated. in the AVP header) has also been deprecated.
o Diameter Extensibility Changes. This includes fixes to the o Diameter Extensibility Changes. This includes fixes to the
Diameter extensibility description (Section 1.3 and others) to Diameter extensibility description (Section 1.3 and others) to
better aid Diameter application designers; in addition, the new better aid Diameter application designers; in addition, the new
specification relaxes the policy with respect to the allocation of specification relaxes the policy with respect to the allocation of
command codes for vendor-specific uses. The new specification command codes for vendor-specific uses. The new specification
relaxes the allocation of command codes for vendor specific uses. relaxes the allocation of command codes for vendor specific uses.
See Section 11.2.1 for details. See Section 11.2.1 for details.
o Application Id Usage. Clarify the proper use of Application Id o Application Id Usage. Clarify the proper use of Application Id
information which can be found in multiple places within a information which can be found in multiple places within a
Diameter message. This includes corelating Application Ids found Diameter message. This includes correlating Application Ids found
in the message headers and AVPs. These changes also clearly in the message headers and AVPs. These changes also clearly
specify the proper Application Id value to use for specific base specify the proper Application Id value to use for specific base
protocol messages (ASR/ASA, STR/STA) as well as clarifying the protocol messages (ASR/ASA, STR/STA) as well as clarifying the
content and use of Vendor-Specific-Application-Id. content and use of Vendor-Specific-Application-Id.
o Routing Fixes. This document more clearly specifies what o Routing Fixes. This document more clearly specifies what
information (AVPs and Application Id) can be used for making information (AVPs and Application Id) can be used for making
general routing decisions. A rule for the prioritization of general routing decisions. A rule for the prioritization of
redirect routing criteria when multiple route entries are found redirect routing criteria when multiple route entries are found
via redirects has also been added (See Section 6.13 for details). via redirects has also been added (See Section 6.13 for details).
skipping to change at page 23, line 22 skipping to change at page 23, line 22
NASREQ and/or Mobile IPv4. A Diameter proxy which does not support NASREQ and/or Mobile IPv4. A Diameter proxy which does not support
both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
Proxy" where X is the application which it supports, and not a Proxy" where X is the application which it supports, and not a
"Diameter Proxy". "Diameter Proxy".
2.1. Transport 2.1. Transport
The Diameter Transport profile is defined in [RFC3539]. The Diameter Transport profile is defined in [RFC3539].
The base Diameter protocol is run on port 3868 for both TCP [RFC793] The base Diameter protocol is run on port 3868 for both TCP [RFC793]
and SCTP [RFC4960]. It is run on port [TBD] when TLS [RFC5246] is and SCTP [RFC4960]. For TLS [RFC5246], a Diameter node that initiate
used. It is assumed that TLS is run on top of TCP when it is used. a TLS connection prior to any message exchanges MUST run on port
[TBD]. It is assumed that TLS is run on top of TCP when it is used.
The remainder of this document uses the term TLS to abbreviate the The remainder of this document uses the term TLS to abbreviate the
use of TLS over TCP. use of TLS over TCP.
If the Diameter peer does not support receiving TLS connections on
port [TBD], i.e. the peer complies only with [RFC3588], then the
initiator MAY revert to using TCP or SCTP and on port 3868. Note
that this scheme is kept for backwards compatibility purpose only and
that there are inherent security vulnerabilities when the initial
CER/CEA messages are sent un-protected (see Section 5.6).
Diameter clients MUST support either TCP or SCTP, while agents and Diameter clients MUST support either TCP or SCTP, while agents and
servers SHOULD support both. servers SHOULD support both.
A Diameter node MAY initiate connections from a source port other A Diameter node MAY initiate connections from a source port other
than the one that it declares it accepts incoming connections on, and than the one that it declares it accepts incoming connections on, and
MUST be prepared to receive connections on port 3868 for TCP or SCTP MUST be prepared to receive connections on port 3868 for TCP or SCTP
and port [TBD] for TLS connections. A given Diameter instance of the and port [TBD] for TLS connections. A given Diameter instance of the
peer state machine MUST NOT use more than one transport connection to peer state machine MUST NOT use more than one transport connection to
communicate with a given peer, unless multiple instances exist on the communicate with a given peer, unless multiple instances exist on the
peer in which case a separate connection per process is allowed. peer in which case a separate connection per process is allowed.
When no transport connection exists with a peer, an attempt to When no transport connection exists with a peer, an attempt to
connect SHOULD be periodically made. This behavior is handled via connect SHOULD be periodically made. This behavior is handled via
the Tc timer, whose recommended value is 30 seconds. There are the Tc timer, whose recommended value is 30 seconds. There are
certain exceptions to this rule, such as when a peer has terminated certain exceptions to this rule, such as when a peer has terminated
the transport connection stating that it does not wish to the transport connection stating that it does not wish to
communicate. communicate.
When connecting to a peer and either zero or more transports are When connecting to a peer and either zero or more transports are
specified, TCP SHOULD be tried first, followed by SCTP. See Section specified, TLS SHOULD be tried first, followed by TCP, then by SCTP.
5.2 for more information on peer discovery. See Section 5.2 for more information on peer discovery.
Diameter implementations SHOULD be able to interpret ICMP protocol Diameter implementations SHOULD be able to interpret ICMP protocol
port unreachable messages as explicit indications that the server is port unreachable messages as explicit indications that the server is
not reachable, subject to security policy on trusting such messages. not reachable, subject to security policy on trusting such messages.
Further guidance regarding the treatment of ICMP errors can be found Further guidance regarding the treatment of ICMP errors can be found
in [I-D.ietf-tcpm-icmp-attacks] and [RFC5461]. Diameter in [I-D.ietf-tcpm-icmp-attacks] and [RFC5461]. Diameter
implementations SHOULD also be able to interpret a reset from the implementations SHOULD also be able to interpret a reset from the
transport and timed-out connection attempts. If Diameter receives transport and timed-out connection attempts. If Diameter receives
data up from TCP that cannot be parsed or identified as a Diameter data up from TCP that cannot be parsed or identified as a Diameter
error made by the peer, the stream is compromised and cannot be error made by the peer, the stream is compromised and cannot be
skipping to change at page 35, line 28 skipping to change at page 35, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop-by-Hop Identifier | | Hop-by-Hop Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-to-End Identifier | | End-to-End Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ... | AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-
Version Version
This Version field MUST be set to 2 to indicate Diameter Version This Version field MUST be set to 1 to indicate Diameter Version
2. 1.
Message Length Message Length
The Message Length field is three octets and indicates the length The Message Length field is three octets and indicates the length
of the Diameter message including the header fields. of the Diameter message including the header fields.
Command Flags Command Flags
The Command Flags field is eight bits. The following bits are The Command Flags field is eight bits. The following bits are
assigned: assigned:
skipping to change at page 43, line 49 skipping to change at page 43, line 49
The AVP Header contains one optional field. This field is only The AVP Header contains one optional field. This field is only
present if the respective bit-flag is enabled. present if the respective bit-flag is enabled.
Vendor-ID Vendor-ID
The Vendor-ID field is present if the 'V' bit is set in the AVP The Vendor-ID field is present if the 'V' bit is set in the AVP
Flags field. The optional four-octet Vendor-ID field contains the Flags field. The optional four-octet Vendor-ID field contains the
IANA assigned "SMI Network Management Private Enterprise Codes" IANA assigned "SMI Network Management Private Enterprise Codes"
[RFC3232] value, encoded in network byte order. Any vendor or [RFC3232] value, encoded in network byte order. Any vendor or
standardization organization that are also treated like vendors in standardization organization that are also treated like vendors in
the IANA managed"SMI Network Management Private Enterprise Codes" the IANA managed "SMI Network Management Private Enterprise Codes"
space wishing to implement a vendor-specific Diameter AVP MUST use space wishing to implement a vendor-specific Diameter AVP MUST use
their own Vendor-ID along with their privately managed AVP address their own Vendor-ID along with their privately managed AVP address
space, guaranteeing that they will not collide with any other space, guaranteeing that they will not collide with any other
vendor's vendor-specific AVP(s), nor with future IETF AVPs. vendor's vendor-specific AVP(s), nor with future IETF AVPs.
A vendor ID value of zero (0) corresponds to the IETF adopted AVP A vendor ID value of zero (0) corresponds to the IETF adopted AVP
values, as managed by the IANA. Since the absence of the vendor values, as managed by the IANA. Since the absence of the vendor
ID field implies that the AVP in question is not vendor specific, ID field implies that the AVP in question is not vendor specific,
implementations MUST NOT use the zero (0) vendor ID. implementations MUST NOT use the zero (0) vendor ID.
skipping to change at page 48, line 22 skipping to change at page 48, line 22
FQDN = Fully Qualified Host Name FQDN = Fully Qualified Host Name
port = ":" 1*DIGIT port = ":" 1*DIGIT
; One of the ports used to listen for ; One of the ports used to listen for
; incoming connections. ; incoming connections.
; If absent, the default Diameter port ; If absent, the default Diameter port
; (3868) is assumed if no transport ; (3868) is assumed if no transport
; security is used and port (TBD) when ; security is used and port (TBD) when
; transport security is used. ; transport security (TLS) is used.
transport = ";transport=" transport-protocol transport = ";transport=" transport-protocol
; One of the transports used to listen ; One of the transports used to listen
; for incoming connections. If absent, ; for incoming connections. If absent,
; the default protocol is assumed to be TCP. ; the default protocol is assumed to be TCP.
; UDP MUST NOT be used when the aaa-protocol ; UDP MUST NOT be used when the aaa-protocol
; field is set to diameter. ; field is set to diameter.
transport-protocol = ( "tcp" / "sctp" / "udp" ) transport-protocol = ( "tcp" / "sctp" / "udp" )
skipping to change at page 62, line 37 skipping to change at page 62, line 37
The receiver of the Capabilities-Exchange-Request (CER) MUST The receiver of the Capabilities-Exchange-Request (CER) MUST
determine common applications by computing the intersection of its determine common applications by computing the intersection of its
own set of supported Application Id against all of the application own set of supported Application Id against all of the application
identifier AVPs (Auth-Application-Id, Acct-Application-Id and Vendor- identifier AVPs (Auth-Application-Id, Acct-Application-Id and Vendor-
Specific-Application-Id) present in the CER. The value of the Specific-Application-Id) present in the CER. The value of the
Vendor-Id AVP in the Vendor-Specific-Application-Id MUST NOT be used Vendor-Id AVP in the Vendor-Specific-Application-Id MUST NOT be used
during computation. The sender of the Capabilities-Exchange-Answer during computation. The sender of the Capabilities-Exchange-Answer
(CEA) SHOULD include all of its supported applications as a hint to (CEA) SHOULD include all of its supported applications as a hint to
the receiver regarding all of its application capabilities. the receiver regarding all of its application capabilities.
Diameter implementations SHOULD first attempt to establish a TLS
connection prior to the CER/CEA exchange. This protects the
capabilities information of both peers. To support older Diameter
implementations that do not fully conform to this document, the
transport security MAY still be negotiated via Inband-Security AVP.
In this case, the receiver of a Capabilities-Exchange-Req (CER)
message that does not have any security mechanisms in common with the
sender MUST return a Capabilities-Exchange-Answer (CEA) with the
Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY, and SHOULD
disconnect the transport layer connection.
CERs received from unknown peers MAY be silently discarded, or a CEA CERs received from unknown peers MAY be silently discarded, or a CEA
MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER. MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER.
In both cases, the transport connection is closed. If the local In both cases, the transport connection is closed. If the local
policy permits receiving CERs from unknown hosts, a successful CEA policy permits receiving CERs from unknown hosts, a successful CEA
MAY be returned. If a CER from an unknown peer is answered with a MAY be returned. If a CER from an unknown peer is answered with a
successful CEA, the lifetime of the peer entry is equal to the successful CEA, the lifetime of the peer entry is equal to the
lifetime of the transport connection. In case of a transport lifetime of the transport connection. In case of a transport
failure, all the pending transactions destined to the unknown peer failure, all the pending transactions destined to the unknown peer
can be discarded. can be discarded.
skipping to change at page 63, line 39 skipping to change at page 64, line 16
<CER> ::= < Diameter Header: 257, REQ > <CER> ::= < Diameter Header: 257, REQ >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
1* { Host-IP-Address } 1* { Host-IP-Address }
{ Vendor-Id } { Vendor-Id }
{ Product-Name } { Product-Name }
[ Origin-State-Id ] [ Origin-State-Id ]
* [ Supported-Vendor-Id ] * [ Supported-Vendor-Id ]
* [ Auth-Application-Id ] * [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ] * [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ] * [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ] [ Firmware-Revision ]
* [ AVP ] * [ AVP ]
5.3.2. Capabilities-Exchange-Answer 5.3.2. Capabilities-Exchange-Answer
The Capabilities-Exchange-Answer (CEA), indicated by the Command-Code The Capabilities-Exchange-Answer (CEA), indicated by the Command-Code
set to 257 and the Command Flags' 'R' bit cleared, is sent in set to 257 and the Command Flags' 'R' bit cleared, is sent in
response to a CER message. response to a CER message.
skipping to change at page 64, line 22 skipping to change at page 64, line 48
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
1* { Host-IP-Address } 1* { Host-IP-Address }
{ Vendor-Id } { Vendor-Id }
{ Product-Name } { Product-Name }
[ Origin-State-Id ] [ Origin-State-Id ]
[ Error-Message ] [ Error-Message ]
[ Failed-AVP ] [ Failed-AVP ]
* [ Supported-Vendor-Id ] * [ Supported-Vendor-Id ]
* [ Auth-Application-Id ] * [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ] * [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ] * [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ] [ Firmware-Revision ]
* [ AVP ] * [ AVP ]
5.3.3. Vendor-Id AVP 5.3.3. Vendor-Id AVP
The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains
the IANA "SMI Network Management Private Enterprise Codes" [RFC3232] the IANA "SMI Network Management Private Enterprise Codes" [RFC3232]
value assigned to the vendor of the Diameter device. It is value assigned to the vendor of the Diameter device. It is
skipping to change at page 69, line 43 skipping to change at page 70, line 13
A CER message is always sent on the initiating connection immediately A CER message is always sent on the initiating connection immediately
after the connection request is successfully completed. In the case after the connection request is successfully completed. In the case
of an election, one of the two connections will shut down. The of an election, one of the two connections will shut down. The
responder connection will survive if the Origin-Host of the local responder connection will survive if the Origin-Host of the local
Diameter entity is higher than that of the peer; the initiator Diameter entity is higher than that of the peer; the initiator
connection will survive if the peer's Origin-Host is higher. All connection will survive if the peer's Origin-Host is higher. All
subsequent messages are sent on the surviving connection. Note that subsequent messages are sent on the surviving connection. Note that
the results of an election on one peer are guaranteed to be the the results of an election on one peer are guaranteed to be the
inverse of the results on the other. inverse of the results on the other.
For TLS usage, TLS handshake will begin when both ends are in the For TLS usage, TLS handshake SHOULD begin when both ends are in the
closed state prior to any Diameter message exchanges. The TLS closed state prior to any Diameter message exchanges. The TLS
connection MUST be established before sending any CER or CEA message connection SHOULD be established before sending any CER or CEA
to secure and protect the capabilities information of both peers. message to secure and protect the capabilities information of both
Establishment of the TLS connection is independent of the state peers. The TLS connection SHOULD be disconnected when the state
machine described here and MUST be treated as a lower layer transport machine moves to the closed state. When connecting to responders
for all Diameter message. The TLS connection SHOULD be disconnected that do not conform to this document (i.e. older Diameter
when the state machine goes back to the closed state to save on implementations that are not prepared to received TLS connections in
system resources. the closed state), the initial TLS connection attempt will fail. The
initiator MAY then attempt to connect via TCP or SCTP and initiate
the TLS handshake when both ends are in the open state. If the
handshake is successful, all further messages will be sent via TLS.
If the handshake fails, both ends moves to the closed state.
The state machine constrains only the behavior of a Diameter The state machine constrains only the behavior of a Diameter
implementation as seen by Diameter peers through events on the wire. implementation as seen by Diameter peers through events on the wire.
Any implementation that produces equivalent results is considered Any implementation that produces equivalent results is considered
compliant. compliant.
state event action next state state event action next state
----------------------------------------------------------------- -----------------------------------------------------------------
Closed Start I-Snd-Conn-Req Wait-Conn-Ack Closed Start I-Snd-Conn-Req Wait-Conn-Ack
skipping to change at page 79, line 14 skipping to change at page 79, line 14
Network Access Identifier (NAI). The realm portion of the NAI is Network Access Identifier (NAI). The realm portion of the NAI is
inserted in the Destination-Realm AVP. inserted in the Destination-Realm AVP.
Diameter agents MAY have a list of locally supported realms and Diameter agents MAY have a list of locally supported realms and
applications, and MAY have a list of externally supported realms and applications, and MAY have a list of externally supported realms and
applications. When a request is received that includes a realm applications. When a request is received that includes a realm
and/or application that is not locally supported, the message is and/or application that is not locally supported, the message is
routed to the peer configured in the Routing Table (see Section 2.7). routed to the peer configured in the Routing Table (see Section 2.7).
Realm names and Application Ids are the minimum supported routing Realm names and Application Ids are the minimum supported routing
criteria, additional information maybe needed to support redirect criteria, additional information may be needed to support redirect
semantics. semantics.
6.1.7. Predictive Loop Avoidance 6.1.7. Predictive Loop Avoidance
Before forwarding or routing a request, Diameter agents, in addition Before forwarding or routing a request, Diameter agents, in addition
to processing done in Section 6.1.3, SHOULD check for the presence of to processing done in Section 6.1.3, SHOULD check for the presence of
candidate route's peer identity in any of the Route-Record AVPs. In candidate route's peer identity in any of the Route-Record AVPs. In
an event of the agent detecting the presence of a candidate route's an event of the agent detecting the presence of a candidate route's
peer identity in a Route-Record AVP, the agent MUST ignore such route peer identity in a Route-Record AVP, the agent MUST ignore such route
for the Diameter request message and attempt alternate routes if any. for the Diameter request message and attempt alternate routes if any.
skipping to change at page 85, line 40 skipping to change at page 85, line 40
The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and The Acct-Application-Id AVP (AVP Code 259) is of type Unsigned32 and
is used in order to advertise support of the Accounting portion of an is used in order to advertise support of the Accounting portion of an
application (see Section 2.4). If present in a message other than application (see Section 2.4). If present in a message other than
CER and CEA, the value of the Acct-Application-Id AVP MUST match the CER and CEA, the value of the Acct-Application-Id AVP MUST match the
Application Id present in the Diameter message header. Application Id present in the Diameter message header.
6.10. Inband-Security-Id AVP 6.10. Inband-Security-Id AVP
The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and The Inband-Security-Id AVP (AVP Code 299) is of type Unsigned32 and
is used in order to advertise support of the security portion of the is used in order to advertise support of the security portion of the
application. The use of this AVP in CER and CEA messages has been application. The use of this AVP in CER and CEA messages is no
deprecated. Instead, discovery of a Diameter entities security longer recommended. Instead, discovery of a Diameter entities
capabilities can be done either through static configuration or via security capabilities can be done either through static configuration
Diameter Peer Discovery described in Section 5.2. or via Diameter Peer Discovery described in Section 5.2.
The following values are supported: The following values are supported:
NO_INBAND_SECURITY 0 NO_INBAND_SECURITY 0
This peer does not support TLS. This is the default value, if the This peer does not support TLS. This is the default value, if the
AVP is omitted. AVP is omitted.
TLS 1 TLS 1
skipping to change at page 97, line 38 skipping to change at page 97, line 38
header length, it is sufficient to include the offending AVP header length, it is sufficient to include the offending AVP
header and a zero filled payload of the minimum required length header and a zero filled payload of the minimum required length
for the payloads data type. If the AVP is a grouped AVP, the for the payloads data type. If the AVP is a grouped AVP, the
grouped AVP header with an empty payload would be sufficient to grouped AVP header with an empty payload would be sufficient to
indicate the offending AVP. In the case where the offending AVP indicate the offending AVP. In the case where the offending AVP
header cannot be fully decoded when the AVP length is less than header cannot be fully decoded when the AVP length is less than
the minimum AVP header length, it is sufficient to include an the minimum AVP header length, it is sufficient to include an
offending AVP header that is formulated by padding the incomplete offending AVP header that is formulated by padding the incomplete
AVP header with zero up to the minimum AVP header length. AVP header with zero up to the minimum AVP header length.
DIAMETER_NO_COMMON_SECURITY 5017
This error is returned when a CER message is received, and there
are no common security mechanisms supported between the peers. A
Capabilities-Exchange-Answer (CEA) MUST be returned with the
Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY.
DIAMETER_UNKNOWN_PEER 5018 DIAMETER_UNKNOWN_PEER 5018
A CER was received from an unknown peer. A CER was received from an unknown peer.
DIAMETER_COMMAND_UNSUPPORTED 5019 DIAMETER_COMMAND_UNSUPPORTED 5019
This error code is used when a Diameter entity receives a message This error code is used when a Diameter entity receives a message
with a Command Code that it does not support. with a Command Code that it does not support.
DIAMETER_INVALID_HDR_BITS 5020 DIAMETER_INVALID_HDR_BITS 5020
skipping to change at page 118, line 16 skipping to change at page 118, line 16
The Origin-State-Id is used to allow detection of terminated sessions The Origin-State-Id is used to allow detection of terminated sessions
for which no STR would have been issued, due to unanticipated for which no STR would have been issued, due to unanticipated
shutdown of an access device. shutdown of an access device.
A Diameter client or access device increments the value of the A Diameter client or access device increments the value of the
Origin-State-Id every time it is started or powered-up. The new Origin-State-Id every time it is started or powered-up. The new
Origin-State-Id is then sent in the CER/CEA message immediately upon Origin-State-Id is then sent in the CER/CEA message immediately upon
connection to the server. The Diameter server receiving the new connection to the server. The Diameter server receiving the new
Origin-State-Id can determine whether the sending Diameter client had Origin-State-Id can determine whether the sending Diameter client had
abrupbtly shutdown by comparing the old value of the Origin-State-Id abruptly shutdown by comparing the old value of the Origin-State-Id
it has kept for that specific client is less than the new value and it has kept for that specific client is less than the new value and
whether it has un-terminated sessions originating from that client. whether it has un-terminated sessions originating from that client.
An access device can also include the Origin-State-Id in request An access device can also include the Origin-State-Id in request
messages other than CER if there are relays or proxies in between the messages other than CER if there are relays or proxies in between the
access device and the server. In this case, however, the server access device and the server. In this case, however, the server
cannot discover that the access device has been restarted unless and cannot discover that the access device has been restarted unless and
until it receives a new request from it. Therefore this mechanism is until it receives a new request from it. Therefore this mechanism is
more opportunistic across proxies and relays. more opportunistic across proxies and relays.
skipping to change at page 131, line 13 skipping to change at page 131, line 13
particular application session. Note that receiving a STOP_RECORD particular application session. Note that receiving a STOP_RECORD
with no Accounting-Sub-Session-Id AVP when sub-sessions were with no Accounting-Sub-Session-Id AVP when sub-sessions were
originally used in the START_RECORD messages implies that all sub- originally used in the START_RECORD messages implies that all sub-
sessions are terminated. sessions are terminated.
There are also cases where an application needs to correlate multiple There are also cases where an application needs to correlate multiple
application sessions into a single accounting record; the accounting application sessions into a single accounting record; the accounting
record may span multiple different Diameter applications and sessions record may span multiple different Diameter applications and sessions
used by the same user at a given time. In such cases, the Acct- used by the same user at a given time. In such cases, the Acct-
Multi-Session- Id AVP is used. The Acct-Multi-Session-Id AVP SHOULD Multi-Session- Id AVP is used. The Acct-Multi-Session-Id AVP SHOULD
be signalled by the server to the access device (typically during be signaled by the server to the access device (typically during
authorization) when it determines that a request belongs to an authorization) when it determines that a request belongs to an
existing session. The access device MUST then include the Acct- existing session. The access device MUST then include the Acct-
Multi-Session-Id AVP in all subsequent accounting messages. Multi-Session-Id AVP in all subsequent accounting messages.
The Acct-Multi-Session-Id AVP MAY include the value of the original The Acct-Multi-Session-Id AVP MAY include the value of the original
Session-Id. It's contents are implementation specific, but MUST be Session-Id. It's contents are implementation specific, but MUST be
globally unique across other Acct-Multi-Session-Id, and MUST NOT globally unique across other Acct-Multi-Session-Id, and MUST NOT
change during the life of a session. change during the life of a session.
A Diameter application document MUST define the exact concept of a A Diameter application document MUST define the exact concept of a
skipping to change at page 136, line 38 skipping to change at page 136, line 38
The AVP with Value field set to GRANT_AND_STORE means that service The AVP with Value field set to GRANT_AND_STORE means that service
SHOULD be granted if there is a connection, or as long as records SHOULD be granted if there is a connection, or as long as records
can still be stored as described in Section 9.4. can still be stored as described in Section 9.4.
This is the default behavior if the AVP isn't included in the This is the default behavior if the AVP isn't included in the
reply from the authorization server. reply from the authorization server.
GRANT_AND_LOSE 3 GRANT_AND_LOSE 3
The AVP with Value field set to GRANT_AND_LOSE means that service The AVP with Value field set to GRANT_AND_LOSE means that service
SHOULD be granted even if the records can not be delivered or SHOULD be granted even if the records cannot be delivered or
stored. stored.
10. AVP Occurrence Table 10. AVP Occurrence Table
The following tables presents the AVPs defined in this document, and The following tables presents the AVPs defined in this document, and
specifies in which Diameter messages they MAY be present or not. specifies in which Diameter messages they MAY be present or not.
AVPs that occur only inside a Grouped AVP are not shown in this AVPs that occur only inside a Grouped AVP are not shown in this
table. table.
The table uses the following symbols: The table uses the following symbols:
skipping to change at page 147, line 15 skipping to change at page 147, line 15
13. Security Considerations 13. Security Considerations
The Diameter base protocol messages SHOULD be secured by using TLS The Diameter base protocol messages SHOULD be secured by using TLS
[RFC5246]. Additional security mechanisms such as IPsec [RFC4301] [RFC5246]. Additional security mechanisms such as IPsec [RFC4301]
MAY also be deployed to secure connections between peers. However, MAY also be deployed to secure connections between peers. However,
all Diameter base protocol implementations MUST support the use of all Diameter base protocol implementations MUST support the use of
TLS and the Diameter protocol MUST NOT be used without any security TLS and the Diameter protocol MUST NOT be used without any security
mechanism. mechanism.
If a Diameter connection is to be protected via TLS or IPsec, then If a Diameter connection is to be protected via TLS or IPsec, then
TLS or IPsec handshake will begin prior to any Diameter message TLS or IPsec handshake SHOULD begin prior to any Diameter message
exchange. All security parameters for TLS or IPsec are configured exchange. All security parameters for TLS or IPsec are configured
independent of the Diameter protocol. All Diameter message will be independent of the Diameter protocol. All Diameter message will be
sent through the TLS or IPsec connection after a successful setup. sent through the TLS or IPsec connection after a successful setup.
For TLS connections to be established in the open state, the CER/CEA
exchange MUST include an Inband-Security-ID AVP with a value of TLS.
The TLS handshake will begin when both ends successfully reached the
open state, after completion of the CER/CEA exchange. If the TLS
handshake is successful, all further messages will be sent via TLS.
If the handshake fails, both ends move to the closed state. See
Sections 13.1 for more details.
13.1. TLS Usage 13.1. TLS Usage
Diameter nodes using TLS for security MUST mutually authenticate as Diameter nodes using TLS for security MUST mutually authenticate as
part of TLS session establishment. In order to ensure mutual part of TLS session establishment. In order to ensure mutual
authentication, the Diameter node acting as TLS server MUST request a authentication, the Diameter node acting as TLS server MUST request a
certificate from the Diameter node acting as TLS client, and the certificate from the Diameter node acting as TLS client, and the
Diameter node acting as TLS client MUST be prepared to supply a Diameter node acting as TLS client MUST be prepared to supply a
certificate on request. certificate on request.
Diameter nodes MUST be able to negotiate the following TLS cipher Diameter nodes MUST be able to negotiate the following TLS cipher
 End of changes. 35 change blocks. 
57 lines changed or deleted 95 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/