idnits 2.17.1 draft-zorn-dime-radia-gate-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 9, 2012) is 4271 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Network Zen 4 Intended status: Standards Track L. Morand 5 Expires: February 10, 2013 Orange Labs 6 T. Hiller 7 Lucent Technologies 8 August 9, 2012 10 The RADIUS-Diameter Gateway (RADIA) Application 11 draft-zorn-dime-radia-gate-06.txt 13 Abstract 15 This document describes the Diameter RADIUS-Diameter Gateway (RADIA) 16 Application, which is designed to facillitate the interoperability of 17 Authentication, Authorization and Accounting (AAA) systems based upon 18 RADIUS and Diameter. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 10, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 68 3. The RADIUS-Diameter Gateway Application . . . . . . . . . . . . 3 69 3.1. Advertising Application Support . . . . . . . . . . . . . . 3 70 3.2. Diameter Session Usage . . . . . . . . . . . . . . . . . . 3 71 3.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.3.1. The RADIA-Request (RDR) Command . . . . . . . . . . . . 4 73 3.3.2. The RADIA-Answer (RDA) Command . . . . . . . . . . . . 4 74 3.4. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . 5 75 3.4.1. Radius-Message AVP . . . . . . . . . . . . . . . . . . 5 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 78 5.1. Diameter Application Identifier . . . . . . . . . . . . . . 5 79 5.2. Diameter Command Codes . . . . . . . . . . . . . . . . . . 5 80 5.3. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . 5 81 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 84 1. Introduction 86 The Diameter Network Access Server (NASREQ) Application [RFC4005] 87 specifies methods to deal with various interactions between the 88 RADIUS [RFC2865] and Diameter [RFC3588] protocols. In particular, 89 the translation of RADIUS messages and attributes to and from 90 Diameter commands and Attribute-Value Pairs (AVPs) is described at 91 some length. However, there is a fundamental and insurmountable 92 problem with attempting to translate Diameter protocol elements into 93 RADIUS protocol elements: a single Diameter AVP may be much larger 94 than an entire RADIUS message. Various workarounds have been 95 proposed to ameliorate this proble, including limiting the size of 96 Diameter elements that might require translation into RADIUS and 97 returning an error upon receipt of an untranslatable AVP. The former 98 approach uneccessarily limits the utility of, for example, the NASREQ 99 application in pure Diameter deployments while the latter can result 100 in the denial of service to otherwise legitimate users. 102 This document describes a simple method to solve the problems of 103 interaction between RADIUS and Diameter by taking advantage of the 104 fact thata RADIUS message can fit into a single Diameter AVP. 106 2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 3. The RADIUS-Diameter Gateway Application 114 The following sections define the syntax, semantics and usage of the 115 RADIA application. 117 3.1. Advertising Application Support 119 Servers and proxies supporting the RADIUS-Diameter Gateway 120 application MUST advertise support by including the value in 121 the Auth-Application-Id of the Capabilities-Exchange-Request (CER), 122 Accounting-Request (ACR), Accounting-Answer (ACA), RADIA-Request 123 (RDR), and RADIA-Answer (RDA) messages. 125 3.2. Diameter Session Usage 127 Session usage in the RADIA application is identical to that in 128 NASREQ. 130 3.3. Commands 132 The RADIA application defines two new commands: Gateway-Request (RDR) 133 and Gateway-Answer (RDA). The following sections describe these 134 commands. 136 3.3.1. The RADIA-Request (RDR) Command 138 The peer sends the RADIA-Request (RDR) command, indicated by the 139 Command-Code field set to and the Command Flags' 'R' bit set, 140 in order to transmit a RADIUS message (encapsulated in the Radius- 141 Message AVP (Section 3.4.1)) toward its final destination. The 142 Radius-Message AVP will generally encapsulate a RADIUS request 143 message (e.g., Access-Request). 145 Message format: 147 ::= < Diameter Header: CC1, REQ, PXY > 148 { Origin-Host } 149 { Origin-Realm } 150 { Destination-Realm } 151 { Auth-Application-Id } 152 { Radius-Message} 153 [ Destination-Host ] 154 * [ Proxy-Info ] 155 * [ Route-Record ] 156 * [ AVP ] 158 3.3.2. The RADIA-Answer (RDA) Command 160 The peer sends the RADIA-Answer (RDA) command, indicated by the 161 Command-Code field set to and the Command Flags' 'R' bit set, 162 in order to transmit a RADIUS message (encapsulated in the Radius- 163 Message AVP (Section 3.4.1)) toward its final destination. The 164 Radius-Message AVP will generally encapsulate a RADIUS reply message 165 (e.g., Access-Accept). 167 Message format: 169 ::= < Diameter Header: CC2, REQ, PXY > 170 { Origin-Host } 171 { Origin-Realm } 172 { Destination-Realm } 173 { Auth-Application-Id } 174 { Radius-Message} 175 [ Destination-Host ] 176 * [ Proxy-Info ] 177 * [ Route-Record ] 178 * [ AVP ] 180 3.4. Attribute-Value Pairs 182 This section describes the single AVP specific to the RADIUS-Diameter 183 Gateway application. 185 3.4.1. Radius-Message AVP 187 The Radius-Message AVP (AVP code ) is of type OctetString. The 188 'M' bit MUST be set and the 'V' bit MUST NOT be set. The AVP 189 contains a complete RADIUS message. 191 4. Security Considerations 193 The protocol defined in this specification has no effect upon the 194 security of either Diameter or RADIUS. 196 5. IANA Considerations 198 Upon publication of this memo as an RFC, IANA is requested to assign 199 values as described in the following sections. 201 5.1. Diameter Application Identifier 203 An application identifier for Diameter RADIUS-Diameter Gateway 204 (, Section 3) must be assigned according to the policy specified 205 in Section 11.3 of RFC 3588. 207 5.2. Diameter Command Codes 209 Command codes must be assigned for the RADIA-Request (RDR) (, 210 Section 3.3.1) and RADIA-Answer (RDA) (, Section 3.3.2) commands 211 according to the policy specified in RFC 3588, Section 11.2.1. 213 5.3. Attribute-Value Pairs 215 A code must be assigned for the following AVP using the policy 216 specified in RFC 3588, Section 11.1.1: Radius-Message (, 217 Section 3.4.1). 219 6. Normative References 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, March 1997. 224 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 225 "Remote Authentication Dial In User Service (RADIUS)", 226 RFC 2865, June 2000. 228 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 229 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 231 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 232 "Diameter Network Access Server Application", RFC 4005, 233 August 2005. 235 Authors' Addresses 237 Glen Zorn 238 Network Zen 239 227/358 Thanon Sanphawut 240 Bang Na, Bangkok 10260 241 Thailand 243 Phone: +66 (0) 909-020106 244 Email: glenzorn@gmail.com 246 Lionel Morand 247 Orange Labs 248 38-40 rue du general Leclerc 249 Issy-moulineaux Cedex 9 92794 250 France 252 Email: Lionel.morand@orange-ftgroup.com 254 Tom Hiller 255 Lucent Technologies 256 1960 Lucent Lane 257 Naperville, Illinois 60566 258 USA 260 Email: tom.hiller@alcatel-lucent.com