idnits 2.17.00 (12 Aug 2021) /tmp/idnits751/draft-zorn-dime-radia-gate-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (July 5, 2009) is 4703 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: January 6, 2010 July 5, 2009 8 The RADIUS-Diameter Gateway (RADIA) Application 9 draft-zorn-dime-radia-gate-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 6, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document describes the Diameter RADIUS-Diameter Gateway (RADIA) 58 Application, which is designed to facillitate the interoperability of 59 Authentication, Authorization and Accounting (AAA) systems based upon 60 RADIUS and Diameter. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 66 3. The RADIUS-Diameter Gateway Application . . . . . . . . . . . . 3 67 3.1. Advertising Application Support . . . . . . . . . . . . . . 3 68 3.2. Diameter Session Usage . . . . . . . . . . . . . . . . . . 3 69 3.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.3.1. The RADIA-Request (RDR) Command . . . . . . . . . . . . 4 71 3.3.2. The RADIA-Answer (RDA) Command . . . . . . . . . . . . 4 72 3.4. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . 5 73 3.4.1. Radius-Message AVP . . . . . . . . . . . . . . . . . . 5 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 76 5.1. Diameter Application Identifier . . . . . . . . . . . . . . 5 77 5.2. Diameter Command Codes . . . . . . . . . . . . . . . . . . 5 78 5.3. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . 6 79 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 82 1. Introduction 84 The Diameter Network Access Server (NASREQ) Application [RFC4005] 85 specifies methods to deal with various interactions between the 86 RADIUS [RFC2865] and Diameter [RFC3588] protocols. In particular, 87 the translation of RADIUS messages and attributes to and from 88 Diameter commands and Attribute-Value Pairs (AVPs) is described at 89 some length. However, there is a fundamental and insurmountable 90 problem with attempting to translate Diameter protocol elements into 91 RADIUS protocol elements: a single Diameter AVP may be much larger 92 than an entire RADIUS message. Various workarounds have been 93 proposed to ameliorate this proble, including limiting the size of 94 Diameter elements that might require translation into RADIUS and 95 returning an error upon receipt of an untranslatable AVP. The former 96 approach uneccessarily limits the utility of, for example, the NASREQ 97 application in pure Diameter deployments while the latter can result 98 in the denial of service to otherwise legitimate users. 100 This document describes a simple method to solve the problems of 101 interaction between RADIUS and Diameter by taking advantage of the 102 fact thata RADIUS message can fit into a single Diameter AVP. 104 2. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 3. The RADIUS-Diameter Gateway Application 112 The following sections define the syntax, semantics and usage of the 113 RADIA application. 115 3.1. Advertising Application Support 117 Servers and proxies supporting the RADIUS-Diameter Gateway 118 application MUST advertise support by including the value in 119 the Auth-Application-Id of the Capabilities-Exchange-Request (CER), 120 Accounting-Request (ACR), Accounting-Answer (ACA), RADIA-Request 121 (RDR), and RADIA-Answer (RDA) messages. 123 3.2. Diameter Session Usage 125 Session usage in the RADIA application is identical to that in 126 NASREQ. 128 3.3. Commands 130 The RADIA application defines two new commands: Gateway-Request (RDR) 131 and Gateway-Answer (RDA). The following sections describe these 132 commands. 134 3.3.1. The RADIA-Request (RDR) Command 136 The peer sends the RADIA-Request (RDR) command, indicated by the 137 Command-Code field set to and the Command Flags' 'R' bit set, 138 in order to transmit a RADIUS message (encapsulated in the Radius- 139 Message AVP (Section 3.4.1)) toward its final destination. The 140 Radius-Message AVP encapsulates a RADIUS request message (e.g., 141 Access-Request). 143 Message format: 145 ::= < Diameter Header: CC1, REQ, PXY > 146 { Origin-Host } 147 { Origin-Realm } 148 { Destination-Realm } 149 { Auth-Application-Id } 150 { Radius-Message} 151 [ User-Name ] 152 [ Destination-Host ] 153 * [ Proxy-Info ] 154 * [ Route-Record ] 155 * [ AVP ] 157 3.3.2. The RADIA-Answer (RDA) Command 159 The peer sends the RADIA-Answer (RDA) command, indicated by the 160 Command-Code field set to and the Command Flags' 'R' bit set, 161 in order to transmit a RADIUS message (encapsulated in the Radius- 162 Message AVP (Section 3.4.1)) toward its final destination. The 163 Radius-Message AVP encapsulates a RADIUS reply message (e.g., Access- 164 Accept). 166 Message format: 168 ::= < Diameter Header: CC2, REQ, PXY > 169 { Origin-Host } 170 { Origin-Realm } 171 { Destination-Realm } 172 { Auth-Application-Id } 173 { Radius-Message} 174 [ User-Name ] 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 1310 East Thomas Street 240 #306 241 Seattle, Washington 98102 242 USA 244 Email: gwz@net-zen.net 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