draft-ietf-dime-rfc4005bis-11.txt   draft-ietf-dime-rfc4005bis-12.txt 
Network Working Group G. Zorn, Ed. Network Working Group G. Zorn, Ed.
Internet-Draft Network Zen Internet-Draft Network Zen
Obsoletes: 4005 (if approved) July 31, 2012 Obsoletes: 4005 (if approved) January 2, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: February 1, 2013 Expires: July 6, 2013
Diameter Network Access Server Application Diameter Network Access Server Application
draft-ietf-dime-rfc4005bis-11 draft-ietf-dime-rfc4005bis-12
Abstract Abstract
This document describes the Diameter protocol application used for This document describes the Diameter protocol application used for
Authentication, Authorization, and Accounting (AAA) services in the Authentication, Authorization, and Accounting (AAA) services in the
Network Access Server (NAS) environment; it obsoletes RFC 4005. When Network Access Server (NAS) environment; it obsoletes RFC 4005. When
combined with the Diameter Base protocol, Transport Profile, and combined with the Diameter Base protocol, Transport Profile, and
Extensible Authentication Protocol specifications, this application Extensible Authentication Protocol specifications, this application
specification satisfies typical network access services requirements. specification satisfies typical network access services requirements.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on February 1, 2013. This Internet-Draft will expire on July 6, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Changes from RFC 4005 . . . . . . . . . . . . . . . . . . 5 1.1. Changes from RFC 4005 . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
1.4. Advertising Application Support . . . . . . . . . . . . . 7 1.4. Advertising Application Support . . . . . . . . . . . . . 7
1.5. Application Identification . . . . . . . . . . . . . . . . 8 1.5. Application Identification . . . . . . . . . . . . . . . . 7
1.6. Accounting Model . . . . . . . . . . . . . . . . . . . . . 8 1.6. Accounting Model . . . . . . . . . . . . . . . . . . . . . 8
2. NAS Calls, Ports, and Sessions . . . . . . . . . . . . . . . . 8 2. NAS Calls, Ports, and Sessions . . . . . . . . . . . . . . . . 8
2.1. Diameter Session Establishment . . . . . . . . . . . . . . 9 2.1. Diameter Session Establishment . . . . . . . . . . . . . . 8
2.2. Diameter Session Reauthentication or Reauthorization . . . 9 2.2. Diameter Session Reauthentication or Reauthorization . . . 9
2.3. Diameter Session Termination . . . . . . . . . . . . . . . 10 2.3. Diameter Session Termination . . . . . . . . . . . . . . . 10
3. Diameter NAS Application Messages . . . . . . . . . . . . . . 10 3. Diameter NAS Application Messages . . . . . . . . . . . . . . 10
3.1. AA-Request (AAR) Command . . . . . . . . . . . . . . . . . 11 3.1. AA-Request (AAR) Command . . . . . . . . . . . . . . . . . 10
3.2. AA-Answer (AAA) Command . . . . . . . . . . . . . . . . . 13 3.2. AA-Answer (AAA) Command . . . . . . . . . . . . . . . . . 12
3.3. Re-Auth-Request (RAR) Command . . . . . . . . . . . . . . 15 3.3. Re-Auth-Request (RAR) Command . . . . . . . . . . . . . . 14
3.4. Re-Auth-Answer (RAA) Command . . . . . . . . . . . . . . . 16 3.4. Re-Auth-Answer (RAA) Command . . . . . . . . . . . . . . . 15
3.5. Session-Termination-Request (STR) Command . . . . . . . . 17 3.5. Session-Termination-Request (STR) Command . . . . . . . . 16
3.6. Session-Termination-Answer (STA) Command . . . . . . . . . 18 3.6. Session-Termination-Answer (STA) Command . . . . . . . . . 17
3.7. Abort-Session-Request (ASR) Command . . . . . . . . . . . 19 3.7. Abort-Session-Request (ASR) Command . . . . . . . . . . . 18
3.8. Abort-Session-Answer (ASA) Command . . . . . . . . . . . . 20 3.8. Abort-Session-Answer (ASA) Command . . . . . . . . . . . . 19
3.9. Accounting-Request (ACR) Command . . . . . . . . . . . . . 21 3.9. Accounting-Request (ACR) Command . . . . . . . . . . . . . 20
3.10. Accounting-Answer (ACA) Command . . . . . . . . . . . . . 23 3.10. Accounting-Answer (ACA) Command . . . . . . . . . . . . . 22
4. Diameter NAS Application AVPs . . . . . . . . . . . . . . . . 24 4. Diameter NAS Application AVPs . . . . . . . . . . . . . . . . 23
4.1. Derived AVP Data Formats . . . . . . . . . . . . . . . . . 24 4.1. Derived AVP Data Formats . . . . . . . . . . . . . . . . . 23
4.1.1. QoSFilterRule . . . . . . . . . . . . . . . . . . . . 24 4.1.1. QoSFilterRule . . . . . . . . . . . . . . . . . . . . 23
4.2. NAS Session AVPs . . . . . . . . . . . . . . . . . . . . . 25 4.2. NAS Session AVPs . . . . . . . . . . . . . . . . . . . . . 24
4.2.1. Call and Session Information . . . . . . . . . . . . . 25 4.2.1. Call and Session Information . . . . . . . . . . . . . 24
4.2.2. NAS-Port AVP . . . . . . . . . . . . . . . . . . . . . 26 4.2.2. NAS-Port AVP . . . . . . . . . . . . . . . . . . . . . 25
4.2.3. NAS-Port-Id AVP . . . . . . . . . . . . . . . . . . . 26 4.2.3. NAS-Port-Id AVP . . . . . . . . . . . . . . . . . . . 25
4.2.4. NAS-Port-Type AVP . . . . . . . . . . . . . . . . . . 27 4.2.4. NAS-Port-Type AVP . . . . . . . . . . . . . . . . . . 26
4.2.5. Called-Station-Id AVP . . . . . . . . . . . . . . . . 27 4.2.5. Called-Station-Id AVP . . . . . . . . . . . . . . . . 26
4.2.6. Calling-Station-Id AVP . . . . . . . . . . . . . . . . 27 4.2.6. Calling-Station-Id AVP . . . . . . . . . . . . . . . . 26
4.2.7. Connect-Info AVP . . . . . . . . . . . . . . . . . . . 28 4.2.7. Connect-Info AVP . . . . . . . . . . . . . . . . . . . 27
4.2.8. Originating-Line-Info AVP . . . . . . . . . . . . . . 28 4.2.8. Originating-Line-Info AVP . . . . . . . . . . . . . . 27
4.2.9. Reply-Message AVP . . . . . . . . . . . . . . . . . . 29 4.2.9. Reply-Message AVP . . . . . . . . . . . . . . . . . . 28
4.3. NAS Authentication AVPs . . . . . . . . . . . . . . . . . 29 4.3. NAS Authentication AVPs . . . . . . . . . . . . . . . . . 28
4.3.1. User-Password AVP . . . . . . . . . . . . . . . . . . 30 4.3.1. User-Password AVP . . . . . . . . . . . . . . . . . . 29
4.3.2. Password-Retry AVP . . . . . . . . . . . . . . . . . . 30 4.3.2. Password-Retry AVP . . . . . . . . . . . . . . . . . . 29
4.3.3. Prompt AVP . . . . . . . . . . . . . . . . . . . . . . 30 4.3.3. Prompt AVP . . . . . . . . . . . . . . . . . . . . . . 29
4.3.4. CHAP-Auth AVP . . . . . . . . . . . . . . . . . . . . 30 4.3.4. CHAP-Auth AVP . . . . . . . . . . . . . . . . . . . . 29
4.3.5. CHAP-Algorithm AVP . . . . . . . . . . . . . . . . . . 31 4.3.5. CHAP-Algorithm AVP . . . . . . . . . . . . . . . . . . 30
4.3.6. CHAP-Ident AVP . . . . . . . . . . . . . . . . . . . . 31 4.3.6. CHAP-Ident AVP . . . . . . . . . . . . . . . . . . . . 30
4.3.7. CHAP-Response AVP . . . . . . . . . . . . . . . . . . 31 4.3.7. CHAP-Response AVP . . . . . . . . . . . . . . . . . . 30
4.3.8. CHAP-Challenge AVP . . . . . . . . . . . . . . . . . . 31 4.3.8. CHAP-Challenge AVP . . . . . . . . . . . . . . . . . . 30
4.3.9. ARAP-Password AVP . . . . . . . . . . . . . . . . . . 31 4.3.9. ARAP-Password AVP . . . . . . . . . . . . . . . . . . 30
4.3.10. ARAP-Challenge-Response AVP . . . . . . . . . . . . . 31 4.3.10. ARAP-Challenge-Response AVP . . . . . . . . . . . . . 30
4.3.11. ARAP-Security AVP . . . . . . . . . . . . . . . . . . 32 4.3.11. ARAP-Security AVP . . . . . . . . . . . . . . . . . . 31
4.3.12. ARAP-Security-Data AVP . . . . . . . . . . . . . . . . 32 4.3.12. ARAP-Security-Data AVP . . . . . . . . . . . . . . . . 31
4.4. NAS Authorization AVPs . . . . . . . . . . . . . . . . . . 32 4.4. NAS Authorization AVPs . . . . . . . . . . . . . . . . . . 31
4.4.1. Service-Type AVP . . . . . . . . . . . . . . . . . . . 34 4.4.1. Service-Type AVP . . . . . . . . . . . . . . . . . . . 33
4.4.2. Callback-Number AVP . . . . . . . . . . . . . . . . . 34 4.4.2. Callback-Number AVP . . . . . . . . . . . . . . . . . 33
4.4.3. Callback-Id AVP . . . . . . . . . . . . . . . . . . . 35 4.4.3. Callback-Id AVP . . . . . . . . . . . . . . . . . . . 34
4.4.4. Idle-Timeout AVP . . . . . . . . . . . . . . . . . . . 35 4.4.4. Idle-Timeout AVP . . . . . . . . . . . . . . . . . . . 34
4.4.5. Port-Limit AVP . . . . . . . . . . . . . . . . . . . . 35 4.4.5. Port-Limit AVP . . . . . . . . . . . . . . . . . . . . 34
4.4.6. NAS-Filter-Rule AVP . . . . . . . . . . . . . . . . . 35 4.4.6. NAS-Filter-Rule AVP . . . . . . . . . . . . . . . . . 34
4.4.7. Filter-Id AVP . . . . . . . . . . . . . . . . . . . . 35 4.4.7. Filter-Id AVP . . . . . . . . . . . . . . . . . . . . 34
4.4.8. Configuration-Token AVP . . . . . . . . . . . . . . . 36 4.4.8. Configuration-Token AVP . . . . . . . . . . . . . . . 35
4.4.9. QoS-Filter-Rule AVP . . . . . . . . . . . . . . . . . 36 4.4.9. QoS-Filter-Rule AVP . . . . . . . . . . . . . . . . . 35
4.4.10. Framed Access Authorization AVPs . . . . . . . . . . . 37 4.4.10. Framed Access Authorization AVPs . . . . . . . . . . . 36
4.4.10.1. Framed-Protocol AVP . . . . . . . . . . . . . . . 37 4.4.10.1. Framed-Protocol AVP . . . . . . . . . . . . . . . 36
4.4.10.2. Framed-Routing AVP . . . . . . . . . . . . . . . 37 4.4.10.2. Framed-Routing AVP . . . . . . . . . . . . . . . 36
4.4.10.3. Framed-MTU AVP . . . . . . . . . . . . . . . . . 37 4.4.10.3. Framed-MTU AVP . . . . . . . . . . . . . . . . . 36
4.4.10.4. Framed-Compression AVP . . . . . . . . . . . . . 37 4.4.10.4. Framed-Compression AVP . . . . . . . . . . . . . 36
4.4.10.5. IP Access Authorization AVPs . . . . . . . . . . 38 4.4.10.5. IP Access Authorization AVPs . . . . . . . . . . 37
4.4.10.5.1. Framed-IP-Address AVP . . . . . . . . . . . . 38 4.4.10.5.1. Framed-IP-Address AVP . . . . . . . . . . . . 37
4.4.10.5.2. Framed-IP-Netmask AVP . . . . . . . . . . . . 38 4.4.10.5.2. Framed-IP-Netmask AVP . . . . . . . . . . . . 37
4.4.10.5.3. Framed-Route AVP . . . . . . . . . . . . . . 38 4.4.10.5.3. Framed-Route AVP . . . . . . . . . . . . . . 37
4.4.10.5.4. Framed-Pool AVP . . . . . . . . . . . . . . . 39 4.4.10.5.4. Framed-Pool AVP . . . . . . . . . . . . . . . 38
4.4.10.5.5. Framed-Interface-Id AVP . . . . . . . . . . . 39 4.4.10.5.5. Framed-Interface-Id AVP . . . . . . . . . . . 38
4.4.10.5.6. Framed-IPv6-Prefix AVP . . . . . . . . . . . 39 4.4.10.5.6. Framed-IPv6-Prefix AVP . . . . . . . . . . . 38
4.4.10.5.7. Framed-IPv6-Route AVP . . . . . . . . . . . . 39 4.4.10.5.7. Framed-IPv6-Route AVP . . . . . . . . . . . . 38
4.4.10.5.8. Framed-IPv6-Pool AVP . . . . . . . . . . . . 40 4.4.10.5.8. Framed-IPv6-Pool AVP . . . . . . . . . . . . 39
4.4.10.6. IPX Access AVPs . . . . . . . . . . . . . . . . . 40 4.4.10.6. IPX Access AVPs . . . . . . . . . . . . . . . . . 39
4.4.10.6.1. Framed-IPX-Network AVP . . . . . . . . . . . 40 4.4.10.6.1. Framed-IPX-Network AVP . . . . . . . . . . . 39
4.4.10.7. AppleTalk Network Access AVPs . . . . . . . . . . 40 4.4.10.7. AppleTalk Network Access AVPs . . . . . . . . . . 39
4.4.10.7.1. Framed-AppleTalk-Link AVP . . . . . . . . . . 40 4.4.10.7.1. Framed-AppleTalk-Link AVP . . . . . . . . . . 39
4.4.10.7.2. Framed-AppleTalk-Network AVP . . . . . . . . 41 4.4.10.7.2. Framed-AppleTalk-Network AVP . . . . . . . . 40
4.4.10.7.3. Framed-AppleTalk-Zone AVP . . . . . . . . . . 41 4.4.10.7.3. Framed-AppleTalk-Zone AVP . . . . . . . . . . 40
4.4.10.8. AppleTalk Remote Access AVPs . . . . . . . . . . 41 4.4.10.8. AppleTalk Remote Access AVPs . . . . . . . . . . 40
4.4.10.8.1. ARAP-Features AVP . . . . . . . . . . . . . . 41 4.4.10.8.1. ARAP-Features AVP . . . . . . . . . . . . . . 40
4.4.10.8.2. ARAP-Zone-Access AVP . . . . . . . . . . . . 42 4.4.10.8.2. ARAP-Zone-Access AVP . . . . . . . . . . . . 41
4.4.11. Non-Framed Access Authorization AVPs . . . . . . . . . 42 4.4.11. Non-Framed Access Authorization AVPs . . . . . . . . . 41
4.4.11.1. Login-IP-Host AVP . . . . . . . . . . . . . . . . 42 4.4.11.1. Login-IP-Host AVP . . . . . . . . . . . . . . . . 41
4.4.11.2. Login-IPv6-Host AVP . . . . . . . . . . . . . . . 42 4.4.11.2. Login-IPv6-Host AVP . . . . . . . . . . . . . . . 41
4.4.11.3. Login-Service AVP . . . . . . . . . . . . . . . . 43 4.4.11.3. Login-Service AVP . . . . . . . . . . . . . . . . 42
4.4.11.4. TCP Services . . . . . . . . . . . . . . . . . . 43 4.4.11.4. TCP Services . . . . . . . . . . . . . . . . . . 42
4.4.11.4.1. Login-TCP-Port AVP . . . . . . . . . . . . . 43 4.4.11.4.1. Login-TCP-Port AVP . . . . . . . . . . . . . 42
4.4.11.5. LAT Services . . . . . . . . . . . . . . . . . . 43 4.4.11.5. LAT Services . . . . . . . . . . . . . . . . . . 42
4.4.11.5.1. Login-LAT-Service AVP . . . . . . . . . . . . 43 4.4.11.5.1. Login-LAT-Service AVP . . . . . . . . . . . . 42
4.4.11.5.2. Login-LAT-Node AVP . . . . . . . . . . . . . 44 4.4.11.5.2. Login-LAT-Node AVP . . . . . . . . . . . . . 43
4.4.11.5.3. Login-LAT-Group AVP . . . . . . . . . . . . . 44 4.4.11.5.3. Login-LAT-Group AVP . . . . . . . . . . . . . 43
4.4.11.5.4. Login-LAT-Port AVP . . . . . . . . . . . . . 45 4.4.11.5.4. Login-LAT-Port AVP . . . . . . . . . . . . . 44
4.5. NAS Tunneling AVPs . . . . . . . . . . . . . . . . . . . . 45 4.5. NAS Tunneling AVPs . . . . . . . . . . . . . . . . . . . . 44
4.5.1. Tunneling AVP . . . . . . . . . . . . . . . . . . . . 46 4.5.1. Tunneling AVP . . . . . . . . . . . . . . . . . . . . 45
4.5.2. Tunnel-Type AVP . . . . . . . . . . . . . . . . . . . 46 4.5.2. Tunnel-Type AVP . . . . . . . . . . . . . . . . . . . 45
4.5.3. Tunnel-Medium-Type AVP . . . . . . . . . . . . . . . . 47 4.5.3. Tunnel-Medium-Type AVP . . . . . . . . . . . . . . . . 46
4.5.4. Tunnel-Client-Endpoint AVP . . . . . . . . . . . . . . 47 4.5.4. Tunnel-Client-Endpoint AVP . . . . . . . . . . . . . . 46
4.5.5. Tunnel-Server-Endpoint AVP . . . . . . . . . . . . . . 48 4.5.5. Tunnel-Server-Endpoint AVP . . . . . . . . . . . . . . 47
4.5.6. Tunnel-Password AVP . . . . . . . . . . . . . . . . . 48 4.5.6. Tunnel-Password AVP . . . . . . . . . . . . . . . . . 47
4.5.7. Tunnel-Private-Group-Id AVP . . . . . . . . . . . . . 48 4.5.7. Tunnel-Private-Group-Id AVP . . . . . . . . . . . . . 48
4.5.8. Tunnel-Assignment-Id AVP . . . . . . . . . . . . . . . 49 4.5.8. Tunnel-Assignment-Id AVP . . . . . . . . . . . . . . . 48
4.5.9. Tunnel-Preference AVP . . . . . . . . . . . . . . . . 50 4.5.9. Tunnel-Preference AVP . . . . . . . . . . . . . . . . 49
4.5.10. Tunnel-Client-Auth-Id AVP . . . . . . . . . . . . . . 51 4.5.10. Tunnel-Client-Auth-Id AVP . . . . . . . . . . . . . . 50
4.5.11. Tunnel-Server-Auth-Id AVP . . . . . . . . . . . . . . 51 4.5.11. Tunnel-Server-Auth-Id AVP . . . . . . . . . . . . . . 50
4.6. NAS Accounting AVPs . . . . . . . . . . . . . . . . . . . 51 4.6. NAS Accounting AVPs . . . . . . . . . . . . . . . . . . . 50
4.6.1. Accounting-Input-Octets AVP . . . . . . . . . . . . . 52 4.6.1. Accounting-Input-Octets AVP . . . . . . . . . . . . . 51
4.6.2. Accounting-Output-Octets AVP . . . . . . . . . . . . . 52 4.6.2. Accounting-Output-Octets AVP . . . . . . . . . . . . . 51
4.6.3. Accounting-Input-Packets AVP . . . . . . . . . . . . . 52 4.6.3. Accounting-Input-Packets AVP . . . . . . . . . . . . . 52
4.6.4. Accounting-Output-Packets AVP . . . . . . . . . . . . 53 4.6.4. Accounting-Output-Packets AVP . . . . . . . . . . . . 52
4.6.5. Acct-Session-Time AVP . . . . . . . . . . . . . . . . 53 4.6.5. Acct-Session-Time AVP . . . . . . . . . . . . . . . . 52
4.6.6. Acct-Authentic AVP . . . . . . . . . . . . . . . . . . 53 4.6.6. Acct-Authentic AVP . . . . . . . . . . . . . . . . . . 52
4.6.7. Accounting-Auth-Method AVP . . . . . . . . . . . . . . 53 4.6.7. Accounting-Auth-Method AVP . . . . . . . . . . . . . . 52
4.6.8. Acct-Delay-Time AVP . . . . . . . . . . . . . . . . . 53 4.6.8. Acct-Delay-Time AVP . . . . . . . . . . . . . . . . . 52
4.6.9. Acct-Link-Count AVP . . . . . . . . . . . . . . . . . 54 4.6.9. Acct-Link-Count AVP . . . . . . . . . . . . . . . . . 53
4.6.10. Acct-Tunnel-Connection AVP . . . . . . . . . . . . . . 54 4.6.10. Acct-Tunnel-Connection AVP . . . . . . . . . . . . . . 54
4.6.11. Acct-Tunnel-Packets-Lost AVP . . . . . . . . . . . . . 55 4.6.11. Acct-Tunnel-Packets-Lost AVP . . . . . . . . . . . . . 54
5. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 55 5. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 54
5.1. AA-Request/Answer AVP Table . . . . . . . . . . . . . . . 55 5.1. AA-Request/Answer AVP Table . . . . . . . . . . . . . . . 54
5.2. Accounting AVP Tables . . . . . . . . . . . . . . . . . . 58 5.2. Accounting AVP Tables . . . . . . . . . . . . . . . . . . 57
5.2.1. Framed Access Accounting AVP Table . . . . . . . . . . 59 5.2.1. Framed Access Accounting AVP Table . . . . . . . . . . 58
5.2.2. Non-Framed Access Accounting AVP Table . . . . . . . . 61 5.2.2. Non-Framed Access Accounting AVP Table . . . . . . . . 60
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
7. Security Considerations . . . . . . . . . . . . . . . . . . . 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 62
7.1. Authentication Considerations . . . . . . . . . . . . . . 62
7.2. AVP Considerations . . . . . . . . . . . . . . . . . . . . 62
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.1. Normative References . . . . . . . . . . . . . . . . . . . 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 63
8.2. Informative References . . . . . . . . . . . . . . . . . . 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 63
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 66
A.1. RFC 4005 . . . . . . . . . . . . . . . . . . . . . . . . . 67 A.1. This Document . . . . . . . . . . . . . . . . . . . . . . 66
A.2. RFC 4005bis . . . . . . . . . . . . . . . . . . . . . . . 68 A.2. RFC 4005 . . . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
This document describes the Diameter protocol application used for This document describes the Diameter protocol application used for
AAA in the Network Access Server (NAS) environment. When combined AAA in the Network Access Server (NAS) environment. When combined
with the Diameter Base protocol [I-D.ietf-dime-rfc3588bis], Transport with the Diameter Base protocol [RFC6733], Transport Profile
Profile [RFC3539], and EAP [RFC4072] specifications, this [RFC3539], and EAP [RFC4072] specifications, this specification
specification satisfies the NAS-related requirements defined in satisfies the NAS-related requirements defined in Aboba, et
Aboba, et al. [RFC2989] and Beadles & Mitton [RFC3169]. al. [RFC2989] and Beadles & Mitton [RFC3169].
First, this document describes the operation of a Diameter NAS First, this document describes the operation of a Diameter NAS
application. Then it defines the Diameter message Command-Codes. application. Then it defines the Diameter message Command-Codes.
The following sections list the AVPs used in these messages, grouped The following sections list the AVPs used in these messages, grouped
by common usage. These are session identification, authentication, by common usage. These are session identification, authentication,
authorization, tunneling, and accounting. The authorization AVPs are authorization, tunneling, and accounting. The authorization AVPs are
further broken down by service type. further broken down by service type.
1.1. Changes from RFC 4005 1.1. Changes from RFC 4005
This document obsoletes RFC 4005 and is not backward compatible with This document obsoletes RFC 4005 and is not backward compatible with
that document. An overview of some the major changes are given that document. An overview of some of the major changes is given
below. below.
o All of the material regarding RADIUS/Diameter protocol o All of the material regarding RADIUS/Diameter protocol
interactions has been removed. interactions has been removed.
o The Command Code Format (CCF) [I-D.ietf-dime-rfc3588bis] for the o The Command Code Format (CCF) [RFC6733] for the Accounting-Request
Accounting-Request and Accounting-Answer messages has been changed and Accounting-Answer messages has been changed to explicitly
to explicitly require the inclusion of the Acct-Application-Id AVP require the inclusion of the Acct-Application-Id AVP and exclude
and exclude the Vendor-Specific-Application-Id AVP. Normally, the Vendor-Specific-Application-Id AVP. Normally, this type of
this type of change would also require the allocation of a new change would also require the allocation of a new command code and
command code and consequently, a new application-id (See Section consequently, a new application-id (See Section 1.3.3 of
1.3.3 of [I-D.ietf-dime-rfc3588bis]). However, the presence of an [RFC6733]). However, the presence of an instance of the Acct-
instance of the Acct-Application-Id AVP was required in RFC 4005, Application-Id AVP was required in RFC 4005, as well:
as well:
The ACR message [BASE] is sent by the NAS to report its session The ACR message [BASE] is sent by the NAS to report its session
information to a target server downstream. information to a target server downstream.
Either of Acct-Application-Id or Vendor-Specific-Application-Id Either of Acct-Application-Id or Vendor-Specific-Application-Id
AVPs MUST be present. If the Vendor-Specific-Application-Id AVPs MUST be present. If the Vendor-Specific-Application-Id
grouped AVP is present, it must have an Acct-Application-Id grouped AVP is present, it must have an Acct-Application-Id
inside. inside.
Thus, though the syntax of the commands has changed, the semantics Thus, though the syntax of the commands has changed, the semantics
have not (with the caveat that the Acct-Application-Id AVP can no have not (with the caveat that the Acct-Application-Id AVP can no
longer be contained in the Vendor-Specific-Application-Id AVP). longer be contained in the Vendor-Specific-Application-Id AVP).
o The lists of RADIUS attribute values have been deleted in favor of o The lists of RADIUS attribute values have been deleted in favor of
references to the appropriate IANA registries. references to the appropriate IANA registries.
o The accounting model to be used is now specified (see o The accounting model to be used is now specified (see
Section 1.6). Section 1.6).
There are many other many miscellaneous fixes that have been There are many other miscellaneous fixes that have been introduced in
introduced in this document that may not be considered significant this document that may not be considered significant but they are
but they are useful nonetheless. Examples are fixes to example IP useful nonetheless. Examples are fixes to example IP addresses,
addresses, addition of clarifying references, etc. All of the errata addition of clarifying references, etc. All of the errata previously
previously filed against RFC 4005 have been fixed. A comprehensive filed against RFC 4005 have been fixed. A comprehensive list of
list of changes is not shown here for practical reasons. changes is not shown here for practical reasons.
1.2. Terminology 1.2. Terminology
Section 1.2 of the Diameter base protocol specification Section 1.2 of the Diameter base protocol specification [RFC6733]
[I-D.ietf-dime-rfc3588bis] defines most of the terminology used in defines most of the terminology used in this document. Additionally,
this document. Additionally, the following terms and acronyms are the following terms and acronyms are used in this application:
used in this application:
NAS (Network Access Server) NAS (Network Access Server)
A device that provides an access service for a user to a network. A device that provides an access service for a user to a network.
The service may be a network connection or a value-added service The service may be a network connection or a value-added service
such as terminal emulation [RFC2881]. such as terminal emulation [RFC2881].
PPP (Point-to-Point Protocol) PPP (Point-to-Point Protocol)
A multiprotocol serial datalink. PPP is the primary IP datalink A multiprotocol serial datalink. PPP is the primary IP datalink
used for dial-in NAS connection service [RFC1661]. used for dial-in NAS connection service [RFC1661].
skipping to change at page 7, line 49 skipping to change at page 7, line 44
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
1.4. Advertising Application Support 1.4. Advertising Application Support
Diameter nodes conforming to this specification MUST advertise Diameter nodes conforming to this specification MUST advertise
support by including the value of one (1) in the Auth-Application-Id support by including the value of one (1) in the Auth-Application-Id
of the Capabilities-Exchange-Request (CER) message. of the Capabilities-Exchange-Request (CER) message [RFC6733].
1.5. Application Identification 1.5. Application Identification
When used in this application, the Auth-Application-Id AVP MUST be When used in this application, the Auth-Application-Id AVP MUST be
set to the value one (1) in the following messages set to the value one (1) in the following messages
o AA-Request (Section 3.1) o AA-Request (Section 3.1)
o Re-Auth-Request(Section 3.3) o Re-Auth-Request(Section 3.3)
o Session-Termination-Request (Section 3.5) o Session-Termination-Request (Section 3.5)
o Abort-Session-Request (Section 3.7) o Abort-Session-Request (Section 3.7)
1.6. Accounting Model 1.6. Accounting Model
It is RECOMMENDED that the coupled accounting model (Section 9.3 of It is RECOMMENDED that the coupled accounting model (Section 9.3 of
[I-D.ietf-dime-rfc3588bis]) be used with this application; therefore, [RFC6733]) be used with this application; therefore, the value of the
the value of the Acct-Application-Id AVP in the Accounting-Request Acct-Application-Id AVP in the Accounting-Request (Section 3.10) and
(Section 3.10) and Accounting-Answer (Section 3.9) messages SHOULD be Accounting-Answer (Section 3.9) messages SHOULD be set to one (1).
set to one (1).
2. NAS Calls, Ports, and Sessions 2. NAS Calls, Ports, and Sessions
The arrival of a new call or service connection at a port of a The arrival of a new call or service connection at a port of a
Network Access Server (NAS) starts a Diameter NAS message exchange. Network Access Server (NAS) starts a Diameter NAS Application message
Information about the call, the identity of the user, and the user's exchange. Information about the call, the identity of the user, and
authentication information are packaged into a Diameter AA-Request the user's authentication information are packaged into a Diameter
(AAR) message and sent to a server. AA-Request (AAR) message and sent to a server.
The server processes the information and responds with a Diameter AA- The server processes the information and responds with a Diameter AA-
Answer (AAA) message that contains authorization information for the Answer (AAA) message that contains authorization information for the
NAS, or a failure code (Result-Code AVP). A value of NAS, or a failure code (Result-Code AVP). A value of
DIAMETER_MULTI_ROUND_AUTH indicates an additional authentication DIAMETER_MULTI_ROUND_AUTH indicates an additional authentication
exchange, and several AAR and AAA messages may be exchanged until the exchange, and several AAR and AAA messages may be exchanged until the
transaction completes. transaction completes.
Depending on the value of the Auth-Request-Type AVP, the Diameter Depending on the value of the Auth-Request-Type AVP, the Diameter
protocol allows authorization-only requests that contain no protocol allows authorization-only requests that contain no
authentication information from the client. This capability goes authentication information from the client. This capability goes
beyond the Call Check capabilities provided by RADIUS (Section 5.6 of beyond the Call Check capabilities provided by RADIUS (Section 5.6 of
[RFC2865]) in that no access decision is requested. As a result, [RFC2865]) in that no access decision is requested. As a result, a
service cannot be started as a result of a response to an new session cannot be started as a result of a response to an
authorization-only request without introducing a significant security authorization-only request without introducing a significant security
vulnerability. vulnerability.
2.1. Diameter Session Establishment 2.1. Diameter Session Establishment
When the authentication or authorization exchange completes When the authentication or authorization exchange completes
successfully, the NAS application SHOULD start a session context. If successfully, the NAS application SHOULD start a session context. If
the Result-Code of DIAMETER_MULTI_ROUND_AUTH is returned, the the Result-Code of DIAMETER_MULTI_ROUND_AUTH is returned, the
exchange continues until a success or error is returned. exchange continues until a success or error is returned.
If accounting is active, the application MUST also send an Accounting If accounting is active, the application MUST also send an Accounting
message [I-D.ietf-dime-rfc3588bis]. An Accounting-Record-Type of message [RFC6733]. An Accounting-Record-Type of START_RECORD is sent
START_RECORD is sent for a new session. If a session fails to start, for a new session. If a session fails to start, the EVENT_RECORD
the EVENT_RECORD message is sent with the reason for the failure message is sent with the reason for the failure described.
described.
Note that the return of an unsupportable Accounting-Realtime-Required Note that the return of an unsupportable Accounting-Realtime-Required
value [I-D.ietf-dime-rfc3588bis] would result in a failure to value [RFC6733] would result in a failure to establish the session.
establish the session.
2.2. Diameter Session Reauthentication or Reauthorization 2.2. Diameter Session Reauthentication or Reauthorization
The Diameter Base protocol allows users to be periodically The Diameter Base protocol allows users to be periodically
reauthenticated and/or reauthorized. In such instances, the reauthenticated and/or reauthorized. In such instances, the
Session-Id AVP in the AAR message MUST be the same as the one present Session-Id AVP in the AAR message MUST be the same as the one present
in the original authentication/authorization message. in the original authentication/authorization message.
A Diameter server informs the NAS of the maximum time allowed before A Diameter server informs the NAS of the maximum time allowed before
reauthentication or reauthorization via the Authorization-Lifetime reauthentication or reauthorization via the Authorization-Lifetime
AVP [I-D.ietf-dime-rfc3588bis]. A NAS MAY reauthenticate and/or AVP [RFC6733]. A NAS MAY reauthenticate and/or reauthorize before
reauthorize before the end, but A NAS MUST reauthenticate and/or the end, but A NAS MUST reauthenticate and/or reauthorize at the end
reauthorize at the end of the period provided by the Authorization- of the period provided by the Authorization-Lifetime AVP. The
Lifetime AVP. The failure of a reauthentication exchange will failure of a reauthentication exchange will terminate the service.
terminate the service.
Furthermore, it is possible for Diameter servers to issue an Furthermore, it is possible for Diameter servers to issue an
unsolicited reauthentication and/or reauthorization request (e.g., unsolicited reauthentication and/or reauthorization request (e.g.,
Re-Auth-Request (RAR) message [I-D.ietf-dime-rfc3588bis]) to the NAS. Re-Auth-Request (RAR) message [RFC6733]) to the NAS. Upon receipt of
Upon receipt of such a message, the NAS MUST respond to the request such a message, the NAS MUST respond to the request with a Re-Auth-
with a Re-Auth-Answer (RAA) message [I-D.ietf-dime-rfc3588bis]. Answer (RAA) message [RFC6733].
If the RAR properly identifies an active session, the NAS will If the RAR properly identifies an active session, the NAS will
initiate a new local reauthentication or authorization sequence as initiate a new local reauthentication or authorization sequence as
indicated by the Re-Auth-Request-Type value. This will cause the NAS indicated by the Re-Auth-Request-Type value. This will cause the NAS
to send a new AAR message using the existing Session-Id. The server to send a new AAR message using the existing Session-Id. The server
will respond with an AAA message to specify the new service will respond with an AAA message to specify the new service
parameters. parameters.
If accounting is active, every change of authentication or If accounting is active, every change of authentication or
authorization SHOULD generate an accounting message. If the NAS authorization SHOULD generate an accounting message. If the NAS
service is a continuation of the prior user context, then an service is a continuation of the prior user context, then an
Accounting-Record-Type of INTERIM_RECORD indicating the new session Accounting-Record-Type of INTERIM_RECORD indicating the new session
attributes and cumulative status would be appropriate. If a new user attributes and cumulative status would be appropriate. If a new user
or a significant change in authorization is detected by the NAS, then or a significant change in authorization is detected by the NAS, then
the service may send two messages of the types STOP_RECORD and the service may send two messages of the types STOP_RECORD and
START_RECORD. Accounting may change the subsession identifiers START_RECORD. Accounting may change the subsession identifiers
(Acct-Session-ID, or Acct-Sub-Session-Id) to indicate such sub- (Acct-Session-ID, or Acct-Sub-Session-Id) to indicate such sub-
sessions. A service may also use a different Session-Id value for sessions. A service may also use a different Session-Id value for
accounting (see Section 9.6 of [I-D.ietf-dime-rfc3588bis]). accounting (see Section 9.6 of [RFC6733]).
However, the Diameter Session-ID AVP value used for the initial However, the Diameter Session-ID AVP value used for the initial
authorization exchange MUST be used to generate an STR message when authorization exchange MUST be used to generate an STR message when
the session context is terminated. the session context is terminated.
2.3. Diameter Session Termination 2.3. Diameter Session Termination
When a NAS receives an indication that a user's session is being When a NAS receives an indication that a user's session is being
disconnected by the client (e.g., an LCP Terminate-Request message disconnected by the client (e.g., an LCP Terminate-Request message
[RFC1661] is received) or an administrative command, the NAS MUST [RFC1661] is received) or an administrative command, the NAS MUST
issue a Session-Termination-Request (STR) [I-D.ietf-dime-rfc3588bis] issue a Session-Termination-Request (STR) [RFC6733] to its Diameter
to its Diameter Server. This will ensure that any resources Server. This will ensure that any resources maintained on the
maintained on the servers are freed appropriately. servers are freed appropriately.
Furthermore, a NAS that receives an Abort-Session-Request (ASR) Furthermore, a NAS that receives an Abort-Session-Request (ASR)
[I-D.ietf-dime-rfc3588bis] MUST issue an Abort-Session-Answer (ASA) [RFC6733] MUST issue an Abort-Session-Answer (ASA) if the session
if the session identified is active and disconnect the PPP (or identified is active and disconnect the PPP (or tunneling) session.
tunneling) session.
If accounting is active, an Accounting STOP_RECORD message If accounting is active, an Accounting STOP_RECORD message [RFC6733]
[I-D.ietf-dime-rfc3588bis] MUST be sent upon termination of the MUST be sent upon termination of the session context.
session context.
More information on Diameter Session Termination can be found in More information on Diameter Session Termination can be found in
Sections 8.4 and 8.5 of [I-D.ietf-dime-rfc3588bis]. Sections 8.4 and 8.5 of [RFC6733].
3. Diameter NAS Application Messages 3. Diameter NAS Application Messages
This section defines the Diameter message Command-Code This section defines the Diameter message Command-Code [RFC6733]
[I-D.ietf-dime-rfc3588bis] values that MUST be supported by all values that MUST be supported by all Diameter implementations
Diameter implementations conforming to this specification. The conforming to this specification. The Command Codes are as follows:
Command Codes are as follows:
+-----------------------------------+---------+------+--------------+ +-----------------------------------+---------+------+--------------+
| Command Name | Abbrev. | Code | Reference | | Command Name | Abbrev. | Code | Reference |
+-----------------------------------+---------+------+--------------+ +-----------------------------------+---------+------+--------------+
| AA-Request | AAR | 265 | Section 3.1 | | AA-Request | AAR | 265 | Section 3.1 |
| AA-Answer | AAA | 265 | Section 3.2 | | AA-Answer | AAA | 265 | Section 3.2 |
| Re-Auth-Request | RAR | 258 | Section 3.3 | | Re-Auth-Request | RAR | 258 | Section 3.3 |
| Re-Auth-Answer | RAA | 258 | Section 3.4 | | Re-Auth-Answer | RAA | 258 | Section 3.4 |
| Session-Termination-Request | STR | 275 | Section 3.5 | | Session-Termination-Request | STR | 275 | Section 3.5 |
| Session-Termination-Answer | STA | 275 | Section 3.6 | | Session-Termination-Answer | STA | 275 | Section 3.6 |
| Abort-Session-Request | ASR | 274 | Section 3.7 | | Abort-Session-Request | ASR | 274 | Section 3.7 |
| Abort-Session-Answer | ASA | 274 | Section 3.8 | | Abort-Session-Answer | ASA | 274 | Section 3.8 |
| Accounting-Request | ACR | 271 | Section 3.9 | | Accounting-Request | ACR | 271 | Section 3.9 |
| Accounting-Answer | ACA | 271 | Section 3.10 | | Accounting-Answer | ACA | 271 | Section 3.10 |
+-----------------------------------+---------+------+--------------+ +-----------------------------------+---------+------+--------------+
Note that the message formats in the following sub-sections use the Note that the message formats in the following sub-sections use the
standard Diameter Command Code Format ([I-D.ietf-dime-rfc3588bis], standard Diameter Command Code Format ([RFC6733], Section 3.2).
Section 3.2).
3.1. AA-Request (AAR) Command 3.1. AA-Request (AAR) Command
The AA-Request (AAR), which is indicated by setting the Command-Code The AA-Request (AAR), which is indicated by setting the Command-Code
field to 265 and the 'R' bit in the Command Flags field, is used to field to 265 and the 'R' bit in the Command Flags field, is used to
request authentication and/or authorization for a given NAS user. request authentication and/or authorization for a given NAS user.
The type of request is identified through the Auth-Request-Type AVP The type of request is identified through the Auth-Request-Type AVP
[I-D.ietf-dime-rfc3588bis]. The recommended value for most [RFC6733]. The recommended value for most situations is
situations is AUTHORIZE_AUTHENTICATE. AUTHORIZE_AUTHENTICATE.
If Authentication is requested, the User-Name attribute SHOULD be If Authentication is requested, the User-Name attribute SHOULD be
present, as well as any additional authentication AVPs that would present, as well as any additional authentication AVPs that would
carry the password information. A request for authorization SHOULD carry the password information. A request for authorization SHOULD
only include the information from which the authorization will be only include the information from which the authorization will be
performed, such as the User-Name, Called-Station-Id, or Calling- performed, such as the User-Name, Called-Station-Id, or Calling-
Station-Id AVPs. All requests SHOULD contain AVPs uniquely Station-Id AVPs. All requests SHOULD contain AVPs uniquely
identifying the source of the call, such as Origin-Host and NAS-Port. identifying the source of the call, such as Origin-Host and NAS-Port.
Certain networks MAY use different AVPs for authorization purposes. Certain networks MAY use different AVPs for authorization purposes.
A request for authorization will include some AVPs defined in A request for authorization will include some AVPs defined in
skipping to change at page 13, line 28 skipping to change at page 13, line 4
defined in Section 4.4. defined in Section 4.4.
For authentication exchanges requiring more than a single round trip, For authentication exchanges requiring more than a single round trip,
the server MUST set the Result-Code AVP to DIAMETER_MULTI_ROUND_AUTH. the server MUST set the Result-Code AVP to DIAMETER_MULTI_ROUND_AUTH.
An AAA message with this result code MAY include one Reply-Message or An AAA message with this result code MAY include one Reply-Message or
more and MAY include zero or one State AVPs. more and MAY include zero or one State AVPs.
If the Reply-Message AVP was present, the network access server If the Reply-Message AVP was present, the network access server
SHOULD send the text to the user's client to display to the user, SHOULD send the text to the user's client to display to the user,
instructing the client to prompt the user for a response. For instructing the client to prompt the user for a response. For
example, this capability can be achieved in PPP via PAP. If the example, this can be achieved in PPP via PAP. If it is impossible to
access client is unable to prompt the user for a new response, it deliver the text prompt to the user, the Diameter NAS Application
MUST treat the AA-Answer (AAA) with the Reply-Message AVP as an error client MUST treat the AA-Answer (AAA) with the Reply-Message AVP as
and deny access. an error and deny access.
Message Format Message Format
<AA-Answer> ::= < Diameter Header: 265, PXY > <AA-Answer> ::= < Diameter Header: 265, PXY >
< Session-Id > < Session-Id >
{ Auth-Application-Id } { Auth-Application-Id }
{ Auth-Request-Type } { Auth-Request-Type }
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
skipping to change at page 15, line 4 skipping to change at page 14, line 30
[ Login-LAT-Node ] [ Login-LAT-Node ]
[ Login-LAT-Port ] [ Login-LAT-Port ]
[ Login-LAT-Service ] [ Login-LAT-Service ]
[ Login-Service ] [ Login-Service ]
[ Login-TCP-Port ] [ Login-TCP-Port ]
* [ NAS-Filter-Rule ] * [ NAS-Filter-Rule ]
* [ QoS-Filter-Rule ] * [ QoS-Filter-Rule ]
* [ Tunneling ] * [ Tunneling ]
* [ Redirect-Host ] * [ Redirect-Host ]
[ Redirect-Host-Usage ] [ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ] [ Redirect-Max-Cache-Time ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ AVP ] * [ AVP ]
3.3. Re-Auth-Request (RAR) Command 3.3. Re-Auth-Request (RAR) Command
A Diameter server may initiate a re-authentication and/or re- A Diameter server can initiate re-authentication and/or re-
authorization service for a particular session by issuing a Re-Auth- authorization for a particular session by issuing a Re-Auth-Request
Request (RAR) message [I-D.ietf-dime-rfc3588bis]. (RAR) message [RFC6733].
For example, for pre-paid services, the Diameter server that For example, for pre-paid services, the Diameter server that
originally authorized a session may need some confirmation that the originally authorized a session may need some confirmation that the
user is still using the services. user is still using the services.
If a NAS receives an RAR message with Session-Id equal to a currently If a NAS receives an RAR message with Session-Id equal to a currently
active session and a Re-Auth-Type that includes authentication, it active session and a Re-Auth-Type that includes authentication, it
MUST initiate a re-authentication toward the user, if the service MUST initiate a re-authentication toward the user, if the service
supports this particular feature. supports this particular feature.
skipping to change at page 16, line 42 skipping to change at page 15, line 42
[ Acct-Multi-Session-Id ] [ Acct-Multi-Session-Id ]
[ State ] [ State ]
* [ Class ] * [ Class ]
[ Reply-Message ] [ Reply-Message ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
* [ AVP ] * [ AVP ]
3.4. Re-Auth-Answer (RAA) Command 3.4. Re-Auth-Answer (RAA) Command
The Re-Auth-Answer (RAA) message [I-D.ietf-dime-rfc3588bis] is sent The Re-Auth-Answer (RAA) message [RFC6733] is sent in response to the
in response to the RAR. The Result-Code AVP MUST be present and RAR. The Result-Code AVP MUST be present and indicates the
indicates the disposition of the request. disposition of the request.
A successful RAA transaction MUST be followed by an AAR message. A successful RAA transaction MUST be followed by an AAR message.
Message Format Message Format
<RA-Answer> ::= < Diameter Header: 258, PXY > <RA-Answer> ::= < Diameter Header: 258, PXY >
< Session-Id > < Session-Id >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
skipping to change at page 17, line 36 skipping to change at page 16, line 36
[ Re-Auth-Request-Type ] [ Re-Auth-Request-Type ]
[ State ] [ State ]
* [ Class ] * [ Class ]
* [ Reply-Message ] * [ Reply-Message ]
[ Prompt ] [ Prompt ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ AVP ] * [ AVP ]
3.5. Session-Termination-Request (STR) Command 3.5. Session-Termination-Request (STR) Command
The Session-Termination-Request (STR) message The Session-Termination-Request (STR) message [RFC6733] is sent by
[I-D.ietf-dime-rfc3588bis] is sent by the NAS to inform the Diameter the NAS to inform the Diameter Server that an authenticated and/or
Server that an authenticated and/or authorized session is being authorized session is being terminated.
terminated.
Message Format Message Format
<ST-Request> ::= < Diameter Header: 275, REQ, PXY > <ST-Request> ::= < Diameter Header: 275, REQ, PXY >
< Session-Id > < Session-Id >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Auth-Application-Id } { Auth-Application-Id }
{ Termination-Cause } { Termination-Cause }
skipping to change at page 18, line 25 skipping to change at page 17, line 25
[ Destination-Host ] [ Destination-Host ]
* [ Class ] * [ Class ]
[ Origin-AAA-Protocol ] [ Origin-AAA-Protocol ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
* [ AVP ] * [ AVP ]
3.6. Session-Termination-Answer (STA) Command 3.6. Session-Termination-Answer (STA) Command
The Session-Termination-Answer (STA) message The Session-Termination-Answer (STA) message [RFC6733] is sent by the
[I-D.ietf-dime-rfc3588bis] is sent by the Diameter Server to Diameter Server to acknowledge the notification that the session has
acknowledge the notification that the session has been terminated. been terminated. The Result-Code AVP MUST be present and MAY contain
The Result-Code AVP MUST be present and MAY contain an indication an indication that an error occurred while the STR was being
that an error occurred while the STR was being serviced. serviced.
Upon sending or receiving the STA, the Diameter Server MUST release Upon sending the STA, the Diameter Server MUST release all resources
all resources for the session indicated by the Session-Id AVP. Any for the session indicated by the Session-Id AVP. Any intermediate
intermediate server in the Proxy-Chain MAY also release any server in the Proxy-Chain MAY also release any resources, if
resources, if necessary. necessary.
Message Format Message Format
<ST-Answer> ::= < Diameter Header: 275, PXY > <ST-Answer> ::= < Diameter Header: 275, PXY >
< Session-Id > < Session-Id >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ User-Name ] [ User-Name ]
* [ Class ] * [ Class ]
skipping to change at page 19, line 27 skipping to change at page 18, line 27
[ Origin-AAA-Protocol ] [ Origin-AAA-Protocol ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ Redirect-Host ] * [ Redirect-Host ]
[ Redirect-Host-Usase ] [ Redirect-Host-Usase ]
[ Redirect-Max-Cache-Time ] [ Redirect-Max-Cache-Time ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ AVP ] * [ AVP ]
3.7. Abort-Session-Request (ASR) Command 3.7. Abort-Session-Request (ASR) Command
The Abort-Session-Request (ASR) message [I-D.ietf-dime-rfc3588bis] The Abort-Session-Request (ASR) message [RFC6733] can be sent by any
may be sent by any Diameter server to the NAS providing session Diameter server to the NAS providing session service to request that
service, to request that the session identified by the Session-Id be the session identified by the Session-Id be stopped.
stopped.
Message Format Message Format
<AS-Request> ::= < Diameter Header: 274, REQ, PXY > <AS-Request> ::= < Diameter Header: 274, REQ, PXY >
< Session-Id > < Session-Id >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Destination-Host } { Destination-Host }
{ Auth-Application-Id } { Auth-Application-Id }
skipping to change at page 20, line 41 skipping to change at page 19, line 41
[ Acct-Multi-Session-Id ] [ Acct-Multi-Session-Id ]
[ State ] [ State ]
* [ Class ] * [ Class ]
* [ Reply-Message ] * [ Reply-Message ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
* [ AVP ] * [ AVP ]
3.8. Abort-Session-Answer (ASA) Command 3.8. Abort-Session-Answer (ASA) Command
The ASA message [I-D.ietf-dime-rfc3588bis] is sent in response to the The ASA message [RFC6733] is sent in response to the ASR. The
ASR. The Result-Code AVP MUST be present and indicates the Result-Code AVP MUST be present and indicates the disposition of the
disposition of the request. request.
If the session identified by Session-Id in the ASR was successfully If the session identified by Session-Id in the ASR was successfully
terminated, Result-Code is set to DIAMETER_SUCCESS. If the session terminated, Result-Code is set to DIAMETER_SUCCESS. If the session
is not currently active, the Result-Code AVP is set to is not currently active, the Result-Code AVP is set to
DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the
session for any other reason, the Result-Code AVP is set to session for any other reason, the Result-Code AVP is set to
DIAMETER_UNABLE_TO_COMPLY. DIAMETER_UNABLE_TO_COMPLY.
Message Format Message Format
skipping to change at page 21, line 27 skipping to change at page 20, line 27
[ Error-Reporting-Host ] [ Error-Reporting-Host ]
* [ Failed-AVP ] * [ Failed-AVP ]
* [ Redirected-Host ] * [ Redirected-Host ]
[ Redirected-Host-Usage ] [ Redirected-Host-Usage ]
[ Redirected-Max-Cache-Time ] [ Redirected-Max-Cache-Time ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ AVP ] * [ AVP ]
3.9. Accounting-Request (ACR) Command 3.9. Accounting-Request (ACR) Command
The ACR message [I-D.ietf-dime-rfc3588bis] is sent by the NAS to The ACR message [RFC6733] is sent by the NAS to report its session
report its session information to a target server downstream. information to a target server downstream.
The Acct-Application-Id AVP MUST be present. The Acct-Application-Id AVP MUST be present.
The AVPs listed in the Base protocol specification The AVPs listed in the Base protocol specification [RFC6733] MUST be
[I-D.ietf-dime-rfc3588bis] MUST be assumed to be present, as assumed to be present, as appropriate. NAS service-specific
appropriate. NAS service-specific accounting AVPs SHOULD be present accounting AVPs SHOULD be present as described in Section 4.6 and the
as described in Section 4.6 and the rest of this specification. rest of this specification.
Message Format Message Format
<AC-Request> ::= < Diameter Header: 271, REQ, PXY > <AC-Request> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id > < Session-Id >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Accounting-Record-Type } { Accounting-Record-Type }
{ Accounting-Record-Number } { Accounting-Record-Number }
skipping to change at page 23, line 25 skipping to change at page 22, line 25
[ Login-LAT-Service ] [ Login-LAT-Service ]
[ Login-Service ] [ Login-Service ]
[ Login-TCP-Port ] [ Login-TCP-Port ]
* [ Tunneling ] * [ Tunneling ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
* [ AVP ] * [ AVP ]
3.10. Accounting-Answer (ACA) Command 3.10. Accounting-Answer (ACA) Command
The ACA message [I-D.ietf-dime-rfc3588bis] is used to acknowledge an The ACA message [RFC6733] is used to acknowledge an Accounting-
Accounting-Request command. The Accounting-Answer command contains Request command. The Accounting-Answer command contains the same
the same Session-Id as the Request. Session-Id as the Request.
Only the target Diameter Server or home Diameter Server SHOULD Only the target Diameter Server or home Diameter Server SHOULD
respond with the Accounting-Answer command. respond with the Accounting-Answer command.
The Acct-Application-Id AVP MUST be present. The Acct-Application-Id AVP MUST be present.
The AVPs listed in the Base protocol specification The AVPs listed in the Base protocol specification [RFC6733] MUST be
[I-D.ietf-dime-rfc3588bis] MUST be assumed to be present, as assumed to be present, as appropriate. NAS service-specific
appropriate. NAS service-specific accounting AVPs SHOULD be present accounting AVPs SHOULD be present as described in Section 4.6 and the
as described in Section 4.6 and the rest of this specification. rest of this specification.
Message Format Message Format
<AC-Answer> ::= < Diameter Header: 271, PXY > <AC-Answer> ::= < Diameter Header: 271, PXY >
< Session-Id > < Session-Id >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Accounting-Record-Type } { Accounting-Record-Type }
{ Accounting-Record-Number } { Accounting-Record-Number }
skipping to change at page 25, line 31 skipping to change at page 24, line 31
QoSFilterRule filters MUST follow the following format: QoSFilterRule filters MUST follow the following format:
action dir proto from src to dst [options] action dir proto from src to dst [options]
where where
action action
tag Mark packet with a specific DSCP [RFC2474] tag Mark packet with a specific DSCP [RFC2474]
meter Meter traffic meter Meter traffic
dir The format is as described under IPFilterRule dir The format is as described under IPFilterRule
[I-D.ietf-dime-rfc3588bis] [RFC6733]
proto The format is as described under IPFilterRule proto The format is as described under IPFilterRule
[I-D.ietf-dime-rfc3588bis] [RFC6733]
src and dst The format is as described under IPFilterRule src and dst The format is as described under IPFilterRule
[I-D.ietf-dime-rfc3588bis] [RFC6733]
The options are described in Section 4.4.9. The options are described in Section 4.4.9.
The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the
ipfw.c code may provide a useful base for implementations. ipfw.c code may provide a useful base for implementations.
4.2. NAS Session AVPs 4.2. NAS Session AVPs
Diameter reserves the AVP Codes 0 - 255 for RADIUS Attributes that Diameter reserves the AVP Codes 0 - 255 for RADIUS Attributes that
are implemented in Diameter. are implemented in Diameter.
4.2.1. Call and Session Information 4.2.1. Call and Session Information
This section describes the AVPs specific to Diameter applications This section describes the AVPs specific to Diameter applications
that are needed to identify the call and session context and status that are needed to identify the call and session context and status
information. On a request, this information allows the server to information. On a request, this information allows the server to
qualify the session. qualify the session.
These AVPs are used in addition to the following AVPs from the base These AVPs are used in addition to the following AVPs from the base
protocol specification [I-D.ietf-dime-rfc3588bis]: protocol specification [RFC6733]:
Session-Id Session-Id
Auth-Application-Id Auth-Application-Id
Origin-Host Origin-Host
Origin-Realm Origin-Realm
Auth-Request-Type Auth-Request-Type
Termination-Cause Termination-Cause
The following table gives the possible flag values for the session The following table gives the possible flag values for the session
level AVPs. level AVPs.
skipping to change at page 26, line 51 skipping to change at page 25, line 51
the user. Note that "port" is meant in its sense as a service the user. Note that "port" is meant in its sense as a service
connection on the NAS, not as an IP protocol identifier. connection on the NAS, not as an IP protocol identifier.
Either the NAS-Port AVP or the NAS-Port-Id AVP (Section 4.2.3) SHOULD Either the NAS-Port AVP or the NAS-Port-Id AVP (Section 4.2.3) SHOULD
be present in the AA-Request (AAR, Section 3.1) command if the NAS be present in the AA-Request (AAR, Section 3.1) command if the NAS
differentiates among its ports. differentiates among its ports.
4.2.3. NAS-Port-Id AVP 4.2.3. NAS-Port-Id AVP
The NAS-Port-Id AVP (AVP Code 87) is of type UTF8String and consists The NAS-Port-Id AVP (AVP Code 87) is of type UTF8String and consists
of ASCII text identifying the port of the NAS authenticating the of 7-bit ASCII text identifying the port of the NAS authenticating
user. Note that "port" is meant in its sense as a service connection the user. Note that "port" is meant in its sense as a service
on the NAS, not as an IP protocol identifier. connection on the NAS, not as an IP protocol identifier.
Either the NAS-Port-Id AVP or the NAS-Port AVP (Section 4.2.2) SHOULD Either the NAS-Port-Id AVP or the NAS-Port AVP (Section 4.2.2) SHOULD
be present in the AA-Request (AAR, Section 3.1) command if the NAS be present in the AA-Request (AAR, Section 3.1) command if the NAS
differentiates among its ports. NAS-Port-Id is intended for use by differentiates among its ports. NAS-Port-Id is intended for use by
NASes that cannot conveniently number their ports. NASes that cannot conveniently number their ports.
4.2.4. NAS-Port-Type AVP 4.2.4. NAS-Port-Type AVP
The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and
contains the type of the port on which the NAS is authenticating the contains the type of the port on which the NAS is authenticating the
user. This AVP SHOULD be present if the NAS uses the same NAS-Port user. This AVP SHOULD be present if the NAS uses the same NAS-Port
number ranges for different service types concurrently. number ranges for different service types concurrently.
The currently supported values of the NAS-Port-Type AVP are listed in The currently supported values of the NAS-Port-Type AVP are listed in
[RADIUSAttrVals]. [RADIUSAttrVals].
4.2.5. Called-Station-Id AVP 4.2.5. Called-Station-Id AVP
The Called-Station-Id AVP (AVP Code 30) is of type UTF8String and The Called-Station-Id AVP (AVP Code 30) is of type UTF8String and
allows the NAS to send the ASCII string describing the Layer 2 allows the NAS to send a 7-bit ASCII string describing the Layer 2
address the user contacted in the request. For dialup access, this address the user contacted in the request. For dialup access, this
can be a phone number obtained by using the Dialed Number can be a phone number obtained by using the Dialed Number
Identification Service (DNIS) or a similar technology. Note that Identification Service (DNIS) or a similar technology. Note that
this may be different from the phone number the call comes in on. this may be different from the phone number the call comes in on.
For use with IEEE 802 access, the Called-Station-Id MAY contain a MAC For use with IEEE 802 access, the Called-Station-Id MAY contain a MAC
address formatted as described in Congdon, et al. [RFC3580]. address formatted as described in Congdon, et al. [RFC3580].
If the Called-Station-Id AVP is present in an AAR message, Auth- If the Called-Station-Id AVP is present in an AAR message, Auth-
Request-Type AVP is set to AUTHORIZE_ONLY and the User-Name AVP is Request-Type AVP is set to AUTHORIZE_ONLY and the User-Name AVP is
absent, the Diameter Server MAY perform authorization based on this absent, the Diameter Server MAY perform authorization based on this
AVP. This can be used by a NAS to request whether a call should be AVP. This can be used by a NAS to request whether a call should be
answered based on the DNIS result. answered based on the DNIS result.
The codification of this field's allowed usage range is outside the Further codification of this field's allowed content and usage is
scope of this specification. outside the scope of this specification.
4.2.6. Calling-Station-Id AVP 4.2.6. Calling-Station-Id AVP
The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String and The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String and
allows the NAS to send the ASCII string describing the Layer 2 allows the NAS to send a 7-bit ASCII string describing the Layer 2
address from which the user connected in the request. For dialup address from which the user connected in the request. For dialup
access, this is the phone number the call came from, using Automatic access, this is the phone number the call came from, using Automatic
Number Identification (ANI) or a similar technology. For use with Number Identification (ANI) or a similar technology. For use with
IEEE 802 access, the Calling-Station-Id AVP MAY contain a MAC IEEE 802 access, the Calling-Station-Id AVP MAY contain a MAC
address, formated as described in RFC 3580. address, formated as described in RFC 3580.
If the Calling-Station-Id AVP is present in an AAR message, the Auth- If the Calling-Station-Id AVP is present in an AAR message, the Auth-
Request-Type AVP is set to AUTHORIZE_ONLY and the User-Name AVP is Request-Type AVP is set to AUTHORIZE_ONLY and the User-Name AVP is
absent, the Diameter Server MAY perform authorization based on the absent, the Diameter Server MAY perform authorization based on the
value of this AVP. This can be used by a NAS to request whether a value of this AVP. This can be used by a NAS to request whether a
call should be answered based on the Layer 2 address (ANI, MAC call should be answered based on the Layer 2 address (ANI, MAC
Address, etc.) Address, etc.)
The codification of this field's allowed usage range is outside the Further codification of this field's allowed content and usage is
scope of this specification. outside the scope of this specification.
4.2.7. Connect-Info AVP 4.2.7. Connect-Info AVP
The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent
in the AA-Request message or an ACR message with the value of the in the AA-Request message or an ACR message with the value of the
Accounting-Record-Type AVP set to STOP. When sent in the AA-Request, Accounting-Record-Type AVP set to STOP. When sent in the AA-Request,
it indicates the nature of the user's connection. The connection it indicates the nature of the user's connection. The connection
speed SHOULD be included at the beginning of the first Connect-Info speed SHOULD be included at the beginning of the first Connect-Info
AVP in the message. If the transmit and receive connection speeds AVP in the message. If the transmit and receive connection speeds
differ, both may be included in the first AVP with the transmit speed differ, both may be included in the first AVP with the transmit speed
skipping to change at page 29, line 26 skipping to change at page 28, line 26
another AA-Request attempt. When used in an AA-Answer message another AA-Request attempt. When used in an AA-Answer message
containing a Result-Code AVP with the value DIAMETER_MULTI_ROUND_AUTH containing a Result-Code AVP with the value DIAMETER_MULTI_ROUND_AUTH
or in an Re-Auth-Request message, it MAY contain text to prompt the or in an Re-Auth-Request message, it MAY contain text to prompt the
user for a response. user for a response.
4.3. NAS Authentication AVPs 4.3. NAS Authentication AVPs
This section defines the AVPs necessary to carry the authentication This section defines the AVPs necessary to carry the authentication
information in the Diameter protocol. The functionality defined here information in the Diameter protocol. The functionality defined here
provides a RADIUS-like AAA service [RFC2865] over a more reliable and provides a RADIUS-like AAA service [RFC2865] over a more reliable and
secure transport, as defined in the base protocol secure transport, as defined in the base protocol [RFC6733].
[I-D.ietf-dime-rfc3588bis].
The following table gives the possible flag values for the session The following table gives the possible flag values for the session
level AVPs. level AVPs.
+----------+ +----------+
| AVP Flag | | AVP Flag |
| rules | | rules |
|----+-----| |----+-----|
|MUST| MUST| |MUST| MUST|
Attribute Name Section Defined | | NOT| Attribute Name Section Defined | | NOT|
skipping to change at page 30, line 13 skipping to change at page 29, line 13
-----------------------------------------|----+-----| -----------------------------------------|----+-----|
4.3.1. User-Password AVP 4.3.1. User-Password AVP
The User-Password AVP (AVP Code 2) is of type OctetString and The User-Password AVP (AVP Code 2) is of type OctetString and
contains the password of the user to be authenticated, or the user's contains the password of the user to be authenticated, or the user's
input in a multi-round authentication exchange. input in a multi-round authentication exchange.
The User-Password AVP contains a user password or one-time password The User-Password AVP contains a user password or one-time password
and therefore represents sensitive information. As required by and therefore represents sensitive information. As required by
Fajardo, et al. [I-D.ietf-dime-rfc3588bis], Diameter messages are Fajardo, et al. [RFC6733], Diameter messages are encrypted by using
encrypted by using IPsec [RFC4301] or TLS [RFC5246]. Unless this AVP IPsec [RFC4301] or TLS [RFC5246]. Unless this AVP is used for one-
is used for one-time passwords, the User-Password AVP SHOULD NOT be time passwords, the User-Password AVP SHOULD NOT be used in untrusted
used in untrusted proxy environments without encrypting it by using proxy environments without encrypting it by using end-to-end security
end-to-end security techniques. techniques.
The clear-text password (prior to encryption) MUST NOT be longer than The clear-text password (prior to encryption) MUST NOT be longer than
128 bytes in length. 128 bytes in length.
4.3.2. Password-Retry AVP 4.3.2. Password-Retry AVP
The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be
included in the AA-Answer if the Result-Code indicates an included in the AA-Answer if the Result-Code indicates an
authentication failure. The value of this AVP indicates how many authentication failure. The value of this AVP indicates how many
authentication attempts a user is permitted before being authentication attempts a user is permitted before being
skipping to change at page 32, line 18 skipping to change at page 31, line 18
DES encryption on this value with the authenticating user's password DES encryption on this value with the authenticating user's password
as the key. If the user's password is fewer than 8 octets in length, as the key. If the user's password is fewer than 8 octets in length,
the password is padded at the end with NULL octets to a length of 8 the password is padded at the end with NULL octets to a length of 8
before it is used as a key. before it is used as a key.
4.3.11. ARAP-Security AVP 4.3.11. ARAP-Security AVP
The ARAP-Security AVP (AVP Code 73) is of type Unsigned32 and MAY be The ARAP-Security AVP (AVP Code 73) is of type Unsigned32 and MAY be
present in the AA-Answer message if the Framed-Protocol AVP present in the AA-Answer message if the Framed-Protocol AVP
(Section 4.4.10.1) is set to the value of ARAP, and the Result-Code (Section 4.4.10.1) is set to the value of ARAP, and the Result-Code
AVP ([I-D.ietf-dime-rfc3588bis], Section 7.1) is set to AVP ([RFC6733], Section 7.1) is set to DIAMETER_MULTI_ROUND_AUTH.
DIAMETER_MULTI_ROUND_AUTH. See RFC 2869 for more information on the See RFC 2869 for more information on the contents of this AVP.
contents of this AVP.
4.3.12. ARAP-Security-Data AVP 4.3.12. ARAP-Security-Data AVP
The ARAP-Security-Data AVP (AVP Code 74) is of type OctetString and The ARAP-Security-Data AVP (AVP Code 74) is of type OctetString and
MAY be present in the AA-Request or AA-Answer message if the Framed- MAY be present in the AA-Request or AA-Answer message if the Framed-
Protocol AVP (Section 4.4.10.1) is set to the value of ARAP and the Protocol AVP (Section 4.4.10.1) is set to the value of ARAP and the
Result-Code AVP ([I-D.ietf-dime-rfc3588bis], Section 7.1) is set to Result-Code AVP ([RFC6733], Section 7.1) is set to
DIAMETER_MULTI_ROUND_AUTH. This AVP contains the security module DIAMETER_MULTI_ROUND_AUTH. This AVP contains the security module
challenge or response associated with the ARAP Security Module challenge or response associated with the ARAP Security Module
specified in the ARAP-Security AVP (Section 4.3.11). specified in the ARAP-Security AVP (Section 4.3.11).
4.4. NAS Authorization AVPs 4.4. NAS Authorization AVPs
This section contains the authorization AVPs supported in the NAS This section contains the authorization AVPs supported in the NAS
Application. The Service-Type AVP SHOULD be present in all messages Application. The Service-Type AVP SHOULD be present in all messages
and, based on its value, additional AVPs defined in this section and and, based on its value, additional AVPs defined in this section and
Section 4.5 MAY be present. Section 4.5 MAY be present.
skipping to change at page 35, line 48 skipping to change at page 34, line 48
4.4.6. NAS-Filter-Rule AVP 4.4.6. NAS-Filter-Rule AVP
The NAS-Filter-Rule AVP (AVP Code 400) is of type IPFilterRule and The NAS-Filter-Rule AVP (AVP Code 400) is of type IPFilterRule and
provides filter rules that need to be configured on the NAS for the provides filter rules that need to be configured on the NAS for the
user. One or more of these AVPs MAY be present in an authorization user. One or more of these AVPs MAY be present in an authorization
response. response.
4.4.7. Filter-Id AVP 4.4.7. Filter-Id AVP
The Filter-Id AVP (AVP Code 11) is of type UTF8String and contains The Filter-Id AVP (AVP Code 11) is of type UTF8String and contains
the name of the filter list for this user. Zero or more Filter-Id the name of the filter list for this user. It is intended to be
AVPs MAY be sent in an authorization answer. human-readable. Zero or more Filter-Id AVPs MAY be sent in an
authorization answer message.
Identifying a filter list by name allows the filter to be used on Identifying a filter list by name allows the filter to be used on
different NASes without regard to filter-list implementation details. different NASes without regard to filter-list implementation details.
However, this AVP is not roaming-friendly, as filter naming differs However, this AVP is not roaming-friendly, as filter naming differs
from one service provider to another. from one service provider to another.
In environments where backward compatibility with RADIUS is not In environments where backward compatibility with RADIUS is not
required, it is RECOMMENDED that the NAS-Filter-Rule AVP required, it is RECOMMENDED that the NAS-Filter-Rule AVP
(Section 4.4.6) be used instead. (Section 4.4.6) be used instead.
skipping to change at page 38, line 38 skipping to change at page 37, line 38
contains the four octets of the IPv4 netmask to be configured for the contains the four octets of the IPv4 netmask to be configured for the
user when the user is a router to a network. It MAY be used in an user when the user is a router to a network. It MAY be used in an
authorization request as a hint to the server that a specific netmask authorization request as a hint to the server that a specific netmask
is desired, but the server is not required to honor the hint in the is desired, but the server is not required to honor the hint in the
corresponding response. This AVP MUST be present in a response if corresponding response. This AVP MUST be present in a response if
the request included this AVP with a value of 0xFFFFFFFF. the request included this AVP with a value of 0xFFFFFFFF.
4.4.10.5.3. Framed-Route AVP 4.4.10.5.3. Framed-Route AVP
The Framed-Route AVP (AVP Code 22) is of type UTF8String and contains The Framed-Route AVP (AVP Code 22) is of type UTF8String and contains
the ASCII routing information to be configured for the user on the the 7-bit ASCII routing information to be configured for the user on
NAS. Zero or more of these AVPs MAY be present in an authorization the NAS. Zero or more of these AVPs MAY be present in an
response. authorization response.
The string MUST contain a destination prefix in dotted quad form The string MUST contain a destination prefix in dotted quad form
optionally followed by a slash and a decimal length specifier stating optionally followed by a slash and a decimal length specifier stating
how many high-order bits of the prefix should be used. This is how many high-order bits of the prefix should be used. This is
followed by a space, a gateway address in dotted quad form, a space, followed by a space, a gateway address in dotted quad form, a space,
and one or more metrics separated by spaces; for example, and one or more metrics separated by spaces; for example,
"192.0.2.0/24 192.0.2.1 1" "192.0.2.0/24 192.0.2.1 1"
The length specifier may be omitted, in which case it should default The length specifier may be omitted, in which case it should default
skipping to change at page 47, line 36 skipping to change at page 46, line 36
4.5.4. Tunnel-Client-Endpoint AVP 4.5.4. Tunnel-Client-Endpoint AVP
The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type UTF8String The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type UTF8String
and contains the address of the initiator end of the tunnel. It MAY and contains the address of the initiator end of the tunnel. It MAY
be used in an authorization request as a hint to the server that a be used in an authorization request as a hint to the server that a
specific endpoint is desired, but the server is not required to honor specific endpoint is desired, but the server is not required to honor
the hint in the corresponding response. This AVP SHOULD be included the hint in the corresponding response. This AVP SHOULD be included
in the corresponding ACR messages, in which case it indicates the in the corresponding ACR messages, in which case it indicates the
address from which the tunnel was initiated. This AVP, along with address from which the tunnel was initiated. This AVP, along with
the Tunnel-Server-Endpoint (Section 4.5.5) and Session-Id AVPs the Tunnel-Server-Endpoint (Section 4.5.5) and Session-Id AVPs
([I-D.ietf-dime-rfc3588bis], Section 8.8), can be used to provide a ([RFC6733], Section 8.8), can be used to provide a globally unique
globally unique means to identify a tunnel for accounting and means to identify a tunnel for accounting and auditingpurposes.
auditingpurposes.
If the value of the Tunnel-Medium-Type AVP (Section 4.5.3) is IPv4 If the value of the Tunnel-Medium-Type AVP (Section 4.5.3) is IPv4
(1), then this string is either the fully qualified domain name (1), then this string is either the fully qualified domain name
(FQDN) of the tunnel client machine, or a "dotted-decimal" IP (FQDN) of the tunnel client machine, or a "dotted-decimal" IP
address. Implementations MUST support the dotted-decimal format and address. Implementations MUST support the dotted-decimal format and
SHOULD support the FQDN format for IP addresses. SHOULD support the FQDN format for IP addresses.
If Tunnel-Medium-Type is IPv6 (2), then this string is either the If Tunnel-Medium-Type is IPv6 (2), then this string is either the
FQDN of the tunnel client machine, or a text representation of the FQDN of the tunnel client machine, or a text representation of the
address in either the preferred or alternate form [RFC3516]. address in either the preferred or alternate form [RFC3516].
Conforming implementations MUST support the preferred form and SHOULD Conforming implementations MUST support the preferred form and SHOULD
support both the alternate text form and the FQDN format for IPv6 support both the alternate text form and the FQDN format for IPv6
addresses. addresses.
If Tunnel-Medium-Type is neither IPv4 nor IPv6, then this string is a If Tunnel-Medium-Type is neither IPv4 nor IPv6, then this string is a
tag referring to configuration data local to the Diameter client that tag referring to configuration data local to the Diameter client that
describes the interface or medium-specific client address to use. describes the interface or medium-specific client address to use.
Note that this application handles internationalized domain names in
the same way as the Diameter base protocol (see Appendix D of RFC
6733 for details).
4.5.5. Tunnel-Server-Endpoint AVP 4.5.5. Tunnel-Server-Endpoint AVP
The Tunnel-Server-Endpoint AVP (AVP Code 67) is of type UTF8String The Tunnel-Server-Endpoint AVP (AVP Code 67) is of type UTF8String
and contains the address of the server end of the tunnel. It MAY be and contains the address of the server end of the tunnel. It MAY be
used in an authorization request as a hint to the server that a used in an authorization request as a hint to the server that a
specific endpoint is desired, but the server is not required to honor specific endpoint is desired, but the server is not required to honor
the hint in the corresponding response. the hint in the corresponding response.
This AVP SHOULD be included in the corresponding ACR messages, in This AVP SHOULD be included in the corresponding ACR messages, in
which case it indicates the address from which the tunnel was which case it indicates the address from which the tunnel was
initiated. This AVP, along with the Tunnel-Client-Endpoint initiated. This AVP, along with the Tunnel-Client-Endpoint
(Section 4.5.4) and Session-Id AVP ([I-D.ietf-dime-rfc3588bis], (Section 4.5.4) and Session-Id AVP ([RFC6733], Section 8.8), can be
Section 8.8), can be used to provide a globally unique means to used to provide a globally unique means to identify a tunnel for
identify a tunnel for accounting and auditing purposes. accounting and auditing purposes.
If Tunnel-Medium-Type is IPv4 (1), then this string is either the If Tunnel-Medium-Type is IPv4 (1), then this string is either the
fully qualified domain name (FQDN) of the tunnel server machine, or a fully qualified domain name (FQDN) of the tunnel server machine, or a
"dotted-decimal" IP address. Implementations MUST support the "dotted-decimal" IP address. Implementations MUST support the
dotted-decimal format and SHOULD support the FQDN format for IP dotted-decimal format and SHOULD support the FQDN format for IP
addresses. addresses.
If Tunnel-Medium-Type is IPv6 (2), then this string is either the If Tunnel-Medium-Type is IPv6 (2), then this string is either the
FQDN of the tunnel server machine, or a text representation of the FQDN of the tunnel server machine, or a text representation of the
address in either the preferred or alternate form [RFC3516]. address in either the preferred or alternate form [RFC3516].
Implementations MUST support the preferred form and SHOULD support Implementations MUST support the preferred form and SHOULD support
both the alternate text form and the FQDN format for IPv6 addresses. both the alternate text form and the FQDN format for IPv6 addresses.
If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag
referring to configuration data local to the Diameter client that referring to configuration data local to the Diameter client that
describes the interface or medium-specific server address to use. describes the interface or medium-specific server address to use.
Note that this application handles internationalized domain names in
the same way as the Diameter base protocol (see Appendix D of RFC
6733 for details).
4.5.6. Tunnel-Password AVP 4.5.6. Tunnel-Password AVP
The Tunnel-Password AVP (AVP Code 69) is of type OctetString and may The Tunnel-Password AVP (AVP Code 69) is of type OctetString and may
contain a password to be used to authenticate to a remote server. contain a password to be used to authenticate to a remote server.
The Tunnel-Password AVP SHOULD NOT be used in untrusted proxy The Tunnel-Password AVP SHOULD NOT be used in untrusted proxy
environments without encrypting it by using end-to-end security environments without encrypting it by using end-to-end security
techniques. techniques.
4.5.7. Tunnel-Private-Group-Id AVP 4.5.7. Tunnel-Private-Group-Id AVP
skipping to change at page 51, line 32 skipping to change at page 50, line 37
authorization request as a hint to the server that a specific authorization request as a hint to the server that a specific
preference is desired, but the server is not required to honor the preference is desired, but the server is not required to honor the
hint in the corresponding response. This AVP MUST be present in the hint in the corresponding response. This AVP MUST be present in the
authorization response if an authentication name other than the authorization response if an authentication name other than the
default is desired. This AVP SHOULD be included in the ACR messages default is desired. This AVP SHOULD be included in the ACR messages
pertaining to the tunneled session. pertaining to the tunneled session.
4.6. NAS Accounting AVPs 4.6. NAS Accounting AVPs
Applications implementing this specification use Diameter Accounting Applications implementing this specification use Diameter Accounting
(as defined in [I-D.ietf-dime-rfc3588bis]) and the AVPs in the (as defined in [RFC6733]) and the AVPs in the following section.
following section. Service-specific AVP usage is defined in the Service-specific AVP usage is defined in the tables in Section 5.
tables in Section 5.
If accounting is active, Accounting Request (ACR) messages SHOULD be If accounting is active, Accounting Request (ACR) messages SHOULD be
sent after the completion of any Authentication or Authorization sent after the completion of any Authentication or Authorization
transaction and at the end of a Session. The value of the transaction and at the end of a Session. The value of the
Accounting-Record-Type AVP [I-D.ietf-dime-rfc3588bis] indicates the Accounting-Record-Type AVP [RFC6733] indicates the type of event.
type of event. All other AVPs identify the session and provide All other AVPs identify the session and provide additional
additional information relevant to the event. information relevant to the event.
The successful completion of the first Authentication or The successful completion of the first Authentication or
Authorization transaction SHOULD cause a START_RECORD to be sent. If Authorization transaction SHOULD cause a START_RECORD to be sent. If
additional Authentications or Authorizations occur in later additional Authentications or Authorizations occur in later
transactions, the first exchange should generate a START_RECORD, and transactions, the first exchange should generate a START_RECORD, and
the later an INTERIM_RECORD. For a given session, there MUST only be the later an INTERIM_RECORD. For a given session, there MUST only be
one set of matching START and STOP records, with any number of one set of matching START and STOP records, with any number of
INTERIM_RECORDS in between, or one EVENT_RECORD indicating the reason INTERIM_RECORDS in between, or one EVENT_RECORD indicating the reason
a session wasn't started. a session wasn't started.
skipping to change at page 52, line 33 skipping to change at page 51, line 38
Acct-Tunnel-Packets-Lost 4.6.11 | M | V | Acct-Tunnel-Packets-Lost 4.6.11 | M | V |
-----------------------------------------|----+-----| -----------------------------------------|----+-----|
4.6.1. Accounting-Input-Octets AVP 4.6.1. Accounting-Input-Octets AVP
The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64 The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64
and contains the number of octets received from the user. and contains the number of octets received from the user.
For NAS usage, this AVP indicates how many octets have been received For NAS usage, this AVP indicates how many octets have been received
from the port in the course of this session. It can only be present from the port in the course of this session. It can only be present
in ACR messages with an Accounting-Record-Type in ACR messages with an Accounting-Record-Type [RFC6733] of
[I-D.ietf-dime-rfc3588bis] of INTERIM_RECORD or STOP_RECORD. INTERIM_RECORD or STOP_RECORD.
4.6.2. Accounting-Output-Octets AVP 4.6.2. Accounting-Output-Octets AVP
The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64 The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64
and contains the number of octets sent to the user. and contains the number of octets sent to the user.
For NAS usage, this AVP indicates how many octets have been sent to For NAS usage, this AVP indicates how many octets have been sent to
the port in the course of this session. It can only be present in the port in the course of this session. It can only be present in
ACR messages with an Accounting-Record-Type of INTERIM_RECORD or ACR messages with an Accounting-Record-Type of INTERIM_RECORD or
STOP_RECORD. STOP_RECORD.
skipping to change at page 55, line 22 skipping to change at page 54, line 29
4.6.11. Acct-Tunnel-Packets-Lost AVP 4.6.11. Acct-Tunnel-Packets-Lost AVP
The Acct-Tunnel-Packets-Lost AVP (AVP Code 86) is of type Unsigned32 The Acct-Tunnel-Packets-Lost AVP (AVP Code 86) is of type Unsigned32
and contains the number of packets lost on a given tunnel. and contains the number of packets lost on a given tunnel.
5. AVP Occurrence Tables 5. AVP Occurrence Tables
The following tables present the AVPs used by NAS applications in NAS The following tables present the AVPs used by NAS applications in NAS
messages and specify in which Diameter messages they may or may not messages and specify in which Diameter messages they may or may not
be present. Messages and AVPs defined in the base Diameter protocol be present. Messages and AVPs defined in the base Diameter protocol
[I-D.ietf-dime-rfc3588bis] are not described in this document. Note [RFC6733] are not described in this document. Note that AVPs that
that AVPs that can only be present within a Grouped AVP are not can only be present within a Grouped AVP are not represented in this
represented in this table. table.
The tables use the following symbols: The tables use the following symbols:
0 The AVP MUST NOT be present in the message. 0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the 0+ Zero or more instances of the AVP MAY be present in the
message. message.
0-1 Zero or one instance of the AVP MAY be present in the 0-1 Zero or one instance of the AVP MAY be present in the
message. message.
1 Exactly one instance of the AVP MUST be present in the 1 Exactly one instance of the AVP MUST be present in the
message. message.
skipping to change at page 58, line 47 skipping to change at page 57, line 47
Tunneling | 0+ | 0+ | Tunneling | 0+ | 0+ |
User-Name | 0-1 | 0-1 | User-Name | 0-1 | 0-1 |
User-Password | 0-1 | 0 | User-Password | 0-1 | 0 |
------------------------------|-----+-----+ ------------------------------|-----+-----+
5.2. Accounting AVP Tables 5.2. Accounting AVP Tables
The tables in this section are used to show which AVPs defined in The tables in this section are used to show which AVPs defined in
this document are to be present and used in NAS application this document are to be present and used in NAS application
Accounting messages. These AVPs are defined in this document, as Accounting messages. These AVPs are defined in this document, as
well as in [I-D.ietf-dime-rfc3588bis] and [RFC2866]. well as in [RFC6733] and [RFC2866].
5.2.1. Framed Access Accounting AVP Table 5.2.1. Framed Access Accounting AVP Table
The table in this section is used when the Service-Type AVP The table in this section is used when the Service-Type AVP
(Section 4.4.1) specifies Framed Access. (Section 4.4.1) specifies Framed Access.
+-----------+ +-----------+
| Command | | Command |
|-----+-----+ |-----+-----+
Attribute Name | ACR | ACA | Attribute Name | ACR | ACA |
skipping to change at page 63, line 8 skipping to change at page 62, line 8
in the "Application IDs" sub-registry of the "Authentication, in the "Application IDs" sub-registry of the "Authentication,
Authorization, and Accounting (AAA) Parameters" registry to point to Authorization, and Accounting (AAA) Parameters" registry to point to
this document, as well. this document, as well.
RFC Editor: Please remove both this note and the IANA note above RFC Editor: Please remove both this note and the IANA note above
before publication. before publication.
7. Security Considerations 7. Security Considerations
This document describes the extension of Diameter for the NAS This document describes the extension of Diameter for the NAS
application. The security considerations of the Diameter protocol application. Security considerations regarding the Diameter protocol
itself are discussed in [I-D.ietf-dime-rfc3588bis]. Use of this itself are discussed in [RFC6733]. Use of this application of
application of Diameter MUST take into consideration the security Diameter MUST take into consideration the security issues and
issues and requirements of the Base protocol. requirements of the Base protocol.
The use of the User-Password (Section 4.3.1) and Tunnel-Password 7.1. Authentication Considerations
(Section 4.5.6) AVPs is not safe in the absence of end-to-end
security; however, end-to-end security for the Diameter protocol is
outside the scope of this document.
This document does not contain a security protocol but does discuss This document does not contain a security protocol but does discuss
how PPP authentication protocols can be carried within the Diameter how PPP authentication protocols can be carried within the Diameter
protocol. The PPP authentication protocols described are PAP and protocol. The PPP authentication protocols described are PAP and
CHAP. CHAP.
The use of PAP SHOULD be discouraged, as it exposes users' passwords The use of PAP SHOULD be discouraged, as it exposes users' passwords
to possibly non-trusted entities. However, PAP is also frequently to possibly non-trusted entities. However, PAP is also frequently
used for use with One-Time Passwords, which do not expose a security used for use with One-Time Passwords, which do not expose a security
risk. risk.
This document also describes how CHAP can be carried within the This document also describes how CHAP can be carried within the
Diameter protocol, which is required for RADIUS backward Diameter protocol, which is required for RADIUS backward
compatibility. The CHAP protocol, as used in a RADIUS environment, compatibility. The CHAP protocol, as used in a RADIUS environment,
facilitates authentication replay attacks. facilitates authentication replay attacks.
The use of the EAP authentication protocols [RFC4072] can offer The use of the EAP authentication protocols [RFC4072] can offer
better security, given a method suitable for the circumstances. better security, given a method suitable for the circumstances.
7.2. AVP Considerations
Diameter AVPs often contain security-sensitive data; for example,
user passwords and location data, network addresses and cryptographic
keys. With the exception of the Configuration-Token (Section 4.4.8),
QoS-Filter-Rule (Section 4.4.9) and Tunneling (Section 4.5.1) AVPs,
all of the AVPs defined in this document are considered to be
security-sensitive.
Diameter messages containing any AVPs considered to be security-
sensitive MUST only be sent protected via mutually authenticated TLS
or IPsec. In addition, those messages MUST NOT be sent via
intermediate nodes unless there is end-to-end security between the
originator and recipient or the originator has locally trusted
configuration that indicates that end-to-end security is not needed.
For example, end-to-end security may not be required in the case
where an intermediary node is known to be operated as part of the
same administrative domain as the endpoints so that an ability to
successfully compromise the intermediary would imply a high
probability of being able to compromise the endpoints as well. Note
that no end-to-end security mechanism is specified in this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ANITypes] NANPA Number Resource Info, "ANI [ANITypes] NANPA Number Resource Info, "ANI Assignments", <ht
Assignments", <http://www.nanpa.com/ tp://www.nanpa.com/number_resource_info/
number_resource_info/ ani_ii_assignments.html>.
ani_ii_assignments.html>.
[I-D.ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, J., and [RFC1994] Simpson, W., "PPP Challenge Handshake
G. Zorn, "Diameter Base Protocol", Authentication Protocol (CHAP)", RFC 1994,
draft-ietf-dime-rfc3588bis-34 (work in August 1996.
progress), June 2012.
[RFC1994] Simpson, W., "PPP Challenge Handshake [RFC2119] Bradner, S., "Key words for use in RFCs to
Authentication Protocol (CHAP)", Indicate Requirement Levels", BCP 14, RFC 2119,
RFC 1994, August 1996. March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC2865] Rigney, C., Willens, S., Rubens, A., and W.
to Indicate Requirement Levels", BCP 14, Simpson, "Remote Authentication Dial In User
RFC 2119, March 1997. Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and
W. Simpson, "Remote Authentication Dial IPv6", RFC 3162, August 2001.
In User Service (RADIUS)", RFC 2865,
June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension",
"RADIUS and IPv6", RFC 3162, August 2001. RFC 3516, April 2003.
[RFC3516] Nerenberg, L., "IMAP4 Binary Content [RFC3539] Aboba, B. and J. Wood, "Authentication,
Extension", RFC 3516, April 2003. Authorization and Accounting (AAA) Transport
Profile", RFC 3539, June 2003.
[RFC3539] Aboba, B. and J. Wood, "Authentication, [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M.,
Authorization and Accounting (AAA) Jones, M., and A. Lior, "Traffic Classification
Transport Profile", RFC 3539, June 2003. and Quality of Service (QoS) Attributes for
Diameter", RFC 5777, February 2010.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
8.2. Informative References 8.2. Informative References
[ARAP] Apple Computer, "Apple Remote Access [ARAP] Apple Computer, "Apple Remote Access Protocol
Protocol (ARAP) Version 2.0 External (ARAP) Version 2.0 External Reference
Reference Specification", R0612LL/B , Specification", R0612LL/B , September 1994.
September 1994.
[AVP-Codes] "IANA AAA AVP Codes Registry", <http:// [AVP-Codes] "IANA AAA AVP Codes Registry", <http://
www.iana.org/assignments/aaa-parameters/ www.iana.org/assignments/aaa-parameters/
aaa-parameters.xml#aaa-parameters-1>. aaa-parameters.xml#aaa-parameters-1>.
[AVP-Vals] "IANA AAA AVP Specific Values", <http:// [AVP-Vals] "IANA AAA AVP Specific Values", <http://
www.iana.org/assignments/aaa-parameters/ www.iana.org/assignments/aaa-parameters/
aaa-parameters.xml#aaa-parameters-2>. aaa-parameters.xml#aaa-parameters-2>.
[App-Ids] "IANA AAA Application IDs Registry", <htt [App-Ids] "IANA AAA Application IDs Registry", <http://
p://www.iana.org/assignments/ www.iana.org/assignments/aaa-parameters/
aaa-parameters/ aaa-parameters.xml#aaa-parameters-1>.
aaa-parameters.xml#aaa-parameters-1>.
[AppleTalk] Sidhu, G., Andrews, R., and A. [AppleTalk] Sidhu, G., Andrews, R., and A. Oppenheimer,
Oppenheimer, "Inside AppleTalk", Second "Inside AppleTalk", Second Edition Apple Computer,
Edition Apple Computer, 1990. 1990.
[Command-Codes] "IANA AAA Command Codes Registry", <http: [BASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G.,
//www.iana.org/assignments/ and J. Arkko, "Diameter Base Protocol", RFC 3588,
aaa-parameters/ September 2003.
aaa-parameters.xml#command-code-rules>.
[IANA] "Internet Assigned Numbers Authority", [Command-Codes] "IANA AAA Command Codes Registry", <http://
<http://www.iana.org/>. www.iana.org/assignments/aaa-parameters/
aaa-parameters.xml#command-code-rules>.
[IPX] Novell, Inc., "NetWare System Technical [IANA] "Internet Assigned Numbers Authority",
Interface Overview", #883-000780-001, <http://www.iana.org/>.
June 1989.
[ISO.8859-1.1987] International Organization for [IPX] Novell, Inc., "NetWare System Technical Interface
Standardization, "Information technology Overview", #883-000780-001, June 1989.
- 8-bit single byte coded graphic -
character sets - Part 1: Latin alphabet
No. 1, JTC1/SC2", ISO Standard 8859-1,
1987.
[LAT] Digital Equipment Corp., "Local Area [ISO.8859-1.1987] International Organization for Standardization,
Transport (LAT) Specification V5.0", AA- "Information technology - 8-bit single byte coded
NL26A-TE, June 1989. graphic - character sets - Part 1: Latin alphabet
No. 1, JTC1/SC2", ISO Standard 8859-1, 1987.
[RADIUSAttrVals] IANA, "IANA Radius Attribute Values [LAT] Digital Equipment Corp., "Local Area Transport
Registry", <http://www.iana.org/ (LAT) Specification V5.0", AA-NL26A-TE,
assignments/radius-types/ June 1989.
radius-types.xml#radius-types-3>.
[RFC1334] Lloyd, B. and W. Simpson, "PPP [RADIUSAttrVals] IANA, "IANA Radius Attribute Values Registry", <ht
Authentication Protocols", RFC 1334, tp://www.iana.org/assignments/radius-types/
October 1992. radius-types.xml#radius-types-3>.
[RFC1661] Simpson, W., "The Point-to-Point Protocol [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication
(PPP)", STD 51, RFC 1661, July 1994. Protocols", RFC 1334, October 1992.
[RFC1990] Sklower, K., Lloyd, B., McGregor, G., [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)",
Carr, D., and T. Coradetti, "The PPP STD 51, RFC 1661, July 1994.
Multilink Protocol (MP)", RFC 1990,
August 1996.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D.,
Black, "Definition of the Differentiated and T. Coradetti, "The PPP Multilink Protocol
Services Field (DS Field) in the IPv4 and (MP)", RFC 1990, August 1996.
IPv6 Headers", RFC 2474, December 1998.
[RFC2548] Zorn, G., "Microsoft Vendor-specific [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
RADIUS Attributes", RFC 2548, March 1999. "Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
J. Wroclawski, "Assured Forwarding PHB Attributes", RFC 2548, March 1999.
Group", RFC 2597, June 1999.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J.
Taarud, J., Little, W., and G. Zorn, Wroclawski, "Assured Forwarding PHB Group",
"Point-to-Point Tunneling Protocol", RFC 2597, June 1999.
RFC 2637, July 1999.
[RFC2866] Rigney, C., "RADIUS Accounting", [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J.,
RFC 2866, June 2000. Little, W., and G. Zorn, "Point-to-Point Tunneling
Protocol", RFC 2637, July 1999.
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
"RADIUS Accounting Modifications for June 2000.
Tunnel Protocol Support", RFC 2867,
June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS
Shriver, J., Holdrege, M., and I. Goyret, Accounting Modifications for Tunnel Protocol
"RADIUS Attributes for Tunnel Protocol Support", RFC 2867, June 2000.
Support", RFC 2868, June 2000.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
"RADIUS Extensions", RFC 2869, June 2000. Holdrege, M., and I. Goyret, "RADIUS Attributes
for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2881] Mitton, D. and M. Beadles, "Network [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
Access Server Requirements Next Extensions", RFC 2869, June 2000.
Generation (NASREQNG) NAS Model",
RFC 2881, July 2000.
[RFC2989] Aboba, B., Calhoun, P., Glass, S., [RFC2881] Mitton, D. and M. Beadles, "Network Access Server
Hiller, T., McCann, P., Shiino, H., Requirements Next Generation (NASREQNG) NAS
Walsh, P., Zorn, G., Dommety, G., Model", RFC 2881, July 2000.
Perkins, C., Patil, B., Mitton, D.,
Manning, S., Beadles, M., Chen, X.,
Sivalingham, S., Hameed, A., Munson, M.,
Jacobs, S., Lim, B., Hirschman, B., Hsu,
R., Koo, H., Lipford, M., Campbell, E.,
Xu, Y., Baba, S., and E. Jaques,
"Criteria for Evaluating AAA Protocols
for Network Access", RFC 2989,
November 2000.
[RFC3169] Beadles, M. and D. Mitton, "Criteria for [RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T.,
Evaluating Network Access Server McCann, P., Shiino, H., Walsh, P., Zorn, G.,
Protocols", RFC 3169, September 2001. Dommety, G., Perkins, C., Patil, B., Mitton, D.,
Manning, S., Beadles, M., Chen, X., Sivalingham,
S., Hameed, A., Munson, M., Jacobs, S., Lim, B.,
Hirschman, B., Hsu, R., Koo, H., Lipford, M.,
Campbell, E., Xu, Y., Baba, S., and E. Jaques,
"Criteria for Evaluating AAA Protocols for Network
Access", RFC 2989, November 2000.
[RFC3246] Davie, B., Charny, A., Bennet, J., [RFC3169] Beadles, M. and D. Mitton, "Criteria for
Benson, K., Le Boudec, J., Courtney, W., Evaluating Network Access Server Protocols",
Davari, S., Firoiu, V., and D. Stiliadis, RFC 3169, September 2001.
"An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le
G., and J. Roese, "IEEE 802.1X Remote Boudec, J., Courtney, W., Davari, S., Firoiu, V.,
Authentication Dial In User Service and D. Stiliadis, "An Expedited Forwarding PHB
(RADIUS) Usage Guidelines", RFC 3580, (Per-Hop Behavior)", RFC 3246, March 2002.
September 2003.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and
"Layer Two Tunneling Protocol - Version 3 J. Roese, "IEEE 802.1X Remote Authentication Dial
(L2TPv3)", RFC 3931, March 2005. In User Service (RADIUS) Usage Guidelines",
RFC 3580, September 2003.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two
"Diameter Extensible Authentication Tunneling Protocol - Version 3 (L2TPv3)",
Protocol (EAP) Application", RFC 4072, RFC 3931, March 2005.
August 2005.
[RFC4301] Kent, S. and K. Seo, "Security [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter
Architecture for the Internet Protocol", Extensible Authentication Protocol (EAP)
RFC 4301, December 2005. Application", RFC 4072, August 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The [RFC4301] Kent, S. and K. Seo, "Security Architecture for
Transport Layer Security (TLS) Protocol the Internet Protocol", RFC 4301, December 2005.
Version 1.2", RFC 5246, August 2008.
[RFC5777] Korhonen, J., Tschofenig, H., [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Arumaithurai, M., Jones, M., and A. Lior, Security (TLS) Protocol Version 1.2", RFC 5246,
"Traffic Classification and Quality of August 2008.
Service (QoS) Attributes for Diameter",
RFC 5777, February 2010.
Appendix A. Acknowledgements Appendix A. Acknowledgements
A.1. RFC 4005 A.1. This Document
The vast majority of the text in this document was taken directly
from RFC 4005; the editor owes a debt of gratitude to the authors
thereof (especially Dave Mitton, who somehow managed to make nroff
paginate the AVP Occurance Tables correctly!).
Thanks (in no particular order) to Jai-Jin Lim, Liu Hans, Sebastien
Decugis, Jouni Korhonen, Mark Jones, Hannes Tschofenig, Dave Crocker,
David Black, Barry Leiba, Peter Saint-Andre and Stefan Winter for
their useful reviews and helpful comments.
A.2. RFC 4005
The authors would like to thank Carl Rigney, Allan C. Rubens, William The authors would like to thank Carl Rigney, Allan C. Rubens, William
Allen Simpson, and Steve Willens for their work on the original Allen Simpson, and Steve Willens for their work on the original
RADIUS protocol, from which many of the concepts in this RADIUS protocol, from which many of the concepts in this
specification were derived. Thanks, also, to Carl Rigney for specification were derived. Thanks, also, to Carl Rigney for
[RFC2866] and [RFC2869]; Ward Willats for [RFC2869]; Glen Zorn, [RFC2866] and [RFC2869]; Ward Willats for [RFC2869]; Glen Zorn,
Bernard Aboba, and Dave Mitton for [RFC2867] and [RFC3162]; and Dory Bernard Aboba, and Dave Mitton for [RFC2867] and [RFC3162]; and Dory
Leifer, John Shriver, Matt Holdrege, Allan Rubens, Glen Zorn and Leifer, John Shriver, Matt Holdrege, Allan Rubens, Glen Zorn and
Ignacio Goyret for their work on [RFC2868]. This document stole text Ignacio Goyret for their work on [RFC2868]. This document stole text
and concepts from both [RFC2868] and [RFC2869]. Thanks go to Carl and concepts from both [RFC2868] and [RFC2869]. Thanks go to Carl
Williams for providing IPv6-specific text. Williams for providing IPv6-specific text.
The authors would also like to acknowledge the following people for The authors would also like to acknowledge the following people for
their contributions in the development of the Diameter protocol: their contributions in the development of the Diameter protocol:
Bernard Aboba, Jari Arkko, William Bulley, Kuntal Chowdhury, Daniel Bernard Aboba, Jari Arkko, William Bulley, Kuntal Chowdhury, Daniel
skipping to change at page 68, line 11 skipping to change at page 67, line 23
their contributions in the development of the Diameter protocol: their contributions in the development of the Diameter protocol:
Bernard Aboba, Jari Arkko, William Bulley, Kuntal Chowdhury, Daniel Bernard Aboba, Jari Arkko, William Bulley, Kuntal Chowdhury, Daniel
C. Fox, Lol Grant, Nancy Greene, Jeff Hagg, Peter Heitman, Paul C. Fox, Lol Grant, Nancy Greene, Jeff Hagg, Peter Heitman, Paul
Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce,
Sumit Vakil, John R. Vollbrecht, and Jeff Weisberg. Sumit Vakil, John R. Vollbrecht, and Jeff Weisberg.
Finally, Pat Calhoun would like to thank Sun Microsystems, as most of Finally, Pat Calhoun would like to thank Sun Microsystems, as most of
the effort put into this document was done while he was in their the effort put into this document was done while he was in their
employ. employ.
A.2. RFC 4005bis
The vast majority of the text in this document was taken directly
from RFC 4005; the editor owes a debt of gratitude to the authors
thereof (especially Dave Mitton, who somehow managed to make nroff
paginate the AVP Occurance Tables correctly!).
Thanks (in no particular order) to Jai-Jin Lim, Liu Hans, Sebastien
Decugis, Jouni Korhonen, Mark Jones, Hannes Tschofenig and Stefan
Winter for their useful reviews and helpful comments.
Author's Address Author's Address
Glen Zorn (editor) Glen Zorn (editor)
Network Zen Network Zen
227/358 Thanon Sanphawut 227/358 Thanon Sanphawut
Bang Na, Bangkok 10260 Bang Na, Bangkok 10260
Thailand Thailand
Phone: +66 (0) 87-040-4617 Phone: +66 (0) 909-201060
EMail: glenzorn@gmail.com EMail: glenzorn@gmail.com
 End of changes. 119 change blocks. 
445 lines changed or deleted 439 lines changed or added

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