idnits 2.17.00 (12 Aug 2021) /tmp/idnits15251/draft-alfano-aaa-qosprot-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1058. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1035. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1042. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1048. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1064), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 16 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 12, 2004) is 6522 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) == Missing Reference: 'M' is mentioned on line 901, but not defined == Missing Reference: 'R' is mentioned on line 905, but not defined == Missing Reference: 'S' is mentioned on line 907, but not defined ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: draft-ietf-aaa-diameter-cc has been published as RFC 4006 == Outdated reference: draft-ietf-aaa-diameter-nasreq has been published as RFC 4005 == Outdated reference: draft-ietf-aaa-diameter-sip-app has been published as RFC 4740 == Outdated reference: draft-ietf-aaa-eap has been published as RFC 4072 == Outdated reference: draft-ietf-nsis-qos-nslp has been published as RFC 5974 == Outdated reference: draft-ietf-nsis-rsvp-sec-properties has been published as RFC 4230 -- No information found for draft-qspecteam-nsis-nslp-qspec - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Authentication, Authorization and F. Alfano 2 Accounting P. McCann 3 Internet-Draft Lucent Technologies 4 Expires: January 10, 2005 H. Tschofenig 5 Siemens 6 July 12, 2004 8 Diameter Quality of Service Application 9 draft-alfano-aaa-qosprot-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 10, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document describes a Diameter Application that performs 43 Authentication, Authorization, and Accounting for Quality-of-Service 44 reservations. This protocol is used by elements along the path of a 45 given application flow to authenticate a reservation request, ensure 46 that the reservation is authorized, and to account for resources used 47 during the life of the application flow. This QoS AAA protocol may 48 be used between any bearer-level network element that lies on the 49 path of an application flow and an application server that lies 50 anywhere in the network, allowing for a wide variety of flexible 51 service deployment models. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3. QoS Authorization for a Session . . . . . . . . . . . . . . . 7 58 3.1 Session Establishment . . . . . . . . . . . . . . . . . . 7 59 3.2 QoS Re-Authorization . . . . . . . . . . . . . . . . . . . 7 60 3.3 Session Termination . . . . . . . . . . . . . . . . . . . 7 61 4. Diameter QoS Messages . . . . . . . . . . . . . . . . . . . . 8 62 4.1 QoS-Request (QAR) Command . . . . . . . . . . . . . . . . 8 63 4.2 QoS-Answer (QAA) Command . . . . . . . . . . . . . . . . . 8 64 5. Diameter QoS AVPs . . . . . . . . . . . . . . . . . . . . . . 10 65 5.1 Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 10 66 5.2 Credit Control . . . . . . . . . . . . . . . . . . . . . . 10 67 5.3 Authentication/Authorization . . . . . . . . . . . . . . . 11 68 5.4 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 11 69 5.5 Diameter QoS Application Defined AVPs . . . . . . . . . . 11 70 5.6 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.7 Security Considerations . . . . . . . . . . . . . . . . . 16 72 5.8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 17 73 5.9 Open Issues . . . . . . . . . . . . . . . . . . . . . . . 17 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 76 6.2 Informative References . . . . . . . . . . . . . . . . . . . 19 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 78 A. AVP Formats . . . . . . . . . . . . . . . . . . . . . . . . . 22 79 A.1 RSVP to Diameter QoS AVPs Mapping . . . . . . . . . . . . 22 80 A.1.1 RSVP Objects for the QoS-RSVP AVP . . . . . . . . . . 22 81 A.1.2 RSVP Objects for the Filter-Rule AVP . . . . . . . . . 24 82 A.1.3 RSVP Objects for the QoS-Auth-Resources . . . . . . . 26 83 A.2 NSIS to Diameter QoS AVPs Mapping . . . . . . . . . . . . 26 84 A.3 SIP to Diameter QoS AVPs Mapping . . . . . . . . . . . . . 27 85 Intellectual Property and Copyright Statements . . . . . . . . 28 87 1. Introduction 89 To meet the quality-of-service needs of applications such as 90 voice-over-IP, it will often be necessary to explicitly request 91 resources from the network. This will allow the network to identify 92 packets belonging to these application flows and ensure that 93 bandwidth, delay, and error rate requirements are met. By performing 94 admission control on individual flows, the network can avoid 95 congestion and the resulting high packet drop rates. 97 When bandwidth is expensive and must be carefully managed, such as in 98 wide-area cellular networks, and/or when applications and transport 99 protocols lack the capability or cannot be trusted to perform 100 congestion control, explicit reservation techniques are required. A 101 variety of protocols could be used to make a reservation request, 102 such as: 104 o RSVP 105 o NSIS 106 o Link-specific means 107 o SIP/SDP 108 +------+ +------+ 109 | Subs | | | 110 | DB | | AS | 111 | | | | 112 +---\--+ +---/--+ 113 \ / 114 \ / 115 /-\----------/\ 116 //// \\\\ 117 || || 118 | AAA Cloud | 119 || || 120 \\\\ //// 121 \-------+-----/ 122 | 123 +---+--+ 124 Application | | 125 Flow ===============+ BE +==========>> 126 | | 127 +------+ 129 Figure 1: An architecture supporting QoS-AAA 131 Figure 1 depicts a bearer element through which application flows 132 need to pass, a cloud of AAA servers, a database containing 133 subscriber records, and an application server. Here the term "AAA 134 Cloud" is used to refer to the network of AAA proxy/broker 135 arrangements that may be in place. Also, note that there may be more 136 than one bearer element that needs to interact with the AAA cloud 137 along the path of a given application flow, although the figure only 138 depicts one for clarity. Similarly, a given user may have subscriber 139 records stored in more than one place and might make use of multiple 140 application servers. In the simplest case, bearer elements will 141 request authentication and authorization for QoS from the AAA cloud, 142 which will route the request to the home network and consult a static 143 subscriber record of the endpoint making the request and return a 144 grant/deny decision. In more complex deployment models, the 145 authorization will be based on dynamic application state, so the 146 request must be authenticated and authorized based on information 147 from one or more application servers. If defined properly, the 148 interface between the bearer element and AAA cloud would be identical 149 in both cases. Bearer elements are therefore insulated from the 150 details of particular applications and need not know that application 151 servers are involved at all. Also, the AAA cloud would naturally 152 encompass business relationships such as those between network 153 operators and third-party application providers, enabling flexible 154 intra- or inter-domain authorization, accounting, and settlement. 156 This document describes a Diameter Application protocol that is used 157 for AAA in an environment where user applications request better than 158 best effort Quality of Service. This Diameter QoS application 159 protocol when combined with [RFC3588], satisfies the QoS related 160 requirements defined in [I-D.alfano-aaa-qosreq]. 162 This document first describes the operation of a Diameter QoS 163 application. Then it defines the Diameter message Command-Codes. 164 The following sections enumerate the AVPs used in these messages. 166 Diameter nodes conforming to this specification MAY advertise support 167 by including the value of TBD in the Auth-Application-Id or the 168 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 169 Capabilities-Exchange-Answer commands [RFC3588]. 171 The value of TBD (TBD) MUST be used as the Application-Id in all QAR 172 and QAA commands. The value of TBD (TBD) MUST be used as the 173 Application-Id in all ACR/ACA commands, because this application 174 defines new, mandatory AVPs for accounting. The value of zero (0) 175 SHOULD be used as the Application-Id in all STR/STA, ASR/ASA, and 176 RAR/RAA commands, because these are defined in the Diameter base 177 protocol and no additional mandatory AVPs for those commands are 178 defined in this document. 180 2. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC-2119 [RFC2119]. 186 Furthermore, we use terminology defined in [RFC3588]. 188 3. QoS Authorization for a Session 190 The request for a quality of service enabled bearer starts a Diameter 191 QoS message exchange. The identity of the user, message 192 authentication information, and depending on the scenario, the 193 identity of the QoS authorizing application server and session 194 identification information, are assembled into a Diameter QoS 195 Authorization Request (QAR) message by the bearer control element(s) 196 responsible for resource allocation and sent either to the identified 197 application server, or to a supporting diameter server in the user's 198 home realm. 200 The server processes the information and responds with a Diameter QoS 201 Answer message (QAA) which contains QoS authorization, accounting, 202 and bearer gating information, or a failure code(Result-Code AVP). 204 3.1 Session Establishment 206 When the QoS authorization exchange completes successfully, the QoS 207 Diameter application SHOULD start a session context for reporting 208 accounting information and loss of bearer. Accounting information is 209 reported as described in [RFC3588] and as extended in this Diameter 210 application. Loss of bearer information is reported using Diameter 211 QoS defined command codes (QAR) and AVPs. 213 3.2 QoS Re-Authorization 215 It is for further study whether a re-authorization capability is 216 required. Thereby an application server can specify a period of time 217 for which an application is authorized to use QoS resources. 219 3.3 Session Termination 221 A Diameter QoS Session is terminated when the authorizing entity 222 sends an Abort Session Request [RFC3588] to the bearer control 223 element, either in response to a loss of bearer report, or session 224 termination at the application layer. 226 4. Diameter QoS Messages 228 This section defines new Diameter message Command-Code [RFC3588] 229 values that MUST be supported by all Diameter implementations that 230 conform to this specification. The Command Codes are: 232 Command-Name Abbrev. Code Reference 233 QoS-Request QAR XXX Y.1 234 QoS-Answer QAA XXX Y.2 236 4.1 QoS-Request (QAR) Command 238 The QoS-Request message (QAR), indicated by the Command-Code field 239 set to XXX and 'R' bit set in the Command Flags field, is used by 240 bearer control elements to request quality of service related 241 resource authorization for a given user and application flow. 243 The message MUST carry authenticating information to validate that 244 the QAR-Request is coming from a valid bearer element. The Request 245 SHOULD carry enough information to identify the user. If the 246 QoS-Request is intended for a specific application server, the 247 Request MUST include session identification AVPs. 249 Message Format 251 ::= < Diameter Header: XXX, REQ, PXY > 252 < Session-Id > 253 { Auth- Application-Id } 254 { Origin-Host } 255 { Origin-Realm } 256 { Destination-Host } 257 { Destination Realm } 258 { Auth-Request-Type } 259 [ QoS-Account-Corr-Id ] 260 [ User-Name ] 261 [ State ] 262 * [ AVP ] 264 4.2 QoS-Answer (QAA) Command 266 The QoS-Answer message (QAA), indicated by the Command-Code field set 267 to XXX and 'R' bit cleared in the Command Flags field, is sent in 268 response to the QoS-Request message. If the QoS-Request message is 269 processed successfully, the response will include the AVPs to allow 270 authorization of the QoS resources as well as accounting and bearer 271 gating information. 273 ::= < Diameter Header: XXX, PXY > 274 < Session-Id > 275 { Auth-Application-Id } 276 { Result-Code } 277 { Origin-Host } 278 { Origin-Realm } 279 [ QoS-Auth-Resources ] 280 [ QoS-Flow-State ] 281 * [ AVP ] 283 5. Diameter QoS AVPs 285 Each of the AVPs identified in the QoS-Request and QoS-Answer command 286 codes and the assignment of their value(s) is given in this section. 288 5.1 Diameter Base Protocol AVPs 290 The AVPs in this section are defined in the Base Protocol, and are 291 included here for reference. For more information, see [RFC3588]. 293 Session-Id AVP 295 The Diameter QoS Application client MUST create a unique value for 296 the Session-Id. This value serves the purpose of uniquely 297 identifier a particular session. 299 Auth-Application-Id 301 The Auth-Application-Id is assigned by IANA to Diameter 302 Applications. The value of the Auth-Application-Id for the 303 Diameter QoS Application is XXX. 305 Result-Code AVP 307 The Result-Code AVP indicates if a particular request was 308 completed successfully. 310 Origin-Host 312 The Origin-Host AVP identifies the endpoint that originated the 313 Diameter message. 315 Origin-Realm 317 The Origin-Realm AVP contains the Realm of the originator of the 318 Diameter message. 320 5.2 Credit Control 322 The AVPs in this section are defined as part of the Diameter draft 323 [I-D.ietf-aaa-diameter-cc]. 325 Accounting-Correlation-Id 327 The Accounting-Correlation-Id AVP (AVP Code TBD) is of type 328 OctetString and contains information to correlate accounting data 329 generated produced by different components of the service, e.g. 331 transport and application level. In the Diameter QoS Application, 332 this AVP is assigned a value by the Diameter QoS client and sent 333 to the server in a QAR message. 335 5.3 Authentication/Authorization 337 Authentication and authorization is important for the Diameter QoS 338 application. Therefore, a number of AVPs of related Diameter 339 applications can be used, such as [I-D.ietf-aaa-eap], 340 [I-D.ietf-aaa-diameter-sip-app] and [I-D.ietf-aaa-diameter-nasreq] 342 The details of the required attributes for authentication and 343 authorization is for further study. 345 5.4 Accounting 347 Applications implementing this specification use Diameter Accounting 348 as defined in the draft [I-D.ietf-aaa-diameter-cc]. The Diameter QoS 349 Application uses a Credit Control Application AVP in its QAR message 350 to specify an Accounting-Correlation ID. 352 5.5 Diameter QoS Application Defined AVPs 354 This section defines the Quality of Service AVPs that are specific to 355 the Diameter QoS Application that MAY be included in the Diameter QoS 356 Application messages. The following table describes the Diameter 357 AVPs in the QoS Application, their AVP code values, types, possible 358 flag values, and whether the AVP MAY be encrypted. 360 | AVP Flag rules | 361 |----+-----+----+-----|----+ 362 AVP Section | | |SHLD| MUST| | 363 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 364 -----------------------------------------|----+-----+----+-----|----| 365 QoS-Auth- XXX 4.3 Grouped | | | | | | 366 Resources | | | | | | 367 QoS-Filter-Rule XXX 4.3 IPfltrRul | | | | | | 368 QoS-Flow-State XXX 4.3 Enumerated | | | | | | 369 QoS-SDP XXX 4.3 OctetString | | | | | | 370 QoS-RSVP XXX 4.3 OctetString | | | | | | 371 QoS-NSIS XXX 4.3 OctetString | | | | | | 372 | | | | | | 373 -----------------------------------------+----+-----+----+-----+----+ 375 QoS-Auth-Resources 377 The QoS-Auth-Resources AVP (AVP Code N) is of type Grouped. Each 378 individual AVP in the grouped QoS-Auth-Resources describes the 379 value of a resource that has been authorized by an application 380 server for a particular user (described by the User-Name AVP) and 381 session (described by the Session-Id AVP). The QoS-Auth-Resources 382 AVP is Optional, however one of QoS-Auth-Resources, or 383 QoS-Flow-State is mandatory in a QAA message. The 384 QoS-Auth-Resources also defines the mandatory fields for a Users 385 Subscription QoS Profile. These AVPs correspond to the QoS 386 Parameters of the Application and may not be the same as the QoS 387 parameters requested of the bearer. If this is the case, some 388 translation from the application level parameters to the bearer 389 level parameters may be required. 391 QoS-Auth-Resources ::= * [ QoS-Filter-Rule ] 392 0*1 < QoS-SDP > 393 0*1 < QoS-RSVP > 394 0*1 < QoS-NSIS > 396 The AVPs that are part of QoS-Auth-resource AVP are: 398 QoS-Filter-Rule: 400 The QoS-Filter-Rule AVP is of type IPFilterRule, and provides 401 filter rules for the packet flow of the user. One or more such 402 AVPs MAY be present in a QAA response. 404 QoS-SDP: 406 The QoS-SDP AVP is of type OctetString. It contains the SDP data 407 from the application layer session negotiation. The format of the 408 data is as specified in [RFC2327]. 410 QoS-RSVP: 412 The QoS-RSVP AVP is of type OctetString. It contains the 413 information carried in the FLOWSPEC (see Appendix A.1). 415 QoS-NSIS: 417 The QoS-NSIS AVP is of type OctetString. It contains QoS 418 parameter information. The format will be described in 419 [I-D.ietf-nsis-qos-nslp] and [I-D.qspecteam-nsis-nslp-qspec]. 420 Note that this work is still in progress. More specific packet 421 format will be described in Appendix A.2 in a future version of 422 this document. 424 It is for further investigation whether a more generic formation for 425 the QoS description in SDP, RSVP and NSIS can be compiled. 427 QoS-Flow-State 429 The QoS-Flow-State AVP is of type Enumerated and is used in both 430 QAR and QAA messages. When included in a QAR message, it 431 indicates the state of the flow identified by the User-Name and 432 Session-Id AVPs. When included in a QAA message, it is 433 instructions to the bearer control element with regard to the 434 state to which the flow should be set. The supported values are 436 0 Open 437 1 Close 438 2 Maintain 440 The QoS-Flow-State is an optional AVP. When not included in a QAA 441 response, the default behavior is to immediately allow the flow of 442 packets (Open). 444 5.6 Scenarios 446 This section illustrates the interworking of NSIS (in Figure 8) and 447 RSVP (in Figure 9) in combination with the Diameter QoS application. 449 Figure 8 shows the interaction between NSIS, application layer 450 signaling (e.g., SIP) and the Diameter QoS application. First, a 451 service request is sent from the client to the application server. 452 This response, for example, returns an authorization token to bind 453 the application layer signaling exchange to the subsequent NSIS 454 signaling session. The authorization token is attached to the NSIS 455 signaling message and the message itself is intercepted by the first 456 NSIS NSLP node. This router then needs to authorize the QoS request 457 and delegates this responsibility to the Diameter QoS application. 458 This type of authorization model is described in Section 3.6 of 459 [I-D.ietf-nsis-qos-nslp]. The Diameter QoS Authorization Request 460 (QAR), which includes authorization information and QoS information 461 is, in this case, forwarded to the administrative domain of the 462 application domain for verification. As a response, the 463 authorization decision is returned with the Diameter QoS Answer 464 message (QAA). Finally, the NSIS QoS NLP aware router acts as an 465 enforcement point. If the authorization decision provided with the 466 QAA message was successful then the NSIS signaling message is 467 forwarded along the path. Otherwise, the QoS NSLP returns an error 468 message to the end host (such as 'Authorisation denied'). 470 Diameter QoS 471 Application 472 Enabled Router Application 473 Enforcement Pt Server 474 Application + 475 Client Domain 1 + Domain 2 476 | | + | 477 | Service Request (QoS) | 478 +------------+------------+-------------> 479 | | + | 480 | | + | 481 | Service Response (QoS', Token) | 482 <------------+------------+-------------+ 483 | | + | 484 | | + | 485 |NSIS (Token)| + | 486 +------------> + | 487 | | + | 488 | | -+-- | 489 | |QAR(Token)- + -QAR(Token)| 490 | +--------/> + --\--------> 491 | | / + \ | 492 | | / + \ | 493 | | | + | | 494 | | QAA(QoS) + QAA(QoS) | 495 | <------+--- + <---+------+ 496 | | | + | | 497 | | | Diameter | | 498 | | \ Network / | 499 | | \ + / | 500 | | \ + / | 501 | Authorization \- + -/ | 502 | Enforcement -+-- | 503 | Decision + | 504 | | + | 505 | | + | 506 | Allow or Terminate Flow | 507 <-----------+*+-------------------------> 508 | | + | 509 | | + | 511 Figure 8: Message flow with NSIS and Diameter QoS Application 513 Figure 9 depicts the interaction between the SIP/RSVP aware end host 514 in a scenario with application layer interaction. The basic 515 signaling exchange is similar to Figure 8 but a few differences 516 exist. First, the Diameter QoS application needs to carry RSVP and 517 SDP specific payloads. Furthermore, the protocol specific mechanisms 518 caused by RSVP (e.g., receiver initiated reservations) and SIP (such 519 as [RFC2327] and [RFC3313]) need to be considered. 521 The message flow in Figure 9 also shows a QoS reservation in both 522 direction - RSVP PATH/RESV messages signaling QoS information in both 523 directions (from the Mobile Node to the Correspondent Node and vice 524 versa). The authorization token handling of the Correspondent Node 525 is omitted from the description. 527 Authorization IMS Proxy Correspondent 528 Enforcement Pt. SIP Server Node 529 (e.g.router) 531 Mobile Node AAA Diameter IMS SIP 532 Proxy Server 533 | | | | | | 534 +-+---------+-------------------+---------+---------+-+ 535 | | |Invite (SDP) | | | | 536 | +---------+---------+---------> | | | 537 | | |100 Trying | | | | 538 | <---------+---------+---------+ | | | 539 | | | | Invite (SDP) | | 540 | | | | +---------> | | 541 | | | | |100 Trying | | 542 | | | | <---------+ | | 543 | | | | | Invite (SDP)| 544 | | | | | +---------> | 545 | | | | | | 180 SDP'| | 546 | | | | | <---------+ | 547 | | | | |180 SDP' | | | 548 | | | | <---------+ | | 549 | | | | +--------+ | | | 550 | | | | |Generate| | | | 551 | | | | | Token | | | | 552 | | | | +--------+ | | | 553 | | |180 (SDP',Token) | | | | 554 +-----------+---------+---------+---------+---------+-+ 555 |RSVP PATH| | | | | 556 +---------> | | | | 557 | | | |RSVP PATH| | 558 | +---------+--...----+---------+---------> 559 | | | | | | 560 | +---------+--...----+---------+---------+ 561 |RSVP RESV| | | | | 562 <---------+ | | | | 563 | | |RSVP PATH| | | 564 | <---------+--...----+---------+---------+ 565 |RSVP PATH| | | | | 566 <---------+ | | | | 567 |RESV(TOKEN) | | | | 568 +---------> | | | | 569 | | | RESV | | 570 | +---------+--...----+---------+---------> 571 | | | | | | 572 | Diameter QoS | | | 573 | Application | | | 574 | Request (Token) | | | 575 | +---------> | | | 576 | | Diameter QoS | | 577 | | Application | | 578 | | Request (Token) | | 579 | | +---------> | | 580 | | Diameter QoS | | 581 | | Application | | 582 | | Response(QoS) | | 583 | | <---------+ | | 584 | Diameter QoS | | | 585 | Application | | | 586 | Response(QoS) | | | 587 | <---------+ | | | 588 |+--------+--------+| | | | 589 |+QoS Authorization|| | | | 590 || Enforcement || | | | 591 || Decision || | | | 592 |+--------+--------+| | | | 593 | | | | | | 594 | |Allow or Delete RSVP Path | | 595 <---------0---------+---------+---------+---------> 596 | | 200 OK | | | 597 <---------+---------+---------+---------+---------+ 598 | | | | | | 599 | | | | | | 601 Figure 9: Message flow with RSVP and Diameter QoS Application 603 A future version of this document will describe scenarios with other 604 authorization models. 606 5.7 Security Considerations 608 This document describes a mechanism for performing authorization of a 609 QoS reservation at a third party entity. Thereby, it is necessary to 610 understand the QoS signaling protocol to forward the necessary 611 information to the backend AAA server. This functionality is 612 particularly useful in roaming environments where the authorization 613 decision is most likely provided at an entity where the user is 614 known. To provide proper authorization authentication might be 615 necessary at least for the generic third party model (described in 616 Section 3.6 of [I-D.ietf-nsis-qos-nslp]. The concept of an 617 authorization token based third party approach is also described in 618 the same document. The impact of the existence of different 619 authorization models is (with respect to this Diameter QoS 620 application) the ability to carry different authentication and 621 authorization information. 623 Further discussions on the authorization handling for QoS signaling 624 protocols is available with [I-D.tschofenig-nsis-aaa-issues] and 625 [I-D.tschofenig-nsis-qos-authz-issues]. 627 5.8 Acknowledgments 629 The authors would like to thank Tseno Tsenov for his early 630 implementation work of this proposal. 632 5.9 Open Issues 634 During our work on this document we identified the following open 635 issues: 637 o The security functionality of RSVP has been analysed in 638 [I-D.ietf-nsis-rsvp-sec-properties]. Some of the mechanisms 639 proposed with [RFC3182] do not seem to be adquate for today's 640 usage. Hence, there is the question which functionality should be 641 supported by the Diameter QoS application. 643 o This Diameter QoS application can reuse a number of other Diameter 644 applications. This is a big advantage over other approaches. 645 This interaction and a list of useful attributes needs to be 646 collected and described. This aspect is for further study. 648 o The NSIS group is currently working on QoS models. As soon as 649 results are available it is feasible to incorporate them into this 650 Diameter application to build a complete solution for QoS 651 signaling which uses a backend infrastructure. 653 o Several authorization models have been described in 654 [I-D.ietf-nsis-qos-nslp]. Section 5.6 currently addresses only 655 the third party approach using authorization tokens. Further work 656 is needed to describe the details of a generic three party 657 scenario. 659 o Section 3.3 describes the session termination functionality. 660 Should a new command code for bearer gating purposes be 661 introduced, i.e., what if the application server wants to 662 temporarily disable the bearer without terminating the session 663 with ASR? 665 o Section 3.2 raises the question of a re-authorizing capability for 666 the Diameter application. The authors think that such a 667 re-authorization capability would be desirable (e.g., using with 668 the RAR/RAA message exchange). Note that it would require the 669 bearer path signaling protocol (for example RSVP or NSIS) to 670 support network-initiated re-auth, which might not always be in 671 place. There should be a failure code for the case where the 672 underlying bearer signaling protocol does not support it. 674 o The QoS-Filter-Rule is of type IPFilterRule and specifies which 675 traffic has to experience QoS treatment. The definition of the 676 IPFilterRule in [RFC3588] does not explicitly list the capability 677 to support IPsec protected traffic. Such a flow identifier 678 description is required with NSIS and [RFC2207]. 680 6. References 682 6.1 Normative References 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", March 1997. 687 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 688 Arkko, "Diameter Base Protocol", RFC 3588, September 2003, 689 . 691 6.2 Informative References 693 [I-D.alfano-aaa-qosreq] 694 Alfano, F., McCann, P., Towle, T., Ejzak, R. and H. 695 Tschofenig, "Requirements for a QoS AAA Protocol", 696 draft-alfano-aaa-qosreq-01 (work in progress), October 697 2003, . 699 [I-D.ietf-aaa-diameter-cc] 700 Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H. 701 Hakala, "Diameter Credit-control Application", 702 draft-ietf-aaa-diameter-cc-05 (work in progress), May 703 2004, . 705 [I-D.ietf-aaa-diameter-nasreq] 706 Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 707 Network Access Server Application", 708 draft-ietf-aaa-diameter-nasreq-16 (work in progress), June 709 2004, . 711 [I-D.ietf-aaa-diameter-sip-app] 712 Garcia-Martin, M., "Diameter Session Initiation Protocol 713 (SIP) Application", draft-ietf-aaa-diameter-sip-app-02 714 (work in progress), April 2004, 715 . 717 [I-D.ietf-aaa-eap] 718 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 719 Authentication Protocol (EAP) Application", 720 draft-ietf-aaa-eap-08 (work in progress), June 2004, 721 . 723 [I-D.ietf-nsis-qos-nslp] 724 Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for 725 Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-03 726 (work in progress), May 2004. 728 [I-D.ietf-nsis-rsvp-sec-properties] 729 Tschofenig, H. and R. Graveman, "RSVP Security 730 Properties", draft-ietf-nsis-rsvp-sec-properties-04 (work 731 in progress), February 2004, 732 . 734 [I-D.qspecteam-nsis-nslp-qspec] 735 Ash, J., Bader, A. and C. Kappler, "QoS-NSLP Qspec 736 Template", draft-qspecteam-nsis-nslp-qspec-00 (work in 737 progress), May 2004, 738 . 740 [I-D.tschofenig-nsis-aaa-issues] 741 Tschofenig, H., "NSIS Authentication, Authorization and 742 Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 743 (work in progress), March 2003, 744 . 746 [I-D.tschofenig-nsis-qos-authz-issues] 747 Tschofenig, H., "QoS NSLP Authorization Issues", 748 draft-tschofenig-nsis-qos-authz-issues-00 (work in 749 progress), June 2003, 750 . 752 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. 753 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 754 Functional Specification", RFC 2205, September 1997, 755 . 757 [RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC 758 Data Flows", RFC 2207, September 1997, 759 . 761 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 762 Services", RFC 2210, September 1997, 763 . 765 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 766 Protocol", RFC 2327, April 1998, . 768 [RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. 769 and A. Sastry, "COPS usage for RSVP", RFC 2749, January 770 2000, . 772 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 773 Herzog, S. and R. Hess, "Identity Representation for 774 RSVP", RFC 3182, October 2001, . 776 [RFC3313] Marshall, W., "Private Session Initiation Protocol (SIP) 777 Extensions for Media Authorization", RFC 3313, January 778 2003, . 780 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session 781 Authorization Policy Element", RFC 3520, April 2003. 783 [RFC3521] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session 784 Set-up with Media Authorization", RFC 3521, April 2003. 786 Authors' Addresses 788 Frank M. Alfano 789 Lucent Technologies 790 1960 Lucent Lane 791 Naperville, IL 60563 792 USA 794 Phone: +1 630 979 7209 795 EMail: falfano@lucent.com 797 Peter J. McCann 798 Lucent Technologies 799 1960 Lucent Lane 800 Naperville, IL 60563 801 USA 803 Phone: +1 630 713 9359 804 EMail: mccap@lucent.com 806 Hannes Tschofenig 807 Siemens 808 Otto-Hahn-Ring 6 809 Munich, Bayern 81739 810 Germany 812 EMail: Hannes.Tschofenig@siemens.com 814 Appendix A. AVP Formats 816 This section provides a strawman proposal for the AVPs introduced by 817 this document. Additionally, the content of the payload is 818 described. Unlike the approach followed with RSVP (see [RFC2749]) 819 where the entire RSVP message is encapsulated into a COPS message 820 this approach only includes the relevant fields. This approach 821 avoids a certain overhead of transmitting fields which are irrelevant 822 for the AAA infrastructure, it keeps implementations simpler and it 823 allows to reuse other Diameter AVPs. Finally, it helps to make this 824 Diameter application less dependent on any particular QoS signaling 825 protocol or a particular QoS model. 827 A.1 RSVP to Diameter QoS AVPs Mapping 829 The following RSVP objects need to be mapped to the Diameter QoS 830 AVPs: FLOWSPEC, FILTER_SPEC and POLICY_DATA. The FLOWSPEC defines a 831 desired QoS, in a Resv message. FILTER_SPEC defines a subset of 832 session data packets that should receive the desired QoS (specified 833 by a FLOWSPEC object), in a Resv message. POLICY_DATA carries 834 information about the user requesting QoS resources. 836 A.1.1 RSVP Objects for the QoS-RSVP AVP 838 The QoS-Flow-state AVP has to carry QoS specific information. This 839 section describes payloads which are relevant for the transport of 840 RSVP QoS specific payloads. 842 The subsequently listed RSVP objects are taken from [RFC2210] and 843 [RFC2205]. For completeness we list these attributes in this 844 section. 846 The RSVP FLOWSPEC object, including the RSVP object header, for 847 requesting Controlled-Load Service is described below: 849 31 24 23 16 15 8 7 0 850 +---------------+---------------+---------------+---------------+ 851 | Length (32 bytes) | Class = 9 | C-Type =2 | 852 +---------------+---------------+---------------+---------------+ 853 | 0 (a) | reserved | 7 (b) | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | 5 (c) |0| reserved | 6 (d) | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | 127 (e) | 0 (f) | 5 (g) | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Token Bucket Size [b] (32-bit IEEE floating point number) | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Peak Data Rate [p] (32-bit IEEE floating point number) | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Minimum Policed Unit [m] (32-bit integer) | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Maximum Packet Size [M] (32-bit integer) | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 (a) - Message format version number (0) 871 (b) - Overall length (7 words not including header) 872 (c) - Service header, service number 5 (Controlled-Load) 873 (d) - Length of controlled-load data, 6 words not including 874 per-service header 875 (e) - Parameter ID, parameter 127 (Token Bucket TSpec) 876 (f) - Parameter 127 flags (none set) 877 (g) - Parameter 127 length, 5 words not including per-service 878 header 880 The RSVP FLOWSPEC object, including the RSVP object header, for 881 requesting Guaranteed Service is described below: 883 31 24 23 16 15 8 7 0 884 +---------------+---------------+---------------+---------------+ 885 | Length (44 bytes) | Class = 9 | C-Type =2 | 886 +---------------+---------------+---------------+---------------+ 887 | 0 (a) | Unused | 10 (b) | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | 2 (c) |0| reserved | 9 (d) | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | 127 (e) | 0 (f) | 5 (g) | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Token Bucket Size [b] (32-bit IEEE floating point number) | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Peak Data Rate [p] (32-bit IEEE floating point number) | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Minimum Policed Unit [m] (32-bit integer) | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Maximum Packet Size [M] (32-bit integer) | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | 130 (h) | 0 (i) | 2 (j) | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Rate [R] (32-bit IEEE floating point number) | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Slack Term [S] (32-bit integer) | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 (a) - Message format version number (0) 911 (b) - Overall length (9 words not including header) 912 (c) - Service header, service number 2 (Guaranteed) 913 (d) - Length of per-service data, 9 words not including per-service 914 header 915 (e) - Parameter ID, parameter 127 (Token Bucket TSpec) 916 (f) - Parameter 127 flags (none set) 917 (g) - Parameter 127 length, 5 words not including parameter header 918 (h) - Parameter ID, parameter 130 (Guaranteed Service RSpec) 919 (i) - Parameter 130 flags (none set) 920 (j) - Parameter 130 length, 2 words not including parameter header 922 A.1.2 RSVP Objects for the Filter-Rule AVP 924 The RSVP FLOWSPEC needs to be associated with the FILTER_SPEC to 925 describe which traffic should experience QoS treatment. The 926 subsequent attributes list relevant payloads used in RSVP for this 927 purpose. These objects need to be carried in the Filter-Rule AVP. 929 The subsequent attributes are reused from RSVP and show the 930 attributes that have to be supported. 932 The IPv4 FILTER_SPEC object has the following structure: 934 31 24 23 16 15 8 7 0 935 +---------------+---------------+---------------+---------------+ 936 | Length ( 8 bytes) | Class = 10 | C-Type =1 | 937 +---------------+---------------+---------------+---------------+ 938 | IPv4 SrcAddress (4 bytes) | 939 +---------------+---------------+---------------+---------------+ 940 | ////// | ////// | SrcPort | 941 +---------------+---------------+---------------+---------------+ 943 The IPv6 FILTER_SPEC object has the following structure: 945 31 24 23 16 15 8 7 0 946 +---------------+---------------+---------------+---------------+ 947 | Length (20 bytes) | Class = 10 | C-Type =2 | 948 +---------------+---------------+---------------+---------------+ 949 | | 950 + + 951 | | 952 + IPv6 SrcAddress (16 bytes) + 953 | | 954 + + 955 | | 956 +---------------+---------------+---------------+---------------+ 957 | ////// | ////// | SrcPort | 958 +---------------+---------------+---------------+---------------+ 960 The IPv6 Flow-label FILTER_SPEC has the following structure: 962 31 24 23 16 15 8 7 0 963 +---------------+---------------+---------------+---------------+ 964 | Length (20 bytes) | Class = 10 | C-Type = 3 | 965 +---------------+---------------+---------------+---------------+ 966 | | 967 + + 968 | | 969 + IPv6 SrcAddress (16 bytes) + 970 | | 971 + + 972 | | 973 +---------------+---------------+---------------+---------------+ 974 | ////// | Flow Label (24 bits) | 975 +---------------+---------------+---------------+---------------+ 977 The IPv4/GPI FILTER_SPEC object, which was introduced with [RFC2207] 978 has the following structure: 980 +-------------+-------------+-------------+-------------+ 981 | IPv4 SrcAddress (4 bytes) | 982 +-------------+-------------+-------------+-------------+ 983 | Generalized Port Identifier (GPI) | 984 +-------------+-------------+-------------+-------------+ 986 The IPv6/GPI FILTER_SPEC object, which was introduced with [RFC2207] 987 has the following structure: 989 +-------------+-------------+-------------+-------------+ 990 | | 991 + + 992 | | 993 + IPv6 SrcAddress (16 bytes) + 994 | | 995 + + 996 | | 997 +-------------+-------------+-------------+-------------+ 998 | Generalized Port Identifier (GPI) | 999 +-------------+-------------+-------------+-------------+ 1001 The Generalized Port Identifier (GPI) contains the SPI. 1003 A.1.3 RSVP Objects for the QoS-Auth-Resources 1005 User authentication/authorization capabilities have been added to 1006 RSVP with [RFC3182]. Additionally, a token-based authorization 1007 mechanism has been proposed with [RFC3520] and [RFC3521] which should 1008 also supported by this Diameter application. A future version of 1009 this document will map these objects to QoS-Auth-Resources AVP (or 1010 related attributes). Please also see the open issue in Section 5.9. 1012 A.2 NSIS to Diameter QoS AVPs Mapping 1014 A future version of this document will contain payload descriptions 1015 of objects introduced by the NSIS protocol suite. Relevant 1016 parameters can be found in [I-D.ietf-nsis-qos-nslp] and in the area 1017 of QoS models (see [I-D.qspecteam-nsis-nslp-qspec] for ongoing work). 1019 A.3 SIP to Diameter QoS AVPs Mapping 1021 QoS authorization with the Diameter QoS Application requires that 1022 also SIP specific mechanisms are exchanged via Diameter. A future 1023 version of this document will describe the mapping of SDP payloads 1024 [RFC2327] to this Diameter application. 1026 Intellectual Property Statement 1028 The IETF takes no position regarding the validity or scope of any 1029 Intellectual Property Rights or other rights that might be claimed to 1030 pertain to the implementation or use of the technology described in 1031 this document or the extent to which any license under such rights 1032 might or might not be available; nor does it represent that it has 1033 made any independent effort to identify any such rights. Information 1034 on the procedures with respect to rights in RFC documents can be 1035 found in BCP 78 and BCP 79. 1037 Copies of IPR disclosures made to the IETF Secretariat and any 1038 assurances of licenses to be made available, or the result of an 1039 attempt made to obtain a general license or permission for the use of 1040 such proprietary rights by implementers or users of this 1041 specification can be obtained from the IETF on-line IPR repository at 1042 http://www.ietf.org/ipr. 1044 The IETF invites any interested party to bring to its attention any 1045 copyrights, patents or patent applications, or other proprietary 1046 rights that may cover technology that may be required to implement 1047 this standard. Please address the information to the IETF at 1048 ietf-ipr@ietf.org. 1050 Disclaimer of Validity 1052 This document and the information contained herein are provided on an 1053 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1054 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1055 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1056 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1057 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1058 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1060 Copyright Statement 1062 Copyright (C) The Internet Society (2004). This document is subject 1063 to the rights, licenses and restrictions contained in BCP 78, and 1064 except as set forth therein, the authors retain all their rights. 1066 Acknowledgment 1068 Funding for the RFC Editor function is currently provided by the 1069 Internet Society.