idnits 2.17.1 draft-ietf-dime-extended-naptr-07.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3588]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3588, updated by this document, for RFC5378 checks: 2001-02-09) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 9, 2011) is 4734 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 4006 (Obsoleted by RFC 8506) -- Possible downref: Non-RFC (?) normative reference: ref. 'WiMAX' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions M. Jones 3 (DIME) Bridgewater Systems 4 Internet-Draft J. Korhonen 5 Updates: 3588 (if approved) Nokia Siemens Networks 6 Intended status: Standards Track L. Morand 7 Expires: November 10, 2011 Orange Labs 8 May 9, 2011 10 Diameter S-NAPTR Usage 11 draft-ietf-dime-extended-naptr-07 13 Abstract 15 The Diameter base protocol specifies mechanisms whereby a given realm 16 may advertise Diameter nodes and the supported transport protocol. 17 However, these mechanisms do not reveal the Diameter applications 18 that each node supports. A peer outside the realm would have to 19 perform a Diameter capability exchange with every node until it 20 discovers one that supports the required application. This document 21 updates [RFC3588] and describes an improvement using an extended 22 format for the Straightforward-Naming Authority Pointer (S-NAPTR) 23 Application Service Tag that allows for discovery of the supported 24 applications without doing Diameter capability exchange beforehand. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 10, 2011. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Extended NAPTR Service Field Format . . . . . . . . . . . . . 3 69 3.1. IETF Standard Track Diameter Applications . . . . . . . . 4 70 3.2. Vendor-specific Diameter Applications . . . . . . . . . . 4 71 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 5 72 5. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5 73 6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 6 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. IETF Diameter Application Service Tags . . . . . . . . . . 7 76 7.2. 3GPP Diameter Application Service Tags . . . . . . . . . . 7 77 7.3. WiMAX Forum Diameter Application Service Tags . . . . . . 8 78 7.4. Vendor-Specific Diameter Application Service Tags . . . . 8 79 7.5. Diameter Application Protocol Tags . . . . . . . . . . . . 9 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 82 10. Editor's Notes . . . . . . . . . . . . . . . . . . . . . . . . 9 83 11. Normative References . . . . . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 The Diameter base protocol [RFC3588] specifies three mechanisms for 89 the Diameter peer discovery. One of these involves the Diameter 90 implementation performing a Naming Authority Pointer (NAPTR) query 91 [RFC3403] for a server in a particular realm. These NAPTR records 92 provide a mapping from a domain, to the SRV record [RFC2782] or 93 A/AAAA record [RFC1035][RFC3596] for contacting a server with the 94 specific transport protocol in the NAPTR services field. 96 The extended NAPTR usage for Diameter peer discovery defined by this 97 document is based on the Straightforward-NAPTR (S-NAPTR) Dynamic 98 Delegation Discovery System (DDDS) Application defined in [RFC3958]. 99 This document updates the Diameter peer discovery procedure described 100 in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service 101 and Application Protocol Tag values that permit the discovery of 102 Diameter peers that support a specific Diameter application and 103 transport protocol. 105 2. Terminology 107 The Diameter base protocol specification (Section 1.4 of [RFC3588]) 108 and the Straightforward-NAPTR (S-NAPTR) DDDS application (section 2.1 109 in [RFC3958]) define the terminology used in this document. 111 3. Extended NAPTR Service Field Format 113 The NAPTR Service Field format defined by the S-NAPTR DDDS 114 application in [RFC3958] follows this Augmented Backus-Naur Form 115 (ABNF, [RFC5234]): 117 service-parms = [ [app-service] *(":" app-protocol)] 118 app-service = experimental-service / iana-registered-service 119 app-protocol = experimental-protocol / iana-registered-protocol 120 experimental-service = "x-" 1*30ALPHANUMSYM 121 experimental-protocol = "x-" 1*30ALPHANUMSYM 122 iana-registered-service = ALPHA *31ALPHANUMSYM 123 iana-registered-protocol = ALPHA *31ALPHANUMSYM 124 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 125 DIGIT = %x30-39 ; 0-9 126 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." 127 ALPHANUMSYM = ALPHA / DIGIT / SYM 128 ; The app-service and app-protocol tags are limited to 32 129 ; characters and must start with an alphabetic character. 130 ; The service-parms are considered case-insensitive. 132 This specification refines the "iana-registered-service" tag 133 definition for the discovery of Diameter agents supporting a specific 134 Diameter application as defined below. 136 iana-registered-service = aaa-service / ALPHA *31ALPHANUMSYM 137 aaa-service = "aaa+ap" appln-id 138 appln-id = DIGIT *DIGIT 139 ; Application identifier expressed as a 140 ; decimal integer. 142 This specification also refines the "iana-registered-protocol" tag 143 definition for the discovery of Diameter agents supporting a specific 144 Diameter transport protocol as defined below. 146 iana-registered-protocol = aaa-protocol / ALPHA *31ALPHANUMSYM 147 aaa-protocol = "diameter." aaa-transport 148 aaa-transport = "tcp" / "sctp" / "tls.tcp" 150 The maximum length of the NAPTR service field is 256 octets including 151 one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 152 of [RFC1035]). 154 3.1. IETF Standard Track Diameter Applications 156 A Diameter agent MUST be capable of using the extended S-NAPTR 157 Application Service Tag for dynamic discovery of a Diameter agent 158 supporting Standard Track applications. Therefore, every IETF 159 Standard Track Diameter application MUST be associated with a "aaa- 160 service" tag formatted as defined in this specification and allocated 161 in accordance with the IANA policy (see Section 7). 163 For example, a NAPTR service field value of: 165 'aaa+ap6:diameter.sctp' 167 Means that the Diameter node in the SRV or A/AAAA record supports 168 the Diameter Session Initiation Protocol (SIP) Application ('6') 169 and SCTP as the transport protocol. 171 3.2. Vendor-specific Diameter Applications 173 S-NAPTR Application Service and Application Protocol Tag values can 174 also be used to discover Diameter peers that support a vendor- 175 specific Diameter application. In this case, the vendor-specific 176 Diameter application MUST be associated with a "aaa-service" tag 177 formatted as defined in this specification and allocated in 178 accordance with the IANA policy (see Section 7). 180 For example, a NAPTR service field value of: 182 'aaa+ap16777251:diameter.sctp' 184 Means that the Diameter node in the SRV or A/AAAA record supports 185 the Diameter 3GPP S6a Application ('16777251') and SCTP as the 186 transport protocol. 188 4. Backwards Compatibility 190 Domain Name System (DNS) administrators SHOULD also provision legacy 191 RFC 3588 style NAPTR records [RFC3403] in order to guarantee 192 backwards compatibility with legacy RFC 3588 compliant Diameter 193 peers. If the DNS administrator provisions both extended S-NAPTR 194 records as defined in this specification and legacy RFC 3588 NAPTR 195 records, then the extended S-NAPTR records MUST have higher priority 196 (e.g. lower order and/or preference values) than legacy NAPTR 197 records. 199 5. Extended NAPTR-based Diameter Peer Discovery 201 The Diameter Peer Discovery principles are described in Section 5.2 202 of [RFC3588]. This specification updates the NAPTR query procedure 203 in the Diameter peer discovery mechanism by allowing the querying 204 node to determine which applications are supported by resolved 205 Diameter peers. 207 The extended format NAPTR records provide a mapping from a domain to 208 the SRV record or A/AAAA record for contacting a server supporting a 209 specific transport protocol and Diameter application. The resource 210 record will contain an empty regular expression and a replacement 211 value, which is the SRV record or the A/AAAA record for that 212 particular transport protocol. 214 The assumption for this mechanism to work is that the DNS 215 administrator of the queried domain has first provisioned the DNS 216 with extended format NAPTR entries. The steps below replace the 217 NAPTR query procedure steps in Section 5.2 of [RFC3588]. 219 a. The Diameter implementation performs a NAPTR query for a server in 220 a particular realm. The Diameter implementation has to know in 221 advance which realm to look for a Diameter agent in and which 222 Application Identifier it is interested in. For example, the 223 realm could be deduced from the Network Access Identifier (NAI) in 224 the User-Name AVP or extracted from the Destination-Realm AVP. 226 b. If the returned NAPTR service fields contain entries formatted as 227 "aaa+apX:Y" where "X" indicates the Application Identifier and "Y" 228 indicates the supported transport protocol(s), the target realm 229 supports the extended format for NAPTR-based Diameter peer 230 discovery defined in this document. 232 If "X" contains the required Application Identifier and "Y" 233 matches a supported transport protocol, the Diameter 234 implementation resolves the "replacement" field entry to a 235 target host using the lookup method appropriate for the "flags" 236 field. 238 If "X" does not contain the required Application Identifier or 239 "Y" does not match a supported transport protocol, the Diameter 240 implementation abandons the peer discovery. 242 c. If the returned NAPTR service fields contain entries formatted as 243 "aaa:X" where "X" indicates the supported transport protocol(s), 244 the target realm supports Diameter but does not support the 245 extended format for NAPTR-based Diameter peer discovery defined in 246 this document. 248 If "X" matches a supported transport protocol, the Diameter 249 implementation resolves the "replacement" field entry to a 250 target host using the lookup method appropriate for the "flags" 251 field. 253 If "X" does not match a supported transport protocol, the 254 Diameter implementation abandons the peer discovery. 256 d. If the target realm does not support NAPTR-based Diameter peer 257 discovery, the client proceeds with the next peer discovery 258 mechanism described in Section 5.2 of [RFC3588]. 260 6. Usage Guidelines 262 Diameter is a peer to peer protocol whereas most of the applications 263 that extend the base protocol behave like client/server applications. 264 The role of the peer is not advertised in the NAPTR tags and not even 265 communicated during Diameter capability negotiation (Capabilities- 266 Exchange-Request and Capabilities-Exchange-Answer message exchange). 267 For this reason, NAPTR-based Diameter peer discovery for an 268 application defining client/server roles should only be used by a 269 client to discover servers. 271 7. IANA Considerations 273 7.1. IETF Diameter Application Service Tags 275 IANA is requested to reserve a value of "aaa" for Diameter in the 276 S-NAPTR Application Service Tag registry created by [RFC3958]. IANA 277 is also requested to reserve the following S-NAPTR Application 278 Service Tags for existing IETF Diameter applications in the same 279 registry. 281 +------------------+----------------------------+ 282 | Tag | Diameter Application | 283 +------------------+----------------------------+ 284 | aaa+ap1 | NASREQ [RFC3588] | 285 | aaa+ap2 | Mobile IPv4 [RFC4004] | 286 | aaa+ap3 | Base Accounting [RFC3588] | 287 | aaa+ap4 | Credit Control [RFC4006] | 288 | aaa+ap5 | EAP [RFC4072] | 289 | aaa+ap6 | SIP [RFC4740] | 290 | aaa+ap7 | Mobile IPv6 IKE [RFC5778] | 291 | aaa+ap8 | Mobile IPv6 Auth [RFC5778] | 292 | aaa+ap9 | QoS [RFC5866] | 293 | aaa+ap4294967295 | Relay [RFC3588] | 294 +------------------+----------------------------+ 296 Future IETF Diameter applications MUST reserve the S-NAPTR 297 Application Service Tag corresponding to the allocated Diameter 298 Application ID as defined in Section 3. 300 7.2. 3GPP Diameter Application Service Tags 302 IANA is requested to reserve the following S-NAPTR Application 303 Service Tags for existing 3GPP Diameter applications in the S-NAPTR 304 Application Service Tag registry created by [RFC3958]. 306 +----------------+----------------------+ 307 | Tag | Diameter Application | 308 +----------------+----------------------+ 309 | aaa+ap16777250 | 3GPP STa [TS29.273] | 310 | aaa+ap16777251 | 3GPP S6a [TS29.272] | 311 | aaa+ap16777264 | 3GPP SWm [TS29.273] | 312 | aaa+ap16777267 | 3GPP S9 [TS29.215] | 313 +----------------+----------------------+ 315 Future 3GPP Diameter applications can reserve entries in the S-NAPTR 316 Application Service Tag registry created by [RFC3958] which 317 correspond to the allocated Diameter Application IDs as defined in 318 Section 3. 320 7.3. WiMAX Forum Diameter Application Service Tags 322 IANA is requested to reserve the following S-NAPTR Application 323 Service Tags for existing WiMAX Forum Diameter applications in the 324 S-NAPTR Application Service Tag registry created by [RFC3958]. 326 +----------------+--------------------------------------------------+ 327 | Tag | Diameter Application | 328 +----------------+--------------------------------------------------+ 329 | aaa+ap16777281 | WiMAX Network Access Authentication and | 330 | | Authorization Diameter Application (WNAAADA) | 331 | | [WiMAX] | 332 | aaa+ap16777282 | WiMAX Network Accounting Diameter Application | 333 | | (WNADA) [WiMAX] | 334 | aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) [WiMAX] | 335 | aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) [WiMAX] | 336 | aaa+ap16777285 | WiMAX DHCP Diameter Application (WDDA) [WiMAX] | 337 | aaa+ap16777286 | WiMAX Location Authentication Authorization | 338 | | Diameter Application (WLAADA) [WiMAX] | 339 | aaa+ap16777287 | WiMAX Policy and Charging Control R3 Policies | 340 | | Diameter Application (WiMAX PCC-R3-P) [WiMAX] | 341 | aaa+ap16777288 | WiMAX Policy and Charging Control R3 Offline | 342 | | Charging Diameter Application (WiMAX PCC-R3-OFC) | 343 | | [WiMAX] | 344 | aaa+ap16777289 | WiMAX Policy and Charging Control R3 Offline | 345 | | Charging Prime Diameter Application (WiMAX | 346 | | PCC-R3-OFC-PRIME) [WiMAX] | 347 | aaa+ap16777290 | WiMAX Policy and Charging Control R3 Online | 348 | | Charging Diameter Application (WiMAX PCC-R3-OC) | 349 | | [WiMAX] | 350 +----------------+--------------------------------------------------+ 352 Future WiMAX Forum Diameter applications can reserve entries in the 353 S-NAPTR Application Service Tag registry created by [RFC3958] which 354 correspond to the allocated Diameter Application IDs as defined in 355 Section 3. 357 7.4. Vendor-Specific Diameter Application Service Tags 359 Vendor-Specific Diameter Application IDs are allocated by IANA 360 according to the "First Come First Served" policy and do not require 361 an IETF specification. However, the S-NAPTR Application Service Tag 362 registry created by [RFC3958] defines a registration policy of 363 "Specification Required" with a further stipulation that the 364 "specification" is an RFC (of any category). If a Vendor-Specific 365 Diameter Application requires the functionality defined in this 366 document, an RFC of any category MUST be published which reserves the 367 S-NAPTR Application Service Tag corresponding to the Vendor-Specific 368 Diameter Application ID as defined in Section 3. 370 7.5. Diameter Application Protocol Tags 372 IANA is requested to reserve the following S-NAPTR Application 373 Protocol Tags for the Diameter transport protocols in the S-NAPTR 374 Application Protocol Tag registry created by [RFC3958]. 376 +------------------+----------+ 377 | Tag | Protocol | 378 +------------------+----------+ 379 | diameter.tcp | TCP | 380 | diameter.sctp | SCTP | 381 | diameter.tls.tcp | TLS/TCP | 382 +------------------+----------+ 384 8. Security Considerations 386 This document specifies an enhancement to RFC 3588 Diameter base 387 protocol defined NAPTR service field format and also modifications to 388 the NAPTR processing logic defined. The enhancements and 389 modifications are based on the S-NAPTR, which is actually a 390 simplification of the NAPTR, and therefore the same security 391 considerations described in RFC 3588 are applicable to this document. 392 No further extensions are required beyond the security mechanisms 393 offered by RFC 3588. However, a malicious host doing S-NAPTR queries 394 learns applications supported by Diameter agents in a certain realm 395 faster, which might help the malicious host to scan potential targets 396 for an attack more efficiently when some applications have known 397 vulnerabilities. 399 9. Acknowledgments 401 We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Lionel 402 Morand and Sebastien Decugis for their comprehensive review comments. 404 10. Editor's Notes 406 This section to be removed prior to publication. 408 This draft updates sections of RFC3588 that are also being updated by 409 RFC3588bis. At the time this draft was started, it was uncertain 410 whether RFC3588bis would be published first. The authors of this 411 draft decided to proceed optimistically assuming this draft would be 412 published first with the understanding that minor updates are 413 required if this is not the case. 415 The application-neutral aspects of Diameter S-NAPTR usage (e.g "aaa: 416 diameter.sctp") were also contributed to RFC3588bis to ensure that it 417 would be functionally complete if it got published first and this 418 draft would come along later to add the application-specific S-NAPTR 419 entries (e.g."aaa+ap5:diameter.sctp"). 421 Depending on the publication order, the S-NAPTR Application Service 422 Tag registry value of "aaa" and the S-NAPTR Application Protocol Tags 423 values ("diameter.tcp"/"diameter.sctp"/"diameter.tls.tcp") will need 424 to be removed either from this draft or RFC3588bis. 426 11. Normative References 428 [RFC1035] Mockapetris, P., "Domain names - implementation and 429 specification", STD 13, RFC 1035, November 1987. 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, March 1997. 434 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 435 specifying the location of services (DNS SRV)", RFC 2782, 436 February 2000. 438 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 439 Part Three: The Domain Name System (DNS) Database", 440 RFC 3403, October 2002. 442 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 443 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 445 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 446 "DNS Extensions to Support IP Version 6", RFC 3596, 447 October 2003. 449 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 450 Service Location Using SRV RRs and the Dynamic Delegation 451 Discovery Service (DDDS)", RFC 3958, January 2005. 453 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 454 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 455 August 2005. 457 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 458 Loughney, "Diameter Credit-Control Application", RFC 4006, 459 August 2005. 461 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 462 Authentication Protocol (EAP) Application", RFC 4072, 463 August 2005. 465 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 466 Canales-Valenzuela, C., and K. Tammi, "Diameter Session 467 Initiation Protocol (SIP) Application", RFC 4740, 468 November 2006. 470 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 471 Specifications: ABNF", STD 68, RFC 5234, January 2008. 473 [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., 474 and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home 475 Agent to Diameter Server Interaction", RFC 5778, 476 February 2010. 478 [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 479 and G. Zorn, "Diameter Quality-of-Service Application", 480 RFC 5866, May 2010. 482 [TS29.215] 483 3rd Generation Partnership Project, "3GPP TS 29.215; 484 Technical Specification Group Core Network and Terminals; 485 Policy and Charging Control (PCC) over S9 reference point; 486 Stage 3 (Release 8)", 487 . 489 [TS29.272] 490 3rd Generation Partnership Project, "3GPP TS 29.272; 491 Technical Specification Group Core Network and Terminals; 492 Evolved Packet System; Mobility Management Entity (MME) 493 and Serving GPRS Support Node (SGSN) Related Interfaces 494 Based on Diameter Protocol (Release 8)", 495 . 497 [TS29.273] 498 3rd Generation Partnership Project, "3GPP TS 29.273; 499 Technical Specification Group Core Network and Terminals; 500 Evolved Packet System; 3GPP EPS AAA interfaces (Release 501 8)", . 503 [WiMAX] WiMAX Forum, "WiMAX Release 1.5", . 506 Authors' Addresses 508 Mark Jones 509 Bridgewater Systems 511 Email: mark@azu.ca 513 Jouni Korhonen 514 Nokia Siemens Networks 516 Email: jouni.nospam@gmail.com 518 Lionel Morand 519 Orange Labs 521 Email: lionel.morand@orange-ftgroup.com