idnits 2.17.00 (12 Aug 2021) /tmp/idnits1753/draft-zorn-dime-radia-gate-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4005, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4005, updated by this document, for RFC5378 checks: 2001-02-09) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (March 7, 2010) is 4458 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). 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 Updates: 4005 (if approved) L. Morand 5 Intended status: Standards Track Orange Labs 6 Expires: September 8, 2010 T. Hiller 7 Lucent Technologies 8 March 7, 2010 10 The RADIUS-Diameter Gateway (RADIA) Application 11 draft-zorn-dime-radia-gate-01.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 to IETF 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), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 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 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 8, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 74 3. The RADIUS-Diameter Gateway Application . . . . . . . . . . . . 3 75 3.1. Advertising Application Support . . . . . . . . . . . . . . 3 76 3.2. Diameter Session Usage . . . . . . . . . . . . . . . . . . 3 77 3.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3.3.1. The RADIA-Request (RDR) Command . . . . . . . . . . . . 4 79 3.3.2. The RADIA-Answer (RDA) Command . . . . . . . . . . . . 4 80 3.4. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . 5 81 3.4.1. Radius-Message AVP . . . . . . . . . . . . . . . . . . 5 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 84 5.1. Diameter Application Identifier . . . . . . . . . . . . . . 5 85 5.2. Diameter Command Codes . . . . . . . . . . . . . . . . . . 5 86 5.3. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . 5 87 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 90 1. Introduction 92 The Diameter Network Access Server (NASREQ) Application [RFC4005] 93 specifies methods to deal with various interactions between the 94 RADIUS [RFC2865] and Diameter [RFC3588] protocols. In particular, 95 the translation of RADIUS messages and attributes to and from 96 Diameter commands and Attribute-Value Pairs (AVPs) is described at 97 some length. However, there is a fundamental and insurmountable 98 problem with attempting to translate Diameter protocol elements into 99 RADIUS protocol elements: a single Diameter AVP may be much larger 100 than an entire RADIUS message. Various workarounds have been 101 proposed to ameliorate this proble, including limiting the size of 102 Diameter elements that might require translation into RADIUS and 103 returning an error upon receipt of an untranslatable AVP. The former 104 approach uneccessarily limits the utility of, for example, the NASREQ 105 application in pure Diameter deployments while the latter can result 106 in the denial of service to otherwise legitimate users. 108 This document describes a simple method to solve the problems of 109 interaction between RADIUS and Diameter by taking advantage of the 110 fact thata RADIUS message can fit into a single Diameter AVP. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. The RADIUS-Diameter Gateway Application 120 The following sections define the syntax, semantics and usage of the 121 RADIA application. 123 3.1. Advertising Application Support 125 Servers and proxies supporting the RADIUS-Diameter Gateway 126 application MUST advertise support by including the value in 127 the Auth-Application-Id of the Capabilities-Exchange-Request (CER), 128 Accounting-Request (ACR), Accounting-Answer (ACA), RADIA-Request 129 (RDR), and RADIA-Answer (RDA) messages. 131 3.2. Diameter Session Usage 133 Session usage in the RADIA application is identical to that in 134 NASREQ. 136 3.3. Commands 138 The RADIA application defines two new commands: Gateway-Request (RDR) 139 and Gateway-Answer (RDA). The following sections describe these 140 commands. 142 3.3.1. The RADIA-Request (RDR) Command 144 The peer sends the RADIA-Request (RDR) command, indicated by the 145 Command-Code field set to and the Command Flags' 'R' bit set, 146 in order to transmit a RADIUS message (encapsulated in the Radius- 147 Message AVP (Section 3.4.1)) toward its final destination. The 148 Radius-Message AVP will generally encapsulate a RADIUS request 149 message (e.g., Access-Request). 151 Message format: 153 ::= < Diameter Header: CC1, REQ, PXY > 154 { Origin-Host } 155 { Origin-Realm } 156 { Destination-Realm } 157 { Auth-Application-Id } 158 { Radius-Message} 159 [ Destination-Host ] 160 * [ Proxy-Info ] 161 * [ Route-Record ] 162 * [ AVP ] 164 3.3.2. The RADIA-Answer (RDA) Command 166 The peer sends the RADIA-Answer (RDA) command, indicated by the 167 Command-Code field set to and the Command Flags' 'R' bit set, 168 in order to transmit a RADIUS message (encapsulated in the Radius- 169 Message AVP (Section 3.4.1)) toward its final destination. The 170 Radius-Message AVP will generally encapsulate a RADIUS reply message 171 (e.g., Access-Accept). 173 Message format: 175 ::= < Diameter Header: CC2, REQ, PXY > 176 { Origin-Host } 177 { Origin-Realm } 178 { Destination-Realm } 179 { Auth-Application-Id } 180 { Radius-Message} 181 [ Destination-Host ] 182 * [ Proxy-Info ] 183 * [ Route-Record ] 184 * [ AVP ] 186 3.4. Attribute-Value Pairs 188 This section describes the single AVP specific to the RADIUS-Diameter 189 Gateway application. 191 3.4.1. Radius-Message AVP 193 The Radius-Message AVP (AVP code ) is of type OctetString. The 194 'M' bit MUST be set and the 'V' bit MUST NOT be set. The AVP 195 contains a complete RADIUS message. 197 4. Security Considerations 199 The protocol defined in this specification has no effect upon the 200 security of either Diameter or RADIUS. 202 5. IANA Considerations 204 Upon publication of this memo as an RFC, IANA is requested to assign 205 values as described in the following sections. 207 5.1. Diameter Application Identifier 209 An application identifier for Diameter RADIUS-Diameter Gateway 210 (, Section 3) must be assigned according to the policy specified 211 in Section 11.3 of RFC 3588. 213 5.2. Diameter Command Codes 215 Command codes must be assigned for the RADIA-Request (RDR) (, 216 Section 3.3.1) and RADIA-Answer (RDA) (, Section 3.3.2) commands 217 according to the policy specified in RFC 3588, Section 11.2.1. 219 5.3. Attribute-Value Pairs 221 A code must be assigned for the following AVP using the policy 222 specified in RFC 3588, Section 11.1.1: Radius-Message (, 223 Section 3.4.1). 225 6. Normative References 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 231 "Remote Authentication Dial In User Service (RADIUS)", 232 RFC 2865, June 2000. 234 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 235 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 237 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 238 "Diameter Network Access Server Application", RFC 4005, 239 August 2005. 241 Authors' Addresses 243 Glen Zorn 244 Network Zen 245 1310 East Thomas Street 246 #306 247 Seattle, Washington 98102 248 USA 250 Email: gwz@net-zen.net 252 Lionel Morand 253 Orange Labs 254 38-40 rue du general Leclerc 255 Issy-moulineaux Cedex 9 92794 256 France 258 Email: Lionel.morand@orange-ftgroup.com 260 Tom Hiller 261 Lucent Technologies 262 1960 Lucent Lane 263 Naperville, Illinois 60566 264 USA 266 Email: tom.hiller@alcatel-lucent.com