| 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: | | | |
| |