rfc3588.txt   draft-ietf-dime-rfc3588bis-01.txt 
Network Working Group P. Calhoun DIME V. Fajardo, Ed.
Request for Comments: 3588 Airespace, Inc. Internet-Draft Toshiba America Research
Category: Standards Track J. Loughney Intended status: Standards Track J. Loughney
Nokia Expires: August 2, 2007 Nokia Research Center
E. Guttman January 29, 2007
Sun Microsystems, Inc.
G. Zorn
Cisco Systems, Inc.
J. Arkko
Ericsson
September 2003
Diameter Base Protocol Diameter Base Protocol
draft-ietf-dime-rfc3588bis-01.txt
Status of this Memo Status of this Memo
This document specifies an Internet standards track protocol for the By submitting this Internet-Draft, each author represents that any
Internet community, and requests discussion and suggestions for applicable patent or other IPR claims of which he or she is aware
improvements. Please refer to the current edition of the "Internet have been or will be disclosed, and any of which he or she becomes
Official Protocol Standards" (STD 1) for the standardization state aware will be disclosed, in accordance with Section 6 of BCP 79.
and status of this protocol. Distribution of this memo is unlimited.
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.
This Internet-Draft will expire on August 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Diameter base protocol is intended to provide an Authentication, The Diameter base protocol is intended to provide an Authentication,
Authorization and Accounting (AAA) framework for applications such as Authorization and Accounting (AAA) framework for applications such as
network access or IP mobility. Diameter is also intended to work in network access or IP mobility. Diameter is also intended to work in
both local Authentication, Authorization & Accounting and roaming both local Authentication, Authorization & Accounting and roaming
situations. This document specifies the message format, transport, situations. This document specifies the message format, transport,
error reporting, accounting and security services to be used by all error reporting, accounting and security services to be used by all
Diameter applications. The Diameter base application needs to be Diameter applications. The Diameter base application needs to be
supported by all Diameter implementations. supported by all Diameter implementations.
Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[KEYWORD].
Table of Contents Table of Contents
1. Introduction................................................. 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Diameter Protocol..................................... 9 1.1. Diameter Protocol . . . . . . . . . . . . . . . . . . . . 10
1.1.1. Description of the Document Set.............. 10 1.1.1. Description of the Document Set . . . . . . . . . . 11
1.2. Approach to Extensibility............................. 11 1.1.2. Conventions Used in This Document . . . . . . . . . 12
1.2.1. Defining New AVP Values...................... 11 1.2. Approach to Extensibility . . . . . . . . . . . . . . . . 12
1.2.2. Creating New AVPs............................ 11 1.2.1. Defining New AVP Values . . . . . . . . . . . . . . 13
1.2.3. Creating New Authentication Applications..... 11 1.2.2. Creating New AVPs . . . . . . . . . . . . . . . . . 13
1.2.4. Creating New Accounting Applications......... 12 1.2.3. Creating New Authentication Applications . . . . . . 13
1.2.5. Application Authentication Procedures........ 14 1.2.4. Creating New Accounting Applications . . . . . . . . 14
1.3. Terminology........................................... 14 1.2.5. Application Authentication Procedures . . . . . . . 15
2. Protocol Overview............................................ 18 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 16
2.1. Transport............................................. 20 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1. SCTP Guidelines.............................. 21 2.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2. Securing Diameter Messages............................ 21 2.1.1. SCTP Guidelines . . . . . . . . . . . . . . . . . . 25
2.3. Diameter Application Compliance....................... 21 2.2. Securing Diameter Messages . . . . . . . . . . . . . . . 25
2.4. Application Identifiers............................... 22 2.3. Diameter Application Compliance . . . . . . . . . . . . . 25
2.5. Connections vs. Sessions.............................. 22 2.4. Application Identifiers . . . . . . . . . . . . . . . . . 26
2.6. Peer Table............................................ 23 2.5. Connections vs. Sessions . . . . . . . . . . . . . . . . 26
2.7. Realm-Based Routing Table............................. 24 2.6. Peer Table . . . . . . . . . . . . . . . . . . . . . . . 27
2.8. Role of Diameter Agents............................... 25 2.7. Realm-Based Routing Table . . . . . . . . . . . . . . . . 28
2.8.1. Relay Agents................................. 26 2.8. Role of Diameter Agents . . . . . . . . . . . . . . . . . 30
2.8.2. Proxy Agents................................. 27 2.8.1. Relay Agents . . . . . . . . . . . . . . . . . . . . 31
2.8.3. Redirect Agents.............................. 28 2.8.2. Proxy Agents . . . . . . . . . . . . . . . . . . . . 32
2.8.4. Translation Agents........................... 29 2.8.3. Redirect Agents . . . . . . . . . . . . . . . . . . 32
2.9. End-to-End Security Framework......................... 30 2.8.4. Translation Agents . . . . . . . . . . . . . . . . . 33
2.10. Diameter Path Authorization........................... 30 2.9. End-to-End Security Framework . . . . . . . . . . . . . . 34
3. Diameter Header.............................................. 32 2.10. Diameter Path Authorization . . . . . . . . . . . . . . . 35
3.1. Command Codes......................................... 35 3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 37
3.2. Command Code ABNF specification....................... 36 3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 40
3.3. Diameter Command Naming Conventions................... 38 3.2. Command Code ABNF specification . . . . . . . . . . . . . 41
4. Diameter AVPs................................................ 38 3.3. Diameter Command Naming Conventions . . . . . . . . . . . 43
4.1. AVP Header............................................ 39 4. Diameter AVPs . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.1. Optional Header Elements..................... 41 4.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 44
4.2. Basic AVP Data Formats................................ 41 4.1.1. Optional Header Elements . . . . . . . . . . . . . . 46
4.3. Derived AVP Data Formats.............................. 42 4.2. Basic AVP Data Formats . . . . . . . . . . . . . . . . . 46
4.4. Grouped AVP Values.................................... 49 4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 48
4.4.1. Example AVP with a Grouped Data Type......... 50 4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 56
4.5. Diameter Base Protocol AVPs........................... 53 4.4.1. Example AVP with a Grouped Data type . . . . . . . . 57
5. Diameter Peers............................................... 56 4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 60
5.1. Peer Connections...................................... 56 5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 63
5.2. Diameter Peer Discovery............................... 56 5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 63
5.3. Capabilities Exchange................................. 59 5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 63
5.3.1. Capabilities-Exchange-Request................ 60 5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 66
5.3.2. Capabilities-Exchange-Answer................. 60 5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 67
5.3.3. Vendor-Id AVP................................ 61 5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 68
5.3.4. Firmware-Revision AVP........................ 61 5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 68
5.3.5. Host-IP-Address AVP.......................... 62 5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 69
5.3.6. Supported-Vendor-Id AVP...................... 62 5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 69
5.3.7. Product-Name AVP............................. 62 5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 69
5.4. Disconnecting Peer Connections........................ 62 5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 69
5.4.1. Disconnect-Peer-Request...................... 63 5.4. Disconnecting Peer connections . . . . . . . . . . . . . 69
5.4.2. Disconnect-Peer-Answer....................... 63 5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 70
5.4.3. Disconnect-Cause AVP......................... 63 5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 70
5.5. Transport Failure Detection........................... 64 5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 71
5.5.1. Device-Watchdog-Request...................... 64 5.5. Transport Failure Detection . . . . . . . . . . . . . . . 71
5.5.2. Device-Watchdog-Answer....................... 64 5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 71
5.5.3. Transport Failure Algorithm.................. 65 5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 72
5.5.4. Failover and Failback Procedures............. 65 5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 72
5.6. Peer State Machine.................................... 66 5.5.4. Failover and Failback Procedures . . . . . . . . . . 72
5.6.1. Incoming connections......................... 68 5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 73
5.6.2. Events....................................... 69 5.6.1. Incoming connections . . . . . . . . . . . . . . . . 75
5.6.3. Actions...................................... 70 5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 76
5.6.4. The Election Process......................... 71 5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 77
6. Diameter Message Processing.................................. 71 5.6.4. The Election Process . . . . . . . . . . . . . . . . 79
6.1. Diameter Request Routing Overview..................... 71 5.6.5. Capabilities Update . . . . . . . . . . . . . . . . 79
6.1.1. Originating a Request........................ 73 6. Diameter message processing . . . . . . . . . . . . . . . . . 80
6.1.2. Sending a Request............................ 73 6.1. Diameter Request Routing Overview . . . . . . . . . . . . 80
6.1.3. Receiving Requests........................... 73 6.1.1. Originating a Request . . . . . . . . . . . . . . . 81
6.1.4. Processing Local Requests.................... 73 6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 82
6.1.5. Request Forwarding........................... 74 6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 82
6.1.6. Request Routing.............................. 74 6.1.4. Processing Local Requests . . . . . . . . . . . . . 82
6.1.7. Redirecting Requests......................... 74 6.1.5. Request Forwarding . . . . . . . . . . . . . . . . . 82
6.1.8. Relaying and Proxying Requests............... 75 6.1.6. Request Routing . . . . . . . . . . . . . . . . . . 83
6.2. Diameter Answer Processing............................ 76 6.1.7. Predictive Loop Avoidance . . . . . . . . . . . . . 83
6.2.1. Processing Received Answers.................. 77 6.1.8. Redirecting requests . . . . . . . . . . . . . . . . 83
6.2.2. Relaying and Proxying Answers................ 77 6.1.9. Relaying and Proxying Requests . . . . . . . . . . . 84
6.3. Origin-Host AVP....................................... 77 6.2. Diameter Answer Processing . . . . . . . . . . . . . . . 85
6.4. Origin-Realm AVP...................................... 78 6.2.1. Processing received Answers . . . . . . . . . . . . 86
6.5. Destination-Host AVP.................................. 78 6.2.2. Relaying and Proxying Answers . . . . . . . . . . . 86
6.6. Destination-Realm AVP................................. 78 6.3. Origin-Host AVP . . . . . . . . . . . . . . . . . . . . . 86
6.7. Routing AVPs.......................................... 78 6.4. Origin-Realm AVP . . . . . . . . . . . . . . . . . . . . 87
6.7.1. Route-Record AVP............................. 79 6.5. Destination-Host AVP . . . . . . . . . . . . . . . . . . 87
6.7.2. Proxy-Info AVP............................... 79 6.6. Destination-Realm AVP . . . . . . . . . . . . . . . . . . 87
6.7.3. Proxy-Host AVP............................... 79 6.7. Routing AVPs . . . . . . . . . . . . . . . . . . . . . . 88
6.7.4. Proxy-State AVP.............................. 79 6.7.1. Route-Record AVP . . . . . . . . . . . . . . . . . . 88
6.8. Auth-Application-Id AVP............................... 79 6.7.2. Proxy-Info AVP . . . . . . . . . . . . . . . . . . . 88
6.9. Acct-Application-Id AVP............................... 79 6.7.3. Proxy-Host AVP . . . . . . . . . . . . . . . . . . . 88
6.10. Inband-Security-Id AVP................................ 79 6.7.4. Proxy-State AVP . . . . . . . . . . . . . . . . . . 88
6.11. Vendor-Specific-Application-Id AVP.................... 80 6.8. Auth-Application-Id AVP . . . . . . . . . . . . . . . . . 88
6.12. Redirect-Host AVP..................................... 80 6.9. Acct-Application-Id AVP . . . . . . . . . . . . . . . . . 89
6.13. Redirect-Host-Usage AVP............................... 80 6.10. Inband-Security-Id AVP . . . . . . . . . . . . . . . . . 89
6.14. Redirect-Max-Cache-Time AVP........................... 81 6.11. Vendor-Specific-Application-Id AVP . . . . . . . . . . . 89
6.15. E2E-Sequence AVP...................................... 82 6.12. Redirect-Host AVP . . . . . . . . . . . . . . . . . . . . 90
7. Error Handling............................................... 82 6.13. Redirect-Host-Usage AVP . . . . . . . . . . . . . . . . . 90
7.1. Result-Code AVP....................................... 84 6.14. Redirect-Max-Cache-Time AVP . . . . . . . . . . . . . . . 91
7.1.1. Informational................................ 84 6.15. E2E-Sequence AVP . . . . . . . . . . . . . . . . . . . . 91
7.1.2. Success...................................... 84 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 93
7.1.3. Protocol Errors.............................. 85 7.1. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 95
7.1.4. Transient Failures........................... 86 7.1.1. Informational . . . . . . . . . . . . . . . . . . . 95
7.1.5. Permanent Failures........................... 86 7.1.2. Success . . . . . . . . . . . . . . . . . . . . . . 96
7.2. Error Bit............................................. 88 7.1.3. Protocol Errors . . . . . . . . . . . . . . . . . . 96
7.3. Error-Message AVP..................................... 89 7.1.4. Transient Failures . . . . . . . . . . . . . . . . . 97
7.4. Error-Reporting-Host AVP.............................. 89 7.1.5. Permanent Failures . . . . . . . . . . . . . . . . . 98
7.5. Failed-AVP AVP........................................ 89 7.2. Error Bit . . . . . . . . . . . . . . . . . . . . . . . . 101
7.6. Experimental-Result AVP............................... 90 7.3. Error-Message AVP . . . . . . . . . . . . . . . . . . . . 101
7.7. Experimental-Result-Code AVP.......................... 90 7.4. Error-Reporting-Host AVP . . . . . . . . . . . . . . . . 102
8. Diameter User Sessions....................................... 90 7.5. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . 102
8.1. Authorization Session State Machine................... 92 7.6. Experimental-Result AVP . . . . . . . . . . . . . . . . . 103
8.2. Accounting Session State Machine...................... 96 7.7. Experimental-Result-Code AVP . . . . . . . . . . . . . . 103
8.3. Server-Initiated Re-Auth.............................. 101 8. Diameter User Sessions . . . . . . . . . . . . . . . . . . . 104
8.3.1. Re-Auth-Request.............................. 102 8.1. Authorization Session State Machine . . . . . . . . . . . 105
8.3.2. Re-Auth-Answer............................... 102 8.2. Accounting Session State Machine . . . . . . . . . . . . 109
8.4. Session Termination................................... 103 8.3. Server-Initiated Re-Auth . . . . . . . . . . . . . . . . 115
8.4.1. Session-Termination-Request.................. 104 8.3.1. Re-Auth-Request . . . . . . . . . . . . . . . . . . 115
8.4.2. Session-Termination-Answer................... 105 8.3.2. Re-Auth-Answer . . . . . . . . . . . . . . . . . . . 116
8.5. Aborting a Session.................................... 105 8.4. Session Termination . . . . . . . . . . . . . . . . . . . 117
8.5.1. Abort-Session-Request........................ 106 8.4.1. Session-Termination-Request . . . . . . . . . . . . 118
8.5.2. Abort-Session-Answer......................... 106 8.4.2. Session-Termination-Answer . . . . . . . . . . . . . 118
8.6. Inferring Session Termination from Origin-State-Id.... 107 8.5. Aborting a Session . . . . . . . . . . . . . . . . . . . 119
8.7. Auth-Request-Type AVP................................. 108 8.5.1. Abort-Session-Request . . . . . . . . . . . . . . . 120
8.8. Session-Id AVP........................................ 108 8.5.2. Abort-Session-Answer . . . . . . . . . . . . . . . . 120
8.9. Authorization-Lifetime AVP............................ 109 8.6. Inferring Session Termination from Origin-State-Id . . . 121
8.10. Auth-Grace-Period AVP................................. 110 8.7. Auth-Request-Type AVP . . . . . . . . . . . . . . . . . . 122
8.11. Auth-Session-State AVP................................ 110 8.8. Session-Id AVP . . . . . . . . . . . . . . . . . . . . . 122
8.12. Re-Auth-Request-Type AVP.............................. 110 8.9. Authorization-Lifetime AVP . . . . . . . . . . . . . . . 123
8.13. Session-Timeout AVP................................... 111 8.10. Auth-Grace-Period AVP . . . . . . . . . . . . . . . . . . 124
8.14. User-Name AVP......................................... 111 8.11. Auth-Session-State AVP . . . . . . . . . . . . . . . . . 124
8.15. Termination-Cause AVP................................. 111 8.12. Re-Auth-Request-Type AVP . . . . . . . . . . . . . . . . 125
8.16. Origin-State-Id AVP................................... 112 8.13. Session-Timeout AVP . . . . . . . . . . . . . . . . . . . 125
8.17. Session-Binding AVP................................... 113 8.14. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 126
8.18. Session-Server-Failover AVP........................... 113 8.15. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 126
8.19. Multi-Round-Time-Out AVP.............................. 114 8.16. Origin-State-Id AVP . . . . . . . . . . . . . . . . . . . 127
8.20. Class AVP............................................. 114 8.17. Session-Binding AVP . . . . . . . . . . . . . . . . . . . 128
8.21. Event-Timestamp AVP................................... 115 8.18. Session-Server-Failover AVP . . . . . . . . . . . . . . . 128
9. Accounting................................................... 115 8.19. Multi-Round-Time-Out AVP . . . . . . . . . . . . . . . . 129
9.1. Server Directed Model................................. 115 8.20. Class AVP . . . . . . . . . . . . . . . . . . . . . . . . 129
9.2. Protocol Messages..................................... 116 8.21. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . . 130
9.3. Application Document Requirements..................... 116 9. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.4. Fault Resilience...................................... 116 9.1. Server Directed Model . . . . . . . . . . . . . . . . . . 131
9.5. Accounting Records.................................... 117 9.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 132
9.6. Correlation of Accounting Records..................... 118 9.3. Application document requirements . . . . . . . . . . . . 132
9.7. Accounting Command-Codes.............................. 119 9.4. Fault Resilience . . . . . . . . . . . . . . . . . . . . 132
9.7.1. Accounting-Request........................... 119 9.5. Accounting Records . . . . . . . . . . . . . . . . . . . 133
9.7.2. Accounting-Answer............................ 120 9.6. Correlation of Accounting Records . . . . . . . . . . . . 134
9.8. Accounting AVPs....................................... 121 9.7. Accounting Command-Codes . . . . . . . . . . . . . . . . 135
9.8.1. Accounting-Record-Type AVP................... 121 9.7.1. Accounting-Request . . . . . . . . . . . . . . . . . 135
9.8.2. Acct-Interim-Interval AVP.................... 122 9.7.2. Accounting-Answer . . . . . . . . . . . . . . . . . 136
9.8.3. Accounting-Record-Number AVP................. 123 9.8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 137
9.8.4. Acct-Session-Id AVP.......................... 123 9.8.1. Accounting-Record-Type AVP . . . . . . . . . . . . . 137
9.8.5. Acct-Multi-Session-Id AVP.................... 123 9.8.2. Acct-Interim-Interval . . . . . . . . . . . . . . . 138
9.8.6. Accounting-Sub-Session-Id AVP................ 123 9.8.3. Accounting-Record-Number AVP . . . . . . . . . . . . 138
9.8.7. Accounting-Realtime-Required AVP............. 123 9.8.4. Acct-Session-Id AVP . . . . . . . . . . . . . . . . 139
10. AVP Occurrence Table......................................... 124 9.8.5. Acct-Multi-Session-Id AVP . . . . . . . . . . . . . 139
10.1. Base Protocol Command AVP Table....................... 124 9.8.6. Accounting-Sub-Session-Id AVP . . . . . . . . . . . 139
10.2. Accounting AVP Table.................................. 126 9.8.7. Accounting-Realtime-Required AVP . . . . . . . . . . 139
11. IANA Considerations.......................................... 127 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 141
11.1. AVP Header............................................ 127 10.1. Base Protocol Command AVP Table . . . . . . . . . . . . . 141
11.1.1. AVP Code..................................... 127 10.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . 142
11.1.2. AVP Flags.................................... 128 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 144
11.2. Diameter Header....................................... 128 11.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 144
11.2.1. Command Codes................................ 128 11.1.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . 144
11.2.2. Command Flags................................ 129 11.1.2. AVP Flags . . . . . . . . . . . . . . . . . . . . . 145
11.3. Application Identifiers............................... 129 11.2. Diameter Header . . . . . . . . . . . . . . . . . . . . . 145
11.4. AVP Values............................................ 129 11.2.1. Command Codes . . . . . . . . . . . . . . . . . . . 145
11.4.1. Result-Code AVP Values....................... 129 11.2.2. Command Flags . . . . . . . . . . . . . . . . . . . 146
11.4.2. Accounting-Record-Type AVP Values............ 130 11.3. Application Identifiers . . . . . . . . . . . . . . . . . 146
11.4.3. Termination-Cause AVP Values................. 130 11.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . 146
11.4.4. Redirect-Host-Usage AVP Values............... 130 11.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . 147
11.4.5. Session-Server-Failover AVP Values........... 130 11.4.2. Accounting-Record-Type AVP Values . . . . . . . . . 147
11.4.6. Session-Binding AVP Values................... 130 11.4.3. Termination-Cause AVP Values . . . . . . . . . . . . 147
11.4.7. Disconnect-Cause AVP Values.................. 130 11.4.4. Redirect-Host-Usage AVP Values . . . . . . . . . . . 147
11.4.8. Auth-Request-Type AVP Values................. 130 11.4.5. Session-Server-Failover AVP Values . . . . . . . . . 147
11.4.9. Auth-Session-State AVP Values................ 130 11.4.6. Session-Binding AVP Values . . . . . . . . . . . . . 147
11.4.10. Re-Auth-Request-Type AVP Values.............. 131 11.4.7. Disconnect-Cause AVP Values . . . . . . . . . . . . 147
11.4.11. Accounting-Realtime-Required AVP Values...... 131 11.4.8. Auth-Request-Type AVP Values . . . . . . . . . . . . 147
11.5. Diameter TCP/SCTP Port Numbers........................ 131 11.4.9. Auth-Session-State AVP Values . . . . . . . . . . . 148
11.6. NAPTR Service Fields.................................. 131 11.4.10. Re-Auth-Request-Type AVP Values . . . . . . . . . . 148
12. Diameter Protocol Related Configurable Parameters............ 131 11.4.11. Accounting-Realtime-Required AVP Values . . . . . . 148
13. Security Considerations...................................... 132 11.4.12. Inband-Security-Id AVP (code 299) . . . . . . . . . 148
13.1. IPsec Usage........................................... 133 11.5. Diameter TCP/SCTP Port Numbers . . . . . . . . . . . . . 148
13.2. TLS Usage............................................. 134 11.6. NAPTR Service Fields . . . . . . . . . . . . . . . . . . 148
13.3. Peer-to-Peer Considerations........................... 134 12. Diameter protocol related configurable parameters . . . . . . 150
14. References................................................... 136 13. Security Considerations . . . . . . . . . . . . . . . . . . . 151
14.1. Normative References.................................. 136 13.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . 151
14.2. Informative References................................ 138 13.2. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 152
15. Acknowledgements............................................. 140 13.3. Peer-to-Peer Considerations . . . . . . . . . . . . . . . 153
Appendix A. Diameter Service Template........................... 141 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 155
Appendix B. NAPTR Example....................................... 142 14.1. Normative References . . . . . . . . . . . . . . . . . . 155
Appendix C. Duplicate Detection................................. 143 14.2. Informational References . . . . . . . . . . . . . . . . 157
Appendix D. Intellectual Property Statement..................... 145 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 160
Authors' Addresses............................................... 146 Appendix B. Diameter Service Template . . . . . . . . . . . . . 161
Full Copyright Statement......................................... 147 Appendix C. NAPTR Example . . . . . . . . . . . . . . . . . . . 163
Appendix D. Duplicate Detection . . . . . . . . . . . . . . . . 164
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 166
Intellectual Property and Copyright Statements . . . . . . . . . 167
1. Introduction 1. Introduction
Authentication, Authorization and Accounting (AAA) protocols such as Authentication, Authorization and Accounting (AAA) protocols such as
TACACS [TACACS] and RADIUS [RADIUS] were initially deployed to TACACS [RFC1492] and RADIUS [RFC2865] were initially deployed to
provide dial-up PPP [PPP] and terminal server access. Over time, provide dial-up PPP [RFC1661] and terminal server access. Over time,
with the growth of the Internet and the introduction of new access with the growth of the Internet and the introduction of new access
technologies, including wireless, DSL, Mobile IP and Ethernet, technologies, including wireless, DSL, Mobile IP and Ethernet,
routers and network access servers (NAS) have increased in complexity routers and network access servers (NAS) have increased in complexity
and density, putting new demands on AAA protocols. and density, putting new demands on AAA protocols.
Network access requirements for AAA protocols are summarized in Network access requirements for AAA protocols are summarized in
[AAAREQ]. These include: [RFC2989]. These include:
Failover Failover
[RADIUS] does not define failover mechanisms, and as a result,
[RFC2865] does not define failover mechanisms, and as a result,
failover behavior differs between implementations. In order to failover behavior differs between implementations. In order to
provide well defined failover behavior, Diameter supports provide well defined failover behavior, Diameter supports
application-layer acknowledgements, and defines failover application-layer acknowledgements, and defines failover
algorithms and the associated state machine. This is described in algorithms and the associated state machine. This is described in
Section 5.5 and [AAATRANS]. Section 5.5 and [RFC3539].
Transmission-level security Transmission-level security
[RADIUS] defines an application-layer authentication and integrity
scheme that is required only for use with Response packets. While [RFC2865] defines an application-layer authentication and
[RADEXT] defines an additional authentication and integrity integrity scheme that is required only for use with Response
mechanism, use is only required during Extensible Authentication packets. While [RFC2869] defines an additional authentication and
Protocol (EAP) sessions. While attribute-hiding is supported, integrity mechanism, use is only required during Extensible
[RADIUS] does not provide support for per-packet confidentiality. Authentication Protocol (EAP) sessions. While attribute-hiding is
In accounting, [RADACCT] assumes that replay protection is supported, [RFC2865] does not provide support for per-packet
provided by the backend billing server, rather than within the confidentiality. In accounting, [RFC2866] assumes that replay
protocol itself. protection is provided by the backend billing server, rather than
within the protocol itself.
While [RFC3162] defines the use of IPsec with RADIUS, support for While [RFC3162] defines the use of IPsec with RADIUS, support for
IPsec is not required. Since within [IKE] authentication occurs IPsec is not required. Since within [RFC2409] authentication
only within Phase 1 prior to the establishment of IPsec SAs in occurs only within Phase 1 prior to the establishment of IPsec SAs
Phase 2, it is typically not possible to define separate trust or in Phase 2, it is typically not possible to define separate trust
authorization schemes for each application. This limits the or authorization schemes for each application. This limits the
usefulness of IPsec in inter-domain AAA applications (such as usefulness of IPsec in inter-domain AAA applications (such as
roaming) where it may be desirable to define a distinct roaming) where it may be desirable to define a distinct
certificate hierarchy for use in a AAA deployment. In order to certificate hierarchy for use in a AAA deployment. In order to
provide universal support for transmission-level security, and provide universal support for transmission-level security, and
enable both intra- and inter-domain AAA deployments, IPsec support enable both intra- and inter-domain AAA deployments, IPsec support
is mandatory in Diameter, and TLS support is optional. Security is mandatory in Diameter, and TLS support is optional. Security
is discussed in Section 13. is discussed in Section 13.
Reliable transport Reliable transport
RADIUS runs over UDP, and does not define retransmission behavior; RADIUS runs over UDP, and does not define retransmission behavior;
as a result, reliability varies between implementations. As as a result, reliability varies between implementations. As
described in [ACCMGMT], this is a major issue in accounting, where described in [RFC2975], this is a major issue in accounting, where
packet loss may translate directly into revenue loss. In order to packet loss may translate directly into revenue loss. In order to
provide well defined transport behavior, Diameter runs over provide well defined transport behavior, Diameter runs over
reliable transport mechanisms (TCP, SCTP) as defined in reliable transport mechanisms (TCP, SCTP) as defined in [RFC3539].
[AAATRANS].
Agent support Agent support
[RADIUS] does not provide for explicit support for agents,
[RFC2865] does not provide for explicit support for agents,
including Proxies, Redirects and Relays. Since the expected including Proxies, Redirects and Relays. Since the expected
behavior is not defined, it varies between implementations. behavior is not defined, it varies between implementations.
Diameter defines agent behavior explicitly; this is described in Diameter defines agent behavior explicitly; this is described in
Section 2.8. Section 2.8.
Server-initiated messages Server-initiated messages
While RADIUS server-initiated messages are defined in [DYNAUTH],
While RADIUS server-initiated messages are defined in [RFC3576],
support is optional. This makes it difficult to implement support is optional. This makes it difficult to implement
features such as unsolicited disconnect or features such as unsolicited disconnect or reauthentication/
reauthentication/reauthorization on demand across a heterogeneous reauthorization on demand across a heterogeneous deployment.
deployment. Support for server-initiated messages is mandatory in Support for server-initiated messages is mandatory in Diameter,
Diameter, and is described in Section 8. and is described in Section 8.
Auditability Auditability
RADIUS does not define data-object security mechanisms, and as a RADIUS does not define data-object security mechanisms, and as a
result, untrusted proxies may modify attributes or even packet result, untrusted proxies may modify attributes or even packet
headers without being detected. Combined with lack of support for headers without being detected. Combined with lack of support for
capabilities negotiation, this makes it very difficult to capabilities negotiation, this makes it very difficult to
determine what occurred in the event of a dispute. While determine what occurred in the event of a dispute. While
implementation of data object security is not mandatory within implementation of data object security is not mandatory within
Diameter, these capabilities are supported, and are described in Diameter, these capabilities are supported, and are described in
[AAACMS]. [AAACMS].
Transition support Transition support
skipping to change at page 7, line 40 skipping to change at page 8, line 43
RADIUS does not define data-object security mechanisms, and as a RADIUS does not define data-object security mechanisms, and as a
result, untrusted proxies may modify attributes or even packet result, untrusted proxies may modify attributes or even packet
headers without being detected. Combined with lack of support for headers without being detected. Combined with lack of support for
capabilities negotiation, this makes it very difficult to capabilities negotiation, this makes it very difficult to
determine what occurred in the event of a dispute. While determine what occurred in the event of a dispute. While
implementation of data object security is not mandatory within implementation of data object security is not mandatory within
Diameter, these capabilities are supported, and are described in Diameter, these capabilities are supported, and are described in
[AAACMS]. [AAACMS].
Transition support Transition support
While Diameter does not share a common protocol data unit (PDU) While Diameter does not share a common protocol data unit (PDU)
with RADIUS, considerable effort has been expended in enabling with RADIUS, considerable effort has been expended in enabling
backward compatibility with RADIUS, so that the two protocols may backward compatibility with RADIUS, so that the two protocols may
be deployed in the same network. Initially, it is expected that be deployed in the same network. Initially, it is expected that
Diameter will be deployed within new network devices, as well as Diameter will be deployed within new network devices, as well as
within gateways enabling communication between legacy RADIUS within gateways enabling communication between legacy RADIUS
devices and Diameter agents. This capability, described in devices and Diameter agents. This capability, described in
[NASREQ], enables Diameter support to be added to legacy networks, [RFC4005], enables Diameter support to be added to legacy
by addition of a gateway or server speaking both RADIUS and networks, by addition of a gateway or server speaking both RADIUS
Diameter. and Diameter.
In addition to addressing the above requirements, Diameter also In addition to addressing the above requirements, Diameter also
provides support for the following: provides support for the following:
Capability negotiation Capability negotiation
RADIUS does not support error messages, capability negotiation, or RADIUS does not support error messages, capability negotiation, or
a mandatory/non-mandatory flag for attributes. Since RADIUS a mandatory/non-mandatory flag for attributes. Since RADIUS
clients and servers are not aware of each other's capabilities, clients and servers are not aware of each other's capabilities,
they may not be able to successfully negotiate a mutually they may not be able to successfully negotiate a mutually
acceptable service, or in some cases, even be aware of what acceptable service, or in some cases, even be aware of what
service has been implemented. Diameter includes support for error service has been implemented. Diameter includes support for error
handling (Section 7), capability negotiation (Section 5.3), and handling (Section 7), capability negotiation (Section 5.3), and
mandatory/non-mandatory attribute-value pairs (AVPs) (Section mandatory/non-mandatory attribute-value pairs (AVPs) (Section
4.1). 4.1).
skipping to change at page 8, line 20 skipping to change at page 9, line 27
a mandatory/non-mandatory flag for attributes. Since RADIUS a mandatory/non-mandatory flag for attributes. Since RADIUS
clients and servers are not aware of each other's capabilities, clients and servers are not aware of each other's capabilities,
they may not be able to successfully negotiate a mutually they may not be able to successfully negotiate a mutually
acceptable service, or in some cases, even be aware of what acceptable service, or in some cases, even be aware of what
service has been implemented. Diameter includes support for error service has been implemented. Diameter includes support for error
handling (Section 7), capability negotiation (Section 5.3), and handling (Section 7), capability negotiation (Section 5.3), and
mandatory/non-mandatory attribute-value pairs (AVPs) (Section mandatory/non-mandatory attribute-value pairs (AVPs) (Section
4.1). 4.1).
Peer discovery and configuration Peer discovery and configuration
RADIUS implementations typically require that the name or address RADIUS implementations typically require that the name or address
of servers or clients be manually configured, along with the of servers or clients be manually configured, along with the
corresponding shared secrets. This results in a large corresponding shared secrets. This results in a large
administrative burden, and creates the temptation to reuse the administrative burden, and creates the temptation to reuse the
RADIUS shared secret, which can result in major security RADIUS shared secret, which can result in major security
vulnerabilities if the Request Authenticator is not globally and vulnerabilities if the Request Authenticator is not globally and
temporally unique as required in [RADIUS]. Through DNS, Diameter temporally unique as required in [RFC2865]. Through DNS, Diameter
enables dynamic discovery of peers. Derivation of dynamic session enables dynamic discovery of peers. Derivation of dynamic session
keys is enabled via transmission-level security. keys is enabled via transmission-level security.
Roaming support Roaming support
The ROAMOPS WG provided a survey of roaming implementations The ROAMOPS WG provided a survey of roaming implementations
[ROAMREV], detailed roaming requirements [ROAMCRIT], defined the [RFC2194], detailed roaming requirements [RFC2477], defined the
Network Access Identifier (NAI) [NAI], and documented existing Network Access Identifier (NAI)[RFC4282], and documented existing
implementations (and imitations) of RADIUS-based roaming implementations (and imitations) of RADIUS-based roaming
[PROXYCHAIN]. In order to improve scalability, [PROXYCHAIN] [RFC2607]. In order to improve scalability, [RFC2607] introduced
introduced the concept of proxy chaining via an intermediate the concept of proxy chaining via an intermediate server,
server, facilitating roaming between providers. However, since facilitating roaming between providers. However, since RADIUS
RADIUS does not provide explicit support for proxies, and lacks does not provide explicit support for proxies, and lacks
auditability and transmission-level security features, RADIUS- auditability and transmission-level security features, RADIUS-
based roaming is vulnerable to attack from external parties as based roaming is vulnerable to attack from external parties as
well as susceptible to fraud perpetrated by the roaming partners well as susceptible to fraud perpetrated by the roaming partners
themselves. As a result, it is not suitable for wide-scale themselves. As a result, it is not suitable for wide-scale
deployment on the Internet [PROXYCHAIN]. By providing explicit deployment on the Internet [RFC2607]. By providing explicit
support for inter-domain roaming and message routing (Sections 2.7 support for inter-domain roaming and message routing (Sections 2.7
and 6), auditability [AAACMS], and transmission-layer security and 6), auditability [AAACMS], and transmission-layer security
(Section 13) features, Diameter addresses these limitations and (Section 13) features, Diameter addresses these limitations and
provides for secure and scalable roaming. provides for secure and scalable roaming.
In the decade since AAA protocols were first introduced, the In the decade since AAA protocols were first introduced, the
capabilities of Network Access Server (NAS) devices have increased capabilities of Network Access Server (NAS) devices have increased
substantially. As a result, while Diameter is a considerably more substantially. As a result, while Diameter is a considerably more
sophisticated protocol than RADIUS, it remains feasible to implement sophisticated protocol than RADIUS, it remains feasible to implement
within embedded devices, given improvements in processor speeds and within embedded devices, given improvements in processor speeds and
the widespread availability of embedded IPsec and TLS the widespread availability of embedded IPsec and TLS
implementations. implementations.
1.1. Diameter Protocol 1.1. Diameter Protocol
The Diameter base protocol provides the following facilities: The Diameter base protocol provides the following facilities:
- Delivery of AVPs (attribute value pairs) o Delivery of AVPs (attribute value pairs)
- Capabilities negotiation
- Error notification o Capabilities negotiation
- Extensibility, through addition of new commands and AVPs (required
in [AAAREQ]). o Error notification
- Basic services necessary for applications, such as handling of
o Extensibility, through addition of new commands and AVPs (required
in [RFC2989]).
o Basic services necessary for applications, such as handling of
user sessions or accounting user sessions or accounting
All data delivered by the protocol is in the form of an AVP. Some of All data delivered by the protocol is in the form of an AVP. Some of
these AVP values are used by the Diameter protocol itself, while these AVP values are used by the Diameter protocol itself, while
others deliver data associated with particular applications that others deliver data associated with particular applications that
employ Diameter. AVPs may be added arbitrarily to Diameter messages, employ Diameter. AVPs may be added arbitrarily to Diameter messages,
so long as the required AVPs are included and AVPs that are so long as the required AVPs are included and AVPs that are
explicitly excluded are not included. AVPs are used by the base explicitly excluded are not included. AVPs are used by the base
Diameter protocol to support the following required features: Diameter protocol to support the following required features:
- Transporting of user authentication information, for the purposes o Transporting of user authentication information, for the purposes
of enabling the Diameter server to authenticate the user. of enabling the Diameter server to authenticate the user.
- Transporting of service specific authorization information, o Transporting of service specific authorization information,
between client and servers, allowing the peers to decide whether a between client and servers, allowing the peers to decide whether a
user's access request should be granted. user's access request should be granted.
- Exchanging resource usage information, which MAY be used for o Exchanging resource usage information, which MAY be used for
accounting purposes, capacity planning, etc. accounting purposes, capacity planning, etc.
- Relaying, proxying and redirecting of Diameter messages through a o Relaying, proxying and redirecting of Diameter messages through a
server hierarchy. server hierarchy.
The Diameter base protocol provides the minimum requirements needed The Diameter base protocol provides the minimum requirements needed
for a AAA protocol, as required by [AAAREQ]. The base protocol may for a AAA protocol, as required by [RFC2989]. The base protocol may
be used by itself for accounting purposes only, or it may be used be used by itself for accounting purposes only, or it may be used
with a Diameter application, such as Mobile IPv4 [DIAMMIP], or with a Diameter application, such as Mobile IPv4 [RFC4004], or
network access [NASREQ]. It is also possible for the base protocol network access [RFC4005]. It is also possible for the base protocol
to be extended for use in new applications, via the addition of new to be extended for use in new applications, via the addition of new
commands or AVPs. At this time the focus of Diameter is network commands or AVPs. At this time the focus of Diameter is network
access and accounting applications. A truly generic AAA protocol access and accounting applications. A truly generic AAA protocol
used by many applications might provide functionality not provided by used by many applications might provide functionality not provided by
Diameter. Therefore, it is imperative that the designers of new Diameter. Therefore, it is imperative that the designers of new
applications understand their requirements before using Diameter. applications understand their requirements before using Diameter.
See Section 2.4 for more information on Diameter applications. See Section 2.4 for more information on Diameter applications.
Any node can initiate a request. In that sense, Diameter is a peer- Any node can initiate a request. In that sense, Diameter is a peer-
to-peer protocol. In this document, a Diameter Client is a device at to-peer protocol. In this document, a Diameter Client is a device at
the edge of the network that performs access control, such as a the edge of the network that performs access control, such as a
Network Access Server (NAS) or a Foreign Agent (FA). A Diameter Network Access Server (NAS) or a Foreign Agent (FA). A Diameter
client generates Diameter messages to request authentication, client generates Diameter messages to request authentication,
authorization, and accounting services for the user. A Diameter authorization, and accounting services for the user. A Diameter
agent is a node that does not authenticate and/or authorize messages agent is a node that does not authenticate and/or authorize messages
locally; agents include proxies, redirects and relay agents. A locally; agents include proxies, redirects and relay agents. A
skipping to change at page 10, line 25 skipping to change at page 11, line 42
Diameter server performs authentication and/or authorization of the Diameter server performs authentication and/or authorization of the
user. A Diameter node MAY act as an agent for certain requests while user. A Diameter node MAY act as an agent for certain requests while
acting as a server for others. acting as a server for others.
The Diameter protocol also supports server-initiated messages, such The Diameter protocol also supports server-initiated messages, such
as a request to abort service to a particular user. as a request to abort service to a particular user.
1.1.1. Description of the Document Set 1.1.1. Description of the Document Set
Currently, the Diameter specification consists of a base Currently, the Diameter specification consists of a base
specification (this document), Transport Profile [AAATRANS] and specification (this document), Transport Profile [RFC3539] and
applications: Mobile IPv4 [DIAMMIP], and NASREQ [NASREQ]. applications: Mobile IPv4 [RFC4004], NASREQ [RFC4005], Credit Control
[RFC4006], EAP [RFC4072] and SIP [RFC4740].
The Transport Profile document [AAATRANS] discusses transport layer The Transport Profile document [RFC3539] discusses transport layer
issues that arise with AAA protocols and recommendations on how to issues that arise with AAA protocols and recommendations on how to
overcome these issues. This document also defines the Diameter overcome these issues. This document also defines the Diameter
failover algorithm and state machine. failover algorithm and state machine.
The Mobile IPv4 [DIAMMIP] application defines a Diameter application The Mobile IPv4 [RFC4004] application defines a Diameter application
that allows a Diameter server to perform AAA functions for Mobile that allows a Diameter server to perform AAA functions for Mobile
IPv4 services to a mobile node. IPv4 services to a mobile node.
The NASREQ [NASREQ] application defines a Diameter Application that The NASREQ [RFC4005] application defines a Diameter Application that
allows a Diameter server to be used in a PPP/SLIP Dial-Up and allows a Diameter server to be used in a PPP/SLIP Dial-Up and
Terminal Server Access environment. Consideration was given for Terminal Server Access environment. Consideration was given for
servers that need to perform protocol conversion between Diameter and servers that need to perform protocol conversion between Diameter and
RADIUS. RADIUS.
The Credit Control [RFC4006] application defines a Diameter
Application that can be used to implement real-time credit-control
for a variety of end user services such as network access, SIP
services, messaging services, and download services. It provides a
general solution to real-time cost and credit-control.
The EAP [RFC4072] application defines a Diameter Application that can
be used to carry EAP packets between the Network Access Server (NAS)
working as an EAP authenticator and a back-end authentication server.
The Diameter EAP application is based on NASREQ and intended for a
similar environment.
The SIP [RFC4740] application defines a Diameter Application that
allows a Diameter client to request authentication and authorization
information to a Diameter server for SIP-based IP multimedia services
(see SIP [RFC3261]).
In summary, this document defines the base protocol specification for In summary, this document defines the base protocol specification for
AAA, which includes support for accounting. The Mobile IPv4 and the AAA, which includes support for accounting. The applications
NASREQ documents describe applications that use this base documents describe applications that use this base specification for
specification for Authentication, Authorization and Accounting. Authentication, Authorization and Accounting.
1.1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Approach to Extensibility 1.2. Approach to Extensibility
The Diameter protocol is designed to be extensible, using several The Diameter protocol is designed to be extensible, using several
mechanisms, including: mechanisms, including:
- Defining new AVP values o Defining new AVP values
- Creating new AVPs
- Creating new authentication/authorization applications o Creating new AVPs
- Creating new accounting applications
- Application authentication procedures o Creating new authentication/authorization applications
o Creating new accounting applications
o Application authentication procedures
Reuse of existing AVP values, AVPs and Diameter applications are Reuse of existing AVP values, AVPs and Diameter applications are
strongly recommended. Reuse simplifies standardization and strongly recommended. Reuse simplifies standardization and
implementation and avoids potential interoperability issues. It is implementation and avoids potential interoperability issues. It is
expected that command codes are reused; new command codes can only be expected that command codes are reused; new command codes can only be
created by IETF Consensus (see Section 11.2.1). created by IETF Consensus (see Section 11.2.1).
1.2.1. Defining New AVP Values 1.2.1. Defining New AVP Values
New applications should attempt to reuse AVPs defined in existing New applications should attempt to reuse AVPs defined in existing
applications when possible, as opposed to creating new AVPs. For applications when possible, as opposed to creating new AVPs. For
AVPs of type Enumerated, an application may require a new value to AVPs of type Enumerated, an application may require a new value to
communicate some service-specific information. communicate some service-specific information.
In order to allocate a new AVP value, a request MUST be sent to IANA In order to allocate a new AVP value, a request MUST be sent to IANA
[IANA], along with an explanation of the new AVP value. IANA [RFC2434], along with an explanation of the new AVP value. IANA
considerations for Diameter are discussed in Section 11. considerations for Diameter are discussed in Section 11.
1.2.2. Creating New AVPs 1.2.2. Creating New AVPs
When no existing AVP can be used, a new AVP should be created. The When no existing AVP can be used, a new AVP should be created. The
new AVP being defined MUST use one of the data types listed in new AVP being defined MUST use one of the data types listed in
Section 4.2. Section 4.2.
In the event that a logical grouping of AVPs is necessary, and In the event that a logical grouping of AVPs is necessary, and
multiple "groups" are possible in a given command, it is recommended multiple "groups" are possible in a given command, it is recommended
that a Grouped AVP be used (see Section 4.4). that a Grouped AVP be used (see Section 4.4).
In order to create a new AVP, a request MUST be sent to IANA, with a In order to create a new AVP, a request MUST be sent to IANA, with a
specification for the AVP. The request MUST include the commands specification for the AVP. The request MUST include the commands
that would make use of the AVP. that would make use of the AVP.
1.2.3. Creating New Authentication Applications 1.2.3. Creating New Authentication Applications
Every Diameter application specification MUST have an IANA assigned Every Diameter application specification MUST have an IANA assigned
Application Identifier (see Section 2.4) or a vendor specific Application Identifier (see Section 2.4 and Section 11.3).
Application Identifier.
Should a new Diameter usage scenario find itself unable to fit within Should a new Diameter usage scenario find itself unable to fit within
an existing application without requiring major changes to the an existing application without requiring major changes to the
specification, it may be desirable to create a new Diameter specification, it may be desirable to create a new Diameter
application. Major changes to an application include: application. Major changes to an application include:
- Adding new AVPs to the command, which have the "M" bit set. o Adding new AVPs to the command, which have the "M" bit set.
- Requiring a command that has a different number of round trips to o Requiring a command that has a different number of round trips to
satisfy a request (e.g., application foo has a command that satisfy a request (e.g., application foo has a command that
requires one round trip, but new application bar has a command requires one round trip, but new application bar has a command
that requires two round trips to complete). that requires two round trips to complete).
- Adding support for an authentication method requiring definition o Adding support for an authentication method requiring definition
of new AVPs for use with the application. Since a new EAP of new AVPs for use with the application. Since a new EAP
authentication method can be supported within Diameter without authentication method can be supported within Diameter without
requiring new AVPs, addition of EAP methods does not require the requiring new AVPs, addition of EAP methods does not require the
creation of a new authentication application. creation of a new authentication application.
Creation of a new application should be viewed as a last resort. An Creation of a new application should be viewed as a last resort. An
implementation MAY add arbitrary non-mandatory AVPs to any command implementation MAY add arbitrary non-mandatory AVPs to any command
defined in an application, including vendor-specific AVPs without defined in an application, including vendor-specific AVPs without
needing to define a new application. Please refer to Section 11.1.1 needing to define a new application. Please refer to Section 11.1.1
for details. for details.
In order to justify allocation of a new application identifier, In order to justify allocation of a new application identifier,
Diameter applications MUST define one Command Code, or add new Diameter applications MUST define one Command Code, or add new
mandatory AVPs to the ABNF. mandatory AVPs to the ABNF.
The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see The expected AVPs MUST be defined in an ABNF [RFC2234] grammar (see
Section 3.2). If the Diameter application has accounting Section 3.2). If the Diameter application has accounting
requirements, it MUST also specify the AVPs that are to be present in requirements, it MUST also specify the AVPs that are to be present in
the Diameter Accounting messages (see Section 9.3). However, just the Diameter Accounting messages (see Section 9.3). However, just
because a new authentication application id is required, does not because a new authentication application id is required, does not
imply that a new accounting application id is required. imply that a new accounting application id is required.
When possible, a new Diameter application SHOULD reuse existing When possible, a new Diameter application SHOULD reuse existing
Diameter AVPs, in order to avoid defining multiple AVPs that carry Diameter AVPs, in order to avoid defining multiple AVPs that carry
similar information. similar information.
skipping to change at page 14, line 12 skipping to change at page 15, line 49
machine), then the base protocol defined standard accounting machine), then the base protocol defined standard accounting
application Id (Section 2.4) MUST be used in ACR/ACA commands. application Id (Section 2.4) MUST be used in ACR/ACA commands.
1.2.5. Application Authentication Procedures 1.2.5. Application Authentication Procedures
When possible, applications SHOULD be designed such that new When possible, applications SHOULD be designed such that new
authentication methods MAY be added without requiring changes to the authentication methods MAY be added without requiring changes to the
application. This MAY require that new AVP values be assigned to application. This MAY require that new AVP values be assigned to
represent the new authentication transform, or any other scheme that represent the new authentication transform, or any other scheme that
produces similar results. When possible, authentication frameworks, produces similar results. When possible, authentication frameworks,
such as Extensible Authentication Protocol [EAP], SHOULD be used. such as Extensible Authentication Protocol [RFC2284], SHOULD be used.
1.3. Terminology 1.3. Terminology
AAA AAA
Authentication, Authorization and Accounting. Authentication, Authorization and Accounting.
Accounting Accounting
The act of collecting information on resource usage for the The act of collecting information on resource usage for the
purpose of capacity planning, auditing, billing or cost purpose of capacity planning, auditing, billing or cost
allocation. allocation.
Accounting Record Accounting Record
An accounting record represents a summary of the resource An accounting record represents a summary of the resource
consumption of a user over the entire session. Accounting servers consumption of a user over the entire session. Accounting servers
creating the accounting record may do so by processing interim creating the accounting record may do so by processing interim
accounting events or accounting events from several devices accounting events or accounting events from several devices
serving the same user. serving the same user.
Authentication Authentication
The act of verifying the identity of an entity (subject). The act of verifying the identity of an entity (subject).
Authorization Authorization
The act of determining whether a requesting entity (subject) will The act of determining whether a requesting entity (subject) will
be allowed access to a resource (object). be allowed access to a resource (object).
AVP AVP
The Diameter protocol consists of a header followed by one or more The Diameter protocol consists of a header followed by one or more
Attribute-Value-Pairs (AVPs). An AVP includes a header and is Attribute-Value-Pairs (AVPs). An AVP includes a header and is
used to encapsulate protocol-specific data (e.g., routing used to encapsulate protocol-specific data (e.g., routing
information) as well as authentication, authorization or information) as well as authentication, authorization or
accounting information. accounting information.
Broker Broker
A broker is a business term commonly used in AAA infrastructures. A broker is a business term commonly used in AAA infrastructures.
A broker is either a relay, proxy or redirect agent, and MAY be A broker is either a relay, proxy or redirect agent, and MAY be
operated by roaming consortiums. Depending on the business model, operated by roaming consortiums. Depending on the business model,
a broker may either choose to deploy relay agents or proxy a broker may either choose to deploy relay agents or proxy agents.
agents.
Diameter Agent Diameter Agent
A Diameter Agent is a Diameter node that provides either relay, A Diameter Agent is a Diameter node that provides either relay,
proxy, redirect or translation services. proxy, redirect or translation services.
Diameter Client Diameter Client
A Diameter Client is a device at the edge of the network that A Diameter Client is a device at the edge of the network that
performs access control. An example of a Diameter client is a performs access control. An example of a Diameter client is a
Network Access Server (NAS) or a Foreign Agent (FA). Network Access Server (NAS) or a Foreign Agent (FA).
Diameter Node Diameter Node
A Diameter node is a host process that implements the Diameter A Diameter node is a host process that implements the Diameter
protocol, and acts either as a Client, Agent or Server. protocol, and acts either as a Client, Agent or Server.
Diameter Peer Diameter Peer
A Diameter Peer is a Diameter Node to which a given Diameter Node A Diameter Peer is a Diameter Node to which a given Diameter Node
has a direct transport connection. has a direct transport connection.
Diameter Security Exchange Diameter Security Exchange
A Diameter Security Exchange is a process through which two A Diameter Security Exchange is a process through which two
Diameter nodes establish end-to-end security. Diameter nodes establish end-to-end security.
Diameter Server Diameter Server
A Diameter Server is one that handles authentication, A Diameter Server is one that handles authentication,
authorization and accounting requests for a particular realm. By authorization and accounting requests for a particular realm. By
its very nature, a Diameter Server MUST support Diameter its very nature, a Diameter Server MUST support Diameter
applications in addition to the base protocol. applications in addition to the base protocol.
Downstream Downstream
Downstream is used to identify the direction of a particular Downstream is used to identify the direction of a particular
Diameter message from the home server towards the access device. Diameter message from the home server towards the access device.
End-to-End Security End-to-End Security
TLS and IPsec provide hop-by-hop security, or security across a TLS and IPsec provide hop-by-hop security, or security across a
transport connection. When relays or proxy are involved, this transport connection. When relays or proxy are involved, this
hop-by-hop security does not protect the entire Diameter user hop-by-hop security does not protect the entire Diameter user
session. End-to-end security is security between two Diameter session. End-to-end security is security between two Diameter
nodes, possibly communicating through Diameter Agents. This nodes, possibly communicating through Diameter Agents. This
security protects the entire Diameter communications path from the security protects the entire Diameter communications path from the
originating Diameter node to the terminating Diameter node. originating Diameter node to the terminating Diameter node.
Home Realm Home Realm
A Home Realm is the administrative domain with which the user A Home Realm is the administrative domain with which the user
maintains an account relationship. maintains an account relationship.
Home Server Home Server
See Diameter Server. See Diameter Server.
Interim accounting Interim accounting
An interim accounting message provides a snapshot of usage during An interim accounting message provides a snapshot of usage during
a user's session. It is typically implemented in order to provide a user's session. It is typically implemented in order to provide
for partial accounting of a user's session in the case of a device for partial accounting of a user's session in the case of a device
reboot or other network problem prevents the reception of a reboot or other network problem prevents the reception of a
session summary message or session record. session summary message or session record.
Local Realm Local Realm
A local realm is the administrative domain providing services to a A local realm is the administrative domain providing services to a
user. An administrative domain MAY act as a local realm for user. An administrative domain MAY act as a local realm for
certain users, while being a home realm for others. certain users, while being a home realm for others.
Multi-session Multi-session
A multi-session represents a logical linking of several sessions. A multi-session represents a logical linking of several sessions.
Multi-sessions are tracked by using the Acct-Multi-Session-Id. An Multi-sessions are tracked by using the Acct-Multi-Session-Id. An
example of a multi-session would be a Multi-link PPP bundle. Each example of a multi-session would be a Multi-link PPP bundle. Each
leg of the bundle would be a session while the entire bundle would leg of the bundle would be a session while the entire bundle would
be a multi-session. be a multi-session.
Network Access Identifier Network Access Identifier
The Network Access Identifier, or NAI [NAI], is used in the
The Network Access Identifier, or NAI [RFC4282], is used in the
Diameter protocol to extract a user's identity and realm. The Diameter protocol to extract a user's identity and realm. The
identity is used to identify the user during authentication and/or identity is used to identify the user during authentication and/or
authorization, while the realm is used for message routing authorization, while the realm is used for message routing
purposes. purposes.
Proxy Agent or Proxy Proxy Agent or Proxy
In addition to forwarding requests and responses, proxies make In addition to forwarding requests and responses, proxies make
policy decisions relating to resource usage and provisioning. policy decisions relating to resource usage and provisioning.
This is typically accomplished by tracking the state of NAS This is typically accomplished by tracking the state of NAS
devices. While proxies typically do not respond to client devices. While proxies typically do not respond to client
Requests prior to receiving a Response from the server, they may Requests prior to receiving a Response from the server, they may
originate Reject messages in cases where policies are violated. originate Reject messages in cases where policies are violated.
As a result, proxies need to understand the semantics of the As a result, proxies need to understand the semantics of the
messages passing through them, and may not support all Diameter messages passing through them, and may not support all Diameter
applications. applications.
skipping to change at page 18, line 30 skipping to change at page 21, line 27
The Diameter protocol requires that agents maintain transaction The Diameter protocol requires that agents maintain transaction
state, which is used for failover purposes. Transaction state state, which is used for failover purposes. Transaction state
implies that upon forwarding a request, the Hop-by-Hop identifier implies that upon forwarding a request, the Hop-by-Hop identifier
is saved; the field is replaced with a locally unique identifier, is saved; the field is replaced with a locally unique identifier,
which is restored to its original value when the corresponding which is restored to its original value when the corresponding
answer is received. The request's state is released upon receipt answer is received. The request's state is released upon receipt
of the answer. A stateless agent is one that only maintains of the answer. A stateless agent is one that only maintains
transaction state. transaction state.
Translation Agent Translation Agent
A translation agent is a stateful Diameter node that performs A translation agent is a stateful Diameter node that performs
protocol translation between Diameter and another AAA protocol, protocol translation between Diameter and another AAA protocol,
such as RADIUS. such as RADIUS.
Transport Connection Transport Connection
A transport connection is a TCP or SCTP connection existing A transport connection is a TCP or SCTP connection existing
directly between two Diameter peers, otherwise known as a Peer- directly between two Diameter peers, otherwise known as a Peer-
to-Peer Connection. to-Peer Connection.
Upstream Upstream
Upstream is used to identify the direction of a particular Upstream is used to identify the direction of a particular
Diameter message from the access device towards the home server. Diameter message from the access device towards the home server.
User User
The entity requesting or using some resource, in support of which The entity requesting or using some resource, in support of which
a Diameter client has generated a request. a Diameter client has generated a request.
2. Protocol Overview 2. Protocol Overview
The base Diameter protocol may be used by itself for accounting The base Diameter protocol may be used by itself for accounting
applications, but for use in authentication and authorization it is applications, but for use in authentication and authorization it is
always extended for a particular application. Two Diameter always extended for a particular application. Two Diameter
applications are defined by companion documents: NASREQ [NASREQ], applications are defined by companion documents: NASREQ [RFC4005],
Mobile IPv4 [DIAMMIP]. These applications are introduced in this Mobile IPv4 [RFC4004]. These applications are introduced in this
document but specified elsewhere. Additional Diameter applications document but specified elsewhere. Additional Diameter applications
MAY be defined in the future (see Section 11.3). MAY be defined in the future (see Section 11.3).
Diameter Clients MUST support the base protocol, which includes Diameter Clients MUST support the base protocol, which includes
accounting. In addition, they MUST fully support each Diameter accounting. In addition, they MUST fully support each Diameter
application that is needed to implement the client's service, e.g., application that is needed to implement the client's service, e.g.,
NASREQ and/or Mobile IPv4. A Diameter Client that does not support NASREQ and/or Mobile IPv4. A Diameter Client that 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
Client" where X is the application which it supports, and not a Client" where X is the application which it supports, and not a
"Diameter Client". "Diameter Client".
skipping to change at page 20, line 16 skipping to change at page 24, line 22
application employed. application employed.
Session state (associated with a Session-Id) MUST be freed upon Session state (associated with a Session-Id) MUST be freed upon
receipt of the Session-Termination-Request, Session-Termination- receipt of the Session-Termination-Request, Session-Termination-
Answer, expiration of authorized service time in the Session-Timeout Answer, expiration of authorized service time in the Session-Timeout
AVP, and according to rules established in a particular Diameter AVP, and according to rules established in a particular Diameter
application. application.
2.1. Transport 2.1. Transport
Transport profile is defined in [AAATRANS]. Transport profile is defined in [RFC3539].
The base Diameter protocol is run on port 3868 of both TCP [TCP] and The base Diameter protocol is run on port 3868 of both TCP [TCP] and
SCTP [SCTP] transport protocols. SCTP [RFC2960] transport protocols.
Diameter clients MUST support either TCP or SCTP, while agents and Diameter clients MUST support either TCP or SCTP, while agents and
servers MUST support both. Future versions of this specification MAY servers MUST support both. Future versions of this specification MAY
mandate that clients support SCTP. mandate that clients support SCTP.
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. A given MUST be prepared to receive connections on port 3868. A given
Diameter instance of the peer state machine MUST NOT use more than Diameter instance of the peer state machine MUST NOT use more than
one transport connection to communicate with a given peer, unless one transport connection to communicate with a given peer, unless
skipping to change at page 20, line 47 skipping to change at page 25, line 4
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, SCTP SHOULD be tried first, followed by TCP. See Section specified, SCTP SHOULD be tried first, followed by TCP. See Section
5.2 for more information on peer discovery. 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.
Diameter implementations SHOULD also be able to interpret a reset
from the transport and timed-out connection attempts.
If Diameter receives data up from TCP that cannot be parsed or Diameter implementations SHOULD also be able to interpret a reset
identified as a Diameter error made by the peer, the stream is from the transport and timed-out connection attempts. If Diameter
compromised and cannot be recovered. The transport connection MUST receives data up from TCP that cannot be parsed or identified as a
be closed using a RESET call (send a TCP RST bit) or an SCTP ABORT Diameter error made by the peer, the stream is compromised and cannot
message (graceful closure is compromised). be recovered. The transport connection MUST be closed using a RESET
call (send a TCP RST bit) or an SCTP ABORT message (graceful closure
is compromised).
2.1.1. SCTP Guidelines 2.1.1. SCTP Guidelines
The following are guidelines for Diameter implementations that The following are guidelines for Diameter implementations that
support SCTP: support SCTP:
1. For interoperability: All Diameter nodes MUST be prepared to 1. For interoperability: All Diameter nodes MUST be prepared to
receive Diameter messages on any SCTP stream in the association. receive Diameter messages on any SCTP stream in the association.
2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP
streams available to the association to prevent head-of-the-line streams available to the association to prevent head-of-the-line
blocking. blocking.
2.2. Securing Diameter Messages 2.2. Securing Diameter Messages
Diameter clients, such as Network Access Servers (NASes) and Mobility Diameter clients, such as Network Access Servers (NASes) and Mobility
Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS]. Agents MUST support IP Security [RFC2401], and MAY support TLS
Diameter servers MUST support TLS and IPsec. The Diameter protocol [RFC2246]. Diameter servers MUST support TLS and IPsec. The
MUST NOT be used without any security mechanism (TLS or IPsec). Diameter protocol MUST NOT be used without any security mechanism
(TLS or IPsec).
It is suggested that IPsec can be used primarily at the edges and in It is suggested that IPsec can be used primarily at the edges and in
intra-domain traffic, such as using pre-shared keys between a NAS a intra-domain traffic, such as using pre-shared keys between a NAS a
local AAA proxy. This also eases the requirements on the NAS to local AAA proxy. This also eases the requirements on the NAS to
support certificates. It is also suggested that inter-domain traffic support certificates. It is also suggested that inter-domain traffic
would primarily use TLS. See Sections 13.1 and 13.2 for more details would primarily use TLS. See Sections 13.1 and 13.2 for more details
on IPsec and TLS usage. on IPsec and TLS usage.
2.3. Diameter Application Compliance 2.3. Diameter Application Compliance
skipping to change at page 22, line 18 skipping to change at page 26, line 18
Identifier (see Section 11.3). The base protocol does not require an Identifier (see Section 11.3). The base protocol does not require an
Application Identifier since its support is mandatory. During the Application Identifier since its support is mandatory. During the
capabilities exchange, Diameter nodes inform their peers of locally capabilities exchange, Diameter nodes inform their peers of locally
supported applications. Furthermore, all Diameter messages contain supported applications. Furthermore, all Diameter messages contain
an Application Identifier, which is used in the message forwarding an Application Identifier, which is used in the message forwarding
process. process.
The following Application Identifier values are defined: The following Application Identifier values are defined:
Diameter Common Messages 0 Diameter Common Messages 0
NASREQ 1 [NASREQ] NASREQ 1 [RFC4005]
Mobile-IP 2 [DIAMMIP] Mobile-IP 2 [RFC4004]
Diameter Base Accounting 3 Diameter Base Accounting 3
Relay 0xffffffff Relay 0xffffffff
Relay and redirect agents MUST advertise the Relay Application Relay and redirect agents MUST advertise the Relay Application
Identifier, while all other Diameter nodes MUST advertise locally Identifier, while all other Diameter nodes MUST advertise locally
supported applications. The receiver of a Capabilities Exchange supported applications. The receiver of a Capabilities Exchange
message advertising Relay service MUST assume that the sender message advertising Relay service MUST assume that the sender
supports all current and future applications. supports all current and future applications.
Diameter relay and proxy agents are responsible for finding an Diameter relay and proxy agents are responsible for finding an
skipping to change at page 22, line 43 skipping to change at page 26, line 43
2.5. Connections vs. Sessions 2.5. Connections vs. Sessions
This section attempts to provide the reader with an understanding of This section attempts to provide the reader with an understanding of
the difference between connection and session, which are terms used the difference between connection and session, which are terms used
extensively throughout this document. extensively throughout this document.
A connection is a transport level connection between two peers, used A connection is a transport level connection between two peers, used
to send and receive Diameter messages. A session is a logical to send and receive Diameter messages. A session is a logical
concept at the application layer, and is shared between an access concept at the application layer, and is shared between an access
device and a server, and is identified via the Session-Id AVP device and a server, and is identified via the Session-Id AVP.
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
| Client | | Relay | | Server | | Client | | Relay | | Server |
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
<----------> <----------> <----------> <---------->
peer connection A peer connection B peer connection A peer connection B
<-----------------------------> <----------------------------->
User session x User session x
Figure 1: Diameter connections and sessions Figure 1: Diameter connections and sessions
In the example provided in Figure 1, peer connection A is established In the example provided in Figure 1, peer connection A is established
between the Client and its local Relay. Peer connection B is between the Client and its local Relay. Peer connection B is
established between the Relay and the Server. User session X spans established between the Relay and the Server. User session X spans
from the Client via the Relay to the Server. Each "user" of a from the Client via the Relay to the Server. Each "user" of a
service causes an auth request to be sent, with a unique session service causes an auth request to be sent, with a unique session
identifier. Once accepted by the server, both the client and the identifier. Once accepted by the server, both the client and the
server are aware of the session. It is important to note that there server are aware of the session.
is no relationship between a connection and a session, and that
Diameter messages for multiple sessions are all multiplexed through a It is important to note that there is no relationship between a
single connection. connection and a session, and that Diameter messages for multiple
sessions are all multiplexed through a single connection. Also note
that Diameter messages pertaining to the session, both application
specific and those that are defined in this document such as ASR/ASA,
RAR/RAA and STR/STA MUST carry the application identifier of the
application. Diameter messages pertaining to peer connection
establishment and maintenance such as CER/CEA, DWR/DWA and DPR/DPA
MUST carry an application id of zero (0).
2.6. Peer Table 2.6. Peer Table
The Diameter Peer Table is used in message forwarding, and referenced The Diameter Peer Table is used in message forwarding, and referenced
by the Realm Routing Table. A Peer Table entry contains the by the Realm Routing Table. A Peer Table entry contains the
following fields: following fields:
Host identity Host identity
Following the conventions described for the DiameterIdentity Following the conventions described for the DiameterIdentity
derived AVP data format in Section 4.4. This field contains the derived AVP data format in Section 4.4. This field contains the
contents of the Origin-Host (Section 6.3) AVP found in the CER or contents of the Origin-Host (Section 6.3) AVP found in the CER or
CEA message. CEA message.
StatusT StatusT
This is the state of the peer entry, and MUST match one of the This is the state of the peer entry, and MUST match one of the
values listed in Section 5.6. values listed in Section 5.6.
Static or Dynamic Static or Dynamic
Specifies whether a peer entry was statically configured, or Specifies whether a peer entry was statically configured, or
dynamically discovered. dynamically discovered.
Expiration time Expiration time
Specifies the time at which dynamically discovered peer table Specifies the time at which dynamically discovered peer table
entries are to be either refreshed, or expired. entries are to be either refreshed, or expired.
TLS Enabled TLS Enabled
Specifies whether TLS is to be used when communicating with the Specifies whether TLS is to be used when communicating with the
peer. peer.
Additional security information, when needed (e.g., keys, Additional security information, when needed (e.g., keys,
certificates) certificates)
2.7. Realm-Based Routing Table 2.7. Realm-Based Routing Table
All Realm-Based routing lookups are performed against what is All Realm-Based routing lookups are performed against what is
commonly known as the Realm Routing Table (see Section 12). A Realm commonly known as the Realm Routing Table (see Section 12). A Realm
skipping to change at page 24, line 19 skipping to change at page 28, line 30
Additional security information, when needed (e.g., keys, Additional security information, when needed (e.g., keys,
certificates) certificates)
2.7. Realm-Based Routing Table 2.7. Realm-Based Routing Table
All Realm-Based routing lookups are performed against what is All Realm-Based routing lookups are performed against what is
commonly known as the Realm Routing Table (see Section 12). A Realm commonly known as the Realm Routing Table (see Section 12). A Realm
Routing Table Entry contains the following fields: Routing Table Entry contains the following fields:
Realm Name Realm Name
This is the field that is typically used as a primary key in the This is the field that is typically used as a primary key in the
routing table lookups. Note that some implementations perform routing table lookups. Note that some implementations perform
their lookups based on longest-match-from-the-right on the realm their lookups based on longest-match-from-the-right on the realm
rather than requiring an exact match. rather than requiring an exact match.
Application Identifier Application Identifier
An application is identified by a vendor id and an application id.
For all IETF standards track Diameter applications, the vendor id An application is identified by an application id. A route entry
is zero. A route entry can have a different destination based on can have a different destination based on the application
the application identification AVP of the message. This field identification in the message header. This field MUST be used as
MUST be used as a secondary key field in routing table lookups. a secondary key field in routing table lookups.
Local Action Local Action
The Local Action field is used to identify how a message should be The Local Action field is used to identify how a message should be
treated. The following actions are supported: treated. The following actions are supported:
1. LOCAL - Diameter messages that resolve to a route entry with 1. LOCAL - Diameter messages that resolve to a route entry with
the Local Action set to Local can be satisfied locally, and do the Local Action set to Local can be satisfied locally, and do
not need to be routed to another server. not need to be routed to another server.
2. RELAY - All Diameter messages that fall within this category 2. RELAY - All Diameter messages that fall within this category
MUST be routed to a next hop server, without modifying any MUST be routed to a next hop server, without modifying any
non-routing AVPs. See Section 6.1.8 for relaying guidelines non-routing AVPs. See Section 6.1.9 for relaying guidelines
3. PROXY - All Diameter messages that fall within this category 3. PROXY - All Diameter messages that fall within this category
MUST be routed to a next hop server. The local server MAY MUST be routed to a next hop server. The local server MAY
apply its local policies to the message by including new AVPs apply its local policies to the message by including new AVPs
to the message prior to routing. See Section 6.1.8 for to the message prior to routing. See Section 6.1.9 for
proxying guidelines. proxying guidelines.
4. REDIRECT - Diameter messages that fall within this category 4. REDIRECT - Diameter messages that fall within this category
MUST have the identity of the home Diameter server(s) appended, MUST have the identity of the home Diameter server(s)
and returned to the sender of the message. See Section 6.1.7 appended, and returned to the sender of the message. See
for redirect guidelines. Section 6.1.9 for redirect guidelines.
Server Identifier Server Identifier
One or more servers the message is to be routed to. These servers One or more servers the message is to be routed to. These servers
MUST also be present in the Peer table. When the Local Action is MUST also be present in the Peer table. When the Local Action is
set to RELAY or PROXY, this field contains the identity of the set to RELAY or PROXY, this field contains the identity of the
server(s) the message must be routed to. When the Local Action server(s) the message must be routed to. When the Local Action
field is set to REDIRECT, this field contains the identity of one field is set to REDIRECT, this field contains the identity of one
or more servers the message should be redirected to. or more servers the message should be redirected to.
Static or Dynamic Static or Dynamic
Specifies whether a route entry was statically configured, or Specifies whether a route entry was statically configured, or
dynamically discovered. dynamically discovered.
Expiration time Expiration time
Specifies the time which a dynamically discovered route table Specifies the time which a dynamically discovered route table
entry expires. entry expires.
It is important to note that Diameter agents MUST support at least It is important to note that Diameter agents MUST support at least
one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation.
Agents do not need to support all modes of operation in order to Agents do not need to support all modes of operation in order to
conform with the protocol specification, but MUST follow the protocol conform with the protocol specification, but MUST follow the protocol
compliance guidelines in Section 2. Relay agents MUST NOT reorder compliance guidelines in Section 2. Relay agents MUST NOT reorder
AVPs, and proxies MUST NOT reorder AVPs. AVPs, and proxies MUST NOT reorder AVPs.
skipping to change at page 25, line 45 skipping to change at page 30, line 18
error is returned with the Result-Code AVP set to error is returned with the Result-Code AVP set to
DIAMETER_UNABLE_TO_DELIVER. DIAMETER_UNABLE_TO_DELIVER.
2.8. Role of Diameter Agents 2.8. Role of Diameter Agents
In addition to client and servers, the Diameter protocol introduces In addition to client and servers, the Diameter protocol introduces
relay, proxy, redirect, and translation agents, each of which is relay, proxy, redirect, and translation agents, each of which is
defined in Section 1.3. These Diameter agents are useful for several defined in Section 1.3. These Diameter agents are useful for several
reasons: reasons:
- They can distribute administration of systems to a configurable o They can distribute administration of systems to a configurable
grouping, including the maintenance of security associations. grouping, including the maintenance of security associations.
- They can be used for concentration of requests from an number of o They can be used for concentration of requests from an number of
co-located or distributed NAS equipment sets to a set of like user co-located or distributed NAS equipment sets to a set of like user
groups. groups.
- They can do value-added processing to the requests or responses. o They can do value-added processing to the requests or responses.
- They can be used for load balancing. o They can be used for load balancing.
- A complex network will have multiple authentication sources, they o A complex network will have multiple authentication sources, they
can sort requests and forward towards the correct target. can sort requests and forward towards the correct target.
The Diameter protocol requires that agents maintain transaction The Diameter protocol requires that agents maintain transaction
state, which is used for failover purposes. Transaction state state, which is used for failover purposes. Transaction state
implies that upon forwarding a request, its Hop-by-Hop identifier is implies that upon forwarding a request, its Hop-by-Hop identifier is
saved; the field is replaced with a locally unique identifier, which saved; the field is replaced with a locally unique identifier, which
is restored to its original value when the corresponding answer is is restored to its original value when the corresponding answer is
received. The request's state is released upon receipt of the received. The request's state is released upon receipt of the
answer. A stateless agent is one that only maintains transaction answer. A stateless agent is one that only maintains transaction
state. state.
skipping to change at page 26, line 34 skipping to change at page 31, line 8
A stateful agent is one that maintains session state information; by A stateful agent is one that maintains session state information; by
keeping track of all authorized active sessions. Each authorized keeping track of all authorized active sessions. Each authorized
session is bound to a particular service, and its state is considered session is bound to a particular service, and its state is considered
active either until it is notified otherwise, or by expiration. Each active either until it is notified otherwise, or by expiration. Each
authorized session has an expiration, which is communicated by authorized session has an expiration, which is communicated by
Diameter servers via the Session-Timeout AVP. Diameter servers via the Session-Timeout AVP.
Maintaining session state MAY be useful in certain applications, such Maintaining session state MAY be useful in certain applications, such
as: as:
- Protocol translation (e.g., RADIUS <-> Diameter) o Protocol translation (e.g., RADIUS <-> Diameter)
- Limiting resources authorized to a particular user o Limiting resources authorized to a particular user
- Per user or transaction auditing o Per user or transaction auditing
A Diameter agent MAY act in a stateful manner for some requests and A Diameter agent MAY act in a stateful manner for some requests and
be stateless for others. A Diameter implementation MAY act as one be stateless for others. A Diameter implementation MAY act as one
type of agent for some requests, and as another type of agent for type of agent for some requests, and as another type of agent for
others. others.
2.8.1. Relay Agents 2.8.1. Relay Agents
Relay Agents are Diameter agents that accept requests and route Relay Agents are Diameter agents that accept requests and route
messages to other Diameter nodes based on information found in the messages to other Diameter nodes based on information found in the
skipping to change at page 30, line 23 skipping to change at page 34, line 43
extension, described in [AAACMS]. The circumstances requiring the extension, described in [AAACMS]. The circumstances requiring the
use of end-to-end security are determined by policy on each of the use of end-to-end security are determined by policy on each of the
peers. Security policies, which are not the subject of peers. Security policies, which are not the subject of
standardization, may be applied by next hop Diameter peer or by standardization, may be applied by next hop Diameter peer or by
destination realm. For example, where TLS or IPsec transmission- destination realm. For example, where TLS or IPsec transmission-
level security is sufficient, there may be no need for end-to-end level security is sufficient, there may be no need for end-to-end
security. security.
End-to-end security policies include: End-to-end security policies include:
- Never use end-to-end security. o Never use end-to-end security.
- Use end-to-end security on messages containing sensitive AVPs. o Use end-to-end security on messages containing sensitive AVPs.
Which AVPs are sensitive is determined by service provider policy. Which AVPs are sensitive is determined by service provider policy.
AVPs containing keys and passwords should be considered sensitive. AVPs containing keys and passwords should be considered sensitive.
Accounting AVPs may be considered sensitive. Any AVP for which Accounting AVPs may be considered sensitive. Any AVP for which
the P bit may be set or which may be encrypted may be considered the P bit may be set or which may be encrypted may be considered
sensitive. sensitive.
- Always use end-to-end security. o Always use end-to-end security.
It is strongly RECOMMENDED that all Diameter implementations support It is strongly RECOMMENDED that all Diameter implementations support
end-to-end security. end-to-end security.
2.10. Diameter Path Authorization 2.10. Diameter Path Authorization
As noted in Section 2.2, Diameter requires transmission level As noted in Section 2.2, Diameter requires transmission level
security to be used on each connection (TLS or IPsec). Therefore, security to be used on each connection (TLS or IPsec). Therefore,
each connection is authenticated, replay and integrity protected and each connection is authenticated, replay and integrity protected and
confidential on a per-packet basis. confidential on a per-packet basis.
skipping to change at page 31, line 12 skipping to change at page 35, line 32
may be authentic, but that does not mean that it is authorized to act may be authentic, but that does not mean that it is authorized to act
as a Diameter Server advertising a set of Diameter applications. as a Diameter Server advertising a set of Diameter applications.
Prior to bringing up a connection, authorization checks are performed Prior to bringing up a connection, authorization checks are performed
at each connection along the path. Diameter capabilities negotiation at each connection along the path. Diameter capabilities negotiation
(CER/CEA) also MUST be carried out, in order to determine what (CER/CEA) also MUST be carried out, in order to determine what
Diameter applications are supported by each peer. Diameter sessions Diameter applications are supported by each peer. Diameter sessions
MUST be routed only through authorized nodes that have advertised MUST be routed only through authorized nodes that have advertised
support for the Diameter application required by the session. support for the Diameter application required by the session.
As noted in Section 6.1.8, a relay or proxy agent MUST append a As noted in Section 6.1.9, a relay or proxy agent MUST append a
Route-Record AVP to all requests forwarded. The AVP contains the Route-Record AVP to all requests forwarded. The AVP contains the
identity of the peer the request was received from. identity of the peer the request was received from.
The home Diameter server, prior to authorizing a session, MUST check The home Diameter server, prior to authorizing a session, MUST check
the Route-Record AVPs to make sure that the route traversed by the the Route-Record AVPs to make sure that the route traversed by the
request is acceptable. For example, administrators within the home request is acceptable. For example, administrators within the home
realm may not wish to honor requests that have been routed through an realm may not wish to honor requests that have been routed through an
untrusted realm. By authorizing a request, the home Diameter server untrusted realm. By authorizing a request, the home Diameter server
is implicitly indicating its willingness to engage in the business is implicitly indicating its willingness to engage in the business
transaction as specified by the contractual relationship between the transaction as specified by the contractual relationship between the
skipping to change at page 32, line 27 skipping to change at page 37, line 27
| Application-ID | | Application-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 1 to indicate Diameter Version This Version field MUST be set to 1 to indicate Diameter Version
1. 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:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|R P E T r r r r| |R P E T r r r r|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
R(equest)
If set, the message is a request. If cleared, the message is
an answer.
P(roxiable)
If set, the message MAY be proxied, relayed or redirected. If
cleared, the message MUST be locally processed.
E(rror)
If set, the message contains a protocol error, and the message
will not conform to the ABNF described for this command.
Messages with the 'E' bit set are commonly referred to as error
messages. This bit MUST NOT be set in request messages. See
Section 7.2.
R(equest) - If set, the message is a request. If cleared, the
message is an answer.
P(roxiable) - If set, the message MAY be proxied, relayed or
redirected. If cleared, the message MUST be
locally processed.
E(rror) - If set, the message contains a protocol error,
and the message will not conform to the ABNF
described for this command. Messages with the 'E'
bit set are commonly referred to as error
messages. This bit MUST NOT be set in request
messages. See Section 7.2.
T(Potentially re-transmitted message) T(Potentially re-transmitted message)
- This flag is set after a link failover procedure,
to aid the removal of duplicate requests. It is This flag is set after a link failover procedure, to aid the
set when resending requests not yet acknowledged, removal of duplicate requests. It is set when resending
as an indication of a possible duplicate due to a requests not yet acknowledged, as an indication of a possible
link failure. This bit MUST be cleared when duplicate due to a link failure. This bit MUST be cleared when
sending a request for the first time, otherwise sending a request for the first time, otherwise the sender MUST
the sender MUST set this flag. Diameter agents set this flag. Diameter agents only need to be concerned about
only need to be concerned about the number of the number of requests they send based on a single received
requests they send based on a single received request; retransmissions by other entities need not be tracked.
request; retransmissions by other entities need Diameter agents that receive a request with the T flag set,
not be tracked. Diameter agents that receive a MUST keep the T flag set in the forwarded request. This flag
request with the T flag set, MUST keep the T flag MUST NOT be set if an error answer message (e.g., a protocol
set in the forwarded request. This flag MUST NOT error) has been received for the earlier message. It can be
be set if an error answer message (e.g., a set only in cases where no answer has been received from the
protocol error) has been received for the earlier server for a request and the request is sent again. This flag
message. It can be set only in cases where no
answer has been received from the server for a
request and the request is sent again. This flag
MUST NOT be set in answer messages. MUST NOT be set in answer messages.
r(eserved) - these flag bits are reserved for future use, and r(eserved)
MUST be set to zero, and ignored by the receiver.
These flag bits are reserved for future use, and MUST be set to
zero, and ignored by the receiver.
Command-Code Command-Code
The Command-Code field is three octets, and is used in order to The Command-Code field is three octets, and is used in order to
communicate the command associated with the message. The 24-bit communicate the command associated with the message. The 24-bit
address space is managed by IANA (see Section 11.2.1). address space is managed by IANA (see Section 11.2.1).
Command-Code values 16,777,214 and 16,777,215 (hexadecimal values Command-Code values 16,777,214 and 16,777,215 (hexadecimal values
FFFFFE -FFFFFF) are reserved for experimental use (See Section FFFFFE -FFFFFF) are reserved for experimental use (See Section
11.3). 11.3).
Application-ID Application-ID
Application-ID is four octets and is used to identify to which Application-ID is four octets and is used to identify to which
application the message is applicable for. The application can be application the message is applicable for. The application can be
an authentication application, an accounting application or a an authentication application, an accounting application or a
vendor specific application. See Section 11.3 for the possible vendor specific application. See Section 11.3 for the possible
values that the application-id may use. values that the application-id may use.
The application-id in the header MUST be the same as what is The application-id in the header MUST be the same as what is
contained in any relevant AVPs contained in the message. contained in any relevant application-id AVPs contained in the
message.
Hop-by-Hop Identifier Hop-by-Hop Identifier
The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in
network byte order) and aids in matching requests and replies. network byte order) and aids in matching requests and replies.
The sender MUST ensure that the Hop-by-Hop identifier in a request The sender MUST ensure that the Hop-by-Hop identifier in a request
is unique on a given connection at any given time, and MAY attempt is unique on a given connection at any given time, and MAY attempt
to ensure that the number is unique across reboots. The sender of to ensure that the number is unique across reboots. The sender of
an Answer message MUST ensure that the Hop-by-Hop Identifier field an Answer message MUST ensure that the Hop-by-Hop Identifier field
contains the same value that was found in the corresponding contains the same value that was found in the corresponding
request. The Hop-by-Hop identifier is normally a monotonically request. The Hop-by-Hop identifier is normally a monotonically
increasing number, whose start value was randomly generated. An increasing number, whose start value was randomly generated. An
answer message that is received with an unknown Hop-by-Hop answer message that is received with an unknown Hop-by-Hop
skipping to change at page 36, line 18 skipping to change at page 41, line 19
specification, which is used to define the AVPs that MUST or MAY be specification, which is used to define the AVPs that MUST or MAY be
present. The following format is used in the definition: present. The following format is used in the definition:
command-def = command-name "::=" diameter-message command-def = command-name "::=" diameter-message
command-name = diameter-name command-name = diameter-name
diameter-name = ALPHA *(ALPHA / DIGIT / "-") diameter-name = ALPHA *(ALPHA / DIGIT / "-")
diameter-message = header [ *fixed] [ *required] [ *optional] diameter-message = header [ *fixed] [ *required] [ *optional]
[ *fixed]
header = "<" Diameter-Header:" command-id header = "<" "Diameter Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">" [r-bit] [p-bit] [e-bit] [application-id]">"
application-id = 1*DIGIT application-id = 1*DIGIT
command-id = 1*DIGIT command-id = 1*DIGIT
; The Command Code assigned to the command ; The Command Code assigned to the command
r-bit = ", REQ" r-bit = ", REQ"
; If present, the 'R' bit in the Command ; If present, the 'R' bit in the Command
; Flags is set, indicating that the message ; Flags is set, indicating that the message
skipping to change at page 37, line 13 skipping to change at page 42, line 13
; anywhere in the message. ; anywhere in the message.
optional = [qual] "[" avp-name "]" optional = [qual] "[" avp-name "]"
; The avp-name in the 'optional' rule cannot ; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name which is included ; evaluate to any AVP Name which is included
; in a fixed or required rule. The AVP can ; in a fixed or required rule. The AVP can
; appear anywhere in the message. ; appear anywhere in the message.
qual = [min] "*" [max] qual = [min] "*" [max]
; See ABNF conventions, RFC 2234 Section 6.6. ; See ABNF conventions, RFC 2234 Section 6.6.
; The absence of any qualifiers depends on whether ; The absence of any qualifiers depends on
; it precedes a fixed, required, or optional ; whether it precedes a fixed, required, or
; rule. If a fixed or required rule has no ; optional rule. If a fixed or required rule has
; qualifier, then exactly one such AVP MUST ; no qualifier, then exactly one such AVP MUST
; be present. If an optional rule has no ; be present. If an optional rule has no
; qualifier, then 0 or 1 such AVP may be ; qualifier, then 0 or 1 such AVP may be
; present. ; present.
; ;
; NOTE: "[" and "]" have a different meaning ; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above). ; than in ABNF (see the optional rule, above).
; These braces cannot be used to express ; These braces cannot be used to express
; optional fixed rules (such as an optional ; optional fixed rules (such as an optional
; ICV at the end). To do this, the convention ; ICV at the end). To do this, the convention
; is '0*1fixed'. ; is '0*1fixed'.
skipping to change at page 38, line 7 skipping to change at page 43, line 5
; specifications. ; specifications.
avp-name = avp-spec / "AVP" avp-name = avp-spec / "AVP"
; The string "AVP" stands for *any* arbitrary ; The string "AVP" stands for *any* arbitrary
; AVP Name, which does not conflict with the ; AVP Name, which does not conflict with the
; required or fixed position AVPs defined in ; required or fixed position AVPs defined in
; the command code definition. ; the command code definition.
The following is a definition of a fictitious command code: The following is a definition of a fictitious command code:
Example-Request ::= < "Diameter-Header: 9999999, REQ, PXY > Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
{ User-Name } { User-Name }
* { Origin-Host } * { Origin-Host }
* [ AVP * [ AVP
3.3. Diameter Command Naming Conventions 3.3. Diameter Command Naming Conventions
Diameter command names typically includes one or more English words Diameter command names typically includes one or more English words
followed by the verb Request or Answer. Each English word is followed by the verb Request or Answer. Each English word is
delimited by a hyphen. A three-letter acronym for both the request delimited by a hyphen. A three-letter acronym for both the request
and answer is also normally provided. and answer is also normally provided.
skipping to change at page 38, line 31 skipping to change at page 43, line 29
the acronyms are STR and STA, respectively. the acronyms are STR and STA, respectively.
Both the request and the answer for a given command share the same Both the request and the answer for a given command share the same
command code. The request is identified by the R(equest) bit in the command code. The request is identified by the R(equest) bit in the
Diameter header set to one (1), to ask that a particular action be Diameter header set to one (1), to ask that a particular action be
performed, such as authorizing a user or terminating a session. Once performed, such as authorizing a user or terminating a session. Once
the receiver has completed the request it issues the corresponding the receiver has completed the request it issues the corresponding
answer, which includes a result code that communicates one of the answer, which includes a result code that communicates one of the
following: following:
- The request was successful o The request was successful
- The request failed o The request failed
- An additional request must be sent to provide information the peer o An additional request must be sent to provide information the peer
requires prior to returning a successful or failed answer. requires prior to returning a successful or failed answer.
- The receiver could not process the request, but provides o The receiver could not process the request, but provides
information about a Diameter peer that is able to satisfy the information about a Diameter peer that is able to satisfy the
request, known as redirect. request, known as redirect.
Additional information, encoded within AVPs, MAY also be included in Additional information, encoded within AVPs, MAY also be included in
answer messages. answer messages.
4. Diameter AVPs 4. Diameter AVPs
Diameter AVPs carry specific authentication, accounting, Diameter AVPs carry specific authentication, accounting,
authorization, routing and security information as well as authorization, routing and security information as well as
skipping to change at page 40, line 13 skipping to change at page 45, line 23
messages with unrecognized AVPs. messages with unrecognized AVPs.
The 'M' bit MUST be set according to the rules defined for the AVP The 'M' bit MUST be set according to the rules defined for the AVP
containing it. In order to preserve interoperability, a Diameter containing it. In order to preserve interoperability, a Diameter
implementation MUST be able to exclude from a Diameter message any implementation MUST be able to exclude from a Diameter message any
Mandatory AVP which is neither defined in the base Diameter Mandatory AVP which is neither defined in the base Diameter
protocol nor in any of the Diameter Application specifications protocol nor in any of the Diameter Application specifications
governing the message in which it appears. It MAY do this in one governing the message in which it appears. It MAY do this in one
of the following ways: of the following ways:
1) If a message is rejected because it contains a Mandatory AVP 1. If a message is rejected because it contains a Mandatory AVP
which is neither defined in the base Diameter standard nor in which is neither defined in the base Diameter standard nor in
any of the Diameter Application specifications governing the any of the Diameter Application specifications governing the
message in which it appears, the implementation may resend the message in which it appears, the implementation may resend the
message without the AVP, possibly inserting additional standard message without the AVP, possibly inserting additional
AVPs instead. standard AVPs instead.
2) A configuration option may be provided on a system wide, per 2. A configuration option may be provided on a system wide, per
peer, or per realm basis that would allow/prevent particular peer, or per realm basis that would allow/prevent particular
Mandatory AVPs to be sent. Thus an administrator could change Mandatory AVPs to be sent. Thus an administrator could change
the configuration to avoid interoperability problems. the configuration to avoid interoperability problems.
Diameter implementations are required to support all Mandatory Diameter implementations are required to support all Mandatory
AVPs which are allowed by the message's formal syntax and defined AVPs which are allowed by the message's formal syntax and defined
either in the base Diameter standard or in one of the Diameter either in the base Diameter standard or in one of the Diameter
Application specifications governing the message. Application specifications governing the message.
AVPs with the 'M' bit cleared are informational only and a AVPs with the 'M' bit cleared are informational only and a
skipping to change at page 41, line 11 skipping to change at page 46, line 22
Vendor-ID field (if present) and the AVP data. If a message is Vendor-ID field (if present) and the AVP data. If a message is
received with an invalid attribute length, the message SHOULD be received with an invalid attribute length, the message SHOULD be
rejected. rejected.
4.1.1. Optional Header Elements 4.1.1. Optional Header Elements
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"
[ASSIGNNO] value, encoded in network byte order. Any vendor [RFC3232] value, encoded in network byte order. Any vendor
wishing to implement a vendor-specific Diameter AVP MUST use their wishing to implement a vendor-specific Diameter AVP MUST use their
own Vendor-ID along with their privately managed AVP address 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 vendor's vendor-specific AVP(s), nor with future IETF
applications. applications.
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 42, line 46 skipping to change at page 48, line 27
define data formats derived from the Basic AVP Data Formats. An define data formats derived from the Basic AVP Data Formats. An
application that defines new AVP Derived Data Formats MUST include application that defines new AVP Derived Data Formats MUST include
them in a section entitled "AVP Derived Data Formats", using the same them in a section entitled "AVP Derived Data Formats", using the same
format as the definitions below. Each new definition must be either format as the definitions below. Each new definition must be either
defined or listed with a reference to the RFC that defines the defined or listed with a reference to the RFC that defines the
format. format.
The below AVP Derived Data Formats are commonly used by applications. The below AVP Derived Data Formats are commonly used by applications.
Address Address
The Address format is derived from the OctetString AVP Base The Address format is derived from the OctetString AVP Base
Format. It is a discriminated union, representing, for example a Format. It is a discriminated union, representing, for example a
32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most 32-bit (IPv4) [IPV4] or 128-bit (IPv6) [RFC2373] address, most
significant octet first. The first two octets of the Address significant octet first. The first two octets of the Address AVP
AVP represents the AddressType, which contains an Address Family represents the AddressType, which contains an Address Family
defined in [IANAADFAM]. The AddressType is used to discriminate defined in [IANAADFAM]. The AddressType is used to discriminate
the content and format of the remaining octets. the content and format of the remaining octets.
Time Time
The Time format is derived from the OctetString AVP Base Format. The Time format is derived from the OctetString AVP Base Format.
The string MUST contain four octets, in the same format as the The string MUST contain four octets, in the same format as the
first four bytes are in the NTP timestamp format. The NTP first four bytes are in the NTP timestamp format. The NTP
Timestamp format is defined in chapter 3 of [SNTP]. Timestamp format is defined in chapter 3 of [RFC2030].
This represents the number of seconds since 0h on 1 January 1900 This represents the number of seconds since 0h on 1 January 1900
with respect to the Coordinated Universal Time (UTC). with respect to the Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. On 6h 28m 16s UTC, 7 February 2036 the time value will overflow.
SNTP [SNTP] describes a procedure to extend the time to 2104. SNTP [RFC2030] describes a procedure to extend the time to 2104.
This procedure MUST be supported by all DIAMETER nodes. This procedure MUST be supported by all DIAMETER nodes.
UTF8String UTF8String
The UTF8String format is derived from the OctetString AVP Base The UTF8String format is derived from the OctetString AVP Base
Format. This is a human readable string represented using the Format. This is a human readable string represented using the
ISO/IEC IS 10646-1 character set, encoded as an OctetString using ISO/IEC IS 10646-1 character set, encoded as an OctetString using
the UTF-8 [UFT8] transformation format described in RFC 2279. the UTF-8 [RFC2279] transformation format described in RFC 2279.
Since additional code points are added by amendments to the 10646 Since additional code points are added by amendments to the 10646
standard from time to time, implementations MUST be prepared to standard from time to time, implementations MUST be prepared to
encounter any code point from 0x00000001 to 0x7fffffff. Byte encounter any code point from 0x00000001 to 0x7fffffff. Byte
sequences that do not correspond to the valid encoding of a code sequences that do not correspond to the valid encoding of a code
point into UTF-8 charset or are outside this range are prohibited. point into UTF-8 charset or are outside this range are prohibited.
The use of control codes SHOULD be avoided. When it is necessary The use of control codes SHOULD be avoided. When it is necessary
to represent a new line, the control code sequence CR LF SHOULD be to represent a new line, the control code sequence CR LF SHOULD be
used. used.
skipping to change at page 44, line 16 skipping to change at page 50, line 4
The DiameterIdentity format is derived from the OctetString AVP The DiameterIdentity format is derived from the OctetString AVP
Base Format. Base Format.
DiameterIdentity = FQDN DiameterIdentity = FQDN
DiameterIdentity value is used to uniquely identify a Diameter DiameterIdentity value is used to uniquely identify a Diameter
node for purposes of duplicate connection and routing loop node for purposes of duplicate connection and routing loop
detection. detection.
The contents of the string MUST be the FQDN of the Diameter node. The contents of the string MUST be the FQDN of the Diameter node.
If multiple Diameter nodes run on the same host, each Diameter If multiple Diameter nodes run on the same host, each Diameter
node MUST be assigned a unique DiameterIdentity. If a Diameter node MUST be assigned a unique DiameterIdentity. If a Diameter
node can be identified by several FQDNs, a single FQDN should be node can be identified by several FQDNs, a single FQDN should be
picked at startup, and used as the only DiameterIdentity for that picked at startup, and used as the only DiameterIdentity for that
node, whatever the connection it is sent on. node, whatever the connection it is sent on.
DiameterURI DiameterURI
The DiameterURI MUST follow the Uniform Resource Identifiers (URI) The DiameterURI MUST follow the Uniform Resource Identifiers (URI)
syntax [URI] rules specified below: syntax [RFC2396] rules specified below:
"aaa://" FQDN [ port ] [ transport ] [ protocol ] "aaa://" FQDN [ port ] [ transport ] [ protocol ]
; No transport security ; No transport security
"aaas://" FQDN [ port ] [ transport ] [ protocol ] "aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Transport security used ; Transport security used
FQDN = Fully Qualified Host Name FQDN = Fully Qualified Host Name
skipping to change at page 44, line 49 skipping to change at page 51, line 27
; One of the ports used to listen for ; One of the ports used to listen for
; incoming connections. ; incoming connections.
; If absent, ; If absent,
; the default Diameter port (3868) is ; the default Diameter port (3868) is
; assumed. ; assumed.
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 SCTP [SCTP] protocol is ; the default SCTP [RFC2960] protocol is
; assumed. UDP MUST NOT be used when ; assumed. UDP MUST NOT be used when
; the aaa-protocol field is set to ; the aaa-protocol field is set to
; diameter. ; diameter.
transport-protocol = ( "tcp" / "sctp" / "udp" ) transport-protocol = ( "tcp" / "sctp" / "udp" )
protocol = ";protocol=" aaa-protocol protocol = ";protocol=" aaa-protocol
; If absent, the default AAA protocol ; If absent, the default AAA protocol
; is diameter. ; is diameter.
skipping to change at page 48, line 35 skipping to change at page 55, line 17
echo reply (0), destination unreachable (3), echo reply (0), destination unreachable (3),
source quench (4), redirect (5), echo request source quench (4), redirect (5), echo request
(8), router advertisement (9), router (8), router advertisement (9), router
solicitation (10), time-to-live exceeded (11), IP solicitation (10), time-to-live exceeded (11), IP
header bad (12), timestamp request (13), header bad (12), timestamp request (13),
timestamp reply (14), information request (15), timestamp reply (14), information request (15),
information reply (16), address mask request (17) information reply (16), address mask request (17)
and address mask reply (18). and address mask reply (18).
There is one kind of packet that the access device MUST always There is one kind of packet that the access device MUST always
discard, that is an IP fragment with a fragment offset of one. This discard, that is an IP fragment with a fragment offset of one.
is a valid packet, but it only has one use, to try to circumvent This is a valid packet, but it only has one use, to try to
firewalls. circumvent firewalls.
An access device that is unable to interpret or apply a deny rule An access device that is unable to interpret or apply a deny rule
MUST terminate the session. An access device that is unable to MUST terminate the session. An access device that is unable to
interpret or apply a permit rule MAY apply a more restrictive interpret or apply a permit rule MAY apply a more restrictive
rule. An access device MAY apply deny rules of its own before the rule. An access device MAY apply deny rules of its own before the
supplied rules, for example to protect the access device owner's supplied rules, for example to protect the access device owner's
infrastructure. infrastructure.
The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the The rule syntax is a modified subset of ipfw(8) from FreeBSD, and
ipfw.c code may provide a useful base for implementations. the ipfw.c code may provide a useful base for implementations.
QoSFilterRule QoSFilterRule
The QosFilterRule format is derived from the OctetString AVP Base The QosFilterRule format is derived from the OctetString AVP Base
Format. It uses the ASCII charset. Packets may be marked or Format. It uses the ASCII charset. Packets may be marked or
metered based on the following information that is associated with metered based on the following information that is associated with
it: it:
Direction (in or out) Direction (in or out)
Source and destination IP address (possibly masked) Source and destination IP address (possibly masked)
Protocol Protocol
Source and destination port (lists or ranges) Source and destination port (lists or ranges)
DSCP values (no mask or range) DSCP values (no mask or range)
skipping to change at page 50, line 11 skipping to change at page 56, line 39
that is, to nest them. AVPs within an AVP of type Grouped have the 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 same padding requirements as non-Grouped AVPs, as defined in Section
4. 4.
The AVP Code numbering space of all AVPs included in a Grouped AVP is The AVP Code numbering space of all AVPs included in a Grouped AVP is
the same as for non-grouped AVPs. Further, if any of the AVPs the same as for non-grouped AVPs. Further, if any of the AVPs
encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, encapsulated within a Grouped AVP has the 'M' (mandatory) bit set,
the Grouped AVP itself MUST also include the 'M' bit set. the Grouped AVP itself MUST also include the 'M' bit set.
Every Grouped AVP defined MUST include a corresponding grammar, using Every Grouped AVP defined MUST include a corresponding grammar, using
ABNF [ABNF] (with modifications), as defined below. ABNF [RFC2234] (with modifications), as defined below.
grouped-avp-def = name "::=" avp grouped-avp-def = name "::=" avp
name-fmt = ALPHA *(ALPHA / DIGIT / "-") name-fmt = ALPHA *(ALPHA / DIGIT / "-")
name = name-fmt name = name-fmt
; The name has to be the name of an AVP, ; The name has to be the name of an AVP,
; defined in the base or extended Diameter ; defined in the base or extended Diameter
; specifications. ; specifications.
skipping to change at page 57, line 15 skipping to change at page 64, line 14
MUST be supported by all DIAMETER nodes, while the latter two options MUST be supported by all DIAMETER nodes, while the latter two options
(SRVLOC and DNS) MAY be supported. (SRVLOC and DNS) MAY be supported.
There are two cases where Diameter peer discovery may be performed. There are two cases where Diameter peer discovery may be performed.
The first is when a Diameter client needs to discover a first-hop The first is when a Diameter client needs to discover a first-hop
Diameter agent. The second case is when a Diameter agent needs to Diameter agent. The second case is when a Diameter agent needs to
discover another agent - for further handling of a Diameter discover another agent - for further handling of a Diameter
operation. In both cases, the following 'search order' is operation. In both cases, the following 'search order' is
recommended: recommended:
1. The Diameter implementation consults its list of static (manually) 1. The Diameter implementation consults its list of static
configured Diameter agent locations. These will be used if they (manually) configured Diameter agent locations. These will be
exist and respond. used if they exist and respond.
2. The Diameter implementation uses SLPv2 [SLP] to discover Diameter 2. The Diameter implementation uses SLPv2 [RFC2165] to discover
services. The Diameter service template [TEMPLATE] is included in Diameter services. The Diameter service template [RFC2609] is
Appendix A. included in Appendix B.
It is recommended that SLPv2 security be deployed (this requires It is recommended that SLPv2 security be deployed (this requires
distributing keys to SLPv2 agents). This is discussed further in distributing keys to SLPv2 agents). This is discussed further in
Appendix A. SLPv2 security SHOULD be used (requiring distribution Appendix B. SLPv2 security SHOULD be used (requiring
of keys to SLPv2 agents) in order to ensure that discovered peers distribution of keys to SLPv2 agents) in order to ensure that
are authorized for their roles. SLPv2 is discussed further in discovered peers are authorized for their roles. SLPv2 is
Appendix A. discussed further in Appendix B.
3. The Diameter implementation performs a NAPTR query for a server in 3. The Diameter implementation performs a NAPTR query for a server
a particular realm. The Diameter implementation has to know in in a particular realm. The Diameter implementation has to know
advance which realm to look for a Diameter agent in. This could in advance which realm to look for a Diameter agent in. This
be deduced, for example, from the 'realm' in a NAI that a Diameter could be deduced, for example, from the 'realm' in a NAI that a
implementation needed to perform a Diameter operation on. Diameter implementation needed to perform a Diameter operation
on.
3.1 The services relevant for the task of transport protocol * The services relevant for the task of transport protocol
selection are those with NAPTR service fields with values selection are those with NAPTR service fields with values
"AAA+D2x", where x is a letter that corresponds to a transport "AAA+D2x", where x is a letter that corresponds to a transport
protocol supported by the domain. This specification defines protocol supported by the domain. This specification defines
D2T for TCP and D2S for SCTP. We also establish an IANA D2T for TCP and D2S for SCTP. We also establish an IANA
registry for NAPTR service name to transport protocol registry for NAPTR service name to transport protocol
mappings. mappings.
These NAPTR records provide a mapping from a domain, to the These NAPTR records provide a mapping from a domain, to the
SRV record for contacting a server with the specific transport SRV record for contacting a server with the specific transport
protocol in the NAPTR services field. The resource record protocol in the NAPTR services field. The resource record
will contain an empty regular expression and a replacement will contain an empty regular expression and a replacement
value, which is the SRV record for that particular transport value, which is the SRV record for that particular transport
protocol. If the server supports multiple transport protocol. If the server supports multiple transport
protocols, there will be multiple NAPTR records, each with a protocols, there will be multiple NAPTR records, each with a
different service value. As per RFC 2915 [NAPTR], the client different service value. As per RFC 2915 [RFC2915], the
discards any records whose services fields are not applicable. client discards any records whose services fields are not
For the purposes of this specification, several rules are applicable. For the purposes of this specification, several
defined. rules are defined.
3.2 A client MUST discard any service fields that identify a * A client MUST discard any service fields that identify a
resolution service whose value is not "D2X", for values of X resolution service whose value is not "D2X", for values of X
that indicate transport protocols supported by the client. that indicate transport protocols supported by the client.
The NAPTR processing as described in RFC 2915 will result in The NAPTR processing as described in RFC 2915 will result in
discovery of the most preferred transport protocol of the discovery of the most preferred transport protocol of the
server that is supported by the client, as well as an SRV server that is supported by the client, as well as an SRV
record for the server. record for the server.
The domain suffixes in the NAPTR replacement field SHOULD The domain suffixes in the NAPTR replacement field SHOULD
match the domain of the original query. match the domain of the original query.
4. If no NAPTR records are found, the requester queries for those 4. If no NAPTR records are found, the requester queries for those
address records for the destination address, address records for the destination address,
'_diameter._sctp'.realm or '_diameter._tcp'.realm. Address '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address
records include A RR's, AAAA RR's or other similar records, chosen records include A RR's, AAAA RR's or other similar records,
according to the requestor's network protocol capabilities. If chosen according to the requestor's network protocol
the DNS server returns no address records, the requestor gives up. capabilities. If the DNS server returns no address records, the
requestor gives up.
If the server is using a site certificate, the domain name in the If the server is using a site certificate, the domain name in the
query and the domain name in the replacement field MUST both be query and the domain name in the replacement field MUST both be
valid based on the site certificate handed out by the server in valid based on the site certificate handed out by the server in
the TLS or IKE exchange. Similarly, the domain name in the SRV the TLS or IKE exchange. Similarly, the domain name in the SRV
query and the domain name in the target in the SRV record MUST query and the domain name in the target in the SRV record MUST
both be valid based on the same site certificate. Otherwise, an both be valid based on the same site certificate. Otherwise, an
attacker could modify the DNS records to contain replacement attacker could modify the DNS records to contain replacement
values in a different domain, and the client could not validate values in a different domain, and the client could not validate
that this was the desired behavior, or the result of an attack that this was the desired behavior, or the result of an attack
Also, the Diameter Peer MUST check to make sure that the Also, the Diameter Peer MUST check to make sure that the
discovered peers are authorized to act in its role. discovered peers are authorized to act in its role.
Authentication via IKE or TLS, or validation of DNS RRs via DNSSEC Authentication via IKE or TLS, or validation of DNS RRs via
is not sufficient to conclude this. For example, a web server may DNSSEC is not sufficient to conclude this. For example, a web
have obtained a valid TLS certificate, and secured RRs may be server may have obtained a valid TLS certificate, and secured RRs
included in the DNS, but this does not imply that it is authorized may be included in the DNS, but this does not imply that it is
to act as a Diameter Server. authorized to act as a Diameter Server.
Authorization can be achieved for example, by configuration of a Authorization can be achieved for example, by configuration of a
Diameter Server CA. Alternatively this can be achieved by Diameter Server CA. Alternatively this can be achieved by
definition of OIDs within TLS or IKE certificates so as to signify definition of OIDs within TLS or IKE certificates so as to
Diameter Server authorization. signify Diameter Server authorization.
A dynamically discovered peer causes an entry in the Peer Table (see A dynamically discovered peer causes an entry in the Peer Table (see
Section 2.6) to be created. Note that entries created via DNS MUST Section 2.6) to be created. Note that entries created via DNS MUST
expire (or be refreshed) within the DNS TTL. If a peer is discovered expire (or be refreshed) within the DNS TTL. If a peer is discovered
outside of the local realm, a routing table entry (see Section 2.7) outside of the local realm, a routing table entry (see Section 2.7)
for the peer's realm is created. The routing table entry's for the peer's realm is created. The routing table entry's
expiration MUST match the peer's expiration value. expiration MUST match the peer's expiration value.
5.3. Capabilities Exchange 5.3. Capabilities Exchange
skipping to change at page 60, line 22 skipping to change at page 67, line 29
advertised support for the application (or has advertised the Relay advertised support for the application (or has advertised the Relay
Application Identifier). Application Identifier).
5.3.1. Capabilities-Exchange-Request 5.3.1. Capabilities-Exchange-Request
The Capabilities-Exchange-Request (CER), indicated by the Command- The Capabilities-Exchange-Request (CER), indicated by the Command-
Code set to 257 and the Command Flags' 'R' bit set, is sent to Code set to 257 and the Command Flags' 'R' bit set, is sent to
exchange local capabilities. Upon detection of a transport failure, exchange local capabilities. Upon detection of a transport failure,
this message MUST NOT be sent to an alternate peer. this message MUST NOT be sent to an alternate peer.
When Diameter is run over SCTP [SCTP], which allows for connections When Diameter is run over SCTP [RFC2960], which allows for
to span multiple interfaces and multiple IP addresses, the connections to span multiple interfaces and multiple IP addresses,
Capabilities-Exchange-Request message MUST contain one Host-IP- the Capabilities-Exchange-Request message MUST contain one Host-IP-
Address AVP for each potential IP address that MAY be locally used Address AVP for each potential IP address that MAY be locally used
when transmitting Diameter messages. when transmitting Diameter messages.
Message Format Message Format
<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 }
skipping to change at page 61, line 5 skipping to change at page 68, line 11
* [ 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.
When Diameter is run over SCTP [SCTP], which allows connections to When Diameter is run over SCTP [RFC2960], which allows connections to
span multiple interfaces, hence, multiple IP addresses, the span multiple interfaces, hence, multiple IP addresses, the
Capabilities-Exchange-Answer message MUST contain one Host-IP-Address Capabilities-Exchange-Answer message MUST contain one Host-IP-Address
AVP for each potential IP address that MAY be locally used when AVP for each potential IP address that MAY be locally used when
transmitting Diameter messages. transmitting Diameter messages.
Message Format Message Format
<CEA> ::= < Diameter Header: 257 > <CEA> ::= < Diameter Header: 257 >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
skipping to change at page 61, line 34 skipping to change at page 68, line 40
* [ Auth-Application-Id ] * [ Auth-Application-Id ]
* [ Inband-Security-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" [ASSIGNNO] the IANA "SMI Network Management Private Enterprise Codes" [RFC3232]
value assigned to the vendor of the Diameter application. In value assigned to the vendor of the Diameter application. In
combination with the Supported-Vendor-Id AVP (Section 5.3.6), this combination with the Supported-Vendor-Id AVP (Section 5.3.6), this
MAY be used in order to know which vendor specific attributes may be MAY be used in order to know which vendor specific attributes may be
sent to the peer. It is also envisioned that the combination of the sent to the peer. It is also envisioned that the combination of the
Vendor-Id, Product-Name (Section 5.3.7) and the Firmware-Revision Vendor-Id, Product-Name (Section 5.3.7) and the Firmware-Revision
(Section 5.3.4) AVPs MAY provide very useful debugging information. (Section 5.3.4) AVPs MAY provide very useful debugging information.
A Vendor-Id value of zero in the CER or CEA messages is reserved and A Vendor-Id value of zero in the CER or CEA messages is reserved and
indicates that this field is ignored. indicates that this field is ignored.
skipping to change at page 62, line 13 skipping to change at page 69, line 19
issuing device. issuing device.
For devices that do not have a firmware revision (general purpose For devices that do not have a firmware revision (general purpose
computers running Diameter software modules, for instance), the computers running Diameter software modules, for instance), the
revision of the Diameter software module may be reported instead. revision of the Diameter software module may be reported instead.
5.3.5. Host-IP-Address AVP 5.3.5. Host-IP-Address AVP
The Host-IP-Address AVP (AVP Code 257) is of type Address and is used The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
to inform a Diameter peer of the sender's IP address. All source to inform a Diameter peer of the sender's IP address. All source
addresses that a Diameter node expects to use with SCTP [SCTP] MUST addresses that a Diameter node expects to use with SCTP [RFC2960]
be advertised in the CER and CEA messages by including a Host-IP- MUST be advertised in the CER and CEA messages by including a
Address AVP for each address. This AVP MUST ONLY be used in the CER Host-IP- Address AVP for each address. This AVP MUST ONLY be used in
and CEA messages. the CER and CEA messages.
5.3.6. Supported-Vendor-Id AVP 5.3.6. Supported-Vendor-Id AVP
The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and
contains the IANA "SMI Network Management Private Enterprise Codes" contains the IANA "SMI Network Management Private Enterprise Codes"
[ASSIGNNO] value assigned to a vendor other than the device vendor. [RFC3232] value assigned to a vendor other than the device vendor.
This is used in the CER and CEA messages in order to inform the peer This is used in the CER and CEA messages in order to inform the peer
that the sender supports (a subset of) the vendor-specific AVPs that the sender supports (a subset of) the vendor-specific AVPs
defined by the vendor identified in this AVP. defined by the vendor identified in this AVP.
5.3.7. Product-Name AVP 5.3.7. Product-Name AVP
The Product-Name AVP (AVP Code 269) is of type UTF8String, and The Product-Name AVP (AVP Code 269) is of type UTF8String, and
contains the vendor assigned name for the product. The Product-Name contains the vendor assigned name for the product. The Product-Name
AVP SHOULD remain constant across firmware revisions for the same AVP SHOULD remain constant across firmware revisions for the same
product. product.
skipping to change at page 64, line 6 skipping to change at page 71, line 14
5.4.3. Disconnect-Cause AVP 5.4.3. Disconnect-Cause AVP
The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A
Diameter node MUST include this AVP in the Disconnect-Peer-Request Diameter node MUST include this AVP in the Disconnect-Peer-Request
message to inform the peer of the reason for its intention to message to inform the peer of the reason for its intention to
shutdown the transport connection. The following values are shutdown the transport connection. The following values are
supported: supported:
REBOOTING 0 REBOOTING 0
A scheduled reboot is imminent. A scheduled reboot is imminent. Receiver of DPR with above result
code MAY attempt reconnection.
BUSY 1 BUSY 1
The peer's internal resources are constrained, and it has The peer's internal resources are constrained, and it has
determined that the transport connection needs to be closed. determined that the transport connection needs to be closed.
Receiver of DPR with above result code SHOULD NOT attempt
reconnection.
DO_NOT_WANT_TO_TALK_TO_YOU 2 DO_NOT_WANT_TO_TALK_TO_YOU 2
The peer has determined that it does not see a need for the The peer has determined that it does not see a need for the
transport connection to exist, since it does not expect any transport connection to exist, since it does not expect any
messages to be exchanged in the near future. messages to be exchanged in the near future. Receiver of DPR
with above result code SHOULD NOT attempt reconnection.
5.5. Transport Failure Detection 5.5. Transport Failure Detection
Given the nature of the Diameter protocol, it is recommended that Given the nature of the Diameter protocol, it is recommended that
transport failures be detected as soon as possible. Detecting such transport failures be detected as soon as possible. Detecting such
failures will minimize the occurrence of messages sent to unavailable failures will minimize the occurrence of messages sent to unavailable
agents, resulting in unnecessary delays, and will provide better agents, resulting in unnecessary delays, and will provide better
failover performance. The Device-Watchdog-Request and Device- failover performance. The Device-Watchdog-Request and Device-
Watchdog-Answer messages, defined in this section, are used to pro- Watchdog-Answer messages, defined in this section, are used to pro-
actively detect transport failures. actively detect transport failures.
skipping to change at page 65, line 13 skipping to change at page 72, line 26
to the Device-Watchdog-Request message. to the Device-Watchdog-Request message.
Message Format Message Format
<DWA> ::= < Diameter Header: 280 > <DWA> ::= < Diameter Header: 280 >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ Error-Message ] [ Error-Message ]
* [ Failed-AVP ] * [ Failed-AVP ]
[ Original-State-Id ] [ Origin-State-Id ]
5.5.3. Transport Failure Algorithm 5.5.3. Transport Failure Algorithm
The transport failure algorithm is defined in [AAATRANS]. All The transport failure algorithm is defined in [RFC3539]. All
Diameter implementations MUST support the algorithm defined in the Diameter implementations MUST support the algorithm defined in the
specification in order to be compliant to the Diameter base protocol. specification in order to be compliant to the Diameter base protocol.
5.5.4. Failover and Failback Procedures 5.5.4. Failover and Failback Procedures
In the event that a transport failure is detected with a peer, it is In the event that a transport failure is detected with a peer, it is
necessary for all pending request messages to be forwarded to an necessary for all pending request messages to be forwarded to an
alternate agent, if possible. This is commonly referred to as alternate agent, if possible. This is commonly referred to as
failover. failover.
skipping to change at page 66, line 21 skipping to change at page 73, line 33
5.6. Peer State Machine 5.6. Peer State Machine
This section contains a finite state machine that MUST be observed by This section contains a finite state machine that MUST be observed by
all Diameter implementations. Each Diameter node MUST follow the all Diameter implementations. Each Diameter node MUST follow the
state machine described below when communicating with each peer. state machine described below when communicating with each peer.
Multiple actions are separated by commas, and may continue on Multiple actions are separated by commas, and may continue on
succeeding lines, as space requires. Similarly, state and next state succeeding lines, as space requires. Similarly, state and next state
may also span multiple lines, as space requires. may also span multiple lines, as space requires.
This state machine is closely coupled with the state machine This state machine is closely coupled with the state machine
described in [AAATRANS], which is used to open, close, failover, described in [RFC3539], which is used to open, close, failover,
probe, and reopen transport connections. Note in particular that probe, and reopen transport connections. Note in particular that
[AAATRANS] requires the use of watchdog messages to probe [RFC3539] requires the use of watchdog messages to probe connections.
connections. For Diameter, DWR and DWA messages are to be used. For Diameter, DWR and DWA messages are to be used.
I- is used to represent the initiator (connecting) connection, while I- is used to represent the initiator (connecting) connection, while
the R- is used to represent the responder (listening) connection. the R- is used to represent the responder (listening) connection.
The lack of a prefix indicates that the event or action is the same The lack of a prefix indicates that the event or action is the same
regardless of the connection on which the event occurred. regardless of the connection on which the event occurred.
The stable states that a state machine may be in are Closed, I-Open The stable states that a state machine may be in are Closed, I-Open
and R-Open; all other states are intermediate. Note that I-Open and and R-Open; all other states are intermediate. Note that I-Open and
R-Open are equivalent except for whether the initiator or responder R-Open are equivalent except for whether the initiator or responder
transport connection is used for communication. transport connection is used for communication.
skipping to change at page 71, line 22 skipping to change at page 79, line 18
the Origin-Host received in the CER sent by its peer with its own the Origin-Host received in the CER sent by its peer with its own
Origin-Host. If the local Diameter entity's Origin-Host is higher Origin-Host. If the local Diameter entity's Origin-Host is higher
than the peer's, a Win-Election event is issued locally. than the peer's, a Win-Election event is issued locally.
The comparison proceeds by considering the shorter OctetString to be The comparison proceeds by considering the shorter OctetString to be
padded with zeros so that it length is the same as the length of the padded with zeros so that it length is the same as the length of the
longer, then performing an octet-by-octet unsigned comparison with longer, then performing an octet-by-octet unsigned comparison with
the first octet being most significant. Any remaining octets are the first octet being most significant. Any remaining octets are
assumed to have value 0x80. assumed to have value 0x80.
5.6.5. Capabilities Update
A Diameter node MUST initiate peer capabilities update by sending a
Capabilities-Exchange-Req (CER) to all its peers which supports peer
capabilities update and is in OPEN state. The receiver of CER in
open state MUST process and reply to the CER as a described in
Section 5.3. The CEA which the receiver sends MUST contain its
latest capabilities. Note that peers which successfully process the
peer capabilities update SHOULD also update their routing tables to
reflect the change. The receiver of the CEA, with a Result-Code AVP
other than DIAMETER_SUCCESS, initiates the transport disconnect. The
peer may periodically attempt to reconnect, as stated in Section 2.1.
Peer capabilities update in the open state SHOULD be limited to the
advertisement of the new list of supported applications and MUST
preclude re-negotiation of security mechanism or other capabilities.
If any capabilities change happens in the node (e.g. change in
security mechanisms), other than a change in the supported
applications, the node SHOULD gracefully terminate (setting the
Disconnect-Cause AVP value to REBOOTING) and re-establish the
diameter connections to all the peers.
6. Diameter message processing 6. Diameter message processing
This section describes how Diameter requests and answers are created This section describes how Diameter requests and answers are created
and processed. and processed.
6.1. Diameter Request Routing Overview 6.1. Diameter Request Routing Overview
A request is sent towards its final destination using a combination A request is sent towards its final destination using a combination
of the Destination-Realm and Destination-Host AVPs, in one of these of the Destination-Realm and Destination-Host AVPs, in one of these
three combinations: three combinations:
- a request that is not able to be proxied (such as CER) MUST NOT o a request that is not able to be proxied (such as CER) MUST NOT
contain either Destination-Realm or Destination-Host AVPs. contain either Destination-Realm or Destination-Host AVPs.
- a request that needs to be sent to a home server serving a o a request that needs to be sent to a home server serving a
specific realm, but not to a specific server (such as the first specific realm, but not to a specific server (such as the first
request of a series of round-trips), MUST contain a Destination- request of a series of round-trips), MUST contain a Destination-
Realm AVP, but MUST NOT contain a Destination-Host AVP. Realm AVP, but MUST NOT contain a Destination-Host AVP.
- otherwise, a request that needs to be sent to a specific home o otherwise, a request that needs to be sent to a specific home
server among those serving a given realm, MUST contain both the server among those serving a given realm, MUST contain both the
Destination-Realm and Destination-Host AVPs. Destination-Realm and Destination-Host AVPs.
The Destination-Host AVP is used as described above when the The Destination-Host AVP is used as described above when the
destination of the request is fixed, which includes: destination of the request is fixed, which includes:
- Authentication requests that span multiple round trips o Authentication requests that span multiple round trips
- A Diameter message that uses a security mechanism that makes use o A Diameter message that uses a security mechanism that makes use
of a pre-established session key shared between the source and the of a pre-established session key shared between the source and the
final destination of the message. final destination of the message.
- Server initiated messages that MUST be received by a specific o Server initiated messages that MUST be received by a specific
Diameter client (e.g., access device), such as the Abort-Session- Diameter client (e.g., access device), such as the Abort-Session-
Request message, which is used to request that a particular user's Request message, which is used to request that a particular user's
session be terminated. session be terminated.
Note that an agent can forward a request to a host described in the Note that an agent can forward a request to a host described in the
Destination-Host AVP only if the host in question is included in its Destination-Host AVP only if the host in question is included in its
peer table (see Section 2.7). Otherwise, the request is routed based peer table (see Section 2.7). Otherwise, the request is routed based
on the Destination-Realm only (see Sections 6.1.6). on the Destination-Realm only (see Sections 6.1.6).