draft-ietf-dime-rfc3588bis-02.txt   draft-ietf-dime-rfc3588bis-03.txt 
DIME V. Fajardo, Ed. DIME V. Fajardo, Ed.
Internet-Draft Toshiba America Research Internet-Draft Toshiba America Research
Intended status: Standards Track J. Loughney Intended status: Standards Track J. Arkko
Expires: September 4, 2007 Nokia Research Center Expires: October 1, 2007 Ericsson Research
March 3, 2007 J. Loughney
Nokia Research Center
March 30, 2007
Diameter Base Protocol Diameter Base Protocol
draft-ietf-dime-rfc3588bis-02.txt draft-ietf-dime-rfc3588bis-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2007. This Internet-Draft will expire on October 1, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Diameter Protocol . . . . . . . . . . . . . . . . . . . . 10 1.1. Diameter Protocol . . . . . . . . . . . . . . . . . . . . 10
1.1.1. Description of the Document Set . . . . . . . . . . 11 1.1.1. Description of the Document Set . . . . . . . . . . 11
1.1.2. Conventions Used in This Document . . . . . . . . . 12 1.1.2. Conventions Used in This Document . . . . . . . . . 12
1.2. Approach to Extensibility . . . . . . . . . . . . . . . . 12 1.2. Approach to Extensibility . . . . . . . . . . . . . . . . 12
1.2.1. Defining New AVP Values . . . . . . . . . . . . . . 13 1.2.1. Defining New AVP Values . . . . . . . . . . . . . . 13
1.2.2. Creating New AVPs . . . . . . . . . . . . . . . . . 13 1.2.2. Creating New AVPs . . . . . . . . . . . . . . . . . 13
1.2.3. Creating New Authentication Applications . . . . . . 13 1.2.3. Creating New Authentication Applications . . . . . . 13
1.2.4. Creating New Accounting Applications . . . . . . . . 14 1.2.4. Creating New Accounting Applications . . . . . . . . 14
1.2.5. Application Authentication Procedures . . . . . . . 15 1.2.5. Application Authentication Procedures . . . . . . . 15
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 16 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 15
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 23 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 22
2.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 24 2.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1. SCTP Guidelines . . . . . . . . . . . . . . . . . . 25 2.1.1. SCTP Guidelines . . . . . . . . . . . . . . . . . . 24
2.2. Securing Diameter Messages . . . . . . . . . . . . . . . 25 2.2. Securing Diameter Messages . . . . . . . . . . . . . . . 24
2.3. Diameter Application Compliance . . . . . . . . . . . . . 25 2.3. Diameter Application Compliance . . . . . . . . . . . . . 24
2.4. Application Identifiers . . . . . . . . . . . . . . . . . 26 2.4. Application Identifiers . . . . . . . . . . . . . . . . . 24
2.5. Connections vs. Sessions . . . . . . . . . . . . . . . . 26 2.5. Connections vs. Sessions . . . . . . . . . . . . . . . . 25
2.6. Peer Table . . . . . . . . . . . . . . . . . . . . . . . 27 2.6. Peer Table . . . . . . . . . . . . . . . . . . . . . . . 26
2.7. Routing Table . . . . . . . . . . . . . . . . . . . . . . 28 2.7. Routing Table . . . . . . . . . . . . . . . . . . . . . . 27
2.8. Role of Diameter Agents . . . . . . . . . . . . . . . . . 30 2.8. Role of Diameter Agents . . . . . . . . . . . . . . . . . 28
2.8.1. Relay Agents . . . . . . . . . . . . . . . . . . . . 31 2.8.1. Relay Agents . . . . . . . . . . . . . . . . . . . . 30
2.8.2. Proxy Agents . . . . . . . . . . . . . . . . . . . . 32 2.8.2. Proxy Agents . . . . . . . . . . . . . . . . . . . . 31
2.8.3. Redirect Agents . . . . . . . . . . . . . . . . . . 32 2.8.3. Redirect Agents . . . . . . . . . . . . . . . . . . 31
2.8.4. Translation Agents . . . . . . . . . . . . . . . . . 33 2.8.4. Translation Agents . . . . . . . . . . . . . . . . . 32
2.9. End-to-End Security Framework . . . . . . . . . . . . . . 34 2.9. Diameter Path Authorization . . . . . . . . . . . . . . . 33
2.10. Diameter Path Authorization . . . . . . . . . . . . . . . 35 3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 35
3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 37 3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 38
3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 40 3.2. Command Code ABNF specification . . . . . . . . . . . . . 38
3.2. Command Code ABNF specification . . . . . . . . . . . . . 41 3.3. Diameter Command Naming Conventions . . . . . . . . . . . 40
3.3. Diameter Command Naming Conventions . . . . . . . . . . . 43 4. Diameter AVPs . . . . . . . . . . . . . . . . . . . . . . . . 42
4. Diameter AVPs . . . . . . . . . . . . . . . . . . . . . . . . 44 4.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 42
4.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 44 4.1.1. Optional Header Elements . . . . . . . . . . . . . . 44
4.1.1. Optional Header Elements . . . . . . . . . . . . . . 46 4.2. Basic AVP Data Formats . . . . . . . . . . . . . . . . . 44
4.2. Basic AVP Data Formats . . . . . . . . . . . . . . . . . 46 4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 46
4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 48 4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 53
4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 56 4.4.1. Example AVP with a Grouped Data type . . . . . . . . 54
4.4.1. Example AVP with a Grouped Data type . . . . . . . . 57 4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 56
4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 60 5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 60
5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 63 5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 60
5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 63 5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 60
5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 63 5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 63
5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 66 5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 64
5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 67 5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 65
5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 68 5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 65
5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 69 5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 66
5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 69 5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 66
5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 69 5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 66
5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 69 5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 66
5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 70 5.4. Disconnecting Peer connections . . . . . . . . . . . . . 66
5.4. Disconnecting Peer connections . . . . . . . . . . . . . 70 5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 67
5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 70 5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 67
5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 71 5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 68
5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 71 5.5. Transport Failure Detection . . . . . . . . . . . . . . . 68
5.5. Transport Failure Detection . . . . . . . . . . . . . . . 72 5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 68
5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 72 5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 69
5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 72 5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 69
5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 73 5.5.4. Failover and Failback Procedures . . . . . . . . . . 69
5.5.4. Failover and Failback Procedures . . . . . . . . . . 73 5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 70
5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 73 5.6.1. Incoming connections . . . . . . . . . . . . . . . . 72
5.6.1. Incoming connections . . . . . . . . . . . . . . . . 76 5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 73
5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 76 5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 74
5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 77 5.6.4. The Election Process . . . . . . . . . . . . . . . . 76
5.6.4. The Election Process . . . . . . . . . . . . . . . . 79 5.6.5. Capabilities Update . . . . . . . . . . . . . . . . 76
5.6.5. Capabilities Update . . . . . . . . . . . . . . . . 79 6. Diameter message processing . . . . . . . . . . . . . . . . . 77
6. Diameter message processing . . . . . . . . . . . . . . . . . 80 6.1. Diameter Request Routing Overview . . . . . . . . . . . . 77
6.1. Diameter Request Routing Overview . . . . . . . . . . . . 80 6.1.1. Originating a Request . . . . . . . . . . . . . . . 78
6.1.1. Originating a Request . . . . . . . . . . . . . . . 81 6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 79
6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 82 6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 79
6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 82 6.1.4. Processing Local Requests . . . . . . . . . . . . . 79
6.1.4. Processing Local Requests . . . . . . . . . . . . . 82 6.1.5. Request Forwarding . . . . . . . . . . . . . . . . . 79
6.1.5. Request Forwarding . . . . . . . . . . . . . . . . . 82 6.1.6. Request Routing . . . . . . . . . . . . . . . . . . 80
6.1.6. Request Routing . . . . . . . . . . . . . . . . . . 83 6.1.7. Predictive Loop Avoidance . . . . . . . . . . . . . 80
6.1.7. Predictive Loop Avoidance . . . . . . . . . . . . . 83 6.1.8. Redirecting requests . . . . . . . . . . . . . . . . 80
6.1.8. Redirecting requests . . . . . . . . . . . . . . . . 83 6.1.9. Relaying and Proxying Requests . . . . . . . . . . . 81
6.1.9. Relaying and Proxying Requests . . . . . . . . . . . 84 6.2. Diameter Answer Processing . . . . . . . . . . . . . . . 82
6.2. Diameter Answer Processing . . . . . . . . . . . . . . . 85 6.2.1. Processing received Answers . . . . . . . . . . . . 83
6.2.1. Processing received Answers . . . . . . . . . . . . 86 6.2.2. Relaying and Proxying Answers . . . . . . . . . . . 83
6.2.2. Relaying and Proxying Answers . . . . . . . . . . . 86 6.3. Origin-Host AVP . . . . . . . . . . . . . . . . . . . . . 83
6.3. Origin-Host AVP . . . . . . . . . . . . . . . . . . . . . 86 6.4. Origin-Realm AVP . . . . . . . . . . . . . . . . . . . . 84
6.4. Origin-Realm AVP . . . . . . . . . . . . . . . . . . . . 87 6.5. Destination-Host AVP . . . . . . . . . . . . . . . . . . 84
6.5. Destination-Host AVP . . . . . . . . . . . . . . . . . . 87 6.6. Destination-Realm AVP . . . . . . . . . . . . . . . . . . 84
6.6. Destination-Realm AVP . . . . . . . . . . . . . . . . . . 87 6.7. Routing AVPs . . . . . . . . . . . . . . . . . . . . . . 85
6.7. Routing AVPs . . . . . . . . . . . . . . . . . . . . . . 88 6.7.1. Route-Record AVP . . . . . . . . . . . . . . . . . . 85
6.7.1. Route-Record AVP . . . . . . . . . . . . . . . . . . 88 6.7.2. Proxy-Info AVP . . . . . . . . . . . . . . . . . . . 85
6.7.2. Proxy-Info AVP . . . . . . . . . . . . . . . . . . . 88 6.7.3. Proxy-Host AVP . . . . . . . . . . . . . . . . . . . 85
6.7.3. Proxy-Host AVP . . . . . . . . . . . . . . . . . . . 88 6.7.4. Proxy-State AVP . . . . . . . . . . . . . . . . . . 85
6.7.4. Proxy-State AVP . . . . . . . . . . . . . . . . . . 88 6.8. Auth-Application-Id AVP . . . . . . . . . . . . . . . . . 85
6.8. Auth-Application-Id AVP . . . . . . . . . . . . . . . . . 88 6.9. Acct-Application-Id AVP . . . . . . . . . . . . . . . . . 85
6.9. Acct-Application-Id AVP . . . . . . . . . . . . . . . . . 89 6.10. Inband-Security-Id AVP . . . . . . . . . . . . . . . . . 86
6.10. Inband-Security-Id AVP . . . . . . . . . . . . . . . . . 89 6.11. Vendor-Specific-Application-Id AVP . . . . . . . . . . . 86
6.11. Vendor-Specific-Application-Id AVP . . . . . . . . . . . 89 6.12. Redirect-Host AVP . . . . . . . . . . . . . . . . . . . . 87
6.12. Redirect-Host AVP . . . . . . . . . . . . . . . . . . . . 90 6.13. Redirect-Host-Usage AVP . . . . . . . . . . . . . . . . . 87
6.13. Redirect-Host-Usage AVP . . . . . . . . . . . . . . . . . 90 6.14. Redirect-Max-Cache-Time AVP . . . . . . . . . . . . . . . 88
6.14. Redirect-Max-Cache-Time AVP . . . . . . . . . . . . . . . 91 6.15. E2E-Sequence AVP . . . . . . . . . . . . . . . . . . . . 88
6.15. E2E-Sequence AVP . . . . . . . . . . . . . . . . . . . . 91 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 89
7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 93 7.1. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 90
7.1. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 95 7.1.1. Informational . . . . . . . . . . . . . . . . . . . 91
7.1.1. Informational . . . . . . . . . . . . . . . . . . . 95 7.1.2. Success . . . . . . . . . . . . . . . . . . . . . . 91
7.1.2. Success . . . . . . . . . . . . . . . . . . . . . . 96 7.1.3. Protocol Errors . . . . . . . . . . . . . . . . . . 92
7.1.3. Protocol Errors . . . . . . . . . . . . . . . . . . 96 7.1.4. Transient Failures . . . . . . . . . . . . . . . . . 93
7.1.4. Transient Failures . . . . . . . . . . . . . . . . . 97 7.1.5. Permanent Failures . . . . . . . . . . . . . . . . . 94
7.1.5. Permanent Failures . . . . . . . . . . . . . . . . . 98 7.2. Error Bit . . . . . . . . . . . . . . . . . . . . . . . . 97
7.2. Error Bit . . . . . . . . . . . . . . . . . . . . . . . . 101 7.3. Error-Message AVP . . . . . . . . . . . . . . . . . . . . 97
7.3. Error-Message AVP . . . . . . . . . . . . . . . . . . . . 101 7.4. Error-Reporting-Host AVP . . . . . . . . . . . . . . . . 97
7.4. Error-Reporting-Host AVP . . . . . . . . . . . . . . . . 102 7.5. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . 97
7.5. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . 102 7.6. Experimental-Result AVP . . . . . . . . . . . . . . . . . 98
7.6. Experimental-Result AVP . . . . . . . . . . . . . . . . . 103 7.7. Experimental-Result-Code AVP . . . . . . . . . . . . . . 99
7.7. Experimental-Result-Code AVP . . . . . . . . . . . . . . 103 8. Diameter User Sessions . . . . . . . . . . . . . . . . . . . 100
8. Diameter User Sessions . . . . . . . . . . . . . . . . . . . 104 8.1. Authorization Session State Machine . . . . . . . . . . . 101
8.1. Authorization Session State Machine . . . . . . . . . . . 105 8.2. Accounting Session State Machine . . . . . . . . . . . . 105
8.2. Accounting Session State Machine . . . . . . . . . . . . 109 8.3. Server-Initiated Re-Auth . . . . . . . . . . . . . . . . 111
8.3. Server-Initiated Re-Auth . . . . . . . . . . . . . . . . 115 8.3.1. Re-Auth-Request . . . . . . . . . . . . . . . . . . 111
8.3.1. Re-Auth-Request . . . . . . . . . . . . . . . . . . 115 8.3.2. Re-Auth-Answer . . . . . . . . . . . . . . . . . . . 112
8.3.2. Re-Auth-Answer . . . . . . . . . . . . . . . . . . . 116 8.4. Session Termination . . . . . . . . . . . . . . . . . . . 112
8.4. Session Termination . . . . . . . . . . . . . . . . . . . 117 8.4.1. Session-Termination-Request . . . . . . . . . . . . 113
8.4.1. Session-Termination-Request . . . . . . . . . . . . 118 8.4.2. Session-Termination-Answer . . . . . . . . . . . . . 114
8.4.2. Session-Termination-Answer . . . . . . . . . . . . . 118 8.5. Aborting a Session . . . . . . . . . . . . . . . . . . . 115
8.5. Aborting a Session . . . . . . . . . . . . . . . . . . . 119 8.5.1. Abort-Session-Request . . . . . . . . . . . . . . . 116
8.5.1. Abort-Session-Request . . . . . . . . . . . . . . . 120 8.5.2. Abort-Session-Answer . . . . . . . . . . . . . . . . 116
8.5.2. Abort-Session-Answer . . . . . . . . . . . . . . . . 120 8.6. Inferring Session Termination from Origin-State-Id . . . 117
8.6. Inferring Session Termination from Origin-State-Id . . . 121 8.7. Auth-Request-Type AVP . . . . . . . . . . . . . . . . . . 118
8.7. Auth-Request-Type AVP . . . . . . . . . . . . . . . . . . 122 8.8. Session-Id AVP . . . . . . . . . . . . . . . . . . . . . 118
8.8. Session-Id AVP . . . . . . . . . . . . . . . . . . . . . 122 8.9. Authorization-Lifetime AVP . . . . . . . . . . . . . . . 119
8.9. Authorization-Lifetime AVP . . . . . . . . . . . . . . . 123 8.10. Auth-Grace-Period AVP . . . . . . . . . . . . . . . . . . 120
8.10. Auth-Grace-Period AVP . . . . . . . . . . . . . . . . . . 124 8.11. Auth-Session-State AVP . . . . . . . . . . . . . . . . . 120
8.11. Auth-Session-State AVP . . . . . . . . . . . . . . . . . 124 8.12. Re-Auth-Request-Type AVP . . . . . . . . . . . . . . . . 121
8.12. Re-Auth-Request-Type AVP . . . . . . . . . . . . . . . . 125 8.13. Session-Timeout AVP . . . . . . . . . . . . . . . . . . . 121
8.13. Session-Timeout AVP . . . . . . . . . . . . . . . . . . . 125 8.14. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 122
8.14. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 126 8.15. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 122
8.15. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 126 8.16. Origin-State-Id AVP . . . . . . . . . . . . . . . . . . . 123
8.16. Origin-State-Id AVP . . . . . . . . . . . . . . . . . . . 127 8.17. Session-Binding AVP . . . . . . . . . . . . . . . . . . . 123
8.17. Session-Binding AVP . . . . . . . . . . . . . . . . . . . 128 8.18. Session-Server-Failover AVP . . . . . . . . . . . . . . . 124
8.18. Session-Server-Failover AVP . . . . . . . . . . . . . . . 128 8.19. Multi-Round-Time-Out AVP . . . . . . . . . . . . . . . . 125
8.19. Multi-Round-Time-Out AVP . . . . . . . . . . . . . . . . 129 8.20. Class AVP . . . . . . . . . . . . . . . . . . . . . . . . 125
8.20. Class AVP . . . . . . . . . . . . . . . . . . . . . . . . 129 8.21. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . . 125
8.21. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . . 130 9. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 127
9. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 131 9.1. Server Directed Model . . . . . . . . . . . . . . . . . . 127
9.1. Server Directed Model . . . . . . . . . . . . . . . . . . 131 9.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 128
9.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 132 9.3. Accounting Application Extension and Requirements . . . . 128
9.3. Accounting Application Extension and Requirements . . . . 132 9.4. Fault Resilience . . . . . . . . . . . . . . . . . . . . 129
9.4. Fault Resilience . . . . . . . . . . . . . . . . . . . . 133 9.5. Accounting Records . . . . . . . . . . . . . . . . . . . 130
9.5. Accounting Records . . . . . . . . . . . . . . . . . . . 134 9.6. Correlation of Accounting Records . . . . . . . . . . . . 130
9.6. Correlation of Accounting Records . . . . . . . . . . . . 135 9.7. Accounting Command-Codes . . . . . . . . . . . . . . . . 131
9.7. Accounting Command-Codes . . . . . . . . . . . . . . . . 135 9.7.1. Accounting-Request . . . . . . . . . . . . . . . . . 131
9.7.1. Accounting-Request . . . . . . . . . . . . . . . . . 135 9.7.2. Accounting-Answer . . . . . . . . . . . . . . . . . 132
9.7.2. Accounting-Answer . . . . . . . . . . . . . . . . . 136 9.8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 133
9.8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 137 9.8.1. Accounting-Record-Type AVP . . . . . . . . . . . . . 133
9.8.1. Accounting-Record-Type AVP . . . . . . . . . . . . . 137 9.8.2. Acct-Interim-Interval . . . . . . . . . . . . . . . 134
9.8.2. Acct-Interim-Interval . . . . . . . . . . . . . . . 138 9.8.3. Accounting-Record-Number AVP . . . . . . . . . . . . 135
9.8.3. Accounting-Record-Number AVP . . . . . . . . . . . . 139 9.8.4. Acct-Session-Id AVP . . . . . . . . . . . . . . . . 135
9.8.4. Acct-Session-Id AVP . . . . . . . . . . . . . . . . 139 9.8.5. Acct-Multi-Session-Id AVP . . . . . . . . . . . . . 135
9.8.5. Acct-Multi-Session-Id AVP . . . . . . . . . . . . . 139 9.8.6. Accounting-Sub-Session-Id AVP . . . . . . . . . . . 135
9.8.6. Accounting-Sub-Session-Id AVP . . . . . . . . . . . 140 9.8.7. Accounting-Realtime-Required AVP . . . . . . . . . . 136
9.8.7. Accounting-Realtime-Required AVP . . . . . . . . . . 140 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 137
10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 141 10.1. Base Protocol Command AVP Table . . . . . . . . . . . . . 137
10.1. Base Protocol Command AVP Table . . . . . . . . . . . . . 141 10.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . 138
10.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . 142 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 140
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 144 11.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 140
11.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 144 11.1.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . 140
11.1.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . 144 11.1.2. AVP Flags . . . . . . . . . . . . . . . . . . . . . 141
11.1.2. AVP Flags . . . . . . . . . . . . . . . . . . . . . 145 11.2. Diameter Header . . . . . . . . . . . . . . . . . . . . . 141
11.2. Diameter Header . . . . . . . . . . . . . . . . . . . . . 145 11.2.1. Command Codes . . . . . . . . . . . . . . . . . . . 141
11.2.1. Command Codes . . . . . . . . . . . . . . . . . . . 145 11.2.2. Command Flags . . . . . . . . . . . . . . . . . . . 142
11.2.2. Command Flags . . . . . . . . . . . . . . . . . . . 146 11.3. Application Identifiers . . . . . . . . . . . . . . . . . 142
11.3. Application Identifiers . . . . . . . . . . . . . . . . . 146 11.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . 142
11.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . 146 11.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . 142
11.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . 147 11.4.2. Accounting-Record-Type AVP Values . . . . . . . . . 143
11.4.2. Accounting-Record-Type AVP Values . . . . . . . . . 147 11.4.3. Termination-Cause AVP Values . . . . . . . . . . . . 143
11.4.3. Termination-Cause AVP Values . . . . . . . . . . . . 147 11.4.4. Redirect-Host-Usage AVP Values . . . . . . . . . . . 143
11.4.4. Redirect-Host-Usage AVP Values . . . . . . . . . . . 147 11.4.5. Session-Server-Failover AVP Values . . . . . . . . . 143
11.4.5. Session-Server-Failover AVP Values . . . . . . . . . 147 11.4.6. Session-Binding AVP Values . . . . . . . . . . . . . 143
11.4.6. Session-Binding AVP Values . . . . . . . . . . . . . 147 11.4.7. Disconnect-Cause AVP Values . . . . . . . . . . . . 143
11.4.7. Disconnect-Cause AVP Values . . . . . . . . . . . . 147 11.4.8. Auth-Request-Type AVP Values . . . . . . . . . . . . 143
11.4.8. Auth-Request-Type AVP Values . . . . . . . . . . . . 147 11.4.9. Auth-Session-State AVP Values . . . . . . . . . . . 144
11.4.9. Auth-Session-State AVP Values . . . . . . . . . . . 148 11.4.10. Re-Auth-Request-Type AVP Values . . . . . . . . . . 144
11.4.10. Re-Auth-Request-Type AVP Values . . . . . . . . . . 148 11.4.11. Accounting-Realtime-Required AVP Values . . . . . . 144
11.4.11. Accounting-Realtime-Required AVP Values . . . . . . 148 11.4.12. Inband-Security-Id AVP (code 299) . . . . . . . . . 144
11.4.12. Inband-Security-Id AVP (code 299) . . . . . . . . . 148 11.5. Diameter TCP/SCTP Port Numbers . . . . . . . . . . . . . 144
11.5. Diameter TCP/SCTP Port Numbers . . . . . . . . . . . . . 148 11.6. NAPTR Service Fields . . . . . . . . . . . . . . . . . . 144
11.6. NAPTR Service Fields . . . . . . . . . . . . . . . . . . 148 12. Diameter protocol related configurable parameters . . . . . . 146
12. Diameter protocol related configurable parameters . . . . . . 150 13. Security Considerations . . . . . . . . . . . . . . . . . . . 147
13. Security Considerations . . . . . . . . . . . . . . . . . . . 151 13.1. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 147
13.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . 151 13.2. Peer-to-Peer Considerations . . . . . . . . . . . . . . . 148
13.2. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 152 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 149
13.3. Peer-to-Peer Considerations . . . . . . . . . . . . . . . 153 14.1. Normative References . . . . . . . . . . . . . . . . . . 149
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 155 14.2. Informational References . . . . . . . . . . . . . . . . 151
14.1. Normative References . . . . . . . . . . . . . . . . . . 155 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 153
14.2. Informational References . . . . . . . . . . . . . . . . 157 Appendix B. NAPTR Example . . . . . . . . . . . . . . . . . . . 154
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 160 Appendix C. Duplicate Detection . . . . . . . . . . . . . . . . 155
Appendix B. Diameter Service Template . . . . . . . . . . . . . 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 157
Appendix C. NAPTR Example . . . . . . . . . . . . . . . . . . . 163 Intellectual Property and Copyright Statements . . . . . . . . . 158
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 [RFC1492] and RADIUS [RFC2865] were initially deployed to TACACS [RFC1492] and RADIUS [RFC2865] were initially deployed to
provide dial-up PPP [RFC1661] 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.
skipping to change at page 7, line 48 skipping to change at page 7, line 48
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 [RFC2409] authentication IPsec is not required. Since within [RFC2409] authentication
occurs only within Phase 1 prior to the establishment of IPsec SAs occurs only within Phase 1 prior to the establishment of IPsec SAs
in Phase 2, it is typically not possible to define separate trust in Phase 2, it is typically not possible to define separate trust
or 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, Diameter also
is mandatory in Diameter, and TLS support is optional. Security provides support for TLS. 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 [RFC2975], 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 [RFC3539]. reliable transport mechanisms (TCP, SCTP) as defined in [RFC3539].
skipping to change at page 8, line 37 skipping to change at page 8, line 37
reauthorization on demand across a heterogeneous deployment. reauthorization on demand across a heterogeneous deployment.
Support for server-initiated messages is mandatory in Diameter, Support for server-initiated messages is mandatory in 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.
implementation of data object security is not mandatory within
Diameter, these capabilities are supported, and are described in
[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
skipping to change at page 10, line 9 skipping to change at page 10, line 6
[RFC2607]. In order to improve scalability, [RFC2607] introduced [RFC2607]. In order to improve scalability, [RFC2607] introduced
the concept of proxy chaining via an intermediate server, the concept of proxy chaining via an intermediate server,
facilitating roaming between providers. However, since RADIUS facilitating roaming between providers. However, since 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 [RFC2607]. 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), and transmission-layer security (Section 13) features,
(Section 13) features, Diameter addresses these limitations and Diameter addresses these limitations and provides for secure and
provides for secure and scalable roaming. 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 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:
o Delivery of AVPs (attribute value pairs) o Delivery of AVPs (attribute value pairs)
o Capabilities negotiation o Capabilities negotiation
o Error notification o Error notification
skipping to change at page 17, line 27 skipping to change at page 17, line 26
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
A Diameter Security Exchange is a process through which two
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
TLS and IPsec provide hop-by-hop security, or security across a
transport connection. When relays or proxy are involved, this
hop-by-hop security does not protect the entire Diameter user
session. End-to-end security is security between two Diameter
nodes, possibly communicating through Diameter Agents. This
security protects the entire Diameter communications path from the
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
skipping to change at page 20, line 27 skipping to change at page 20, line 11
acting as relay or proxy agents for other types. As with proxy acting as relay or proxy agents for other types. As with proxy
agents, redirect agents do not keep state with respect to sessions agents, redirect agents do not keep state with respect to sessions
or NAS resources. or NAS resources.
Roaming Relationships Roaming Relationships
Roaming relationships include relationships between companies and Roaming relationships include relationships between companies and
ISPs, relationships among peer ISPs within a roaming consortium, ISPs, relationships among peer ISPs within a roaming consortium,
and relationships between an ISP and a roaming consortium. and relationships between an ISP and a roaming consortium.
Security Association
A security association is an association between two endpoints in
a Diameter session which allows the endpoints to communicate with
integrity and confidentially, even in the presence of relays
and/or proxies.
Session Session
A session is a related progression of events devoted to a A session is a related progression of events devoted to a
particular activity. Each application SHOULD provide guidelines particular activity. Each application SHOULD provide guidelines
as to when a session begins and ends. All Diameter packets with as to when a session begins and ends. All Diameter packets with
the same Session-Identifier are considered to be part of the same the same Session-Identifier are considered to be part of the same
session. session.
Session state Session state
skipping to change at page 25, line 28 skipping to change at page 24, line 28
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 [RFC2401], and MAY support TLS Agents MAY support TLS [RFC2246]. Diameter servers MUST support TLS.
[RFC2246]. Diameter servers MUST support TLS and IPsec. The IPSec [RFC2401] can be deployed between Diameter peers as an
Diameter protocol MUST NOT be used without any security mechanism additional security measure independent of the Diameter protocol.
(TLS or IPsec). The Diameter protocol SHOULD NOT be used without any security
mechanism.
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
local AAA proxy. This also eases the requirements on the NAS to
support certificates. It is also suggested that inter-domain traffic
would primarily use TLS. See Sections 13.1 and 13.2 for more details
on IPsec and TLS usage.
2.3. Diameter Application Compliance 2.3. Diameter Application Compliance
Application Identifiers are advertised during the capabilities Application Identifiers are advertised during the capabilities
exchange phase (see Section 5.3). For a given application, exchange phase (see Section 5.3). For a given application,
advertising support of an application implies that the sender advertising support of an application implies that the sender
supports all command codes, and the AVPs specified in the associated supports all command codes, and the AVPs specified in the associated
ABNFs, described in the specification. ABNFs, described in the specification.
An implementation MAY add arbitrary non-mandatory AVPs to any command An implementation MAY add arbitrary non-mandatory AVPs to any command
skipping to change at page 32, line 27 skipping to change at page 31, line 15
2.8.2. Proxy Agents 2.8.2. Proxy Agents
Similarly to relays, proxy agents route Diameter messages using the Similarly to relays, proxy agents route Diameter messages using the
Diameter Routing Table. However, they differ since they modify Diameter Routing Table. However, they differ since they modify
messages to implement policy enforcement. This requires that proxies messages to implement policy enforcement. This requires that proxies
maintain the state of their downstream peers (e.g., access devices) maintain the state of their downstream peers (e.g., access devices)
to enforce resource usage, provide admission control, and to enforce resource usage, provide admission control, and
provisioning. provisioning.
It is important to note that although proxies MAY provide a value-add
function for NASes, they do not allow access devices to use end-to-
end security, since modifying messages breaks authentication.
Proxies MAY be used in call control centers or access ISPs that Proxies MAY be used in call control centers or access ISPs that
provide outsourced connections, they can monitor the number and types provide outsourced connections, they can monitor the number and types
of ports in use, and make allocation and admission decisions of ports in use, and make allocation and admission decisions
according to their configuration. according to their configuration.
Proxies that wish to limit resources MUST maintain session state. Proxies that wish to limit resources MUST maintain session state.
All proxies MUST maintain transaction state. All proxies MUST maintain transaction state.
Since enforcing policies requires an understanding of the service Since enforcing policies requires an understanding of the service
being provided, Proxies MUST only advertise the Diameter applications being provided, Proxies MUST only advertise the Diameter applications
skipping to change at page 34, line 20 skipping to change at page 33, line 4
Translation of messages can only occur if the agent recognizes the Translation of messages can only occur if the agent recognizes the
application of a particular request, and therefore translation agents application of a particular request, and therefore translation agents
MUST only advertise their locally supported applications. MUST only advertise their locally supported applications.
+------+ ---------> +------+ ---------> +------+ +------+ ---------> +------+ ---------> +------+
| | RADIUS Request | | Diameter Request | | | | RADIUS Request | | Diameter Request | |
| NAS | | TLA | | HMS | | NAS | | TLA | | HMS |
| | RADIUS Answer | | Diameter Answer | | | | RADIUS Answer | | Diameter Answer | |
+------+ <--------- +------+ <--------- +------+ +------+ <--------- +------+ <--------- +------+
example.net example.net example.com example.net example.net example.com
Figure 4: Translation of RADIUS to Diameter Figure 4: Translation of RADIUS to Diameter
2.9. End-to-End Security Framework 2.9. Diameter Path Authorization
End-to-end security services include confidentiality and message
origin authentication. These services are provided by supporting AVP
integrity and confidentiality between two peers, communicating
through agents.
End-to-end security is provided via the End-to-End security
extension, described in [AAACMS]. The circumstances requiring the
use of end-to-end security are determined by policy on each of the
peers. Security policies, which are not the subject of
standardization, may be applied by next hop Diameter peer or by
destination realm. For example, where TLS or IPsec transmission-
level security is sufficient, there may be no need for end-to-end
security.
End-to-end security policies include:
o Never use end-to-end security.
o Use end-to-end security on messages containing sensitive AVPs.
Which AVPs are sensitive is determined by service provider policy.
AVPs containing keys and passwords should be considered sensitive.
Accounting AVPs may be considered sensitive. Any AVP for which
the P bit may be set or which may be encrypted may be considered
sensitive.
o Always use end-to-end security.
It is strongly RECOMMENDED that all Diameter implementations support
end-to-end security.
2.10. Diameter Path Authorization
As noted in Section 2.2, Diameter requires transmission level As noted in Section 2.2, Diameter provides transmission level
security to be used on each connection (TLS or IPsec). Therefore, security for each connection using TLS. Therefore, each connection
each connection is authenticated, replay and integrity protected and can be authenticated, replay and integrity protected.
confidential on a per-packet basis.
In addition to authenticating each connection, each connection as In addition to authenticating each connection, each connection as
well as the entire session MUST also be authorized. Before well as the entire session MUST also be authorized. Before
initiating a connection, a Diameter Peer MUST check that its peers initiating a connection, a Diameter Peer MUST check that its peers
are authorized to act in their roles. For example, a Diameter peer are authorized to act in their roles. For example, a Diameter peer
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
skipping to change at page 44, line 8 skipping to change at page 42, line 8
o 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 and routing information as well as configuration
configuration details for the request and reply. details for the request and reply.
Some AVPs MAY be listed more than once. The effect of such an AVP is Some AVPs MAY be listed more than once. The effect of such an AVP is
specific, and is specified in each case by the AVP description. specific, and is specified in each case by the AVP description.
Each AVP of type OctetString MUST be padded to align on a 32-bit Each AVP of type OctetString MUST be padded to align on a 32-bit
boundary, while other AVP types align naturally. A number of zero- boundary, while other AVP types align naturally. A number of zero-
valued bytes are added to the end of the AVP Data field till a word valued bytes are added to the end of the AVP Data field till a word
boundary is reached. The length of the padding is not reflected in boundary is reached. The length of the padding is not reflected in
the AVP Length field. the AVP Length field.
4.1. AVP Header 4.1. AVP Header
The fields in the AVP header MUST be sent in network byte order. The The fields in the AVP header MUST be sent in network byte order. The
format of the header is: format of the header is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code | | AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P r r r r r| AVP Length | |V M r r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) | | Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... | Data ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
AVP Code AVP Code
The AVP Code, combined with the Vendor-Id field, identifies the The AVP Code, combined with the Vendor-Id field, identifies the
attribute uniquely. AVP numbers 1 through 255 are reserved for attribute uniquely. AVP numbers 1 through 255 are reserved for
backward compatibility with RADIUS, without setting the Vendor-Id backward compatibility with RADIUS, without setting the Vendor-Id
field. AVP numbers 256 and above are used for Diameter, which are field. AVP numbers 256 and above are used for Diameter, which are
allocated by IANA (see Section 11.1). allocated by IANA (see Section 11.1).
AVP Flags AVP Flags
The AVP Flags field informs the receiver how each attribute must The AVP Flags field informs the receiver how each attribute must
be handled. The 'r' (reserved) bits are unused and SHOULD be set be handled. The 'r' (reserved) bits are unused and SHOULD be set
to 0. Note that subsequent Diameter applications MAY define to 0. Note that subsequent Diameter applications MAY define
additional bits within the AVP Header, and an unrecognized bit additional bits within the AVP Header, and an unrecognized bit
SHOULD be considered an error. The 'P' bit indicates the need for SHOULD be considered an error.
encryption for end-to-end security.
The 'M' Bit, known as the Mandatory bit, indicates whether support The 'M' Bit, known as the Mandatory bit, indicates whether support
of the AVP is required. If an AVP with the 'M' bit set is of the AVP is required. If an AVP with the 'M' bit set is
received by a Diameter client, server, proxy, or translation agent received by a Diameter client, server, proxy, or translation agent
and either the AVP or its value is unrecognized, the message MUST and either the AVP or its value is unrecognized, the message MUST
be rejected. Diameter Relay and redirect agents MUST NOT reject be rejected. Diameter Relay and redirect agents MUST NOT reject
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
skipping to change at page 56, line 11 skipping to change at page 53, line 8
the first matched rule terminating the evaluation. Each packet is the first matched rule terminating the evaluation. Each packet is
evaluated once. If no rule matches, the packet is treated as best evaluated once. If no rule matches, the packet is treated as best
effort. An access device that is unable to interpret or apply a effort. An access device that is unable to interpret or apply a
QoS rule SHOULD NOT terminate the session. QoS rule SHOULD NOT terminate the session.
QoSFilterRule filters MUST follow the format: QoSFilterRule filters MUST follow the format:
action dir proto from src to dst [options] action dir proto from src to dst [options]
tag - Mark packet with a specific DSCP tag - Mark packet with a specific DSCP
[DIFFSERV]. The DSCP option MUST be [RFC2474]. The DSCP option MUST be
included. included.
meter - Meter traffic. The metering options meter - Meter traffic. The metering options
MUST be included. MUST be included.
dir The format is as described under IPFilterRule. dir The format is as described under IPFilterRule.
proto The format is as described under proto The format is as described under
IPFilterRule. IPFilterRule.
src and dst The format is as described under src and dst The format is as described under
skipping to change at page 60, line 8 skipping to change at page 56, line 51
336| 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b | 336| 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
. . . . . .
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
464| 0x41 |Padding|Padding|Padding| 464| 0x41 |Padding|Padding|Padding|
+-------+-------+-------+-------+ +-------+-------+-------+-------+
4.5. Diameter Base Protocol AVPs 4.5. Diameter Base Protocol AVPs
The following table describes the Diameter AVPs defined in the base The following table describes the Diameter AVPs defined in the base
protocol, their AVP Code values, types, possible flag values and protocol, their AVP Code values, types, possible flag values.
whether the AVP MAY be encrypted. For the originator of a Diameter
message, "Encr" (Encryption) means that if a message containing that
AVP is to be sent via a Diameter agent (proxy, redirect or relay)
then the message MUST NOT be sent unless there is end-to-end security
between the originator and the recipient and integrity /
confidentiality protection is offered for this AVP OR the originator
has locally trusted configuration that indicates that end-to-end
security is not needed. Similarly, for the originator of a Diameter
message, a "P" in the "MAY" column means that if a message containing
that AVP is to be sent via a Diameter agent (proxy, redirect or
relay) then the message MUST NOT be sent unless there is end-to-end
security between the originator and the recipient or the originator
has locally trusted configuration that indicates that end-to-end
security is not needed.
Due to space constraints, the short form DiamIdent is used to Due to space constraints, the short form DiamIdent is used to
represent DiameterIdentity. represent DiameterIdentity.
+---------------------+ +---------------------+
| AVP Flag rules | | AVP Flag rules |
|----+-----+----+-----|----+ |----+-----+----+-----|
AVP Section | | |SHLD| MUST| | AVP Section | | |SHLD| MUST|
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|
-----------------------------------------|----+-----+----+-----|----| -----------------------------------------|----+-----+----+-----|
Acct- 85 9.8.2 Unsigned32 | M | P | | V | Y | Acct- 85 9.8.2 Unsigned32 | M | P | | V |
Interim-Interval | | | | | | Interim-Interval | | | | |
Accounting- 483 9.8.7 Enumerated | M | P | | V | Y | Accounting- 483 9.8.7 Enumerated | M | P | | V |
Realtime-Required | | | | | | Realtime-Required | | | | |
Acct- 50 9.8.5 UTF8String | M | P | | V | Y | Acct- 50 9.8.5 UTF8String | M | P | | V |
Multi-Session-Id | | | | | | Multi-Session-Id | | | | |
Accounting- 485 9.8.3 Unsigned32 | M | P | | V | Y | Accounting- 485 9.8.3 Unsigned32 | M | P | | V |
Record-Number | | | | | | Record-Number | | | | |
Accounting- 480 9.8.1 Enumerated | M | P | | V | Y | Accounting- 480 9.8.1 Enumerated | M | P | | V |
Record-Type | | | | | | Record-Type | | | | |
Accounting- 44 9.8.4 OctetString| M | P | | V | Y | Accounting- 44 9.8.4 OctetString| M | P | | V |
Session-Id | | | | | | Session-Id | | | | |
Accounting- 287 9.8.6 Unsigned64 | M | P | | V | Y | Accounting- 287 9.8.6 Unsigned64 | M | P | | V |
Sub-Session-Id | | | | | | Sub-Session-Id | | | | |
Acct- 259 6.9 Unsigned32 | M | P | | V | N | Acct- 259 6.9 Unsigned32 | M | P | | V |
Application-Id | | | | | | Application-Id | | | | |
Auth- 258 6.8 Unsigned32 | M | P | | V | N | Auth- 258 6.8 Unsigned32 | M | P | | V |
Application-Id | | | | | | Application-Id | | | | |
Auth-Request- 274 8.7 Enumerated | M | P | | V | N | Auth-Request- 274 8.7 Enumerated | M | P | | V |
Type | | | | | | Type | | | | |
Authorization- 291 8.9 Unsigned32 | M | P | | V | N | Authorization- 291 8.9 Unsigned32 | M | P | | V |
Lifetime | | | | | | Lifetime | | | | |
Auth-Grace- 276 8.10 Unsigned32 | M | P | | V | N | Auth-Grace- 276 8.10 Unsigned32 | M | P | | V |
Period | | | | | | Period | | | | |
Auth-Session- 277 8.11 Enumerated | M | P | | V | N | Auth-Session- 277 8.11 Enumerated | M | P | | V |
State | | | | | | State | | | | |
Re-Auth-Request- 285 8.12 Enumerated | M | P | | V | N | Re-Auth-Request- 285 8.12 Enumerated | M | P | | V |
Type | | | | | | Type | | | | |
Class 25 8.20 OctetString| M | P | | V | Y | Class 25 8.20 OctetString| M | P | | V |
Destination-Host 293 6.5 DiamIdent | M | P | | V | N | Destination-Host 293 6.5 DiamIdent | M | P | | V |
Destination- 283 6.6 DiamIdent | M | P | | V | N | Destination- 283 6.6 DiamIdent | M | P | | V |
Realm | | | | | | Realm | | | | |
Disconnect-Cause 273 5.4.3 Enumerated | M | P | | V | N | Disconnect-Cause 273 5.4.3 Enumerated | M | P | | V |
E2E-Sequence AVP 300 6.15 Grouped | M | P | | V | Y | E2E-Sequence AVP 300 6.15 Grouped | M | P | | V |
Error-Message 281 7.3 UTF8String | | P | | V,M | N | Error-Message 281 7.3 UTF8String | | P | | V,M |
Error-Reporting- 294 7.4 DiamIdent | | P | | V,M | N | Error-Reporting- 294 7.4 DiamIdent | | P | | V,M |
Host | | | | | | Host | | | | |
Event-Timestamp 55 8.21 Time | M | P | | V | N | Event-Timestamp 55 8.21 Time | M | P | | V |
Experimental- 297 7.6 Grouped | M | P | | V | N | Experimental- 297 7.6 Grouped | M | P | | V |
Result | | | | | | Result | | | | |
-----------------------------------------|----+-----+----+-----|----| -----------------------------------------|----+-----+----+-----|
+---------------------+ +---------------------+
| AVP Flag rules | | AVP Flag rules |
|----+-----+----+-----|----+ |----+-----+----+-----|
AVP Section | | |SHLD| MUST|MAY | AVP Section | | |SHLD| MUST|
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|
-----------------------------------------|----+-----+----+-----|----| -----------------------------------------|----+-----+----+-----|
Experimental- 298 7.7 Unsigned32 | M | P | | V | N | Experimental- 298 7.7 Unsigned32 | M | P | | V |
Result-Code | | | | | | Result-Code | | | | |
Failed-AVP 279 7.5 Grouped | M | P | | V | N | Failed-AVP 279 7.5 Grouped | M | P | | V |
Firmware- 267 5.3.4 Unsigned32 | | | |P,V,M| N | Firmware- 267 5.3.4 Unsigned32 | | | |P,V,M|
Revision | | | | | | Revision | | | | |
Host-IP-Address 257 5.3.5 Address | M | P | | V | N | Host-IP-Address 257 5.3.5 Address | M | P | | V |
Inband-Security | M | P | | V | N | Inband-Security | M | P | | V |
-Id 299 6.10 Unsigned32 | | | | | | -Id 299 6.10 Unsigned32 | | | | |
Multi-Round- 272 8.19 Unsigned32 | M | P | | V | Y | Multi-Round- 272 8.19 Unsigned32 | M | P | | V |
Time-Out | | | | | | Time-Out | | | | |
Origin-Host 264 6.3 DiamIdent | M | P | | V | N | Origin-Host 264 6.3 DiamIdent | M | P | | V |
Origin-Realm 296 6.4 DiamIdent | M | P | | V | N | Origin-Realm 296 6.4 DiamIdent | M | P | | V |
Origin-State-Id 278 8.16 Unsigned32 | M | P | | V | N | Origin-State-Id 278 8.16 Unsigned32 | M | P | | V |
Product-Name 269 5.3.7 UTF8String | | | |P,V,M| N | Product-Name 269 5.3.7 UTF8String | | | |P,V,M|
Proxy-Host 280 6.7.3 DiamIdent | M | | | P,V | N | Proxy-Host 280 6.7.3 DiamIdent | M | | | P,V |
Proxy-Info 284 6.7.2 Grouped | M | | | P,V | N | Proxy-Info 284 6.7.2 Grouped | M | | | P,V |
Proxy-State 33 6.7.4 OctetString| M | | | P,V | N | Proxy-State 33 6.7.4 OctetString| M | | | P,V |
Redirect-Host 292 6.12 DiamURI | M | P | | V | N | Redirect-Host 292 6.12 DiamURI | M | P | | V |
Redirect-Host- 261 6.13 Enumerated | M | P | | V | N | Redirect-Host- 261 6.13 Enumerated | M | P | | V |
Usage | | | | | | Usage | | | | |
Redirect-Max- 262 6.14 Unsigned32 | M | P | | V | N | Redirect-Max- 262 6.14 Unsigned32 | M | P | | V |
Cache-Time | | | | | | Cache-Time | | | | |
Result-Code 268 7.1 Unsigned32 | M | P | | V | N | Result-Code 268 7.1 Unsigned32 | M | P | | V |
Route-Record 282 6.7.1 DiamIdent | M | | | P,V | N | Route-Record 282 6.7.1 DiamIdent | M | | | P,V |
Session-Id 263 8.8 UTF8String | M | P | | V | Y | Session-Id 263 8.8 UTF8String | M | P | | V |
Session-Timeout 27 8.13 Unsigned32 | M | P | | V | N | Session-Timeout 27 8.13 Unsigned32 | M | P | | V |
Session-Binding 270 8.17 Unsigned32 | M | P | | V | Y | Session-Binding 270 8.17 Unsigned32 | M | P | | V |
Session-Server- 271 8.18 Enumerated | M | P | | V | Y | Session-Server- 271 8.18 Enumerated | M | P | | V |
Failover | | | | | | Failover | | | | |
Supported- 265 5.3.6 Unsigned32 | M | P | | V | N | Supported- 265 5.3.6 Unsigned32 | M | P | | V |
Vendor-Id | | | | | | Vendor-Id | | | | |
Termination- 295 8.15 Enumerated | M | P | | V | N | Termination- 295 8.15 Enumerated | M | P | | V |
Cause | | | | | | Cause | | | | |
User-Name 1 8.14 UTF8String | M | P | | V | Y | User-Name 1 8.14 UTF8String | M | P | | V |
Vendor-Id 266 5.3.3 Unsigned32 | M | P | | V | N | Vendor-Id 266 5.3.3 Unsigned32 | M | P | | V |
Vendor-Specific- 260 6.11 Grouped | M | P | | V | N | Vendor-Specific- 260 6.11 Grouped | M | P | | V |
Application-Id | | | | | | Application-Id | | | | |
-----------------------------------------|----+-----+----+-----|----| -----------------------------------------|----+-----+----+-----|
5. Diameter Peers 5. Diameter Peers
This section describes how Diameter nodes establish connections and This section describes how Diameter nodes establish connections and
communicate with peers. communicate with peers.
5.1. Peer Connections 5.1. Peer Connections
Although a Diameter node may have many possible peers that it is able Although a Diameter node may have many possible peers that it is able
to communicate with, it may not be economical to have an established to communicate with, it may not be economical to have an established
skipping to change at page 64, line 4 skipping to change at page 61, line 4
secondary, an alternate peer SHOULD replace the deleted peer, and secondary, an alternate peer SHOULD replace the deleted peer, and
assume the role of either primary or secondary. assume the role of either primary or secondary.
5.2. Diameter Peer Discovery 5.2. Diameter Peer Discovery
Allowing for dynamic Diameter agent discovery will make it possible Allowing for dynamic Diameter agent discovery will make it possible
for simpler and more robust deployment of Diameter services. In for simpler and more robust deployment of Diameter services. In
order to promote interoperable implementations of Diameter peer order to promote interoperable implementations of Diameter peer
discovery, the following mechanisms are described. These are based discovery, the following mechanisms are described. These are based
on existing IETF standards. The first option (manual configuration) on existing IETF standards. The first option (manual configuration)
MUST be supported by all DIAMETER nodes, while the latter two options MUST be supported by all DIAMETER nodes, while the latter option
(SRVLOC and DNS) MAY be supported. (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 1. The Diameter implementation consults its list of static
(manually) configured Diameter agent locations. These will be (manually) configured Diameter agent locations. These will be
used if they exist and respond. used if they exist and respond.
2. The Diameter implementation uses SLPv2 [RFC2165] to discover 2. The Diameter implementation performs a NAPTR query for a server
Diameter services. The Diameter service template [RFC2609] is
included in Appendix B.
It is recommended that SLPv2 security be deployed (this requires
distributing keys to SLPv2 agents). This is discussed further in
Appendix B. SLPv2 security SHOULD be used (requiring
distribution of keys to SLPv2 agents) in order to ensure that
discovered peers are authorized for their roles. SLPv2 is
discussed further in Appendix B.
3. The Diameter implementation performs a NAPTR query for a server
in a particular realm. The Diameter implementation has to know in a particular realm. The Diameter implementation has to know
in advance which realm to look for a Diameter agent in. This in advance which realm to look for a Diameter agent in. This
could be deduced, for example, from the 'realm' in a NAI that a could be deduced, for example, from the 'realm' in a NAI that a
Diameter implementation needed to perform a Diameter operation Diameter implementation needed to perform a Diameter operation
on. on.
* 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
skipping to change at page 65, line 22 skipping to change at page 62, line 11
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 3. 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, records include A RR's, AAAA RR's or other similar records,
chosen according to the requestor's network protocol chosen according to the requestor's network protocol
capabilities. If the DNS server returns no address records, the capabilities. If the DNS server returns no address records, the
requestor gives up. 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
skipping to change at page 79, line 18 skipping to change at page 76, line 18
the Origin-Host received in the CER with its own Origin-Host as two the Origin-Host received in the CER with its own Origin-Host as two
streams of octets. If the local Origin-Host lexicographically streams of octets. If the local Origin-Host lexicographically
succeeds the received Origin-Host a Win-Election event is issued succeeds the received Origin-Host a Win-Election event is issued
locally. locally.
To be consistent with DNS case insensitivity, octets that fall in the To be consistent with DNS case insensitivity, octets that fall in the
ASCII range 'a' through 'z' MUST compare equally to their upper-case ASCII range 'a' through 'z' MUST compare equally to their upper-case
counterparts between 'A' and 'Z', i.e. value 0x41 compares equal to counterparts between 'A' and 'Z', i.e. value 0x41 compares equal to
0x61, 0x42 to 0x62 and so forth up to and including 0x5a and 0x7a. 0x61, 0x42 to 0x62 and so forth up to and including 0x5a and 0x7a.
The winner of the election MUST close the connection it initiated.
Historically, maintaining the responder side of a connection was more
efficient than maintaining the initiator side. However, current
practices makes this distinction irrelevant.
5.6.5. Capabilities Update 5.6.5. Capabilities Update
A Diameter node MUST initiate peer capabilities update by sending a A Diameter node MUST initiate peer capabilities update by sending a
Capabilities-Exchange-Req (CER) to all its peers which supports peer Capabilities-Exchange-Req (CER) to all its peers which supports peer
capabilities update and is in OPEN state. The receiver of CER in 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 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 Section 5.3. The CEA which the receiver sends MUST contain its
latest capabilities. Note that peers which successfully process the latest capabilities. Note that peers which successfully process the
peer capabilities update SHOULD also update their routing tables to peer capabilities update SHOULD also update their routing tables to
reflect the change. The receiver of the CEA, with a Result-Code AVP reflect the change. The receiver of the CEA, with a Result-Code AVP
skipping to change at page 85, line 24 skipping to change at page 82, line 24
| | (Request) | | (Request) | | | | (Request) | | (Request) | |
| NAS +-------------------+ DRL +-------------------+ HMS | | NAS +-------------------+ DRL +-------------------+ HMS |
| | | | | | | | | | | |
+------+ <------ +------+ <------ +------+ +------+ <------ +------+ <------ +------+
example.net (Answer) example.net (Answer) example.com example.net (Answer) example.net (Answer) example.com
(Origin-Host=hms.example.com) (Origin-Host=hms.example.com) (Origin-Host=hms.example.com) (Origin-Host=hms.example.com)
(Origin-Realm=example.com) (Origin-Realm=example.com) (Origin-Realm=example.com) (Origin-Realm=example.com)
Figure 6: Routing of Diameter messages Figure 6: Routing of Diameter messages
Relay agents does not require full validation of incoming messages. Relay agents do not require full validation of incoming messages. At
At the minimum, validation of the message header and relevant routing a minimum, validation of the message header and relevant routing AVPs
AVPs has to be done when relaying messages. has to be done when relaying messages.
6.2. Diameter Answer Processing 6.2. Diameter Answer Processing
When a request is locally processed, the following procedures MUST be When a request is locally processed, the following procedures MUST be
applied to create the associated answer, in addition to any applied to create the associated answer, in addition to any
additional procedures that MAY be discussed in the Diameter additional procedures that MAY be discussed in the Diameter
application defining the command: application defining the command:
o The same Hop-by-Hop identifier in the request is used in the o The same Hop-by-Hop identifier in the request is used in the
answer. answer.
skipping to change at page 88, line 9 skipping to change at page 85, line 9
Request messages whose ABNF does not list the Destination-Realm AVP Request messages whose ABNF does not list the Destination-Realm AVP
as a mandatory AVP are inherently non-routable messages. as a mandatory AVP are inherently non-routable messages.
This AVP SHOULD be placed as close to the Diameter header as This AVP SHOULD be placed as close to the Diameter header as
possible. possible.
6.7. Routing AVPs 6.7. Routing AVPs
The AVPs defined in this section are Diameter AVPs used for routing The AVPs defined in this section are Diameter AVPs used for routing
purposes. These AVPs change as Diameter messages are processed by purposes. These AVPs change as Diameter messages are processed by
agents, and therefore MUST NOT be protected by end-to-end security. agents.
6.7.1. Route-Record AVP 6.7.1. Route-Record AVP
The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The
identity added in this AVP MUST be the same as the one received in identity added in this AVP MUST be the same as the one received in
the Origin-Host of the Capabilities Exchange message. the Origin-Host of the Capabilities Exchange message.
6.7.2. Proxy-Info AVP 6.7.2. Proxy-Info AVP
The Proxy-Info AVP (AVP Code 284) is of type Grouped. The Grouped The Proxy-Info AVP (AVP Code 284) is of type Grouped. The Grouped
skipping to change at page 89, line 47 skipping to change at page 86, line 42
Grouped and is used to advertise support of a vendor-specific Grouped and is used to advertise support of a vendor-specific
Diameter Application. Exactly one instance of Auth-Application-Id or Diameter Application. Exactly one instance of Auth-Application-Id or
Acct-Application-Id AVP MAY be present. The application identifier Acct-Application-Id AVP MAY be present. The application identifier
carried by either Auth-Application-Id or Acct-Application-Id AVP MUST carried by either Auth-Application-Id or Acct-Application-Id AVP MUST
comply with vendor specific application identifier assignment comply with vendor specific application identifier assignment
described in Sec 11.3. It MUST also match the application id present described in Sec 11.3. It MUST also match the application id present
in the diameter header except when used in a CER or CEA messages. in the diameter header except when used in a CER or CEA messages.
The Vendor-Id AVP is an informational AVP pertaining to the vendor The Vendor-Id AVP is an informational AVP pertaining to the vendor
who may have authorship of the vendor-specific diameter application. who may have authorship of the vendor-specific diameter application.
It should not be used as a means of defining a vendor-specific It should not be used as a means of defining a completely separate
application identifiers space. vendor-specific application identifier space.
This AVP MUST also be present as the first AVP in all experimental This AVP MUST also be present as the first AVP in all experimental
commands defined in the vendor-specific application. commands defined in the vendor-specific application.
This AVP SHOULD be placed as close to the Diameter header as This AVP SHOULD be placed as close to the Diameter header as
possible. possible.
AVP Format AVP Format
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 > <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
skipping to change at page 92, line 7 skipping to change at page 88, line 47
MUST be deleted. MUST be deleted.
6.15. E2E-Sequence AVP 6.15. E2E-Sequence AVP
The E2E-Sequence AVP (AVP Code 300) provides anti-replay protection The E2E-Sequence AVP (AVP Code 300) provides anti-replay protection
for end to end messages and is of type grouped. It contains a random for end to end messages and is of type grouped. It contains a random
value (an OctetString with a nonce) and counter (an Integer). For value (an OctetString with a nonce) and counter (an Integer). For
each end-to-end peer with which a node communicates (or remembers each end-to-end peer with which a node communicates (or remembers
communicating) a different nonce value MUST be used and the counter communicating) a different nonce value MUST be used and the counter
is initiated at zero and increases by one each time this AVP is is initiated at zero and increases by one each time this AVP is
emitted to that peer. This AVP MUST be included in all messages emitted to that peer.
which use end-to-end protection (e.g., CMS signing or encryption).
7. Error Handling 7. Error Handling
There are two different types of errors in Diameter; protocol and There are two different types of errors in Diameter; protocol and
application errors. A protocol error is one that occurs at the base application errors. A protocol error is one that occurs at the base
protocol level, and MAY require per hop attention (e.g., message protocol level, and MAY require per hop attention (e.g., message
routing error). Application errors, on the other hand, generally routing error). Application errors, on the other hand, generally
occur due to a problem with a function specified in a Diameter occur due to a problem with a function specified in a Diameter
application (e.g., user authentication, Missing AVP). application (e.g., user authentication, Missing AVP).
skipping to change at page 96, line 26 skipping to change at page 92, line 11
When returned, the request was successfully completed, but When returned, the request was successfully completed, but
additional processing is required by the application in order to additional processing is required by the application in order to
provide service to the user. provide service to the user.
7.1.3. Protocol Errors 7.1.3. Protocol Errors
Errors that fall within the Protocol Error category SHOULD be treated Errors that fall within the Protocol Error category SHOULD be treated
on a per-hop basis, and Diameter proxies MAY attempt to correct the on a per-hop basis, and Diameter proxies MAY attempt to correct the
error, if it is possible. Note that these and only these errors MUST error, if it is possible. Note that these and only these errors MUST
only be used in answer messages whose 'E' bit is set. To provide only be used in answer messages whose 'E' bit is set. To provide
backward compatibility with existing implementations that follows backward compatibility with existing implementations that follow
[RFC3588], some of the error values that have previously been used in [RFC3588], some of the error values that have previously been used in
this category by [RFC3588] will not be re-used. Therefore the error this category by [RFC3588] will not be re-used. Therefore the error
values enumerated here maybe non-sequential. values enumerated here maybe non-sequential.
DIAMETER_UNABLE_TO_DELIVER 3002 DIAMETER_UNABLE_TO_DELIVER 3002
This error is given when Diameter can not deliver the message to This error is given when Diameter can not deliver the message to
the destination, either because no host within the realm the destination, either because no host within the realm
supporting the required application was available to process the supporting the required application was available to process the
request, or because Destination-Host AVP was given without the request, or because Destination-Host AVP was given without the
skipping to change at page 97, line 40 skipping to change at page 93, line 26
This error is returned when a request is received with an invalid This error is returned when a request is received with an invalid
message length. message length.
7.1.4. Transient Failures 7.1.4. Transient Failures
Errors that fall within the transient failures category are used to Errors that fall within the transient failures category are used to
inform a peer that the request could not be satisfied at the time it inform a peer that the request could not be satisfied at the time it
was received, but MAY be able to satisfy the request in the future. was received, but MAY be able to satisfy the request in the future.
Note that these errors MUST be used in answer messages whose 'E' bit Note that these errors MUST be used in answer messages whose 'E' bit
not is set. is not set.
DIAMETER_AUTHENTICATION_REJECTED 4001 DIAMETER_AUTHENTICATION_REJECTED 4001
The authentication process for the user failed, most likely due to The authentication process for the user failed, most likely due to
an invalid password used by the user. Further attempts MUST only an invalid password used by the user. Further attempts MUST only
be tried after prompting the user for a new password. be tried after prompting the user for a new password.
DIAMETER_OUT_OF_SPACE 4002 DIAMETER_OUT_OF_SPACE 4002
A Diameter node received the accounting request but was unable to A Diameter node received the accounting request but was unable to
skipping to change at page 98, line 26 skipping to change at page 94, line 16
Errors that fall within the permanent failures category are used to Errors that fall within the permanent failures category are used to
inform the peer that the request failed, and should not be attempted inform the peer that the request failed, and should not be attempted
again. Note that these errors SHOULD be used in answer messages again. Note that these errors SHOULD be used in answer messages
whose 'E' bit is not set. In error conditions where it is not whose 'E' bit is not set. In error conditions where it is not
possible or efficient to compose application specific answer grammar possible or efficient to compose application specific answer grammar
then answer messages with E-bit set and complying to the grammar then answer messages with E-bit set and complying to the grammar
described in 7.2 MAY also be used for permanent errors. described in 7.2 MAY also be used for permanent errors.
To provide backward compatibility with existing implementations that To provide backward compatibility with existing implementations that
follows [RFC3588], some of the error values that have previously been follow [RFC3588], some of the error values that have previously been
used in this category by [RFC3588] will not be re-used. Therefore used in this category by [RFC3588] will not be re-used. Therefore
the error values enumerated here maybe non-sequential. the error values enumerated here maybe non-sequential.
DIAMETER_AVP_UNSUPPORTED 5001 DIAMETER_AVP_UNSUPPORTED 5001
The peer received a message that contained an AVP that is not The peer received a message that contained an AVP that is not
recognized or supported and was marked with the Mandatory bit. A recognized or supported and was marked with the Mandatory bit. A
Diameter message with this error MUST contain one or more Failed- Diameter message with this error MUST contain one or more Failed-
AVP AVP containing the AVPs that caused the failure. AVP AVP containing the AVPs that caused the failure.
skipping to change at page 100, line 4 skipping to change at page 95, line 34
A message was received with an AVP that MUST NOT be present. The A message was received with an AVP that MUST NOT be present. The
Failed-AVP AVP MUST be included and contain a copy of the Failed-AVP AVP MUST be included and contain a copy of the
offending AVP. offending AVP.
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009
A message was received that included an AVP that appeared more A message was received that included an AVP that appeared more
often than permitted in the message definition. The Failed-AVP often than permitted in the message definition. The Failed-AVP
AVP MUST be included and contain a copy of the first instance of AVP MUST be included and contain a copy of the first instance of
the offending AVP that exceeded the maximum number of occurrences the offending AVP that exceeded the maximum number of occurrences
DIAMETER_NO_COMMON_APPLICATION 5010 DIAMETER_NO_COMMON_APPLICATION 5010
This error is returned when a node that is not acting as a relay This error is returned by a Diameter node that is not acting as a
and supporting a specific set of application has an empty relay when it receives a CER which advertises a set of
intersection with the set of application advertised by its peer. applications that it does not support.
DIAMETER_UNSUPPORTED_VERSION 5011 DIAMETER_UNSUPPORTED_VERSION 5011
This error is returned when a request was received, whose version This error is returned when a request was received, whose version
number is unsupported. number is unsupported.
DIAMETER_UNABLE_TO_COMPLY 5012 DIAMETER_UNABLE_TO_COMPLY 5012
This error is returned when a request is rejected for unspecified This error is returned when a request is rejected for unspecified
reasons. reasons.
skipping to change at page 102, line 23 skipping to change at page 98, line 6
the one encoded in the Origin-Host AVP. This AVP is intended to be the one encoded in the Origin-Host AVP. This AVP is intended to be
used for troubleshooting purposes, and MUST be set when the Result- used for troubleshooting purposes, and MUST be set when the Result-
Code AVP indicates a failure. Code AVP indicates a failure.
7.5. Failed-AVP AVP 7.5. Failed-AVP AVP
The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
debugging information in cases where a request is rejected or not debugging information in cases where a request is rejected or not
fully processed due to erroneous information in a specific AVP. The fully processed due to erroneous information in a specific AVP. The
value of the Result-Code AVP will provide information on the reason value of the Result-Code AVP will provide information on the reason
for the Failed-AVP AVP. for the Failed-AVP AVP. A Diameter message SHOULD contain only one
Failed-AVP that corresponds to the error indicated by the Result-Code
AVP. For practical purposes, this Failed-AVP would typically refer
to the first AVP processing error that a Diameter node encounters.
The possible reasons for this AVP are the presence of an improperly The possible reasons for this AVP are the presence of an improperly
constructed AVP, an unsupported or unrecognized AVP, an invalid AVP constructed AVP, an unsupported or unrecognized AVP, an invalid AVP
value, the omission of a required AVP, the presence of an explicitly value, the omission of a required AVP, the presence of an explicitly
excluded AVP (see tables in Section 10), or the presence of two or excluded AVP (see tables in Section 10), or the presence of two or
more occurrences of an AVP which is restricted to 0, 1, or 0-1 more occurrences of an AVP which is restricted to 0, 1, or 0-1
occurrences. occurrences.
A Diameter message MAY contain one Failed-AVP AVP, containing the A Diameter message SHOULD contain one Failed-AVP AVP, containing the
entire AVP that could not be processed successfully. If the failure entire AVP that could not be processed successfully. If the failure
reason is omission of a required AVP, an AVP with the missing AVP reason is omission of a required AVP, an AVP with the missing AVP
code, the missing vendor id, and a zero filled payload of the minimum code, the missing vendor id, and a zero filled payload of the minimum
required length for the omitted AVP will be added. If the failure required length for the omitted AVP will be added. If the failure
reason is an invalid AVP length where the reported length is less reason is an invalid AVP length where the reported length is less
than the minimum AVP header length or greater than the reported than the minimum AVP header length or greater than the reported
message length, a copy of the offending AVP header and a zero filled message length, a copy of the offending AVP header and a zero filled
payload of the minimum required length SHOULD be added. payload of the minimum required length SHOULD be added.
AVP Format AVP Format
skipping to change at page 132, line 20 skipping to change at page 128, line 20
message is used to transmit the accounting information to the Home message is used to transmit the accounting information to the Home
AAA server, which MUST reply with the Accounting-Answer message to AAA server, which MUST reply with the Accounting-Answer message to
confirm reception. The Accounting-Answer message includes the confirm reception. The Accounting-Answer message includes the
Result-Code AVP, which MAY indicate that an error was present in the Result-Code AVP, which MAY indicate that an error was present in the
accounting message. A rejected Accounting-Request message MAY cause accounting message. A rejected Accounting-Request message MAY cause
the user's session to be terminated, depending on the value of the the user's session to be terminated, depending on the value of the
Accounting-Realtime-Required AVP received earlier for the session in Accounting-Realtime-Required AVP received earlier for the session in
question. question.
Each Diameter Accounting protocol message MAY be compressed, in order Each Diameter Accounting protocol message MAY be compressed, in order
to reduce network bandwidth usage. If IPsec and IKE are used to to reduce network bandwidth usage. If TLS is used to secure the
secure the Diameter session, then IP compression [RFC3173] MAY be Diameter session, then TLS compression [RFC2246] MAY be used.
used and IKE [RFC2409] MAY be used to negotiate the compression
parameters. If TLS is used to secure the Diameter session, then TLS
compression [RFC2246] MAY be used.
9.3. Accounting Application Extension and Requirements 9.3. Accounting Application Extension and Requirements
Each Diameter application (e.g., NASREQ, MobileIP), MUST define their Each Diameter application (e.g., NASREQ, MobileIP), MUST define their
Service-Specific AVPs that MUST be present in the Accounting-Request Service-Specific AVPs that MUST be present in the Accounting-Request
message in a section entitled "Accounting AVPs". The application message in a section entitled "Accounting AVPs". The application
MUST assume that the AVPs described in this document will be present MUST assume that the AVPs described in this document will be present
in all Accounting messages, so only their respective service-specific in all Accounting messages, so only their respective service-specific
AVPs need to be defined in this section. AVPs need to be defined in this section.
Applications have the option of using one or both of the following Applications have the option of using one or both of the following
accounting application extension models: accounting application extension models:
Coupled Accounting Service
The accounting messages will carry the application identifier of
the application that is using it. The application itself will
process the received accounting records or forward them to an
accounting server. There is no accounting application
advertisement required during capabilities exchange and the
accounting messages will be routed the same as any of the other
application messages.
Split Accounting Service Split Accounting Service
The accounting message will carry the application identifier of The accounting message will carry the application identifier of
the Diameter base accounting application (see Section 2.4). the Diameter base accounting application (see Section 2.4).
Accounting messages maybe routed to Diameter nodes other than the Accounting messages maybe routed to Diameter nodes other than the
corresponding Diameter application. These nodes might be corresponding Diameter application. These nodes might be
centralized accounting servers that provide accounting service for centralized accounting servers that provide accounting service for
multiple different Diameter applications. These nodes MUST multiple different Diameter applications. These nodes MUST
advertise the Diameter base accounting application identifier advertise the Diameter base accounting application identifier
during capabilities exchange. during capabilities exchange.
Accounting messages which uses the Diameter base accounting Accounting messages which uses the Diameter base accounting
application identifier in its header MUST include the application application identifier in its header MUST include the application
identifier of the Diameter application it is providing service for identifier of the Diameter application it is providing service for
in the Acct-Application-Id AVP. This allows the accounting server in the Acct-Application-Id AVP. This allows the accounting server
to determine which Diameter application the accounting records are to determine which Diameter application the accounting records are
for. for.
Coupled Accounting Service
The accounting messages will carry the application identifier of
the application that is using it. The application itself will
process the received accounting records or forward them to an
accounting server. There is no accounting application
advertisement required during capabilities exchange and the
accounting messages will be routed the same as any of the other
application messages.
In cases where an application does not define its own accounting
service, it is preferred that the split accounting model be used.
9.4. Fault Resilience 9.4. Fault Resilience
Diameter Base protocol mechanisms are used to overcome small message Diameter Base protocol mechanisms are used to overcome small message
loss and network faults of temporary nature. loss and network faults of temporary nature.
Diameter peers acting as clients MUST implement the use of failover Diameter peers acting as clients MUST implement the use of failover
to guard against server failures and certain network failures. to guard against server failures and certain network failures.
Diameter peers acting as agents or related off-line processing Diameter peers acting as agents or related off-line processing
systems MUST detect duplicate accounting records caused by the systems MUST detect duplicate accounting records caused by the
sending of same record to several servers and duplication of messages sending of same record to several servers and duplication of messages
in transit. This detection MUST be based on the inspection of the in transit. This detection MUST be based on the inspection of the
Session-Id and Accounting-Record-Number AVP pairs. Appendix D Session-Id and Accounting-Record-Number AVP pairs. Appendix C
discusses duplicate detection needs and implementation issues. discusses duplicate detection needs and implementation issues.
Diameter clients MAY have non-volatile memory for the safe storage of Diameter clients MAY have non-volatile memory for the safe storage of
accounting records over reboots or extended network failures, network accounting records over reboots or extended network failures, network
partitions, and server failures. If such memory is available, the partitions, and server failures. If such memory is available, the
client SHOULD store new accounting records there as soon as the client SHOULD store new accounting records there as soon as the
records are created and until a positive acknowledgement of their records are created and until a positive acknowledgement of their
reception from the Diameter Server has been received. Upon a reboot, reception from the Diameter Server has been received. Upon a reboot,
the client MUST starting sending the records in the non-volatile the client MUST starting sending the records in the non-volatile
memory to the accounting server with appropriate modifications in memory to the accounting server with appropriate modifications in
skipping to change at page 134, line 10 skipping to change at page 130, line 10
memory areas before the correct Accounting-Answer has been received. memory areas before the correct Accounting-Answer has been received.
The client MAY remove oldest, undelivered or yet unacknowledged The client MAY remove oldest, undelivered or yet unacknowledged
accounting data if it runs out of resources such as memory. It is an accounting data if it runs out of resources such as memory. It is an
implementation dependent matter for the client to accept new sessions implementation dependent matter for the client to accept new sessions
under this condition. under this condition.
9.5. Accounting Records 9.5. Accounting Records
In all accounting records, the Session-Id AVP MUST be present; the In all accounting records, the Session-Id AVP MUST be present; the
User-Name AVP MUST be present if it is available to the Diameter User-Name AVP MUST be present if it is available to the Diameter
client. If strong authentication across agents is required, end-to- client.
end security may be used for authentication purposes.
Different types of accounting records are sent depending on the Different types of accounting records are sent depending on the
actual type of accounted service and the authorization server's actual type of accounted service and the authorization server's
directions for interim accounting. If the accounted service is a directions for interim accounting. If the accounted service is a
one-time event, meaning that the start and stop of the event are one-time event, meaning that the start and stop of the event are
simultaneous, then the Accounting-Record-Type AVP MUST be present and simultaneous, then the Accounting-Record-Type AVP MUST be present and
set to the value EVENT_RECORD. set to the value EVENT_RECORD.
If the accounted service is of a measurable length, then the AVP MUST If the accounted service is of a measurable length, then the AVP MUST
use the values START_RECORD, STOP_RECORD, and possibly, use the values START_RECORD, STOP_RECORD, and possibly,
skipping to change at page 136, line 41 skipping to change at page 132, line 37
[ Event-Timestamp ] [ Event-Timestamp ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
* [ AVP ] * [ AVP ]
9.7.2. Accounting-Answer 9.7.2. Accounting-Answer
The Accounting-Answer (ACA) command, indicated by the Command-Code The Accounting-Answer (ACA) command, indicated by the Command-Code
field set to 271 and the Command Flags' 'R' bit cleared, is used to field set to 271 and the Command Flags' 'R' bit cleared, is used to
acknowledge an Accounting-Request command. The Accounting-Answer acknowledge an Accounting-Request command. The Accounting-Answer
command contains the same Session-Id and includes the usage AVPs only command contains the same Session-Id as the corresponding request.
if CMS is in use when sending this command. Note that the inclusion
of the usage AVPs when CMS is not being used leads to unnecessarily
large answer messages, and can not be used as a server's proof of the
receipt of these AVPs in an end-to-end fashion. If the Accounting-
Request was protected by end-to-end security, then the corresponding
ACA message MUST be protected by end-to-end security.
Only the target Diameter Server, known as the home Diameter Server, Only the target Diameter Server, known as the home Diameter Server,
SHOULD respond with the Accounting-Answer command. SHOULD respond with the Accounting-Answer command.
One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
MUST be present. If the Vendor-Specific-Application-Id grouped AVP MUST be present. If the Vendor-Specific-Application-Id grouped AVP
is present, it must have an Acct-Application-Id inside. is present, it must have an Acct-Application-Id inside.
The AVP listed below SHOULD include service specific accounting AVPs, The AVP listed below SHOULD include service specific accounting AVPs,
as described in Section 9.3. as described in Section 9.3.
skipping to change at page 151, line 7 skipping to change at page 147, line 7
cannot be locally processed. cannot be locally processed.
Tc timer Tc timer
The Tc timer controls the frequency that transport connection The Tc timer controls the frequency that transport connection
attempts are done to a peer with whom no active transport attempts are done to a peer with whom no active transport
connection exists. The recommended value is 30 seconds. connection exists. The recommended value is 30 seconds.
13. Security Considerations 13. Security Considerations
The Diameter base protocol assumes that messages are secured by using The Diameter base protocol assumes that messages maybe secured by
either IPSec or TLS. This security mechanism is acceptable in using TLS. As an alternative, IPSec can be also be used to secure
environments where there is no untrusted third party agent. In other Diameter peer connections but its usage is transparent from the
situations, end-to-end security is needed. Diameter node and Diameter protocol perspective. These security
mechanism is acceptable in environments where there is no untrusted
third party agent.
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 [RFC2401] and MAY support TLS Agents MAY support TLS [RFC2246]. Diameter servers MUST support TLS.
[RFC2246]. Diameter servers MUST support TLS and IPsec. Diameter Diameter implementations SHOULD use transmission-level security of
implementations MUST use transmission-level security of some kind some kind (IPsec or TLS) on each connection.
(IPsec or TLS) on each connection.
If a Diameter connection is not protected by IPsec, then the CER/CEA If a Diameter connection is to be protected via TLS, then the CER/CEA
exchange MUST include an Inband-Security-ID AVP with a value of TLS. exchange MUST include an Inband-Security-ID AVP with a value of TLS.
For TLS usage, a TLS handshake will begin when both ends are in the For TLS usage, a TLS handshake will begin when both ends are in the
open state, after completion of the CER/CEA exchange. If the TLS open state, after completion of the CER/CEA exchange. If the TLS
handshake is successful, all further messages will be sent via TLS. handshake is successful, all further messages will be sent via TLS.
If the handshake fails, both ends move to the closed state. If the handshake fails, both ends move to the closed state. See
Sections 13.1 for more details.
It is suggested that IPsec be used primarily at the edges for intra-
domain exchanges. For NAS devices without certificate support, pre-
shared keys can be used between the NAS and a local AAA proxy.
For protection of inter-domain exchanges, TLS is recommended. See
Sections 13.1 and 13.2 for more details on IPsec and TLS usage.
13.1. IPsec Usage
All Diameter implementations MUST support IPsec ESP [RFC2401] in
transport mode with non-null encryption and authentication algorithms
to provide per-packet authentication, integrity protection and
confidentiality, and MUST support the replay protection mechanisms of
IPsec.
Diameter implementations MUST support IKE for peer authentication,
negotiation of security associations, and key management, using the
IPsec DOI [RFC2407]. Diameter implementations MUST support peer
authentication using a pre-shared key, and MAY support certificate-
based peer authentication using digital signatures. Peer
authentication using the public key encryption methods outlined in
IKE's Sections 5.2 and 5.3 [RFC2409] SHOULD NOT be used.
Conformant implementations MUST support both IKE Main Mode and
Aggressive Mode. When pre-shared keys are used for authentication,
IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be
used. When digital signatures are used for authentication, either
IKE Main Mode or IKE Aggressive Mode MAY be used.
When digital signatures are used to achieve authentication, an IKE
negotiator SHOULD use IKE Certificate Request Payload(s) to specify
the certificate authority (or authorities) that are trusted in
accordance with its local policy. IKE negotiators SHOULD use
pertinent certificate revocation checks before accepting a PKI
certificate for use in IKE's authentication procedures.
The Phase 2 Quick Mode exchanges used to negotiate protection for
Diameter connections MUST explicitly carry the Identity Payload
fields (IDci and IDcr). The DOI provides for several types of
identification data. However, when used in conformant
implementations, each ID Payload MUST carry a single IP address and a
single non-zero port number, and MUST NOT use the IP Subnet or IP
Address Range formats. This allows the Phase 2 security association
to correspond to specific TCP and SCTP connections.
Since IPsec acceleration hardware may only be able to handle a
limited number of active IKE Phase 2 SAs, Phase 2 delete messages may
be sent for idle SAs, as a means of keeping the number of active
Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete
message SHOULD NOT be interpreted as a reason for tearing down a
Diameter connection. Rather, it is preferable to leave the
connection up, and if additional traffic is sent on it, to bring up
another IKE Phase 2 SA to protect it. This avoids the potential for
continually bringing connections up and down.
13.2. TLS Usage 13.1. TLS Usage
A Diameter node that initiates a connection to another Diameter node A Diameter node that initiates a connection to another Diameter node
acts as a TLS client according to [RFC2246], and a Diameter node that acts as a TLS client according to [RFC2246], and a Diameter node that
accepts a connection acts as a TLS server. Diameter nodes accepts a connection acts as a TLS server. Diameter nodes
implementing TLS for security MUST mutually authenticate as part of implementing TLS for security MUST mutually authenticate as part of
TLS session establishment. In order to ensure mutual authentication, TLS session establishment. In order to ensure mutual authentication,
the Diameter node acting as TLS server must request a certificate the Diameter node acting as TLS server must request a certificate
from the Diameter node acting as TLS client, and the Diameter node from the Diameter node acting as TLS client, and the Diameter node
acting as TLS client MUST be prepared to supply a certificate on acting as TLS client MUST be prepared to supply a certificate on
request. request.
skipping to change at page 153, line 10 skipping to change at page 148, line 5
TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA
Diameter nodes SHOULD be able to negotiate the following TLS cipher Diameter nodes SHOULD be able to negotiate the following TLS cipher
suite: suite:
TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA
Diameter nodes MAY negotiate other TLS cipher suites. Diameter nodes MAY negotiate other TLS cipher suites.
13.3. Peer-to-Peer Considerations 13.2. Peer-to-Peer Considerations
As with any peer-to-peer protocol, proper configuration of the trust As with any peer-to-peer protocol, proper configuration of the trust
model within a Diameter peer is essential to security. When model within a Diameter peer is essential to security. When
certificates are used, it is necessary to configure the root certificates are used, it is necessary to configure the root
certificate authorities trusted by the Diameter peer. These root CAs certificate authorities trusted by the Diameter peer. These root CAs
are likely to be unique to Diameter usage and distinct from the root are likely to be unique to Diameter usage and distinct from the root
CAs that might be trusted for other purposes such as Web browsing. CAs that might be trusted for other purposes such as Web browsing.
In general, it is expected that those root CAs will be configured so In general, it is expected that those root CAs will be configured so
as to reflect the business relationships between the organization as to reflect the business relationships between the organization
hosting the Diameter peer and other organizations. As a result, a hosting the Diameter peer and other organizations. As a result, a
Diameter peer will typically not be configured to allow connectivity Diameter peer will typically not be configured to allow connectivity
with any arbitrary peer. When certificate authentication Diameter with any arbitrary peer. With certificate authentication, Diameter
peers may not be known beforehand, and therefore peer discovery may peers may not be known beforehand and therefore peer discovery may be
be required. required.
Note that IPsec is considerably less flexible than TLS when it comes
to configuring root CAs. Since use of Port identifiers is prohibited
within IKE Phase 1, within IPsec it is not possible to uniquely
configure trusted root CAs for each application individually; the
same policy must be used for all applications. This implies, for
example, that a root CA trusted for use with Diameter must also be
trusted to protect SNMP. These restrictions can be awkward at best.
Since TLS supports application-level granularity in certificate
policy, TLS SHOULD be used to protect Diameter connections between
administrative domains. IPsec is most appropriate for intra-domain
usage when pre-shared keys are used as a security mechanism.
When pre-shared key authentication is used with IPsec to protect
Diameter, unique pre-shared keys are configured with Diameter peers,
who are identified by their IP address (Main Mode), or possibly their
FQDN (Aggressive Mode). As a result, it is necessary for the set of
Diameter peers to be known beforehand. Therefore, peer discovery is
typically not necessary.
The following is intended to provide some guidance on the issue.
It is recommended that a Diameter peer implement the same security
mechanism (IPsec or TLS) across all its peer-to-peer connections.
Inconsistent use of security mechanisms can result in redundant
security mechanisms being used (e.g., TLS over IPsec) or worse,
potential security vulnerabilities. When IPsec is used with
Diameter, a typical security policy for outbound traffic is "Initiate
IPsec, from me to any, destination port Diameter"; for inbound
traffic, the policy would be "Require IPsec, from any to me,
destination port Diameter".
This policy causes IPsec to be used whenever a Diameter peer
initiates a connection to another Diameter peer, and to be required
whenever an inbound Diameter connection occurs. This policy is
attractive, since it does not require policy to be set for each peer
or dynamically modified each time a new Diameter connection is
created; an IPsec SA is automatically created based on a simple
static policy. Since IPsec extensions are typically not available to
the sockets API on most platforms, and IPsec policy functionality is
implementation dependent, use of a simple static policy is the often
the simplest route to IPsec-enabling a Diameter implementation.
One implication of the recommended policy is that if a node is using
both TLS and IPsec, there is not a convenient way in which to use
either TLS or IPsec, but not both, without reserving an additional
port for TLS usage. Since Diameter uses the same port for TLS and
non-TLS usage, where the recommended IPsec policy is put in place, a
TLS-protected connection will match the IPsec policy, and both IPsec
and TLS will be used to protect the Diameter connection. To avoid
this, it would be necessary to plumb peer-specific policies either
statically or dynamically.
If IPsec is used to secure Diameter peer-to-peer connections, IPsec
policy SHOULD be set so as to require IPsec protection for inbound
connections, and to initiate IPsec protection for outbound
connections. This can be accomplished via use of inbound and
outbound filter policy.
14. References 14. References
14.1. Normative References 14.1. Normative References
[FLOATPOINT] [FLOATPOINT]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE
Standard 754-1985", August 1985. Standard 754-1985", August 1985.
[IANAADFAM] [IANAADFAM]
IANA,, "Address Family Numbers", IANA,, "Address Family Numbers",
http://www.iana.org/assignments/address-family-numbers. http://www.iana.org/assignments/address-family-numbers.
[IANAWEB] IANA,, "Number assignment", http://www.iana.org.
[RADTYPE] IANA,, "RADIUS Types", [RADTYPE] IANA,, "RADIUS Types",
http://www.iana.org/assignments/radius-types. http://www.iana.org/assignments/radius-types.
[IPV4] Postel, J., "Internet Protocol", RFC 791, September 1981. [IPV4] Postel, J., "Internet Protocol", RFC 791, September 1981.
[TCP] Postel, J., "Transmission Control Protocol", RFC 793, [TCP] Postel, J., "Transmission Control Protocol", RFC 793,
January 1981. January 1981.
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539, June 2003. Accounting (AAA) Transport Profile", RFC 3539, June 2003.
skipping to change at page 156, line 17 skipping to change at page 150, line 16
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998. Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
skipping to change at page 157, line 21 skipping to change at page 150, line 48
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan,
"Service Location Protocol", RFC 2165, June 1997.
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996. for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates
and Service: Schemes", RFC 2609, June 1999.
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Layer Security over Stream Control Transmission Protocol",
RFC 3436, December 2002.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998. 10646", RFC 2279, January 1998.
14.2. Informational References 14.2. Informational References
[RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., [RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
Shiino, H., Zorn, G., Dommety, G., C.Perkins, B.Patil, Shiino, H., Zorn, G., Dommety, G., C.Perkins, B.Patil,
D.Mitton, S.Manning, M.Beadles, P.Walsh, X.Chen, D.Mitton, S.Manning, M.Beadles, P.Walsh, X.Chen,
S.Sivalingham, A.Hameed, M.Munson, S.Jacobs, B.Lim, S.Sivalingham, A.Hameed, M.Munson, S.Jacobs, B.Lim,
B.Hirschman, R.Hsu, Y.Xu, E.Campell, S.Baba, and E.Jaques, B.Hirschman, R.Hsu, Y.Xu, E.Campell, S.Baba, and E.Jaques,
"Criteria for Evaluating AAA Protocols for Network "Criteria for Evaluating AAA Protocols for Network
Access", RFC 2989, November 2000. Access", RFC 2989, November 2000.
[RFC3141] Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety, G.,
Sivalingham, S., Lim, B., McCann, P., Shiino, H.,
Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford, M.,
Calhoun, P., Lo, C., Jaques, E., Campbell, E., Y.Xu,
S.Baba, T.Ayaki, T.Seki, and A.Hameed, "CDMA2000 Wireless
Data Requirements for AAA", RFC 3141, June 2001.
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000. Accounting Management", RFC 2975, October 2000.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576, Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003. July 2003.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC2977] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile
IP Authentication, Authorization, and Accounting
Requirements", RFC 2977, October 2000.
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server
Requirements Next Generation (NASREQNG) NAS Model",
RFC 2881, July 2000.
[RFC3169] Beadles, M. and D. Mitton, "Criteria for Evaluating
Network Access Server Protocols", RFC 3169,
September 2001.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000. Extensions", RFC 2869, June 2000.
skipping to change at page 159, line 18 skipping to change at page 152, line 12
[RFC2477] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming [RFC2477] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
Protocols", RFC 2477, January 1999. Protocols", RFC 2477, January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called
TACACS", RFC 1492, July 1993. TACACS", RFC 1492, July 1993.
[AAACMS] Calhoun, P., Bulley, W., and S. Farrell, "Diameter CMS
Security Application", Work in Progress.
[IANA-EXP] [IANA-EXP]
Narten, T., "Assigning Experimental and Testing Numbers Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful, Work in Progress.". Considered Useful, Work in Progress.".
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to thank the following people that have The authors would like to thank the following people that have
provided proposals and contributions to this document: provided proposals and contributions to this document:
To Vishnu Ram and Satendra Gera for their contributions on To Vishnu Ram and Satendra Gera for their contributions on
Capabilities Updates, Predictive Loop Avoidance as well as many other Capabilities Updates, Predictive Loop Avoidance as well as many other
technical proposals. To Tolga Asveren for his insights and technical proposals. To Tolga Asveren for his insights and
contributions on almost all of the proposed solutions incorporated contributions on almost all of the proposed solutions incorporated
into this document. To Timothy Smith for helping on the Capabilities into this document. To Timothy Smith for helping on the Capabilities
Updates and other topics. To Tony Zhang for providing fixes to loop Updates and other topics. To Tony Zhang for providing fixes to loop
holes on composing Failed-AVPs as well as many other issues and holes on composing Failed-AVPs as well as many other issues and
topics. To Jan Nordqvist for clearly stating the usage of topics. To Jan Nordqvist for clearly stating the usage of
application ids. To Anders Kristensen for providing needed technical application ids. To Anders Kristensen for providing needed technical
opinions. opinions. To David Frascone for providing invaluable review of the
document.
Special thanks also to people who have provided invaluable comments Special thanks also to people who have provided invaluable comments
and inputs especially in resolving controversial issues: and inputs especially in resolving controversial issues:
Glen Zorn, Yoshihiro Ohba, Marco Stura, and Pasi Eronen. Glen Zorn, Yoshihiro Ohba, Marco Stura, and Pasi Eronen.
Finally, we would like to thank the original authors of this Finally, we would like to thank the original authors of this
document: document:
Pat Calhoun, John Loughney, Jari Arkko, Erik Guttman and Glen Zorn. Pat Calhoun, John Loughney, Jari Arkko, Erik Guttman and Glen Zorn.
Their invaluable knowledge and experience has given us a robust and Their invaluable knowledge and experience has given us a robust and
flexible AAA protocol that many people have seen great value in flexible AAA protocol that many people have seen great value in
adopting. We greatly appreciate their support and stewardship for adopting. We greatly appreciate their support and stewardship for
the continued improvements of Diameter as a protocol. We would also the continued improvements of Diameter as a protocol. We would also
like to extend our gratitude to folks aside from the authors who have like to extend our gratitude to folks aside from the authors who have
assisted and contributed to the original version of this document. assisted and contributed to the original version of this document.
Their efforts significantly contributed to the success of Diameter. Their efforts significantly contributed to the success of Diameter.
Appendix B. Diameter Service Template Appendix B. NAPTR Example
The following service template describes the attributes used by
Diameter servers to advertise themselves. This simplifies the
process of selecting an appropriate server to communicate with. A
Diameter client can request specific Diameter servers based on
characteristics of the Diameter service desired (for example, an AAA
server to use for accounting.)
Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com> Language of
service template: en
Security Considerations:
Diameter clients and servers use various cryptographic mechanisms
to protect communication integrity, confidentiality as well as
perform end-point authentication. It would thus be difficult if
not impossible for an attacker to advertise itself using SLPv2 and
pose as a legitimate Diameter peer without proper preconfigured
secrets or cryptographic keys. Still, as Diameter services are
vital for network operation it is important to use SLPv2
authentication to prevent an attacker from modifying or
eliminating service advertisements for legitimate Diameter
servers.
Template text:
-------------------------template begins here-----------------------
template-type=service:diameter
template-version=0.0
template-description=
The Diameter protocol is defined by RFC 3588.
template-url-syntax=
url-path= ; The Diameter URL format is described in Section 2.9.
; Example: 'aaa://aaa.example.com:1812;transport=tcp
supported-auth-applications= string L M
# This attribute lists the Diameter applications supported by the
# AAA implementation. The applications currently defined are:
#
# Application Name Defined by
# ---------------- -----------------------------------
# NASREQ Diameter Network Access Server Application
# MobileIP Diameter Mobile IP Application
#
# Notes:
# . Diameter implementations support one or more applications.
# . Additional applications may be defined in the future.
# An updated service template will be created at that time.
#
NASREQ,MobileIP
supported-acct-applications= string L M
# This attribute lists the Diameter applications supported by the
# AAA implementation. The applications currently defined are:
# Application Name Defined by
# ---------------- -----------------------------------
# NASREQ Diameter Network Access Server Application
# MobileIP Diameter Mobile IP Application
#
# Notes:
# . Diameter implementations support one or more applications.
# . Additional applications may be defined in the future.
# An updated service template will be created at that time.
#
NASREQ,MobileIP
supported-transports= string L M
SCTP
# This attribute lists the supported transports that the Diameter
# implementation accepts. Note that a compliant Diameter
# implementation MUST support SCTP, though it MAY support other
# transports, too.
SCTP,TCP
-------------------------template ends here-----------------------
Appendix C. NAPTR Example
As an example, consider a client that wishes to resolve aaa:ex.com. As an example, consider a client that wishes to resolve aaa:ex.com.
The client performs a NAPTR query for that domain, and the following The client performs a NAPTR query for that domain, and the following
NAPTR records are returned: NAPTR records are returned:
;; order pref flags service regexp replacement ;; order pref flags service regexp replacement
IN NAPTR 50 50 "s" "AAA+D2S" "" IN NAPTR 50 50 "s" "AAA+D2S" ""
_diameter._sctp.example.com IN NAPTR 100 50 "s" "AAA+D2T" _diameter._sctp.example.com IN NAPTR 100 50 "s" "AAA+D2T"
"" _aaa._tcp.example.com "" _aaa._tcp.example.com
This indicates that the server supports SCTP, and TCP, in that order. This indicates that the server supports SCTP, and TCP, in that order.
If the client supports over SCTP, SCTP will be used, targeted to a If the client supports over SCTP, SCTP will be used, targeted to a
host determined by an SRV lookup of _diameter._sctp.ex.com. That host determined by an SRV lookup of _diameter._sctp.ex.com. That
lookup would return: lookup would return:
;; Priority Weight Port Target ;; Priority Weight Port Target
IN SRV 0 1 5060 server1.example.com IN SRV 0 IN SRV 0 1 5060 server1.example.com IN SRV 0
2 5060 server2.example.com 2 5060 server2.example.com
Appendix D. Duplicate Detection Appendix C. Duplicate Detection
As described in Section 9.4, accounting record duplicate detection is As described in Section 9.4, accounting record duplicate detection is
based on session identifiers. Duplicates can appear for various based on session identifiers. Duplicates can appear for various
reasons: reasons:
o Failover to an alternate server. Where close to real-time o Failover to an alternate server. Where close to real-time
performance is required, failover thresholds need to be kept low performance is required, failover thresholds need to be kept low
and this may lead to an increased likelihood of duplicates. and this may lead to an increased likelihood of duplicates.
Failover can occur at the client or within Diameter agents. Failover can occur at the client or within Diameter agents.
skipping to change at page 166, line 16 skipping to change at page 157, line 16
Victor Fajardo (editor) Victor Fajardo (editor)
Toshiba America Research Toshiba America Research
One Telcordia Drive, 1S-222 One Telcordia Drive, 1S-222
Piscataway, NJ 08854 Piscataway, NJ 08854
USA USA
Phone: 1 908-421-1845 Phone: 1 908-421-1845
Email: vfajardo@tari.toshiba.com Email: vfajardo@tari.toshiba.com
Jari Arkko
Ericsson Research
02420 Jorvas
Finland
Phone: +358 40 5079256
Email: jari.arkko@ericsson.com
John Loughney John Loughney
Nokia Research Center Nokia Research Center
Itamerenkatu 11-13 Itamerenkatu 11-13
Helsinki, 00180 Helsinki, 00180
Finland Finland
Phone: +358 50 483 6242 Phone: +358 50 483 6242
Email: john.loughney@nokia.com Email: john.loughney@nokia.com
Full Copyright Statement Full Copyright Statement
 End of changes. 63 change blocks. 
708 lines changed or deleted 373 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/