draft-ietf-dime-rfc3588bis-04.txt   draft-ietf-dime-rfc3588bis-05.txt 
DIME V. Fajardo, Ed. DIME V. Fajardo, Ed.
Internet-Draft Toshiba America Research Internet-Draft Toshiba America Research
Intended status: Standards Track J. Arkko Intended status: Standards Track J. Arkko
Expires: December 7, 2007 Ericsson Research Expires: January 7, 2008 Ericsson Research
J. Loughney J. Loughney
Nokia Research Center Nokia Research Center
June 5, 2007 July 6, 2007
Diameter Base Protocol Diameter Base Protocol
draft-ietf-dime-rfc3588bis-04.txt draft-ietf-dime-rfc3588bis-05.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 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 7, 2007. This Internet-Draft will expire on January 7, 2008.
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 3, line 5 skipping to change at page 3, line 5
2.9. Diameter Path Authorization . . . . . . . . . . . . . . . 33 2.9. Diameter Path Authorization . . . . . . . . . . . . . . . 33
3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 35 3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 35
3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 38 3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 38
3.2. Command Code ABNF specification . . . . . . . . . . . . . 38 3.2. Command Code ABNF specification . . . . . . . . . . . . . 38
3.3. Diameter Command Naming Conventions . . . . . . . . . . . 40 3.3. Diameter Command Naming Conventions . . . . . . . . . . . 40
4. Diameter AVPs . . . . . . . . . . . . . . . . . . . . . . . . 42 4. Diameter AVPs . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 42 4.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.1. Optional Header Elements . . . . . . . . . . . . . . 44 4.1.1. Optional Header Elements . . . . . . . . . . . . . . 44
4.2. Basic AVP Data Formats . . . . . . . . . . . . . . . . . 44 4.2. Basic AVP Data Formats . . . . . . . . . . . . . . . . . 44
4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 46 4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 46
4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 53 4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 52
4.4.1. Example AVP with a Grouped Data type . . . . . . . . 54 4.4.1. Example AVP with a Grouped Data type . . . . . . . . 53
4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 56 4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 56
5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 60 5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 59
5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 60 5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 59
5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 60 5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 59
5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 63 5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 62
5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 64 5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 63
5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 65 5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 64
5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 65 5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 64
5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 66 5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 65
5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 66 5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 65
5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 66 5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 65
5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 66 5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 65
5.4. Disconnecting Peer connections . . . . . . . . . . . . . 66 5.4. Disconnecting Peer connections . . . . . . . . . . . . . 65
5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 67 5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 66
5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 67 5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 66
5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 68 5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 67
5.5. Transport Failure Detection . . . . . . . . . . . . . . . 68 5.5. Transport Failure Detection . . . . . . . . . . . . . . . 67
5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 68 5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 67
5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 69 5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 68
5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 69 5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 68
5.5.4. Failover and Failback Procedures . . . . . . . . . . 69 5.5.4. Failover and Failback Procedures . . . . . . . . . . 68
5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 70 5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 69
5.6.1. Incoming connections . . . . . . . . . . . . . . . . 72 5.6.1. Incoming connections . . . . . . . . . . . . . . . . 71
5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 73 5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 72
5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 74 5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 73
5.6.4. The Election Process . . . . . . . . . . . . . . . . 76 5.6.4. The Election Process . . . . . . . . . . . . . . . . 75
5.6.5. Capabilities Update . . . . . . . . . . . . . . . . 76 5.6.5. Capabilities Update . . . . . . . . . . . . . . . . 75
6. Diameter message processing . . . . . . . . . . . . . . . . . 77 6. Diameter message processing . . . . . . . . . . . . . . . . . 76
6.1. Diameter Request Routing Overview . . . . . . . . . . . . 77 6.1. Diameter Request Routing Overview . . . . . . . . . . . . 76
6.1.1. Originating a Request . . . . . . . . . . . . . . . 78 6.1.1. Originating a Request . . . . . . . . . . . . . . . 77
6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 79 6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 78
6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 79 6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 78
6.1.4. Processing Local Requests . . . . . . . . . . . . . 79 6.1.4. Processing Local Requests . . . . . . . . . . . . . 78
6.1.5. Request Forwarding . . . . . . . . . . . . . . . . . 79 6.1.5. Request Forwarding . . . . . . . . . . . . . . . . . 78
6.1.6. Request Routing . . . . . . . . . . . . . . . . . . 80 6.1.6. Request Routing . . . . . . . . . . . . . . . . . . 79
6.1.7. Predictive Loop Avoidance . . . . . . . . . . . . . 80 6.1.7. Predictive Loop Avoidance . . . . . . . . . . . . . 79
6.1.8. Redirecting requests . . . . . . . . . . . . . . . . 80 6.1.8. Redirecting requests . . . . . . . . . . . . . . . . 79
6.1.9. Relaying and Proxying Requests . . . . . . . . . . . 82 6.1.9. Relaying and Proxying Requests . . . . . . . . . . . 81
6.2. Diameter Answer Processing . . . . . . . . . . . . . . . 82 6.2. Diameter Answer Processing . . . . . . . . . . . . . . . 81
6.2.1. Processing received Answers . . . . . . . . . . . . 83 6.2.1. Processing received Answers . . . . . . . . . . . . 82
6.2.2. Relaying and Proxying Answers . . . . . . . . . . . 83 6.2.2. Relaying and Proxying Answers . . . . . . . . . . . 82
6.3. Origin-Host AVP . . . . . . . . . . . . . . . . . . . . . 84 6.3. Origin-Host AVP . . . . . . . . . . . . . . . . . . . . . 83
6.4. Origin-Realm AVP . . . . . . . . . . . . . . . . . . . . 84 6.4. Origin-Realm AVP . . . . . . . . . . . . . . . . . . . . 83
6.5. Destination-Host AVP . . . . . . . . . . . . . . . . . . 84 6.5. Destination-Host AVP . . . . . . . . . . . . . . . . . . 83
6.6. Destination-Realm AVP . . . . . . . . . . . . . . . . . . 85 6.6. Destination-Realm AVP . . . . . . . . . . . . . . . . . . 84
6.7. Routing AVPs . . . . . . . . . . . . . . . . . . . . . . 85 6.7. Routing AVPs . . . . . . . . . . . . . . . . . . . . . . 84
6.7.1. Route-Record AVP . . . . . . . . . . . . . . . . . . 85 6.7.1. Route-Record AVP . . . . . . . . . . . . . . . . . . 84
6.7.2. Proxy-Info AVP . . . . . . . . . . . . . . . . . . . 85 6.7.2. Proxy-Info AVP . . . . . . . . . . . . . . . . . . . 84
6.7.3. Proxy-Host AVP . . . . . . . . . . . . . . . . . . . 85 6.7.3. Proxy-Host AVP . . . . . . . . . . . . . . . . . . . 84
6.7.4. Proxy-State AVP . . . . . . . . . . . . . . . . . . 85 6.7.4. Proxy-State AVP . . . . . . . . . . . . . . . . . . 84
6.8. Auth-Application-Id AVP . . . . . . . . . . . . . . . . . 86 6.8. Auth-Application-Id AVP . . . . . . . . . . . . . . . . . 85
6.9. Acct-Application-Id AVP . . . . . . . . . . . . . . . . . 86 6.9. Acct-Application-Id AVP . . . . . . . . . . . . . . . . . 85
6.10. Inband-Security-Id AVP . . . . . . . . . . . . . . . . . 86 6.10. Inband-Security-Id AVP . . . . . . . . . . . . . . . . . 85
6.11. Vendor-Specific-Application-Id AVP . . . . . . . . . . . 86 6.11. Vendor-Specific-Application-Id AVP . . . . . . . . . . . 85
6.12. Redirect-Host AVP . . . . . . . . . . . . . . . . . . . . 87 6.12. Redirect-Host AVP . . . . . . . . . . . . . . . . . . . . 86
6.13. Redirect-Host-Usage AVP . . . . . . . . . . . . . . . . . 87 6.13. Redirect-Host-Usage AVP . . . . . . . . . . . . . . . . . 86
6.14. Redirect-Max-Cache-Time AVP . . . . . . . . . . . . . . . 89 6.14. Redirect-Max-Cache-Time AVP . . . . . . . . . . . . . . . 88
6.15. E2E-Sequence AVP . . . . . . . . . . . . . . . . . . . . 89 6.15. E2E-Sequence AVP . . . . . . . . . . . . . . . . . . . . 88
7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 90 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 89
7.1. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 91 7.1. Result-Code AVP . . . . . . . . . . . . . . . . . . . . . 90
7.1.1. Informational . . . . . . . . . . . . . . . . . . . 92 7.1.1. Informational . . . . . . . . . . . . . . . . . . . 91
7.1.2. Success . . . . . . . . . . . . . . . . . . . . . . 92 7.1.2. Success . . . . . . . . . . . . . . . . . . . . . . 91
7.1.3. Protocol Errors . . . . . . . . . . . . . . . . . . 93 7.1.3. Protocol Errors . . . . . . . . . . . . . . . . . . 92
7.1.4. Transient Failures . . . . . . . . . . . . . . . . . 94 7.1.4. Transient Failures . . . . . . . . . . . . . . . . . 93
7.1.5. Permanent Failures . . . . . . . . . . . . . . . . . 95 7.1.5. Permanent Failures . . . . . . . . . . . . . . . . . 94
7.2. Error Bit . . . . . . . . . . . . . . . . . . . . . . . . 98 7.2. Error Bit . . . . . . . . . . . . . . . . . . . . . . . . 97
7.3. Error-Message AVP . . . . . . . . . . . . . . . . . . . . 98 7.3. Error-Message AVP . . . . . . . . . . . . . . . . . . . . 97
7.4. Error-Reporting-Host AVP . . . . . . . . . . . . . . . . 98 7.4. Error-Reporting-Host AVP . . . . . . . . . . . . . . . . 97
7.5. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . 98 7.5. Failed-AVP AVP . . . . . . . . . . . . . . . . . . . . . 97
7.6. Experimental-Result AVP . . . . . . . . . . . . . . . . . 99 7.6. Experimental-Result AVP . . . . . . . . . . . . . . . . . 98
7.7. Experimental-Result-Code AVP . . . . . . . . . . . . . . 100 7.7. Experimental-Result-Code AVP . . . . . . . . . . . . . . 99
8. Diameter User Sessions . . . . . . . . . . . . . . . . . . . 101 8. Diameter User Sessions . . . . . . . . . . . . . . . . . . . 100
8.1. Authorization Session State Machine . . . . . . . . . . . 102 8.1. Authorization Session State Machine . . . . . . . . . . . 101
8.2. Accounting Session State Machine . . . . . . . . . . . . 107 8.2. Accounting Session State Machine . . . . . . . . . . . . 106
8.3. Server-Initiated Re-Auth . . . . . . . . . . . . . . . . 112 8.3. Server-Initiated Re-Auth . . . . . . . . . . . . . . . . 111
8.3.1. Re-Auth-Request . . . . . . . . . . . . . . . . . . 112 8.3.1. Re-Auth-Request . . . . . . . . . . . . . . . . . . 111
8.3.2. Re-Auth-Answer . . . . . . . . . . . . . . . . . . . 113 8.3.2. Re-Auth-Answer . . . . . . . . . . . . . . . . . . . 112
8.4. Session Termination . . . . . . . . . . . . . . . . . . . 114 8.4. Session Termination . . . . . . . . . . . . . . . . . . . 113
8.4.1. Session-Termination-Request . . . . . . . . . . . . 115 8.4.1. Session-Termination-Request . . . . . . . . . . . . 114
8.4.2. Session-Termination-Answer . . . . . . . . . . . . . 115 8.4.2. Session-Termination-Answer . . . . . . . . . . . . . 114
8.5. Aborting a Session . . . . . . . . . . . . . . . . . . . 116 8.5. Aborting a Session . . . . . . . . . . . . . . . . . . . 115
8.5.1. Abort-Session-Request . . . . . . . . . . . . . . . 117 8.5.1. Abort-Session-Request . . . . . . . . . . . . . . . 116
8.5.2. Abort-Session-Answer . . . . . . . . . . . . . . . . 117 8.5.2. Abort-Session-Answer . . . . . . . . . . . . . . . . 116
8.6. Inferring Session Termination from Origin-State-Id . . . 118 8.6. Inferring Session Termination from Origin-State-Id . . . 117
8.7. Auth-Request-Type AVP . . . . . . . . . . . . . . . . . . 119 8.7. Auth-Request-Type AVP . . . . . . . . . . . . . . . . . . 118
8.8. Session-Id AVP . . . . . . . . . . . . . . . . . . . . . 119 8.8. Session-Id AVP . . . . . . . . . . . . . . . . . . . . . 118
8.9. Authorization-Lifetime AVP . . . . . . . . . . . . . . . 120 8.9. Authorization-Lifetime AVP . . . . . . . . . . . . . . . 119
8.10. Auth-Grace-Period AVP . . . . . . . . . . . . . . . . . . 121 8.10. Auth-Grace-Period AVP . . . . . . . . . . . . . . . . . . 120
8.11. Auth-Session-State AVP . . . . . . . . . . . . . . . . . 121 8.11. Auth-Session-State AVP . . . . . . . . . . . . . . . . . 120
8.12. Re-Auth-Request-Type AVP . . . . . . . . . . . . . . . . 122 8.12. Re-Auth-Request-Type AVP . . . . . . . . . . . . . . . . 121
8.13. Session-Timeout AVP . . . . . . . . . . . . . . . . . . . 122 8.13. Session-Timeout AVP . . . . . . . . . . . . . . . . . . . 121
8.14. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 123 8.14. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 122
8.15. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 123 8.15. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 122
8.16. Origin-State-Id AVP . . . . . . . . . . . . . . . . . . . 124 8.16. Origin-State-Id AVP . . . . . . . . . . . . . . . . . . . 123
8.17. Session-Binding AVP . . . . . . . . . . . . . . . . . . . 124 8.17. Session-Binding AVP . . . . . . . . . . . . . . . . . . . 123
8.18. Session-Server-Failover AVP . . . . . . . . . . . . . . . 125 8.18. Session-Server-Failover AVP . . . . . . . . . . . . . . . 124
8.19. Multi-Round-Time-Out AVP . . . . . . . . . . . . . . . . 126 8.19. Multi-Round-Time-Out AVP . . . . . . . . . . . . . . . . 125
8.20. Class AVP . . . . . . . . . . . . . . . . . . . . . . . . 126 8.20. Class AVP . . . . . . . . . . . . . . . . . . . . . . . . 125
8.21. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . . 126 8.21. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . . 125
9. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 128 9. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 127
9.1. Server Directed Model . . . . . . . . . . . . . . . . . . 128 9.1. Server Directed Model . . . . . . . . . . . . . . . . . . 127
9.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 129 9.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 128
9.3. Accounting Application Extension and Requirements . . . . 129 9.3. Accounting Application Extension and Requirements . . . . 128
9.4. Fault Resilience . . . . . . . . . . . . . . . . . . . . 130 9.4. Fault Resilience . . . . . . . . . . . . . . . . . . . . 129
9.5. Accounting Records . . . . . . . . . . . . . . . . . . . 131 9.5. Accounting Records . . . . . . . . . . . . . . . . . . . 130
9.6. Correlation of Accounting Records . . . . . . . . . . . . 131 9.6. Correlation of Accounting Records . . . . . . . . . . . . 130
9.7. Accounting Command-Codes . . . . . . . . . . . . . . . . 132 9.7. Accounting Command-Codes . . . . . . . . . . . . . . . . 131
9.7.1. Accounting-Request . . . . . . . . . . . . . . . . . 132 9.7.1. Accounting-Request . . . . . . . . . . . . . . . . . 131
9.7.2. Accounting-Answer . . . . . . . . . . . . . . . . . 133 9.7.2. Accounting-Answer . . . . . . . . . . . . . . . . . 132
9.8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 134 9.8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 133
9.8.1. Accounting-Record-Type AVP . . . . . . . . . . . . . 134 9.8.1. Accounting-Record-Type AVP . . . . . . . . . . . . . 133
9.8.2. Acct-Interim-Interval . . . . . . . . . . . . . . . 135 9.8.2. Acct-Interim-Interval . . . . . . . . . . . . . . . 134
9.8.3. Accounting-Record-Number AVP . . . . . . . . . . . . 136 9.8.3. Accounting-Record-Number AVP . . . . . . . . . . . . 135
9.8.4. Acct-Session-Id AVP . . . . . . . . . . . . . . . . 136 9.8.4. Acct-Session-Id AVP . . . . . . . . . . . . . . . . 135
9.8.5. Acct-Multi-Session-Id AVP . . . . . . . . . . . . . 136 9.8.5. Acct-Multi-Session-Id AVP . . . . . . . . . . . . . 135
9.8.6. Accounting-Sub-Session-Id AVP . . . . . . . . . . . 136 9.8.6. Accounting-Sub-Session-Id AVP . . . . . . . . . . . 135
9.8.7. Accounting-Realtime-Required AVP . . . . . . . . . . 137 9.8.7. Accounting-Realtime-Required AVP . . . . . . . . . . 136
10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 138 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 137
10.1. Base Protocol Command AVP Table . . . . . . . . . . . . . 138 10.1. Base Protocol Command AVP Table . . . . . . . . . . . . . 137
10.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . 139 10.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . 138
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 141 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 140
11.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 141 11.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 140
11.1.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . 141 11.1.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . 140
11.1.2. AVP Flags . . . . . . . . . . . . . . . . . . . . . 142 11.1.2. AVP Flags . . . . . . . . . . . . . . . . . . . . . 141
11.2. Diameter Header . . . . . . . . . . . . . . . . . . . . . 142 11.2. Diameter Header . . . . . . . . . . . . . . . . . . . . . 141
11.2.1. Command Codes . . . . . . . . . . . . . . . . . . . 142 11.2.1. Command Codes . . . . . . . . . . . . . . . . . . . 141
11.2.2. Command Flags . . . . . . . . . . . . . . . . . . . 143 11.2.2. Command Flags . . . . . . . . . . . . . . . . . . . 142
11.3. Application Identifiers . . . . . . . . . . . . . . . . . 143 11.3. Application Identifiers . . . . . . . . . . . . . . . . . 142
11.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . 143 11.4. AVP Values . . . . . . . . . . . . . . . . . . . . . . . 142
11.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . 143 11.4.1. Result-Code AVP Values . . . . . . . . . . . . . . . 143
11.4.2. Accounting-Record-Type AVP Values . . . . . . . . . 144 11.4.2. Accounting-Record-Type AVP Values . . . . . . . . . 143
11.4.3. Termination-Cause AVP Values . . . . . . . . . . . . 144 11.4.3. Termination-Cause AVP Values . . . . . . . . . . . . 143
11.4.4. Redirect-Host-Usage AVP Values . . . . . . . . . . . 144 11.4.4. Redirect-Host-Usage AVP Values . . . . . . . . . . . 143
11.4.5. Session-Server-Failover AVP Values . . . . . . . . . 144 11.4.5. Session-Server-Failover AVP Values . . . . . . . . . 143
11.4.6. Session-Binding AVP Values . . . . . . . . . . . . . 144 11.4.6. Session-Binding AVP Values . . . . . . . . . . . . . 143
11.4.7. Disconnect-Cause AVP Values . . . . . . . . . . . . 144 11.4.7. Disconnect-Cause AVP Values . . . . . . . . . . . . 143
11.4.8. Auth-Request-Type AVP Values . . . . . . . . . . . . 144 11.4.8. Auth-Request-Type AVP Values . . . . . . . . . . . . 143
11.4.9. Auth-Session-State AVP Values . . . . . . . . . . . 145 11.4.9. Auth-Session-State AVP Values . . . . . . . . . . . 144
11.4.10. Re-Auth-Request-Type AVP Values . . . . . . . . . . 145 11.4.10. Re-Auth-Request-Type AVP Values . . . . . . . . . . 144
11.4.11. Accounting-Realtime-Required AVP Values . . . . . . 145 11.4.11. Accounting-Realtime-Required AVP Values . . . . . . 144
11.4.12. Inband-Security-Id AVP (code 299) . . . . . . . . . 145 11.4.12. Inband-Security-Id AVP (code 299) . . . . . . . . . 144
11.5. Diameter TCP/SCTP Port Numbers . . . . . . . . . . . . . 145 11.5. Diameter TCP/SCTP Port Numbers . . . . . . . . . . . . . 144
11.6. NAPTR Service Fields . . . . . . . . . . . . . . . . . . 145 11.6. NAPTR Service Fields . . . . . . . . . . . . . . . . . . 144
12. Diameter protocol related configurable parameters . . . . . . 147 12. Diameter protocol related configurable parameters . . . . . . 146
13. Security Considerations . . . . . . . . . . . . . . . . . . . 148 13. Security Considerations . . . . . . . . . . . . . . . . . . . 147
13.1. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 148 13.1. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 147
13.2. Peer-to-Peer Considerations . . . . . . . . . . . . . . . 149 13.2. Peer-to-Peer Considerations . . . . . . . . . . . . . . . 148
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 150 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 149
14.1. Normative References . . . . . . . . . . . . . . . . . . 150 14.1. Normative References . . . . . . . . . . . . . . . . . . 149
14.2. Informational References . . . . . . . . . . . . . . . . 152 14.2. Informational References . . . . . . . . . . . . . . . . 151
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 154 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 153
Appendix B. NAPTR Example . . . . . . . . . . . . . . . . . . . 155 Appendix B. NAPTR Example . . . . . . . . . . . . . . . . . . . 154
Appendix C. Duplicate Detection . . . . . . . . . . . . . . . . 156 Appendix C. Duplicate Detection . . . . . . . . . . . . . . . . 155
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 157
Intellectual Property and Copyright Statements . . . . . . . . . 159 Intellectual Property and Copyright Statements . . . . . . . . . 158
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 40 skipping to change at page 7, line 40
integrity scheme that is required only for use with Response integrity scheme that is required only for use with Response
packets. While [RFC2869] defines an additional authentication and packets. While [RFC2869] defines an additional authentication and
integrity mechanism, use is only required during Extensible integrity mechanism, use is only required during Extensible
Authentication Protocol (EAP) sessions. While attribute-hiding is Authentication Protocol (EAP) sessions. While attribute-hiding is
supported, [RFC2865] does not provide support for per-packet supported, [RFC2865] does not provide support for per-packet
confidentiality. In accounting, [RFC2866] assumes that replay confidentiality. In accounting, [RFC2866] assumes that replay
protection is provided by the backend billing server, rather than protection is provided by the backend billing server, rather than
within the protocol itself. within the protocol itself.
While [RFC3162] defines the use of IPsec with RADIUS, support for While [RFC3162] defines the use of IPsec with RADIUS, support for
IPsec is not required. Since within [RFC2409] authentication IPsec is not required. Since within [RFC4306] 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, Diameter also enable both intra- and inter-domain AAA deployments, Diameter also
provides support for TLS. Security is discussed in Section 13. provides support for TLS. Security is discussed in Section 13.
skipping to change at page 13, line 8 skipping to change at page 13, line 8
o Creating new authentication/authorization applications o Creating new authentication/authorization applications
o Creating new accounting applications o Creating new accounting applications
o Application authentication procedures o Application authentication procedures
Reuse of existing AVP values, AVPs and Diameter applications are Reuse of existing AVP values, AVPs and Diameter applications are
strongly recommended. Reuse simplifies standardization and strongly recommended. Reuse simplifies standardization and
implementation and avoids potential interoperability issues. It is implementation and avoids potential interoperability issues. It is
expected that command codes are reused; new command codes can only be expected that command codes are reused; new command codes can only be
created by IETF Consensus (see Section 11.2.1). created by Expert Review (see Section 11.2.1).
1.2.1. Defining New AVP Values 1.2.1. Defining New AVP Values
New applications should attempt to reuse AVPs defined in existing New applications should attempt to reuse AVPs defined in existing
applications when possible, as opposed to creating new AVPs. For applications when possible, as opposed to creating new AVPs. For
AVPs of type Enumerated, an application may require a new value to AVPs of type Enumerated, an application may require a new value to
communicate some service-specific information. communicate some service-specific information.
In order to allocate a new AVP value, a request MUST be sent to IANA In order to allocate a new AVP value, a request MUST be sent to IANA
[RFC2434], along with an explanation of the new AVP value. IANA [RFC2434], along with an explanation of the new AVP value. IANA
skipping to change at page 14, line 22 skipping to change at page 14, line 22
implementation MAY add arbitrary non-mandatory AVPs to any command implementation MAY add arbitrary non-mandatory AVPs to any command
defined in an application, including vendor-specific AVPs without defined in an application, including vendor-specific AVPs without
needing to define a new application. Please refer to Section 11.1.1 needing to define a new application. Please refer to Section 11.1.1
for details. for details.
In order to justify allocation of a new application identifier, In order to justify allocation of a new application identifier,
Diameter applications MUST define one Command Code, add new mandatory Diameter applications MUST define one Command Code, add new mandatory
AVPs to the ABNF or significantly change the state machine or AVPs to the ABNF or significantly change the state machine or
processing rules of an existing application. processing rules of an existing application.
The expected AVPs MUST be defined in an ABNF [RFC2234] grammar (see The expected AVPs MUST be defined in an ABNF [RFC4234] grammar (see
Section 3.2). If the Diameter application has accounting Section 3.2). If the Diameter application has accounting
requirements, it MUST also specify the AVPs that are to be present in requirements, it MUST also specify the AVPs that are to be present in
the Diameter Accounting messages (see Section 9.3). However, just the Diameter Accounting messages (see Section 9.3). However, just
because a new authentication application id is required, does not because a new authentication application id is required, does not
imply that a new accounting application id is required. imply that a new accounting application id is required.
When possible, a new Diameter application SHOULD reuse existing When possible, a new Diameter application SHOULD reuse existing
Diameter AVPs, in order to avoid defining multiple AVPs that carry Diameter AVPs, in order to avoid defining multiple AVPs that carry
similar information. similar information.
skipping to change at page 15, line 44 skipping to change at page 15, line 44
machine), then the base protocol defined standard accounting machine), then the base protocol defined standard accounting
application Id (Section 2.4) MUST be used in ACR/ACA commands. application Id (Section 2.4) MUST be used in ACR/ACA commands.
1.2.5. Application Authentication Procedures 1.2.5. Application Authentication Procedures
When possible, applications SHOULD be designed such that new When possible, applications SHOULD be designed such that new
authentication methods MAY be added without requiring changes to the authentication methods MAY be added without requiring changes to the
application. This MAY require that new AVP values be assigned to application. This MAY require that new AVP values be assigned to
represent the new authentication transform, or any other scheme that represent the new authentication transform, or any other scheme that
produces similar results. When possible, authentication frameworks, produces similar results. When possible, authentication frameworks,
such as Extensible Authentication Protocol [RFC2284], SHOULD be used. such as Extensible Authentication Protocol [RFC3748], SHOULD be used.
1.3. Terminology 1.3. Terminology
AAA AAA
Authentication, Authorization and Accounting. Authentication, Authorization and Accounting.
Accounting Accounting
The act of collecting information on resource usage for the The act of collecting information on resource usage for the
purpose of capacity planning, auditing, billing or cost purpose of capacity planning, auditing, billing or cost
skipping to change at page 24, 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 MAY support TLS [RFC2246]. Diameter servers MUST support TLS. Agents MAY support TLS [RFC4346]. Diameter servers MUST support TLS.
IPSec [RFC2401] can be deployed between Diameter peers as an IPSec [RFC4301] can be deployed between Diameter peers as an
additional security measure independent of the Diameter protocol. additional security measure independent of the Diameter protocol.
The Diameter protocol SHOULD NOT be used without any security The Diameter protocol SHOULD NOT be used without any security
mechanism. mechanism.
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
skipping to change at page 39, line 46 skipping to change at page 39, line 46
; The AVP MUST be present and can appear ; The AVP MUST be present and can appear
; anywhere in the message. ; anywhere in the message.
optional = [qual] "[" avp-name "]" optional = [qual] "[" avp-name "]"
; The avp-name in the 'optional' rule cannot ; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name which is included ; evaluate to any AVP Name which is included
; in a fixed or required rule. The AVP can ; in a fixed or required rule. The AVP can
; appear anywhere in the message. ; appear anywhere in the message.
qual = [min] "*" [max] qual = [min] "*" [max]
; See ABNF conventions, RFC 2234 Section 6.6. ; See ABNF conventions, RFC 4234 Section 6.6.
; The absence of any qualifiers depends on ; The absence of any qualifiers depends on
; whether it precedes a fixed, required, or ; whether it precedes a fixed, required, or
; optional rule. If a fixed or required rule has ; optional rule. If a fixed or required rule has
; no qualifier, then exactly one such AVP MUST ; no qualifier, then exactly one such AVP MUST
; be present. If an optional rule has no ; be present. If an optional rule has no
; qualifier, then 0 or 1 such AVP may be ; qualifier, then 0 or 1 such AVP may be
; present. ; present.
; ;
; NOTE: "[" and "]" have a different meaning ; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above). ; than in ABNF (see the optional rule, above).
skipping to change at page 46, line 24 skipping to change at page 46, line 24
format as the definitions below. Each new definition must be either format as the definitions below. Each new definition must be either
defined or listed with a reference to the RFC that defines the defined or listed with a reference to the RFC that defines the
format. format.
The below AVP Derived Data Formats are commonly used by applications. The below AVP Derived Data Formats are commonly used by applications.
Address Address
The Address format is derived from the OctetString AVP Base The Address format is derived from the OctetString AVP Base
Format. It is a discriminated union, representing, for example a Format. It is a discriminated union, representing, for example a
32-bit (IPv4) [IPV4] or 128-bit (IPv6) [RFC2373] address, most 32-bit (IPv4) [IPV4] or 128-bit (IPv6) [RFC4291] address, most
significant octet first. The first two octets of the Address AVP significant octet first. The first two octets of the Address AVP
represents the AddressType, which contains an Address Family represents the AddressType, which contains an Address Family
defined in [IANAADFAM]. The AddressType is used to discriminate defined in [IANAADFAM]. The AddressType is used to discriminate
the content and format of the remaining octets. the content and format of the remaining octets.
Time Time
The Time format is derived from the OctetString AVP Base Format. The Time format is derived from the OctetString AVP Base Format.
The string MUST contain four octets, in the same format as the The string MUST contain four octets, in the same format as the
first four bytes are in the NTP timestamp format. The NTP first four bytes are in the NTP timestamp format. The NTP
Timestamp format is defined in chapter 3 of [RFC2030]. Timestamp format is defined in chapter 3 of [RFC4330].
This represents the number of seconds since 0h on 1 January 1900 This represents the number of seconds since 0h on 1 January 1900
with respect to the Coordinated Universal Time (UTC). with respect to the Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. On 6h 28m 16s UTC, 7 February 2036 the time value will overflow.
SNTP [RFC2030] describes a procedure to extend the time to 2104. SNTP [RFC4330] describes a procedure to extend the time to 2104.
This procedure MUST be supported by all DIAMETER nodes. This procedure MUST be supported by all DIAMETER nodes.
UTF8String UTF8String
The UTF8String format is derived from the OctetString AVP Base The UTF8String format is derived from the OctetString AVP Base
Format. This is a human readable string represented using the Format. This is a human readable string represented using the
ISO/IEC IS 10646-1 character set, encoded as an OctetString using ISO/IEC IS 10646-1 character set, encoded as an OctetString using
the UTF-8 [RFC2279] transformation format described in RFC 2279. the UTF-8 [RFC3629] transformation format described in RFC 3629.
Since additional code points are added by amendments to the 10646 Since additional code points are added by amendments to the 10646
standard from time to time, implementations MUST be prepared to standard from time to time, implementations MUST be prepared to
encounter any code point from 0x00000001 to 0x7fffffff. Byte encounter any code point from 0x00000001 to 0x7fffffff. Byte
sequences that do not correspond to the valid encoding of a code sequences that do not correspond to the valid encoding of a code
point into UTF-8 charset or are outside this range are prohibited. point into UTF-8 charset or are outside this range are prohibited.
The use of control codes SHOULD be avoided. When it is necessary The use of control codes SHOULD be avoided. When it is necessary
to represent a new line, the control code sequence CR LF SHOULD be to represent a new line, the control code sequence CR LF SHOULD be
used. used.
skipping to change at page 48, line 8 skipping to change at page 48, line 8
The contents of the string MUST be the FQDN of the Diameter node. The contents of the string MUST be the FQDN of the Diameter node.
If multiple Diameter nodes run on the same host, each Diameter If multiple Diameter nodes run on the same host, each Diameter
node MUST be assigned a unique DiameterIdentity. If a Diameter node MUST be assigned a unique DiameterIdentity. If a Diameter
node can be identified by several FQDNs, a single FQDN should be node can be identified by several FQDNs, a single FQDN should be
picked at startup, and used as the only DiameterIdentity for that picked at startup, and used as the only DiameterIdentity for that
node, whatever the connection it is sent on. node, whatever the connection it is sent on.
DiameterURI DiameterURI
The DiameterURI MUST follow the Uniform Resource Identifiers (URI) The DiameterURI MUST follow the Uniform Resource Identifiers (URI)
syntax [RFC2396] rules specified below: syntax [RFC3986] rules specified below:
"aaa://" FQDN [ port ] [ transport ] [ protocol ] "aaa://" FQDN [ port ] [ transport ] [ protocol ]
; No transport security ; No transport security
"aaas://" FQDN [ port ] [ transport ] [ protocol ] "aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Transport security used ; Transport security used
FQDN = Fully Qualified Host Name FQDN = Fully Qualified Host Name
skipping to change at page 52, line 29 skipping to change at page 52, line 29
An access device that is unable to interpret or apply a deny rule An access device that is unable to interpret or apply a deny rule
MUST terminate the session. An access device that is unable to MUST terminate the session. An access device that is unable to
interpret or apply a permit rule MAY apply a more restrictive interpret or apply a permit rule MAY apply a more restrictive
rule. An access device MAY apply deny rules of its own before the rule. An access device MAY apply deny rules of its own before the
supplied rules, for example to protect the access device owner's supplied rules, for example to protect the access device owner's
infrastructure. infrastructure.
The rule syntax is a modified subset of ipfw(8) from FreeBSD, and The rule syntax is a modified subset of ipfw(8) from FreeBSD, and
the ipfw.c code may provide a useful base for implementations. the ipfw.c code may provide a useful base for implementations.
QoSFilterRule
The QosFilterRule format is derived from the OctetString AVP Base
Format. It uses the ASCII charset. Packets may be marked or
metered based on the following information that is associated with
it:
Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
DSCP values (no mask or range)
Rules for the appropriate direction are evaluated in order, with
the first matched rule terminating the evaluation. Each packet is
evaluated once. If no rule matches, the packet is treated as best
effort. An access device that is unable to interpret or apply a
QoS rule SHOULD NOT terminate the session.
QoSFilterRule filters MUST follow the format: