idnits 2.17.00 (12 Aug 2021) /tmp/idnits4213/draft-groeting-eap-netselection-results-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1235. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1251), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** 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: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == 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 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 539: '... AAA-Server SHOULD discard these pac...' RFC 2119 keyword, line 592: '... supplicant SHOULD send an EAP logof...' 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 6515 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) == Unused Reference: 'ISO4217' is defined on line 923, but no explicit reference was found in the text == Outdated reference: draft-adrangi-eap-network-discovery has been published as RFC 4284 ** Downref: Normative reference to an Informational draft: draft-adrangi-eap-network-discovery (ref. 'I-D.adrangi-eap-network-discovery') == Outdated reference: draft-ietf-eap-netsel-problem has been published as RFC 5113 ** Downref: Normative reference to an Informational draft: draft-ietf-eap-netsel-problem (ref. 'I-D.ietf-eap-netsel-problem') -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1X' == Outdated reference: A later version (-04) exists of draft-arkko-eap-service-identity-auth-00 == Outdated reference: draft-tschofenig-eap-ikev2 has been published as RFC 5106 -- Obsolete informational reference (is this intentional?): RFC 3770 (Obsoleted by RFC 4334) Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 2 EAP W. Groeting 3 Internet-Draft S. Berg 4 Expires: January 10, 2005 M. Ness 5 H. Tschofenig 6 Siemens AG 7 July 12, 2004 9 Network Selection Implementation Results 10 draft-groeting-eap-netselection-results-00 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 10, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document aims to highlight implementation results on network 44 discovery as well as some new ideas for its extension. The 45 implementation is based on the draft on mediating network discovery, 46 a mechanism that enables a mobile node to discover roaming partners 47 of an access network via EAP. The concept allows automatic network 48 selection of end hosts, based on additional parameters, hence 49 reducing interacting with the user.This document should also open a 50 discussion on the need on network capability mechanisms. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Concept Aspects . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1 Why has EAP been proposed to exchange this type of 58 information . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.2 Information from the Access Network . . . . . . . . . . . 6 60 2.2.1 Roaming Agreements . . . . . . . . . . . . . . . . . . 6 61 2.2.2 Cost of network resource usage . . . . . . . . . . . . 7 62 2.2.3 Quality of Services . . . . . . . . . . . . . . . . . 7 63 2.2.4 Authorisation Information . . . . . . . . . . . . . . 7 64 2.2.5 Privacy Policy . . . . . . . . . . . . . . . . . . . . 8 65 2.2.6 Middlebox Devices . . . . . . . . . . . . . . . . . . 8 66 3. Implementation Aspects and Test Environment . . . . . . . . . 9 67 3.1 Design of Information transmitted . . . . . . . . . . . . 10 68 3.2 Implementation at the AAA-Server . . . . . . . . . . . . . 11 69 3.3 Implementation at the Supplicant . . . . . . . . . . . . . 13 70 3.4 Test Platform . . . . . . . . . . . . . . . . . . . . . . 14 71 3.4.1 FreeRADIUS . . . . . . . . . . . . . . . . . . . . . . 14 72 3.4.2 Xsupplicant . . . . . . . . . . . . . . . . . . . . . 15 73 3.4.3 Challenges . . . . . . . . . . . . . . . . . . . . . . 15 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 22 79 7.2 Informative References . . . . . . . . . . . . . . . . . . . 22 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 81 A. Cost Attribute . . . . . . . . . . . . . . . . . . . . . . . . 25 82 A.1 Cost-Header Attribute . . . . . . . . . . . . . . . . . . 25 83 A.2 Cost-Unit SubAttribute . . . . . . . . . . . . . . . . . . 26 84 A.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 B. QoS Attribute . . . . . . . . . . . . . . . . . . . . . . . . 29 86 B.1 UMTS QoS-Classes . . . . . . . . . . . . . . . . . . . . . 29 87 B.2 QoS-Header Attribute . . . . . . . . . . . . . . . . . . . 29 88 B.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . 30 89 Intellectual Property and Copyright Statements . . . . . . . . 31 91 1. Introduction 93 Wireless LANs (WLAN) are receiving more attention as a complementary 94 technology to 3G and there is an ever increasing number of hotspot 95 deployments in areas such as airports and hotels. Currently, these 96 hotspots are managed by Wireless ISP (WISP) operators that do not 97 have an existing cellular subscriber base. Soon, WISP will provide 98 WLAN access to a multiple number of mobile network providers. 100 To support the selection of a Roaming enabled WISP, the mechanism for 101 mediating network discovery, as described in 102 [I-D.adrangi-eap-network-discovery], can be used. This document 103 highlights some implementation aspects of this draft and discusses 104 some extensions to it. These parameters could be, e.g., cost and 105 quality of service information. These parameters allow the end host 106 to make a more intelligent network selection decision. 108 The objectives of the draft are to show the need for and the 109 advantages of network discovery. It is primarily intended to trigger 110 a discussion on a scalable network discovery mechanism, which will 111 support end hosts regarding appropriate network selection. 113 As the discussion has already been started within different 114 organizations like 3GPP and IEEE, a discussion on the information 115 transmitted as well as the mechanism itself needs to take place. The 116 authors would like to forward the discussion within the IETF by 117 presenting some implementation findings and some ideas on not yet 118 solved open issues. 120 The draft is based on results of an implementation that covers one of 121 the three options for mediating network discovery. Next to the 122 mediating networks additional parameters have been defined and 123 encoded as described within this document. 125 This document is structured as follows. Section 2 covers the 126 conceptual aspects and considered network information elements, 127 followed by the implementation results in section 3. Section 4 128 covers the security considerations and finally a conclusion is given 129 in section 5. In the annex, some additional information on pricing 130 and QoS issues is given. 132 1.1 Terminology 134 authenticator 136 The end of the link initiating EAP authentication. The term 137 authenticator is used in [IEEE-802.1X], and has the same meaning in 138 this document. 140 peer 142 The end of the link that responds to the authenticator. In 143 [IEEE-802.1X], this end is known as the Supplicant. 145 Supplicant 147 The end of the link that responds to the authenticator in 148 [IEEE-802.1X]. In this document, this end of the link is called the 149 peer. 151 backend authentication server 153 A backend authentication server is an entity that provides an 154 authentication service to an authenticator. When used, this server 155 typically executes EAP methods for the authenticator. This 156 terminology is also used in [IEEE-802.1X]. 158 AAA 160 Authentication, Authorization, and Accounting. AAA protocols with 161 EAP support include RADIUS and Diameter. 163 2. Concept Aspects 165 As the number of IEEE 802.11 wireless access networks proliferates, 166 the support of roaming functionalities and thus the efficient 167 exchange of mediating network information becomes more and more 168 important [I-D.adrangi-eap-network-discovery]. Local WISPs are 169 interested in offering their access points to a large number of users 170 from other providers, and at the same time mobile operators are 171 anxious to integrate WLAN access even through intermediary networks 172 into their packet switched system. 174 To support more intelligent end host decisions, it seems to be 175 beneficial to discover certain characteristics about the network up 176 front during the association and authentication phase. Such 177 information could include authentication models, roaming information, 178 quality of service (see Appendix B) and cost parameters (see Appendix 179 A). 181 2.1 Why has EAP been proposed to exchange this type of information 183 The IETF draft by Adrangi et al. [I-D.adrangi-eap-network-discovery] 184 proposes a solution to transport mediating network information within 185 the EAP protocol and thus enables 3GPP/WLAN interworking and roaming. 187 EAP is a generic container protocol that can - in theory - carry any 188 information desired by the network (as long as both sides of the 189 information exchange understand the information that they are 190 receiving). It is an obvious choice for Layer 2 information exchange 191 about network capabilities since it is highly likely that EAP will be 192 implemented in both, the end host and the network. However, when EAP 193 is used in this fashion (i.e., beyond its original intention) it is 194 important to note that there are possible impacts on security, 195 scalability and the EAP state machine. 197 One idea is to extend this mechanism to include extra data within 198 Identity-Messages, e.g., requiring a certain bit rate or a certain 199 quality of service. If information can be carried in identity 200 messages, then the end host can make further decisions based on it, 201 before the full authentication procedure has been completed (and 202 hence probably before accounting has started). This is particularly 203 useful for the case of cost and service availability information. 205 However, it needs to be taken into account that an EAP identity 206 message, including any information carried within, is not protected. 207 In addition, if the amount of exchanged information is too large then 208 performance characteristics of EAP as an information transport 209 protocol will become a limitation. 211 2.2 Information from the Access Network 213 The end host can retrieve information about the access network 214 dynamically when it moves into coverage of that network. This 215 information is retrieved via a link layer network capability 216 discovery mechanism. Each piece of information may or may not have 217 an effect on whether or not the end host attaches to and 218 authenticates with that network. 220 As already proposed in [I-D.adrangi-eap-network-discovery] the 221 discovery of roaming agreements and mediating networks is a valuable 222 access network information. This can be extended by other access 223 network information elements like costs and charging, quality of 224 service, authorization information, privacy policy and middlebox 225 devices, which help the end host to make his attachment decision. 227 The information required within multimode end hosts to support 228 efficient interface selection and network capability discovery 229 algorithms are classified according their importance. Mandatory 230 indicates that this should be included in near term implementations 231 of the algorithms, optional indicates that the availability of this 232 information improves the quality of the algorithm decisions, but is 233 not vital to its operation. 235 The time of information discovery is classified related to the moment 236 of association, i.e. the establishment of medium access control 237 (MAC) transport services between access point/station (AP/STA), and 238 authentication, the service used to establish the identity of one 239 station as a member of the set of stations authorized to associate 240 with another station [IEEE-SPEC-99]. 242 The expected lifetime of the information, i.e. how frequently this 243 information is updated and how persistent the information is within 244 the end host, is characterized by the following categories: 246 Duration of session: the information is only valid for the 247 lifetime of the session of an application with which it is 248 associated 249 Duration of attach: the information is only valid for the lifetime 250 of the interface attachment to that AN. 251 Inter-attach: the information is stored between attachments to an 252 AN, but will timeout after some defined period. 254 2.2.1 Roaming Agreements 256 This information specifies what roaming agreements are in place in 257 the network. It allows the mobile node to determine whether it can 258 authenticate with the network, and which subscription credentials to 259 use. 261 Importance: Mandatory for authentication purpose 262 When discovered: Pre-authentication 263 How dynamic: Inter-attach 265 2.2.2 Cost of network resource usage 267 This information provides hints to the user device about the cost of 268 using this network. It is useful to support mobile nodes that base 269 network selection services on more complex policies based on user 270 preferences, such as always use the cheapest. The cost information 271 provided by the access network can be manifold. It includes 272 information on the access network itself, cost information of roaming 273 partners, different charging modes (per data, per time, per service, 274 flat) and other information like the amount, currency, number of 275 units, etc. The definition of an appropriate data format is subject 276 of further investigation 278 Importance: Optional 279 When discovered: Preferably pre-authentication 280 How dynamic: Inter-attach 282 2.2.3 Quality of Services 284 Each network may support different levels of quality of service (e.g. 285 there are four QoS classes in 3GPP) that can support different data 286 rates. The multimode end host may be required to make decisions 287 about whether or not to attach to a network based on what QoS can 288 offer. 290 Importance: Optional, this is a useful hint, especially for 291 handover scenarios 292 When discovered: Pre-authentication 293 How dynamic: Inter-attach 295 2.2.4 Authorisation Information 297 The AN will receive information from the home network about what the 298 user is authorized to access and for how long. If this information 299 can be transferred to the MT then it can be used to make informed 300 decisions e.g. about interface selection - there is no point 301 choosing to use an interface if it is about to become idle because 302 the time for which it is authorized is nearly finished. It would 303 also be useful for feedback to the user. As this information might 304 belong to a particular user, it needs further investigation on how to 305 secure such kind of information. A plain authorization information 306 advertisement seems rather difficult to realize. 308 Importance: Optional 309 When discovered: Pre-authentication 310 How dynamic: Duration of Session 312 The functionality required to obtain this information is quite 313 complex and does not yet exist so this information is considered to 314 be optional at the moment. 316 2.2.5 Privacy Policy 318 Access networks have the ability to monitor the users behaviors with 319 regard to their application layer usage (e.g., HTTP or SIP) and to 320 create user specific profiles. Many network access authentication 321 protocols allow networks to learn the user identity since 322 authentication and key exchange protocols which support user identity 323 confidentiality are rarely used. The increasing deployment of 324 location based services creates an additional privacy threat for end 325 users. Similarly to the privacy initiatives in the web environment 326 additional information about the privacy policy of an access network 327 can be communicated. Such indication might reveal an end user that a 328 particular network does not distribute location information to the 329 user's home network during network access authentication, location 330 information is not provided to third parties other than the network 331 or that no application specific information is provided to third 332 parties. 334 Importance: Optional 335 When discovered: Pre-authentication 336 How dynamic: Duration of attach 338 2.2.6 Middlebox Devices 340 There are several types of applications that do not operate well if 341 there is a NAT or firewall between communicating hosts/servers. Some 342 examples of such applications are games, VoIP applications, H323/SIP, 343 some instant message applications, and quality of service signaling 344 protocols such as RSVP. 346 Consequently, the end host may need to know whether there are any 347 middlebox devices, e.g. firewalls and NATs present in the AN in case 348 the user wants to use applications that have a problem with them. A 349 network without a middlebox device would be preferable. 351 Importance: Optional 352 When discovered: Pre-authentication 353 How dynamic: Duration of attach 355 3. Implementation Aspects and Test Environment 357 In Section 3 of [I-D.adrangi-eap-network-discovery] three options for 358 delivering mediating network information with EAP are proposed. Each 359 of these options uses a Identity-Request to submit this information. 360 Only option 3 can be implemented without any modification of the AP 361 and with every AP which is IEEE 802.1x enabled. Option 3 uses only 362 the AAA server to transmit information to the end host (i.e., 363 supplicant) rather than a modified access point. Hence, the authors 364 think that this approach works for most existing systems. Lower 365 effort and costs of implementation and better backwards compatibility 366 are the reasons to favor this option for an implementation. 368 Figure 1 demonstrates the information exchange between supplicant, AP 369 and AAA server when implementing the preferred solution: 371 Wireless AP AN RADIUS 372 Client server 373 | (1) | | 374 | EAP Id. Req. | | 375 |< ------------| | 376 | | | 377 | (2) | | 378 | EAP Id. Resp.| | 379 |------------ >| (3) | 380 | |Access Request | 381 | |(EAP Id. Resp.) | 382 | |-------------- >| 383 | | | 384 | | (4) | 385 | |Access Challenge| 386 | |(EAP Id. Req. + | 387 | | (Network Info) | 388 | (5) |< --------------| 389 | EAP Id. Req. | | 390 |(Network Info)| | 391 |< ------------| | 392 | | | 393 | (6) | | 394 |EAP Id. Resp. | | 395 | | | 396 |------------ >| (7) | 397 | |Access Request | 398 | |(EAP Id. Resp.) | 399 | |-------------- >| 400 | ... | ... | 401 |< EAP Authentication Methods > | 402 | ... | ... | 403 | | | 404 | (8) | | 405 | EAP Success | | 406 |< ------------| | 408 Figure 1: Option 3: Use a subsequent EAP-Identity Request issued by 409 the access network RADIUS server 411 Based on this model the following subchapters explain the 412 implementation in a working test environment. 414 3.1 Design of Information transmitted 416 Beneath the definition of a Netinfo-Packet, which offers the 417 possibility to check if the Data field in an EAP packet is used for 418 network information, the syntax for the network information has to be 419 defined, too. 421 In [I-D.adrangi-eap-network-discovery] the following syntax is 422 proposed: network-info = attribute "=" value. for just transmitting 423 the names of the mediating networks, this syntax is useful. When 424 offering e.g. six attributes about three mediating networks there 425 occurs a problem with the space available in the EAP packet. A 426 solution to that problem is to send the network information in a 427 defined order, seperated with a defined delimiter. Figure 2 is a 428 possible way to transmit information about: the name of the mediating 429 network, the cost of the mediating network, roaming agreements, 430 quality of service , middlebox information and authorisation 431 information (in this exemplary for three mediating networks): 433 _______________________ 434 | | | | 435 | MN1 | MN2 | MN3 | MN: Mediating Network 436 | | | | 437 |-------|-------|-------| 438 | | | | 439 | C1 | C2 | C3 | C: Cost 440 | | | | 441 |-------|-------|-------| 442 | | | | 443 | RA1 | RA2 | RA3 | RA: Roaming Agreements 444 | | | | 445 |-------|-------|-------| 446 | | | | 447 | QS1 | QS2 | QS3 | QS: Quality of Service 448 | | | | 449 |-------|-------|-------| 450 | | | | 451 | MI1 | MI2 | MI3 | MI: Middlebox Information 452 | | | | 453 |-------|-------|-------| 454 | | | | 455 | AI1 | AI2 | AI3 | AI: Authorisation Information 456 | | | | 457 |-------|-------|-------| 458 | | | | 459 | PP1 | PP2 | PP3 | PP: Privacy Policy 460 | | | | 461 ----------------------- 463 Figure 2: Matrix for Network Information 465 Converted into a string this data looks like (used "," as delimeter 466 between attributes and ";" as delimeter between values): 467 network-information=MN1;MN2;MN3,Cost1;Cost2;Cost3, 468 RA1;RA2;RA3,QS1;QS2;QS3,MI1;MI2;MI3,AI1;AI2;AI3,PP1;PP2;PP3 470 Beneath the benefit of saving valuable space in the EAP packet this 471 syntax has one disadvantage: to interpret the data on supplicant side 472 correct, from all mediating networks all parameters have to be 473 transmitted. If none of the mediating networks offers a specific 474 parameter, this parameter has to be transmitted as a NULL. 476 3.2 Implementation at the AAA-Server 478 In an authentication process the AAA-Server normally receives an 479 Access Request/Identity-Response which is sent by the supplicant and 480 passed trough by AP. As response to this message the AAA-Server has 481 to react with an Access Challenge including the start sequence for 482 the chosen EAP authentication method. At this point we have to 483 intervene and query which packet to send now. Figure 3 shows the 484 possible decisions: 486 ----------- 487 | incoming | 488 | Id. Resp. | 489 |___________| 490 | 491 | 492 V 493 ____ 494 / \ 495 /realm \ yes 496 | |-----------------------| 497 \known / | 498 \____/ | 499 | | 500 | no | 501 V | 502 ____ ____ | 503 / \ / \ | 504 /decor.\ yes / MN \ yes | 505 | |------>| |------>| 506 \ NAI / \known / | 507 \____/ \____/ | 508 | | | 509 | no | no | 510 V | V 511 ----------- | ----------- 512 | send Id. | | | start | 513 | Req. with |<--------| | Authentic.| 514 | NI | | method | 515 |___________| |___________| 517 Figure 3: Decision on incoming Identity-Response 519 There are three queries to be done for knowing, how to react on an 520 incoming Identity-Response: 522 o Check if the realm submitted with the username is known 523 o Check if the username includes a decorated-nai 524 o Check if the mediating network submitted with the decorated-nai is 525 known 527 If any of this queries can be answered with "yes" the normal 528 authentication process can be started. Otherwise an Access Challenge 529 including an EAP Identity-Request which submits mediating network 530 information has to be sent [I-D.adrangi-eap-network-discovery]. 532 One thing missing in this behaviour model is the reaction on an 533 Identity-Response which arrives the second time - without having 534 changed anything in username attribute. For this reason a counter 535 has to be inserted into FreeRADIUS-code which makes it possible to 536 check for packets who are arriving more than one time. As proposed 537 in [I-D.adrangi-eap-network-discovery] the AAA-Server has to handle 538 these packets based on the local routing policy. In fact the 539 AAA-Server SHOULD discard these packets and send an EAP Failure 540 packet which stops the authentication process. 542 This proceeding modifies the AAA-Server that way, that he is still 543 able to handle authentication request from unmodified supplicants 544 (they only have send a valid realm or mediating network). Also 545 supplicants which send an Identity-Response including a valid 546 decorated-nai directly, do not have to receive an additional 547 Identity-Request because they already chose the mediating network. 549 3.3 Implementation at the Supplicant 551 At supplicant side there is also one point where it makes most sense 552 to implement a query when to send a decorated-nai. This is on every 553 incoming Identity-Request. For example all incoming 554 Identity-Requests could be checked for their size, and then be 555 interpreted or not. 557 Next step is to validate the data which received. Therefore header 558 information which came with the possible network information should 559 be interpreted. Figure 4 shows the possible design of a 560 Netinfo-Packet: 562 1 byte 2 bytes 1 byte 563 |------- |----------------|------- | 564 | Type | Length | NoM | 565 |--------|----------------|--------| 566 | Data | 567 |----------------------------------| 569 Figure 4: Design of a Netinfo-Packet 571 o "Type" is a 1 byte long field which defines of which version the 572 network information are (e.g.: Type 1 could only include 573 information about the names of the mediating networks. Whereas 574 Type 2 includes informations like e.g. costs, too). 576 o "Length" is 2 bytes long and contains the length of the string 577 included in the Data-field 578 o "NoM" is also 1 byte long and defines the number of mediating 579 networks, which are transmitted with that packet. 580 o "Data" contains a string with the network information 582 After the correctness of the network information is confirmed, the 583 data can be processed. Which data is exactly interpreted depends on 584 the preferences the user made, e.g. the setting "Always cheapest 585 connected" may only interpret "cost" and leave the rest unregarded. 587 Of importance is only, that the algorithmus comes to a decision if to 588 proceed authenticating to the access network and which mediating 589 network to choose. 591 If it decides not to continue with authenticating process, the 592 supplicant SHOULD send an EAP logoff packet. Else an 593 Identity-Response has to be sent, which includes a decorated-nai as 594 username. Part of this decorated-nai is the chosen mediating 595 network. 597 3.4 Test Platform 599 To ensure that this approach described before is not only of 600 theoretic nature it was necessary to build up a test system. This 601 test platform consists of an AAA-Server, an AP and a supplicant. The 602 following two subchapters give some hints on the installation, 603 configuration and modification of these three network components. 605 The aim of this implementation was not to develop a product ready for 606 market, but to point out that it is possible to realize the proposal 607 suggested by Adrangi and in this draft. Hence the way for 608 implementing was not to completly new develop all software, but to 609 find the shortest way for realization. This recommends to use 610 existing software, which is published under the GPL and therefore can 611 be modified. 613 3.4.1 FreeRADIUS 615 FreeRADIUS is an AAA-Server which was former developed as Cistron 616 RADIUS server and is now the leading AAA-Server developed for Linux 617 under the GPL. The sources are available for download at 618 http://www.freeradius.org/. 620 FreeRADIUS has a module for EAP authentication. The sources for this 621 module can be found in the directory src/modules/rlm_eap/. All 622 necessary modifications to FreeRADIUS has to be done in this 623 directory. 625 3.4.2 Xsupplicant 627 There are not many IEEE 802.1x implementations available for Linux 628 right now. Xsupplicant seems to be the most popular at the moment. 629 Xsupplicant is available for download at http://www.open1x.org/. It 630 is also developed under GPL. Xsupplicant is not a full 631 RADIUS-client, it is only ready for EAP authentication. 633 3.4.3 Challenges 635 While implementing one problem occured: the second Identity-Response 636 from Supplicant (which is the one with the Decorated-NAI inside) does 637 not arrive at the AAA-Server. Because the packet leaves the 638 Supplicant and cannot be discovered at the AAA-Server at all, the 639 packet seems to get lost at the AP. 641 Analysis on the AP (via Telnet a lot of debugging on the AP is 642 possible) resulted, that the Identity value of the Identity-Response 643 is not the one expected by the AP. It looks like the AP does not 644 store the Identity of the Identity-Request sent by the AAA-Server. 645 When the Identity-Response to that request arrives at the AP the 646 reaction is right: the message is blocked. 648 The solution is to prevent the AAA-Server from increasing the 649 Identity value in the EAP packet, when sending the second 650 Identity-Request. Hence it is sent with the same Identity like the 651 original Identity-Request and the AP lets the Identity-Response to 652 that packet pass. 654 4. Security Considerations 656 [I-D.ietf-eap-netsel-problem] tries to classify the problem space of 657 network selection: 659 Access Network discovery: 661 Access Network discovery is concerned about the selection of a 662 particular network (if multiple access networks are available) 663 based on a number of parameters. This section mainly focuses on 664 the security implication of this particular aspect. 666 Identifier selection: 668 Identifier selection plays a role when an end user has more than 669 one identifier to select from. The selected identifier might 670 impact the selected roaming partner of the attached network and 671 thus might have cost and performance implications. In some sense 672 this is a policy-based routing mechanism with interesting impacts 673 on the traditional Internet pricing where the edge pricing between 674 neighboring networks was excercised. In more sophisticated 675 scenarios one might imagine that IP packets are routed by the 676 access network through different ISPs depending on some 677 classifiers in the packet (such as DiffServ codepoints or 678 particular destination IP addresses). The security properties are 679 not well understood for these scenarios. As an example, one might 680 consider a moving network which has to change its roaming partners 681 over time based on mobility. How should the end host be notified 682 about the possible implication on the cost? Should the user be 683 re-authorized? How should the user be certain that such a provider 684 change was actually necessary? 686 AAA routing: 688 After selecting a particular identifier, the NAI is used to route 689 the AAA messages back to the home network (possibly via some 690 intermediate brokers). No dynamic routing protocols are available 691 for AAA routing and the selection of a particular route might have 692 impacts on the price. This issue is mostly outside the scope of 693 this document. 695 Payload routing: 697 As part of the authorization information provided by the home AAA 698 server the routing and treatment of packets might be affected. 699 The payload route binding problem refers to mismatch between the 700 routing of IP packet and the hinted (or offered) route. It needs 701 to be studied whether this is truly a problem. This issue is 702 outside the scope of this document. 704 There is a risk that a large number of service providers with complex 705 roaming agreements create a non-transparent service and 706 cost-structure. In a traditional subscription-based scenario users 707 are registered with their home networks and use this trust 708 relationship to dynamically establishment a financial settlement 709 between the home and the visited network and required security 710 associations (for example to provide link layer security between the 711 end host and an entity in the visited network such as the access 712 point). This is the typical AAA deployment scenario. In such a 713 scenarios users do not learn the identity of the access network as 714 part of a regular authentication and key exchange protocol message 715 exchange. The usage of EAP the Extensible Authentication Protocol in 716 IEEE 802.1x/IEEE 802.11i or also PANA never aimed to allow 717 authentication of the access network to the end host. As such, the 718 identity of the access network is not revealed (in a secure fashion). 719 The user is therefore only authenticated to the home network (and 720 hopefully vice versa). This design decision is also reflected in the 721 choice of identifier space used in the WLAN IEEE 802.11 environment. 722 The Service Set Identifier (SSID) does not mandate a structure and 723 hence is not really suitable as an identifier to perform 724 authentication and authorization. Overloading the SSID as an 725 identifier to indicate particular services is attractive, but fails 726 in most cases. In fact, most administrators of WLANs do not change 727 the default SSID (see for example [Pri04] for a study about WLAN 728 usage in London where approximately 40% of the access points are 729 running their default SSID.) Such an approach makes the phone book 730 (see [RFC3017]) approach (as an out-of-band mechanism to associate a 731 particular service to an identifier) difficult to deploy. The 732 approach of assisting with the selection of the appropriate 733 certificate based on a list of SSIDs as described in [RFC3770] will 734 also fail. Apart from this fact, the authentication and 735 authorization message exchange between the end host and the home 736 network is, for the subscription-based environment, required. Public 737 key based authentication between the end host and the access network 738 cannot replace the exchange between the end host and the home network 739 due to the need for a financial compensation. Hence, authentication 740 of the access network, if possible, could only aim to securely 741 exchange parameters between the end host and the visited network. 742 This draft discusses some of these parameters or objects (such as 743 cost or QoS parameters). Several approaches are possible to address 744 the problem of protecting the distributed information. 746 First, the access network might "broadcast" (or distribute) 747 information about the offered service (price, QoS, etc.). End hosts 748 process this information automatically and make their decision. The 749 access network might lie about the offered price (to the user) since 750 this information is not protected by any means. The access network 751 provide could charge the user more than "agreed". It would be 752 possible to verify the broadcasted information by utilizing the same 753 mechanism as proposed with the 'lying NAS' problem. This mechanism 754 requires that the distributed information can be securely exchanged 755 between the EAP peer (end host) and the EAP server (user's home 756 network) within an EAP method. 758 Second, the access network could be authenticated before user 759 authentication takes place. This would allow to securely exchange 760 parameters between the access network and the user and to even allow 761 the user to provide more information about the offered services to 762 the user. The following message exchange may be reasonable: 764 Alice wants to attach to one of the access networks found. She 765 establishes a secure tunnel based on unilateral (network to user 766 authentication). Then she would like to know what services are 767 offered by this network. Subsequently, if she is happy about the 768 offered price she decides to authenticate herself to the home network 769 (by selecting a particular identifier and the corresponding 770 credentials) to establish the necessary financial relationship 771 between the home and the visited network. 773 This type of service is provided by today's hotspots with web 774 interfaces. The usage of virtual access points or authentication at 775 a highly layer (such as PANA) comes into mind when higher security 776 other than packet filters are desired. This mechanism, however, 777 requires user interaction and is therefore slow and error-prone. 778 This process can of course be provided by protocols. Today there is 779 no standardized protocol available which allows users to exchange 780 information about offered and desired services, to communicate cost 781 limits, to request cost information for network resources or to learn 782 already accumulated costs. 784 Authentication of the visited network requires some sort of 785 server-side PKI which might not be available. Additionally, 786 providing public key based authentication and the subsequent protocol 787 exchange requires some time which causes delays during the network 788 access procedure. 790 Even with the last approach it is still possible for the network to 791 return incorrect charging information to the user's home network. 792 Performing a higher number of re-authentication steps which are 793 associated to a maximum amount each (similar to the idea proposed by 794 micro-payment protocols) can help to give the user more control over 795 his / her expenses. 797 Especially in roaming environments where an end host is likely to 798 have access to a large number of visited networks within a short time 799 period cost control is even more complicated. User interaction might 800 not be highly desireable. In fact these issues are a show-stopper 801 for seamless mobility. 803 It might be worth mentioning that the issues and problems of cost 804 control has already been identified in the NSIS working group some 805 time ago in the context of Quality of Service signaling where the 806 problems go beyond those described in this document (and with network 807 selection as well). 809 As a summary, to provide a short-term solution the authors suggest to 810 provide a mechanism to exchange information about the offered and the 811 desired service between the end host and the access network. 812 Subsequently, this information has to be repeated both in the EAP 813 method and the AAA infrastructure to give the user and the home 814 network the ability to detect fraud. This proposal has not been 815 verified by the current implementation and hence needs further 816 assessment. 818 5. Conclusion 820 This document presents some implementation results, which are 821 considered to be suitable and useful for future implementations and 822 extensions. The authors think that the mechanism proposed by 823 [I-D.adrangi-eap-network-discovery] is suitable as network discovery 824 for mediating network discovery. However, while implementing the 825 proposed mechanism some irregularity towards the behavior of the 826 Access point have been found and described. An implementation 827 specific solution has been presented. Additional access network 828 information elements like QoS and costs have been introduced, 829 evaluated and implemented to prove the performance of the mechanism 830 to convey network capablilities. The set of information identified 831 is not considered as a complete approach and is mainly intended to 832 trigger further discussion. The same holds for the exact data 833 formats which are for further study. The security evaluation on 834 network selection discovered some fields, which are not well 835 understood so far and hence need further assessment. A proposal has 836 been given for an increased security level for network discovery. 838 The interoperability between unmodified and modified end hosts and 839 AAA-Servers is given. AAA-Servers that are not modified do not send 840 an additional Identity-Request, but directly authenticate the user. 841 End hosts have to sent a valid Decorated-NAI from the beginning. 842 Then the AAA-Server authenticates the end host without any new 843 Identity-Request. 845 6. Acknowledgement 847 The authors would like to thank Eleanor Hepworth, Dirk Kroeselberg 848 and Stephen McCann for their comments. 850 7. References 852 7.1 Normative References 854 [I-D.adrangi-eap-network-discovery] 855 Adrangi, F., Lortz, V., Bari, F., Eronen, P. and W. 856 Watson, "Mediating Network Discovery in the Extensible 857 Authentication Protocol (EAP)", 858 draft-adrangi-eap-network-discovery-01 (work in progress), 859 June 2004, 860 . 862 [I-D.ietf-eap-netsel-problem] 863 Arkko, J. and B. Aboba, "Network Discovery and Selection 864 Problem", draft-ietf-eap-netsel-problem-00 (work in 865 progress), January 2004, 866 . 868 [IEEE-802.1X] 869 Institute of Electrical and Electronics Engineers, "Local 870 and Metropolitan Area Networks: Port-Based Network Access 871 Control", September 2001, . 873 7.2 Informative References 875 [3GPP TS23.107] 876 3rd Generation Partnership Project, "3rd Generation 877 Partnership Project; Technical Specification Group 878 Services and System Aspects; Quality of Service (QoS) 879 concept and architecture (Release 6)", Technical 880 Specification 3GPP TS 23.107 V6.1.0 (2004-03), March 2004, 881 . 883 [GRJK00] Gerke, J., Ritter, H., Schiller, J. and K. Wehrle, 884 "Elements of an open framework for pricing in the future 885 internet, in Proceedings of the Conference on Quality of 886 future Internet Services (QofIS 2000), pages 300--311, 887 Berlin", 2000, . 889 [I-D.arkko-eap-service-identity-auth] 890 Arkko, J. and P. Eronen, "Authenticated Service Identities 891 for the Extensible Authentication Protocol (EAP)", 892 draft-arkko-eap-service-identity-auth-00 (work in 893 progress), April 2004, 894 . 896 [I-D.caron-aaa-cost-advertisement] 897 Caron, J., "AAA cost advertisement extensions", 898 draft-caron-aaa-cost-advertisement-00 (work in progress), 899 June 2002, 900 . 902 [I-D.heckmann-tdp] 903 Heckmann, O., "Tariff Distribution Protocol (TDP)", 904 draft-heckmann-tdp-00 (work in progress), March 2002, 905 . 907 [I-D.prasanna-bip] 908 Prasanna, R., "BIP: Billing Information Protocol", 909 draft-prasanna-bip-00 (work in progress), December 2002, 910 . 912 [I-D.tschofenig-eap-ikev2] 913 Tschofenig, H., Kroeselberg, D. and Y. Ohba, "EAP IKEv2 914 Method (EAP-IKEv2)", draft-tschofenig-eap-ikev2-02 (work 915 in progress), October 2003, 916 . 918 [IEEE-SPEC-99] 919 Institute for Electric Engineers, "IEEE802.11 Spec 1999 920 Edition", Technical Specification IEEE802.11 Spec 1999 921 Edition, 1999, . 923 [ISO4217] International Organization for Standardization, "Codes for 924 the representation of currencies and funds", ISO Standard 925 4217, August 2001. 927 [KSS98] Karsten, M., Schmitt, J. and R. Steinmet, "An embedded 928 charging approach for RSVP, in International Workshop on 929 Quality of Service '98. Napa, California, USA", May 1998, 930 . 932 [ORW00] Oberle, V., Ritter, H. and K. Wehrle, "Bpp: A protocol for 933 exchanging pricing information between autonomous systems, 934 in Proceedings of HPSR 2001 (IEEE Workshop on 935 High-Performance Switching and Routing), Dallas (USA)", 936 May 2001, . 938 [Pri04] Priest, J., "The State of Wireless London, available at 939 'http://www.spacestudios.org.uk/content/articles/461.pdf' 940 (July 2004)", March 2004. 942 [RFC3017] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone 943 Book", RFC 3017, December 2000, . 945 [RFC3770] Housley, R. and T. Moore, "Certificate Extensions and 946 Attributes Supporting Authentication in Point-to-Point 947 Protocol (PPP) and Wireless Local Area Networks (WLAN)", 948 RFC 3770, May 2004. 950 [RNAP] Wang, X. and H. Schulzrinne, "Rnap: A resource negotiation 951 and pricing protocol, in International Workshop on Network 952 and Operating Systems Support for Digital Audio and Video 953 (NOSSDAV'99), pages 77--93, Basking Ridge, New Jersey", 954 1999, . 956 Authors' Addresses 958 Wolfgang Groeting 959 Siemens AG, ICM MP PD TI 2 960 Frankenstrasse 2 961 46395 Bocholt 962 Germany 964 EMail: Wolfgang.Groeting@siemens.com 966 Stefan Berg 967 Siemens AG, ICM MP PD TI 2 968 Frankenstrasse 2 969 46395 Bocholt 970 Germany 972 EMail: Stefan.Berg@siemens.com 974 Malte Ness 975 Siemens AG, ICM MP PD TI 2 976 Frankenstrasse 2 977 46395 Bocholt 978 Germany 980 EMail: Malte.Ness@bch.siemens.de 982 Hannes Tschofenig 983 Siemens AG 984 Otto-Hahn-Ring 6 985 81739 Munich 986 Germany 988 EMail: Hannes.Tschofenig@siemens.com 990 Appendix A. Cost Attribute 992 To be more specific about the proposed attributes in Section 2.2.2. 993 In the past various drafts have proposed to include cost specific 994 into protocols (such QoS signaling protocols, AAA protocols or SIP). 995 The flexibility of the proposals varies a simple cost attribute, to 996 complex formulas and even JAVA classes which allow sophisticated 997 price calculation. From the investigated proposals (including TDP 998 [I-D.heckmann-tdp], RNAP [RNAP], BIP [I-D.prasanna-bip], BPP [GRJK00] 999 and [ORW00], [KSS98] ) [I-D.caron-aaa-cost-advertisement] was simple 1000 enough to be reused for our purpose. 1002 We use the following attributes, Cost-Header attribute and one or 1003 more Cost-Unit subattribute for encoding this type of information. 1005 A.1 Cost-Header Attribute 1007 0 1 2 3 1008 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Type | Length | Decimals |No-of-AVPs | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Currency-Code ... 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 Type: 1016 To Be Assigned by IANA 1018 Length: 1020 Indicates the length of this header attribute in bytes. 1022 No-of-AVPs (6 bits): 1024 This field points to the number of Cost-Unit attributes 1025 following the header attribute. 1027 Decimals (10 bits) 1029 Indicates where to place the comment in all subsequent units. 1030 For example, if Decimals is set to 2 then a value of 1031 199 means 1.99. The value of '0' indicates that no decimal should 1032 set. The value should be read as it is. 1034 Currency-Code (3 - 6 Bytes): 1036 The value field of the Currency-Code attribute is of type "string" 1037 and indicates the currency to be applied to the Cost value as 1038 indicated by the Cost attribute. The string value for a single 1039 currency is defined in ISO 4217. 1041 A.2 Cost-Unit SubAttribute 1043 The Cost-Header attribute, described in Appendix A.1, is followed by 1044 one or more Cost-Unit subattributes. 1046 0 1 2 3 1047 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | SubType | Quantity | Repeat ... 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Repeat | Amount | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 SubType: 1055 1 Time-based chargig: billing is based on duration in seconds 1056 2 Volume-based charging: billing is based on total bytes 1058 Quantity: 1060 Quantity is the number of seconds or bytes that this amount will 1061 cover. 0 means none, and all ones means unlimited. 1063 Repeat: 1065 Repeat is the number of times this unit will be repeated before 1066 moving on to the next one. 0 means unlimited. 1068 Amount: 1070 Amount is the amount of money that should be billed. The value 1071 stored here should be divided by 10^decimals to get the number of 1072 currency units. 1074 A.3 Example 1076 To express the network cost for 10 EUR (independent of the time) the 1077 following payload has to be transmitted. 1079 Cost-Header AVP: 1081 Type = IANA assigned 1082 Length = 5 1083 Decimals = 0 1084 No-of-AVPs = 1 1085 Currency-Code = EUR (3 bytes) 1087 Cost-Unit: 1089 SubType = 1 (Time-based charging) 1090 Quantity = all ones (means unlimited) 1091 Repeat = 0 (unlimited) 1092 Amount = 10 1094 More complex, non-linear pricing schemes can also be expressed by 1095 listing several Cost-Unit attributes. For example, to express a 1096 pricing policy where 2 EUR are charged for the first 30 minutes and 1097 then 0.02 EUR for every further minute. 1099 Cost-Header AVP: 1101 Type = IANA assigned 1102 Length = 5 1103 Decimals = 2 1104 No-of-AVPs = 2 1105 Currency-Code = EUR (3 bytes) 1107 Cost-Unit: 1109 SubType = 1 (Time-based charging) 1110 Quantity = 1800 (60 * 30 minutes) 1111 Repeat = 0 (no repeat) 1112 Amount = 200 1114 Cost-Unit: 1116 SubType = 1 (Time-based charging) 1117 Quantity = 60 (60 seconds) 1118 Repeat = 0 (unlimited) 1119 Amount = 2 1121 The transport of these attributes within RADIUS or Diameter and via 1122 an EAP protoocol (see an example in [I-D.tschofenig-eap-ikev2] and 1123 the generalized version in [I-D.arkko-eap-service-identity-auth]) are 1124 not described in this document. 1126 Appendix B. QoS Attribute 1128 In Section 2.2.4. it was proposed to indicate supported QoS classes. 1129 To be more specific, the UMTS classes, defined in [3GPP TS23.107], 1130 could be used. 1132 B.1 UMTS QoS-Classes 1134 There are four different QoS classes defined in [3GPP TS23.107]: 1135 conversational class 1136 streaming class 1137 interactive class 1138 background class 1140 The main distinguishing factor between these QoS classes is how delay 1141 sensitive the traffic is: Conversational class is meant for traffic 1142 which is very delay sensitive while Background class is the most 1143 delay insensitive traffic class. 1145 Conversational and Streaming classes are mainly intended to be used 1146 to carry real-time traffic flows. The main divider between them is 1147 how delay sensitive the traffic is. Conversational real-time 1148 services, like video telephony, are the most delay sensitive 1149 applications and those data streams should be carried in 1150 Conversational class. 1152 Interactive class and Background are mainly meant to be used by 1153 traditional Internet applications like WWW, Email, Telnet, FTP and 1154 News. Due to looser delay requirements, compare to conversational 1155 and streaming classes, both provide better error rate by means of 1156 channel coding and retransmission. The main difference between 1157 Interactive and Background class is that Interactive class is mainly 1158 used by interactive applications, e.g. interactive Email or 1159 interactive Web browsing, while Background class is meant for 1160 background traffic, e.g. background download of Emails or background 1161 file downloading. Responsiveness of the interactive applications is 1162 ensured by separating interactive and background applications. 1163 Traffic in the Interactive class has higher priority in scheduling 1164 than Background class traffic, so background applications use 1165 transmission resources only when interactive applications do not need 1166 them. This is very important in wireless environment where the 1167 bandwidth is low compared to fixed networks. 1169 B.2 QoS-Header Attribute 1170 0 1 2 1171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | Type | Length | QoS ... 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 Type: 1178 To Be Assigned by IANA 1180 Length: 1182 Indicates the length of this header attribute in bytes. 1184 QoS: 1186 This field contains the supported QoS classes 1187 Bit1 - conversational 1188 Bit2 - streaming 1189 Bit3 - interactive 1190 Bit4 - background 1191 Bit5 (and following) - tbd 1193 B.3 Example 1195 To express the network supports UMTS QoS classes interactive 1196 and background the following payload has to be transmitted: 1198 QoS-Header: 1200 Type = IANA assigned 1201 Length = 4 1202 QoS = 0011 1204 A network supports exclusively real time services and indicates only 1205 UMTS QoS class conversational: 1207 QoS-Header: 1209 Type = IANA assigned 1210 Length = 1 1211 QoS = 1 1213 Intellectual Property Statement 1215 The IETF takes no position regarding the validity or scope of any 1216 Intellectual Property Rights or other rights that might be claimed to 1217 pertain to the implementation or use of the technology described in 1218 this document or the extent to which any license under such rights 1219 might or might not be available; nor does it represent that it has 1220 made any independent effort to identify any such rights. Information 1221 on the procedures with respect to rights in RFC documents can be 1222 found in BCP 78 and BCP 79. 1224 Copies of IPR disclosures made to the IETF Secretariat and any 1225 assurances of licenses to be made available, or the result of an 1226 attempt made to obtain a general license or permission for the use of 1227 such proprietary rights by implementers or users of this 1228 specification can be obtained from the IETF on-line IPR repository at 1229 http://www.ietf.org/ipr. 1231 The IETF invites any interested party to bring to its attention any 1232 copyrights, patents or patent applications, or other proprietary 1233 rights that may cover technology that may be required to implement 1234 this standard. Please address the information to the IETF at 1235 ietf-ipr@ietf.org. 1237 Disclaimer of Validity 1239 This document and the information contained herein are provided on an 1240 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1241 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1242 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1243 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1244 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1245 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1247 Copyright Statement 1249 Copyright (C) The Internet Society (2004). This document is subject 1250 to the rights, licenses and restrictions contained in BCP 78, and 1251 except as set forth therein, the authors retain all their rights. 1253 Acknowledgment 1255 Funding for the RFC Editor function is currently provided by the 1256 Internet Society.