idnits 2.17.1 draft-ietf-radext-ieee802-01.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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1494. ** 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. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'IEEE802.1D' is mentioned on line 349, but not defined == Missing Reference: 'IEEE 8021D' is mentioned on line 394, but not defined == Missing Reference: 'TODO' is mentioned on line 877, but not defined == Missing Reference: 'TBD' is mentioned on line 905, but not defined == Unused Reference: 'RFC3748' is defined on line 1027, but no explicit reference was found in the text == Unused Reference: 'RFC4005' is defined on line 1031, but no explicit reference was found in the text == Unused Reference: 'IEEE8021D' is defined on line 1034, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 1052, but no explicit reference was found in the text == Unused Reference: 'RFC2866' is defined on line 1066, but no explicit reference was found in the text == Unused Reference: 'RFC2867' is defined on line 1068, but no explicit reference was found in the text == Unused Reference: 'IEEE80211' is defined on line 1086, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 2868 ** Obsolete normative reference: RFC 3576 (Obsoleted by RFC 5176) ** Downref: Normative reference to an Informational RFC: RFC 3579 ** Downref: Normative reference to an Informational RFC: RFC 3580 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021D' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021Q' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021X' -- Obsolete informational reference (is this intentional?): RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2674 (Obsoleted by RFC 4363) -- Duplicate reference: RFC2607, mentioned in 'RFC3629', was also mentioned in 'RFC2607'. Summary: 10 errors (**), 0 flaws (~~), 14 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group Paul Congdon 2 INTERNET-DRAFT Mauricio Sanchez 3 Hewlett-Packard Company 4 A. Lior 5 17 January 2006 Bridgewater Systems 6 F. Adrangi 7 Intel 8 Bernard Aboba 9 Microsoft 11 VLAN, Priority, and Filtering Attributes 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 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 July, 17 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society 2006. All rights reserved. 41 Abstract 43 In certain scenarios it is desirable to limit user access using 44 dynamic VLANs, reprioritization, filters, or redirection. This 45 document proposes additional attributes for this purpose, for use 46 with the Remote Authentication Dial In User Server (RADIUS). The 47 attributes described in this document are expected to be useful in 48 a variety of environments, including enterprise and service 49 provider scenarios. 51 Table of Contents 53 1. Introduction........................................... 3 54 1.1. Terminology...................................... 4 55 1.2. Requirements Language............................ 4 56 1.3. Capability Advertisement ........................ 5 57 1.4. Attribute Interpretation......................... 5 58 2. RADIUS Authentication.................................. 5 59 2.1. Egress-VLANID.................................... 5 60 2.2. Ingress-Filters.................................. 6 61 2.3. Egress-VLAN-Name................................. 7 62 2.4. User-Priority-Table.............................. 8 63 2.5. NAS-Filter-Rule.................................. 9 64 3. RADIUS Accounting...................................... 19 65 3.1. Acct-NAS-Filter-Rule............................. 19 66 4. Table of Attributes.................................... 20 67 5. IANA Considerations.................................... 20 68 6. Security Considerations................................ 21 69 7. References............................................. 21 70 7.1 Normative References................................... 21 71 7.2 Informative References................................. 23 72 Appendix A - Traffic Redirection.............................. 24 73 Appendix B - NAS-Filter-Rule Examples......................... 29 74 ACKNOWLEDGMENTS............................................... 30 75 AUTHORS' ADDRESSES............................................ 30 76 Intellectual Property Statement............................... 31 77 Disclaimer of Validity........................................ 32 78 Full Copyright Statement ..................................... 32 79 1. Introduction 81 Within the confines of RADIUS authentication, authorization, and 82 accounting (AAA) environments, there is a requirement for 83 standardized RADIUS attributes to limit user access using dynamic 84 VLANs, reprioritization, filters or redirection. 86 For example, in IEEE 802.1X [IEEE8021X] environments, which 87 provides "network port authentication" for IEEE 802 [IEEE802] 88 media, including Ethernet [IEEE8023] and 802.11 [IEEE80211i] 89 wireless LANS, there exists a strong desire to control 90 authorization beyond just the untagged VLAN parameter based on 91 tunnel attributes in [RFC2868] and usage of these in [RFC3580]. 93 This document describes VLAN, reprioritization, filtering and 94 redirection attributes that may prove useful in IEEE 802.1X and a 95 variety of situations. The attributes defined in this document may 96 be used with RADIUS dynamic authorization [RFC3576]. 98 The Filter-ID attribute defined in [RFC2865] requires the NAS to 99 be pre-populated with the desired filters. This may be difficult 100 to deploy in roaming scenarios where the home realm may not know 101 what filters have been pre-populated by the local operator. The 102 filtering attributes specified in this document enable explicit 103 description of layer 2 and layer 3 filters as well as redirection, 104 and therefore extend the filter language described in [RFC3588]. 106 User traffic redirection is supported with or without tunneling. 107 Tunneling support is provided using the tunnel attributes defined 108 in [RFC2868]. Redirection of traffic in mid-session may break 109 applications. 111 While [RFC3580] enables support for VLAN assignment based on the 112 tunnel attributes defined in [RFC2868], it does not provide 113 support for a more complete set of VLAN functionality as defined 114 by [IEEE8021Q]. The VLAN attributes defined in this document 115 provide support within RADIUS analogous to the management 116 variables supported in [IEEE8021Q] and MIB objects defined in 117 [RFC2674]. In addition, this document enables support for a wider 118 range of [IEEE8021X] configurations. 120 1.1. Terminology 122 In this document when we refer to Blocking of IP traffic we mean 123 Filtering of IP traffic. Additionally, this document uses the 124 following terms: 126 Authenticator 127 An authenticator is an entity that require authentication 128 from the supplicant. The authenticator may be connected 129 to the supplicant at the other end of a point-to-point 130 LAN segment or 802.11 wireless link. 132 Authentication server 133 An authentication server is an entity that provides an 134 authentication service to an authenticator. This service 135 verifies from the credentials provided by the supplicant, 136 the claim of identity made by the supplicant. 138 Hot-lining 139 Blocking and redirection of users traffic is known as 140 hot-lining of accounts. In this document, hot-lining is 141 used as the motivation for these attributes and an 142 illustration of how they would be used. However, the 143 attributes may be used together or separately to provide 144 other features. 146 Redirection 147 Refers to an action taken by the NAS to redirect the 148 user's traffic to an alternate location. 150 Supplicant 151 A supplicant is an entity that is being authenticated by 152 an authenticator. The supplicant may be connected to the 153 authenticator at one end of a point-to-point LAN segment 154 or 802.11 wireless link. 156 1.2. Requirements Language 158 In this document, several words are used to signify the 159 requirements of the specification. The key words "MUST", "MUST 160 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 161 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 162 interpreted as described in [RFC2119]. 164 An implementation is not compliant if it fails to satisfy one or 165 more of the must or must not requirements for the protocols it 166 implements. An implementation that satisfies all the must, must 167 not, should and should not requirements for its protocols is said 168 to be "unconditionally compliant"; one that satisfies all the must 169 and must not requirements but not all the should or should not 170 requirements for its protocols is said to be "conditionally 171 compliant". 173 1.3. Capability Advertisement 175 RADIUS does not currently define a method by which a NAS can 176 advertise its capabilities and in many instances, it would be 177 desirable for the home network to know what capabilities are 178 supported by the NAS to ensure proper operational behavior. The 179 attributes defined in this document are intended to be used to 180 enforce policy by the NAS. If a NAS does not recognize these 181 attributes it will most likely ignore them and the desired policy 182 will not be enforced. A method for the NAS advertising the 183 capability to support these attributes would help the RADIUS 184 server understand if the intended policies can be enforced. As a 185 result, the attributes in this document, in particular NAS-Filter- 186 Rule(TBD), can benefit from capability advertisement, if 187 available. 189 1.4 Attribute Interpretation 191 Unless otherwise noted in the individual description of an 192 attribute contained herein, a NAS that conforms to this 193 specification and receives an Access-Accept message that contains 194 an attribute from this document that it cannot apply MUST 195 interpret this though an Access-Reject had been sent and MUST 196 terminate the session. If accounting is enabled on the NAS, it 197 MUST generate an Accounting-Request(Stop) message upon session 198 termination. 200 Similarly, if a NAS conforming to this specification and also 201 conforming to RFC 3576 [RFC3576] receives a CoA message that 202 contains an attribute from this document that it cannot apply, it 203 MUST NOT terminate the session and MUST generate a CoA-NAK packet 204 with ERROR-CAUSE(101) set to "Unsupported Attribute"(401). If 205 accounting is enabled on the NAS, it MUST NOT generate an 206 Accounting-Request(Stop) message in such instances. 208 2. RADIUS Authentication 210 This specification introduces five new RADIUS authentication 211 attributes. 213 2.1. Egress-VLANID 215 Description 217 The Egress-VLANID attribute represents an allowed IEEE 802 218 Egress VLANID for this port. The Egress-VLANID contains two 219 parts: the first part indicates if the VLANID is allowed for 220 tagged or untagged packets and the second part is the VLANID. 222 Multiple Egress-VLANID attributes can be delivered in an 223 authentication response; each attribute adds the specified VLAN 224 to the list of allowed egress VLANs for the port. 226 The Egress-VLANID attribute is shown below. The fields are 227 transmitted from left to right: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Length | Tag Option | Pad (12-bit) 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Pad | VLANID (12-bit) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Type 239 TBD 241 Length 243 6 245 Integer 247 The Integer field is four octets in length. The format of the 248 Integer field consists of three parts, the first consuming the 249 high-order octet, the second consuming the subsequent 12-bits, 250 and the third consuming the low-order 12-bits. The high-order 251 octet, the Tag Option, indicates whether the frames on the VLAN 252 are tagged 0x31 or untagged 0x32. The second part is 12-bits of 253 padding. Padding bits MUST be 0 (zero). The third part is the 254 12-bit [IEEE8021Q] VLAN VID value. 256 2.2. Ingress-Filters 258 Description 260 The Ingress-Filters attribute corresponds to Ingress Filter 261 per-port variable defined in IEEE 802.1Q clause 8.4.5. When 262 the attribute has the value "Enabled", the set of VLANs that 263 are allowed to ingress a port must match the set of VLANs that 264 are allowed to egress a port. Only a single Ingress-Filters 265 attribute MAY be sent within an Access-Accept or CoA-Request; 266 this attribute MUST NOT be sent within an Access-Request, 267 Access-Challenge, Access-Reject, or Disconnect-Request. 269 The Ingress-Filters attribute is shown below. The fields are 270 transmitted from left to right: 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type | Length | Integer 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Integer (cont.) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Type 282 TBD 284 Length 286 6 288 Integer 290 The values include: 292 1 - Enabled 293 2 - Disabled 295 2.3. Egress-VLAN-Name 297 Description 299 Clause 12.10.2.1.3 (a) in [IEEE8021Q] describes the 300 administratively assigned VLAN Name associated with a VLAN ID 301 defined within an 802.1Q bridge. The Egress-VLAN-Name attribute 302 represents an allowed VLAN for this port. It works similar to 303 the Egress-VLANID attribute except that the VLAN-ID itself is 304 not specified or known, rather the VLAN name is used to 305 identify the VLAN within the system. 307 The Egress-VLAN-Name attribute contains two parts; the first 308 part indicates if frames on the VLAN for this port are to be 309 represented in tagged or untagged format, the second part is 310 the VLAN name. 312 Multiple Egress-VLAN-Name attributes can be delivered in an 313 authentication response; each attribute adds the named VLAN to 314 the list of allowed egress VLANs for the port. 316 The Egress-VLAN-Name attribute is shown below. The fields are 317 transmitted from left to right: 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | Length | Tag Option | VLAN-Name 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 VLAN-Name (cont.) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Type 329 TBD 331 Length 333 >= 4 335 String 337 The first octet of this string, the tag option field, indicates 338 whether the frames on the VLAN are tagged 0x31 or untagged 339 0x32. The remaining octets of the VLAN-Name field represent 340 the VLAN Name as defined in 802.1Q-2003 clause 12.10.2.1.3 (a). 341 [RFC3629] UTF-8 encoded 10646 characters are recommended, but a 342 robust implementation SHOULD support the field as 343 undistinguished octets. 345 2.4. User-Priority-Table 347 Description 349 [IEEE802.1D] clause 7.5.1 discusses how to regenerate (or re- 350 map) user priority on frames received at a port. This per-port 351 configuration enables a bridge to cause the priority of 352 received traffic at a port to be mapped to a particular 353 priority. The management variables are described in clause 354 14.6.2.2. 356 This attribute represents the IEEE 802 prioritization that will 357 be applied to packets arriving at this port. There are eight 358 possible user priorities, according to the [IEEE802] standard. 360 The User-Priority-Table attribute is shown below. The fields 361 are transmitted from left to right: 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type (TBD) | Length | String 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 String (cont.) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Type 373 TBD 375 Length 377 10 379 String 381 The table, expressed as an 8 octet string, maps the incoming 382 priority (if one exists - the default is 0) into one of eight 383 regenerated priorities. The format of this attribute is an 384 eight byte octet string, where the first octet maps to incoming 385 priority 0, the second octet to incoming priority 1, etc. The 386 values in each octet represent the regenerated priority of the 387 packet. 389 It is thus possible to either remap incoming priorities to more 390 appropriate values; or to honor the incoming priorities; or to 391 override any incoming priorities, forcing them to all map to a 392 single chosen priority. 394 The [IEEE 8021D] specification, Annex G, provides a useful 395 description of traffic type - traffic class mappings. 397 2.5. NAS-Filter-Rule 399 Description 401 The NAS-Filter-Rule attribute is derived from the Diameter 402 IPFilterRule and enables provisioning of base encapsulation 403 (Layer 2) rules, Internet Protocol (Layer 3-4) rules, and HTTP 404 (Layer 5+) rules on the NAS by the RADIUS server. Compared to 405 Diameter's IPFilterRule, NAS-Filter-Rule is a superset in 406 functionality, but is largely based on the same syntax 407 foundations. 409 For each rule and depending on the rule type, the NAS can be 410 instructed to take a single action as follows: 412 Rule Type Allowable rule action 413 ------------------- --------------------- 414 Base Encapsulation filter, tunnel 415 Internet Protocol filter, tunnel 416 HTTP filter, redirect 418 When specifying a base encapsulation rule, NAS-Filter-Rule 419 processes packets based on the following information that is 420 associated with it: 422 Direction (in and/or out) 423 Base encapsulation type 424 Source and destination MAC address (possibly masked) 426 For a base encapsulation rule, the filter action entails having 427 the NAS permit (i.e. forward) or deny (i.e. block) a user's 428 traffic. The tunnel action entails having the NAS forward user 429 traffic to or from a named tunnel that has been established per 430 [RFC2868]. 432 When specifying an Internet Protocol rule, NAS-Filter-Rule 433 processes packets based on the following information that is 434 associated with it: 436 Direction (in and/or out) 437 Source and destination IP address (possibly masked) 438 Protocol 439 Source and destination port (lists or ranges) 440 TCP flags 441 IP fragment flag 442 IP options 443 ICMP types 445 For an Internet Protocol rule, the filter action entails having 446 the NAS permit (i.e. forward) or deny (i.e. block) a user's 447 traffic. The tunnel action entails having the NAS forward user 448 traffic to or from a named tunnel that has been established per 449 [RFC2868]. 451 When specifying an HTTP rule, NAS-Filter-Rule process packets 452 based on the following information that is associated with it: 454 HTTP URL 455 Source and destination IP address (possibly masked) 457 For an HTTP rule, the filter action entails having the NAS 458 permit (i.e. forward) or deny (i.e. block) a user's [RFC2616] 459 request message. For a deny action, the NAS MAY respond to the 460 request message with a code 403 (Forbidden) response in 461 accordance with [RFC2616]. For a redirect action the NAS SHOULD 462 respond to the user's request with a code 302 (Found) response 463 in accordance with [RFC2616]. 465 For the HTTP redirection action, it is also possible to have 466 redirection automatically removed by including a redir-cnt 467 count parameter along with the rule. The rule will be removed 468 from the active rule set when the rule matches redir-cnt number 469 of times. Upon removal from the active rule set, traffic is no 470 longer evaluated against this rule. 472 It should be noted that an HTTP filter or redirect rule is only 473 useful with plain-text HTTP and not HTTPS. Redirection or 474 filtering of HTTPS is outside the scope of this document. 476 As per the requirements of RFC 2865, Section 2.3, if multiple 477 NAS-Filter-Rule attributes are contained within an Access- 478 Request or Access-Accept packet, they MUST be maintained in 479 order. The attributes MUST be consecutive attributes in the 480 packet. RADIUS proxies MUST NOT reorder NAS-Filter-Rule 481 attributes. 483 The RADIUS server can return multiple NAS-Filter-Rule 484 attributes in an Access-Accept or CoA-Request packet. Where 485 more than one NAS-Filter-Rule attribute is included, it is 486 assumed that the attributes are to be concatenated to form a 487 single filter list. Furthermore, if the list contains different 488 types of rules, they MUST appear in the following order: flush 489 rules, base encapsulation tunnel rules, base encapsulation 490 filter rules, IP tunnel rules, HTTP redirect rules, IP filter 491 rules, and HTTP filter rules. 493 Rules are evaluated in order, with the first matched rule 494 terminating the evaluation. Each packet is evaluated once. If 495 no rule matches, then packet is dropped (implicit deny all). 497 When an HTTP redirect rule matches, the NAS shall reply to the 498 HTTP request with an HTTP redirect in accordance with [RFC2616] 499 redirecting traffic to specific URL. 501 Filter-ID (11) and NAS-Filter-Rule both define how filters are 502 to be applied in the NAS. These attributes are not intended to 503 be used concurrently and SHOULD NOT appear in the same RADIUS 504 message. Only one type of filtering attribute must be 505 processed. If a Filter-ID (11) is present, then the NAS-Filter- 506 Rule MUST be ignored, if present. 508 The NAS-Filter-Rule attribute is shown below. The fields are 509 transmitted from left to right: 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type (TBD) | Length | Text 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Text (cont.) | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Type 521 TBD 523 Length 525 >= 3 527 Text 529 The text conforms to the following ABNF [RFC2234] formatted syntax 530 specification: 532 ; Start of ABNF description of NAS-Filter-Rule 534 rule = (flush-rule / permit-all-rule 535 / l2-filter-rule / l2-tunnel-rule 536 / ip-filter-rule / ip-tunnel-rule 537 / http-filter-rule / http-redir-rule) 538 rule-delim 540 ; Flush Rule 541 flush-rule = "flush" 543 ; Permit all rule 544 permit-all-rule = "permit inout any from any to any" 546 ; Base encapsulation filter rule 547 l2-filter-rule = ("permit" / "deny") " " 548 ("in" / "out" / "inout") " " 549 l2-filter-body [" " log-rule] 550 l2-filter-body = (l2-proto " from " l2-address " to " 551 l2-address) / l2-rmon-str 552 l2-proto = "l2:ether2" [":0x" 1*4HEXDIG] 553 l2-rmon-str = "l2:" 1*DIGIT *("." 1*DIGIT) 554 l2-address = ["!"] (macaddr / (macaddr "/" macmask) 555 / "any") 556 macaddr = 2HEXDIG 5("-" 2HEXDIG) 557 macmask = DIGIT ; 0-9 558 / %x31-33 DIGIT ; 10-39 559 / "4" %x30-38 ; 40-48 561 ;Base encapsulation tunnel rule 562 l2-tunnel-rule = "tunnel " tunnel-id " " 563 ("in" / "out" / "inout") " " 564 l2-filter-body [" " log-rule] 566 ;IP Filter Rule 567 ip-filter-rule = ("permit" / "deny") " " 568 ("in" / "out" / "inout") " " 569 ("ip" / ip-proto) filter-body 570 [" " ip-option] [" " log-rule] 571 ip-proto = d8 572 ip-address = ["!"] (ipv4-address ["/" ipv4mask] / 573 ipv6-address ["/" ipv6mask] / 574 "any" / 575 "assigned") 576 ipv4-address = d8 "." d8 "." d8 "." d8 577 ipv4mask = DIGIT ; 0-9 578 / %x31-32 DIGIT ; 10-29 579 / "3" %x30-32 ; 30-32 580 ipv6-address = 1*4HEXDIG 7(":" 1*4HEXDIG) 581 ipv6mask = DIGIT ; 0-9 582 / %x31-39 DIGIT ; 10-99 583 / "1" %x30-31 DIGIT ; 100-119 584 / "1" %x32 %x30-38 ; 120-128 585 tcp-ports = tcp-port *("," tcp-port) 586 tcp-port = d16 / d16 "-" d16 587 ip-option = "frag" / 588 ["ipoptions " ["!"] ipopt *("," ["!"] ipopt)] 589 ["tcpoptions " ["!"] tcpopt 590 *("," ["!"] tcpopt)] 591 ["established"] 592 ["setup"] 593 ["tcpflags " ["!"] tcpflag 594 *("," ["!"] tcpflag)] 595 ["icmptypes " icmptype *("," icmptype)] 596 ipopt = "ssrr" / "lsrr" / "rr" / "ts" 597 tcpopt = "mss" / "window" / "sack" / "ts" / "cc" 598 tcpflag = "fin" / "syn" / "rst" / "psh" / "ack" / "urg" 600 icmptype = d8 / d8 "-" d8 601 / "echo reply" / "destination unreachable" 602 / "source quench" / "redirect" 603 / "echo request" / "router advertisement" 604 / "router solicit" / "time-to-live exceeded" 605 / "IP header bad" / "timestamp request" 606 / "timestamp reply" / "information request" 607 / "information reply" 608 / "address mask request" 609 / "address mask reply" 611 ;IP Tunnel Rule 612 ip-tunnel-rule = "tunnel " tunnel-id " " 613 ("in" / "out" / "inout") " " 614 ("ip" / ip-proto) filter-body 615 [" " ip-option] [" " log-rule] 617 ;HTTP Filter Rule 618 http-filter-rule= ("permit" / "deny") org-url " " 619 ("in" / "out" / "inout") filter-body 620 [" " log-rule] 622 ;HTTP Redirect Rule 623 http-redir-rule= "redirect " [redir-cnt " "] redir-url 624 filter-body [" " org-url] 625 [" " log-rule] 626 redir-cnt = 1*DIGIT 627 org-url = http_URL 628 ;Note: Syntax for http_URL defined in 629 ;[RFC2616], section 3.2.2 630 redir-url = http_URL 632 ;Common 633 filter-body = " from " ip-address [" " tcp-ports] 634 " to " ip-address [" " tcp-ports] 635 tunnel-id = DQUOTE 636 *(TEXTDATA 637 / ("%" 2HEXDIG) 638 / ("\" 1*("\")) 639 / ("\" DQUOTE)) 640 DQUOTE 641 log-rule = "cnt" 643 ;Primitives 644 rule-delim = LF 645 d8 = DIGIT ; 0-9 646 / %x31-39 DIGIT ; 10-99 647 / "1" 2DIGIT ; 100-199 648 / "2" %x30-34 DIGIT ; 200-249 649 / "25" %x30-35 ; 250-255 650 d16 = DIGIT ; 0-9 651 / %x31-35 1*4DIGIT ; 10-59999 652 / "6" "4" 3DIGIT ; 60000-64999 653 / "6" "5" %x30-34 2DIGIT ; 65000-65499 654 / "6" "5" "5" %x30-32 1DIGIT ; 65500-65529 655 / "6" "5" "5" "3" %x30-36 ; 65530-65536 656 TEXTDATA = %x20-21 / %x23-2B / %x2D-7E 658 ; End of ABNF description of NAS-Filter-Rule 660 Descriptions of notable fields and keywords follow: 662 "permit" Allow packets that match the rule. 664 "deny" Drop packets that match the rule. 666 "redirect" Redirect packets that match the rule. 668 "tunnel" Tunnel packets that match the rule. 670 "flush" A flush rule removes all previously assigned 671 filter rules. When flush is specified, it can be 672 followed by other NAS-Filter-Rule attributes. This 673 allows for an atomic change of authorization with a 674 single RADIUS message. 676 "permit inout any from any to any" 677 Special rule that matches against all traffic. This 678 allows the implicit deny at the end of a filter 679 list to be overridden. 681 "in" Is from the terminal. 683 "out" Is to the terminal. 685 "inout" Is from and to the terminal. 687 ipv4-address An IPv4 number in dotted-quad form. Only this 688 exact IP number will match the rule. 689 ipv6-address An IPv6 number in canonical IPv6 form. Only 690 this exact IP number will match the rule 691 ipv4-address/ipv4mask 692 An IP number with a mask width of the form 693 192.0.2.0/24. In this case, all IP numbers from 694 192.0.2.0 to 192.0.2.255 will match. 696 The bit width MUST be valid for the IP version and 697 the IP number MUST NOT have bits set beyond the 698 mask. For a match to occur, the same IP version 699 MUST be present in the packet that was used in 700 describing the IP address. To test for a 701 particular IP version, the bits part can be set to 702 zero. 704 "any" Keyword for 0.0.0.0/0 or the IPv6 equivalent. 706 "assigned" Keyword for the address or set of addresses 707 assigned to the terminal. For IPv4, a typical 708 first rule is often "deny in ip !assigned" 710 The sense of the match can be inverted by preceding 711 an address with the not modifier (!), causing all 712 other addresses to be matched instead. This does 713 not affect the selection of port numbers. 715 tcp-port With the TCP, UDP and SCTP protocols, this field 716 specifies ports to match. 718 Note: The '-' notation specifies a range of ports 719 (including boundaries). Fragmented packets that 720 have a non-zero offset (i.e., not the first 721 fragment) will never match a rule that has one or 722 more port specifications. See the "frag" keyword 723 for details on matching fragmented packets. 725 log-rule Increments rule hit counter by one every time a 726 packet matches on rule. Counters start with a zero 727 value at session start and are reset back to a zero 728 value every time a successful authorization change 729 occurs due to a CoA message being received by the 730 NAS. 732 For base encapsulation rules: 733 "l2:" Prefix on any base encapsulation rule to designate 734 as rule as such. 736 "l2:ether2" Keyword means any Ethernet-II (DIX Ethernet) will 737 match. 739 ether2:val Used to specify an Ethernet-II type by hexadecimal 740 number, whereby "val" is replaced by desired 741 number. Example: "l2:ether2:0x800" for IP ethertype 742 (0x0800). 744 l2-rmon-str Used to specify base encapsulation per the octet 745 string format defined in [RFC2895], section 4.2. 746 Example: "l2:0.0.0.2.0.0.0.240" for Netbios over 747 LLC. 749 macaddr For base encapsulation filter rules of "l2:ether2" 750 type, the Ethernet MAC address with octet values 751 separated by a "-". Example: "00-10-A4-23-19-C0". 753 macaddr/mask An Ethernet number as above with a mask width of 754 the form "00-10-A4-23-00-00/32". In this case, all 755 MAC addresses from 00-10-A4-23-00-00 to 00-10-A4- 756 23-FF-FF will match. The MAC address MUST NOT have 757 bits set beyond the mask. The keyword "any" is 758 00-00-00-00-00-00/0. 760 The sense of the match can be inverted by preceding 761 an address with the not modifier (!), causing all 762 other addresses to be matched instead. 764 Note: macaddr nor macaddr/mask argument is not used 765 for "l2:rmon" type rules. 767 For IP rules: 768 "ip" Keyword means any IP protocol will match. 770 ip-proto An IP protocol specified by number. 772 "frag" Match if the packet is a fragment and this is not 773 the first fragment of the datagram. frag may not 774 be used in conjunction with either tcpflags or 775 TCP/UDP port specifications. 777 "ipoptions" Match if the IP header contains the comma separated 778 list of options specified in spec. The supported 779 IP options are: ssrr (strict source route), lsrr 780 (loose source route), rr (record packet route) and 781 ts(timestamp). The absence of a particular option 782 may be denoted with a '!'. 784 "tcpoptions" Match if the TCP header contains the comma 785 separated list of options specified in spec. The 786 supported TCP options are: 788 mss (maximum segment size), window (tcp window 789 advertisement), sack (selective ack), ts (rfc1323 790 timestamp) and cc (rfc1644 t/tcp connection count). 791 The absence of a particular option may be denoted 792 with a '!'. 794 "established" TCP packets only. Match packets that have the 795 RST or ACK bits set. 797 "setup" TCP packets only. Match packets that have the SYN 798 bit set but no ACK bit. 800 "tcpflags" TCP packets only. Match if the TCP header contains 801 the comma separated list of flags specified in 802 spec. The supported TCP flags are: 804 fin, syn, rst, psh, ack and urg. The absence of a 805 particular flag may be denoted with a '!'. A rule 806 that contains a tcpflags specification can never 807 match a fragmented packet that has a non-zero 808 offset. See the "frag" option for details on 809 matching fragmented packets. 811 "icmptypes" ICMP packets only. Match if the ICMP type is in 812 the list types. The list may be specified as any 813 combination of ranges or individual types separated 814 by commas. Both the numeric values and the 815 symbolic values listed below can be used. The 816 supported ICMP types are: 818 echo reply (0), destination unreachable (3), source 819 quench (4), redirect (5), echo request(8), router 820 advertisement (9), router solicitation (10), time- 821 to-live exceeded (11), IP header bad (12), 822 timestamp request (13), timestamp reply (14), 823 information request (15), information reply (16), 824 address mask request (17) and address mask reply 825 (18). 827 For HTTP redirection rules: 828 redir_cnt Specifies the number of HTTP redirect rule matches 829 that should transpire before removing this rule 830 from the active rule set. Upon removal from the 831 active rule set, traffic is no longer evaluated 832 against this rule. 834 redir_URL An HTTP URL. When the 'redirect' rule matches 835 (src/dst and/or org_URL ), HTTP requests are 836 redirected to redir_URL address in accordance with 837 [RFC2616] redirection traffic to specific URL. 839 org_URL An HTTP URL. Specifies the HTTP URL against which 840 user HTTP requests will be evaluated. If user HTTP 841 request matches org_URL, then redirection action is 842 taken. 844 For base encapsulation and IP tunnel rules: 845 tunnel_id A tunnel id. When the 'tunnel' rule matches, 846 traffic is redirected over the tunnel with the 847 specified tunnel_id. Traffic can only be redirected 848 to or from named tunnels that have been established 849 per [RFC2868] and named using the Tunnel- 850 Assignment-ID attribute described therein. 852 The tunnel id MUST be encapsulated in double quotes 853 and use the following escape functions in case the 854 tunnel id itself contains any quotes: 856 For all occurrences of " replace with \" 857 For all occurrences of \ replace with \\ 859 Example: A tunnel with the name of tunnel "ppp1" 860 would be specified as "tunnel \"pp1\"" within the 861 rule. 863 A NAS that is unable to interpret or apply a deny rule MUST 864 terminate the session. A NAS MAY apply deny rules of its own 865 before the supplied rules, for example to protect the access 866 device owner's infrastructure. 868 3. RADIUS Accounting 870 This specification introduces one new RADIUS accounting attribute. 872 3.1. Acct-NAS-Filter-Rule 874 Description 876 Acct-NAS-Filter-Rule enables a RADIUS client to include NAS- 877 Filter-Rule[TODO] rule match counters as part of the accounting 878 message. 880 The Acct-NAS-Filter-Rule attribute is shown below. The fields 881 are transmitted from left to right: 883 0 1 2 3 884 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 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Type | Length | Counter (64-bits) 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 Counter (cont.) 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 Counter (cont.) | Text (NAS-Filter-Rule) | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 Type 894 TBD 896 Length 897 >=3 899 String 901 The first eight octets of this string are used for a 64-bit 902 value of the rule counter. The remaining octets are used to 903 specify which filter rule the counter value is for. The rule 904 specification MUST conform to the syntax rules specified for 905 NAS-Filter-Rule[TBD]. 907 4. Table of Attributes 909 The following table provides a guide to which attributes may be 910 found in which kinds of packets, and in what quantity. 912 Access- Access- Access- Access- CoA- 913 Request Accept Reject Challenge Req # Attribute 914 0 0+ 0 0 0+ TBD Egress-VLANID 915 0 0-1 0 0 0-1 TBD Ingress-Filters 916 0 0-1 0 0 0-1 TBD User-Priority-Table 917 0 0+ 0 0 0+ TBD NAS-Filter-Rule 919 Actng- Actng- 920 Request Response # Attribute 921 0-1 0 TBD Acct-NAS-Filter-Rule 923 The following table defines the meaning of the above table 924 entries. 926 0 This attribute MUST NOT be present in packet. 927 0+ Zero or more instances of this attribute MAY be present in 928 the packet. 929 0-1 Zero or one instance of this attribute MAY be 930 present in the packet. 932 5. IANA Considerations 934 This document uses the RADIUS [RFC2865] namespace, see 935 . Allocation of 936 seven updates for the section "RADIUS Attribute Types" is 937 requested. The RADIUS attributes for which values are requested 938 are: 940 TBD - Egress-VLANID 941 TBD - Ingress-Filters 942 TBD - User-Priority-Table 943 TBD - NAS-Filter-Rule 944 TBD - Acct-NAS-Filter-Rule 946 6. Security Considerations 948 Since this document describes the use of RADIUS for purposes of 949 authentication, authorization, and accounting in IEEE 802.1X- 950 nabled networks, it is vulnerable to all of the threats that are 951 present in other RADIUS applications. For a discussion of these 952 threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580]. 954 This document specifies new attributes that can be included in 955 existing RADIUS messages. These messages are protected using 956 existing security mechanisms; see [RFC2865] and [RFC3576] for a 957 more detailed description and related security considerations. 959 The security mechanisms in [RFC2865] and [RFC3576] are primarily 960 concerned with an outside attacker who modifies messages in 961 transit or inserts new messages. They do not prevent an authorized 962 RADIUS server or proxy from inserting attributes with a malicious 963 purpose in message it sends. 965 An attacker who compromises an authorized RADIUS server or proxy 966 can use the attributes defined in this document to influence the 967 behavior of the NAS in ways that previously may not have been 968 possible. For example, modifications to the VLAN-related 969 attributes may cause the NAS to permit access to other VLANs that 970 were intended. To give another example, inserting suitable 971 redirection rules to the NAS-Filter-Rule attribute may allow the 972 attacker to eavesdrop or modify packets sent by a legitimate 973 client. 975 In general, the NAS cannot know whether the attribute values it 976 receives from an authenticated and authorized server are well- 977 intentioned or malicious, and thus it is not possible to 978 completely protect against attacks by compromised nodes. In some 979 cases, the extent of the possible attacks can be limited by 980 performing more fine-grained authorization checks at the NAS. 981 For instance, a NAS could be configured to accept only certain 982 VLAN IDs from a certain RADIUS server/proxy, or not to accept any 983 redirection rules if it is known they are not used in this 984 environment. 986 7. References 988 7.1. Normative references 990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 991 Requirement Levels", RFC 2119, March, 1997. 993 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 994 L., Leach P., Berners-Lee T., "Hypertext Transfer Protocol 995 -- HTTP/1.1", RFC 2616, June 1999. 997 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 998 Authentication Dial In User Service (RADIUS)", RFC 2865, 999 June 2000. 1001 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 1002 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1003 Support", RFC 2868, June 2000. 1005 [RFC2895] Bierman, A., Bucci, C., Iddon, R., "Remote Network 1006 Monitoring MIB Protocol Identifier Reference", RFC 1007 2895, August 2000 1009 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 1010 3162, August 2001. 1012 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 1013 Aboba,"Dynamic Authorization Extensions to Remote 1014 Authentication Dial In User Service (RADIUS)", RFC 3576, 1015 July 2003. 1017 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 1018 Authentication Protocol (EAP)", RFC 3579, September 2003. 1020 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., 1021 "IEEE 802.1X Remote Authentication Dial In User Service 1022 (RADIUS) Usage Guidelines", RFC3580, September 2003. 1024 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko, 1025 J., "Diameter Base Protocol", RFC 3588, September 2003. 1027 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1028 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1029 3748, June 2004. 1031 [RFC4005] Calhoun, P., Zorn, G., Spence, D., Mitton, D., "Diameter 1032 Network Access Server Application", RFC 4005, August 2005. 1034 [IEEE8021D] 1035 IEEE Standards for Local and Metropolitan Area Networks: 1036 Media Access Control (MAC) Bridges, IEEE Std 802.1D-2004, 1037 June 2004. 1039 [IEEE8021Q] 1040 IEEE Standards for Local and Metropolitan Area Networks: 1041 Draft Standard for Virtual Bridged Local Area Networks, 1042 P802.1Q, January 1998. 1044 [IEEE8021X] 1045 IEEE Standards for Local and Metropolitan Area Networks: 1047 Port based Network Access Control, IEEE Std 802.1X-2004, 1048 August 2004. 1050 7.2. Informative references 1052 [RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest 1053 Algorithm", RFC 1321, April 1992. 1055 [RFC2234] Croker, E., Overell, P., "Augmented BNF for Syntax 1056 Specifications: ABNF", RFC 2234, November 1997. 1058 [RFC2607] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy 1059 Implementation in Roaming", RFC 2607, June 1999. 1061 [RFC2674] Bell, E., Smith, A., Langille, P., Rijhsinghani, A., 1062 McCloghrie, K., Definitions of Managed Objects 1063 for Bridges with Traffic Classes, Multicast Filtering and 1064 Virtual LAN Extensions", RFC 2674, August 1999. 1066 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1068 [RFC2867] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting 1069 Modifications for Tunnel Protocol Support", RFC 2867, June 1070 2000. 1072 [RFC3629] Yergeau, F., "UTF-8, a transformation of ISO 10646", RFC 1073 2607, November 2003. 1075 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 1076 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1078 [IEEE8023] 1079 ISO/IEC 8802-3 Information technology - Telecommunications 1080 And information exchange between systems - Local and 1081 metropolitan area networks - Common specifications - Part 1082 3: Carrier Sense Multiple Access with Collision Detection 1083 (CSMA/CD) Access Method and Physical Layer Specifications, 1084 (also ANSI/IEEE Std 802.3- 1996), 1996. 1086 [IEEE80211] 1087 Information technology - Telecommunications and information 1088 exchange between systems - Local and metropolitan area 1089 networks - Specific Requirements Part 11: Wireless LAN 1090 Medium Access Control (MAC) and Physical Layer (PHY) 1091 Specifications, IEEE Std. 802.11-1999, 1999. 1093 [IEEE80211i] 1094 Institute of Electrical and Electronics Engineers, 1095 "Supplement to Standard for Telecommunications and 1096 Information Exchange Between Systems - LAN/MAN Specific 1097 Requirements - Part 11:Wireless LAN Medium Access Control 1098 (MAC) and Physical Layer 1099 (PHY) Specifications: Specification for Enhanced Security", 1100 June 2004. 1102 Appendix A - Traffic Redirection 1104 There are several ways to redirect the user's traffic. Which 1105 method will be used depends on the capabilities available at the 1106 NAS and Service Provider's preference. This Appendix describes 1107 various methods to redirect user traffic by using the new 1108 attributes outlined in this document in conjunction with existing 1109 attributes, which are: 1111 1) Tunneling; and 1112 2) HTTP Redirection; 1114 For each method we describe how redirection is done at service 1115 initiation and mid-session. We also describe how redirection is 1116 removed when it is no longer desired. 1118 A.1 Tunneling 1120 User traffic can be redirected by tunneling the user's traffic to 1121 an alternate location. Tunneling will typically redirect all of 1122 the user's traffic for the Service. When tunneling is used to 1123 redirect all the traffic, then filtering may not be necessary. 1125 A.1.1 Service Initiation 1127 Redirect using tunnels at service initiation requires that the 1128 RADIUS server send the appropriate [RFC2868] tunnel attributes and 1129 NAS-Filter-Rule attributes to the NAS. The [RFC2868] tunnel 1130 attributes describe the tunnel endpoint and the type of tunnel to 1131 construct. The 'tunnel ' option for the NAS-Filter- 1132 Rule allows the specification of a traffic rule for which to 1133 redirect traffic to a named tunnel. 1135 A.1.2 Mid-session Tunnel Redirection 1137 Redirection of traffic using tunnels mid-session involves sending 1138 the tunnel attributes as per [RFC2868] to the NAS using Change-of- 1139 Authorization (CoA) message. The operation is described in 1140 [RFC3576]. Careful attention should be paid to the security 1141 issues in [RFC3576]. 1143 Note that if the session is already tunneled (eg. Mobile-IP) then 1144 the CoA message with a new tunnel specification can be sent to the 1145 NAS or alternatively the redirection can occur at the tunnel 1146 endpoint (the Home Agent) using any one of these methods. 1148 A.1.3 Tunnel Redirection Removal 1150 If the normal mode for the session was to tunnel the session and 1151 redirection was sent to the NAS, the RADIUS Server can send the 1152 original tunnel attributes to the NAS in a CoA message. The NAS 1153 will tear down the tunnel and establish a connection back to the 1154 original tunnel endpoint. 1156 However, if the normal mode for the session is not to use 1157 tunneling then there is a problem because RADIUS does not have a 1158 mechanism whereby it can de-tunnel. Receiving a CoA message 1159 without tunnel attributes would not have an effect on an existing 1160 tunnel. In order to de-tunnel the session, the RADIUS server has 1161 to send the NAS a CoA message with Service-Type(6) set to 1162 "Authorize-Only" causing the NAS to perform a re-Authorization. 1163 In response to the re-Authorization, the RADIUS server will send 1164 an Access-Accept packet without the tunneling information. Upon 1165 receiving the corresponding Access-Accept packet the NAS MUST 1166 apply the new authorization attributes. If these do not contain 1167 tunnel attributes, then the NAS MUST tear down the tunnel. 1169 A.1.4 Tunnel Redirection Examples 1171 The following examples illustrate how traffic flows when subjected 1172 to a NAS-Filter-Rule using tunnel redirection. In these 1173 scenarios, the following notation is used to represent traffic 1174 flows: 1176 ------> Flow in one direction 1177 <-----> Flow in two directions 1178 ======> Flow in a tunnel in one direction 1179 <=====> and in both directions 1181 A RADIUS server that wishes all IP traffic to flow between the 1182 client and a selected redirection destination will issue an 1183 Access-Accept that contains the specification for the tunnel using 1184 the attributes defined by RFC 2868 and an NAS-Filter-Rule 1185 attribute using the tunnel action and arguments. 1187 An example NAS-Filter-Rule will look like: 1189 tunnel "t1" in ip from assigned to any 1190 This will cause all traffic that flows from the client to any 1191 destination to be tunneled over the named tunnel "t1" to the 1192 tunnel endpoint (TEP). 1194 +-------+ +------+ +------+ +------+ 1195 | | | | |Tunnel| | | 1196 |client +<---------->+ NAS +<==t1===>+ End +<----->+ Dest | 1197 | | | | |Point | | | 1198 +-------+ +------+ +------+ +------+ 1200 The direction argument takes the values of "in", "out" or "inout" 1201 and is important because it controls how information is routed. 1202 The following diagram demonstrates how traffic is routed. In all 1203 these diagrams time is increasing as we proceed down the page. 1205 When rule direction is "in": 1207 client NAS TEP DESTINATION 1208 | | | | 1209 |---------->|===t1===>|--------->| 1210 | | | | 1211 |<----------|<-------------------| (flows directly to NAS) 1212 | | | | 1214 The inbound traffic from the client matches the specified filter 1215 rule and the IP packet is placed in the tunnel to the TEP. The TEP 1216 forwards the packet to the Destination using the destination IP 1217 address in the packet header. Note that the source address of the 1218 packet is the address assigned at the NAS. Therefore if the 1219 destination were to reply to the packet it would use the NAS 1220 source address and the packet would flow directly to the NAS and 1221 to the client bypassing the TEP. The Home network would use this 1222 capability if it was only interested in metering or seeing the 1223 inbound traffic from the client. 1225 However, if the home network wanted to see the traffic in both 1226 directions it could deploy a NAT function at the TEP. 1228 Here is the flow when the TEP is acting like a NAT: 1230 client NAS TEP/NAT DESTINATION 1231 | | | | 1232 |---------->|===t1===>|--------->| 1233 | | | | 1234 |<----------|<==t1====|<---------| 1236 The client establishes a connection to the Destination, but the 1237 TEP acting as NAT, changes the source address of the IP packet(as 1238 NATs do) to that of the TEP/NAT. Now any replies from the 1239 Destination are sent to the TEP/NAT. The TEP/NAT then forwards 1240 these packets to the client through the NAS. 1242 When the TEP is acting as a NAT, using the direction argument "in" 1243 is important. The direction argument set to "out" will have no 1244 effect on traffic coming from the tunnel since all traffic to the 1245 client should come from the TEP/NAT inside the tunnel. The 1246 direction argument set to "inout" will have the same effect as if 1247 it were set to "in". 1249 The TEP/NAT forwards all traffic for the client into the tunnel to 1250 the NAS. The NAS always forwards any egressing traffic from the 1251 tunnel to the client. It does not apply any redirection rules on 1252 traffic egressing a tunnel. The NAS does not care whether the TEP 1253 is transparent or is acting as a NAT. 1255 A.2 HTTP Redirection 1257 Another method of redirection is at the application layer, 1258 specifically the HTTP layer. An HTTP aware NAS redirects traffic 1259 by issuing an HTTP Redirect response causing the users browser to 1260 navigate to an alternate Web Portal. 1262 The call flow associated with performing redirection at the HTTP 1263 layer is very similar with the call flow associated with 1264 redirection done at the IP layer. 1266 The same NAS-Filter-Rule(TBD) attribute described above is used to 1267 convey the redirection rules to use for HTTP redirection. HTTP 1268 redirection rules within the NAS-Filter-Rule attribute supports 1269 the encoding of a redirection URL to apply when a rule is matched. 1271 A.2.1 Service Initiation 1273 As with previous call flows, the RADIUS MAY send multiple HTTP 1274 redirect or filtering rules within a NAS-Filter-Rule(TBD) 1275 attribute to the NAS in the Access-Accept message. 1277 A.2.2 Mid-session HTTP Redirection 1279 If HTTP redirection is required to be applied to a service that 1280 has already been started then the RADIUS server can push the 1281 redirection rules, and optionally the filter rules, to the NAS 1282 within a NAS-Filter-Rule(TBD) attribute using a CoA message. The 1283 NAS will then commence to apply the redirection rules and/or the 1284 filter rules. 1286 Alternatively, the RADIUS server can request that the NAS re- 1287 authorize the session using the procedures defined in [RFC3576]. 1288 The RADIUS server responds with an Access-Accept message (with 1289 Service-Type(6) set to "Authorize Only" that will contain the 1290 redirection and optionally filtering rules within a NAS-Filter- 1291 Rule(TBD) attribute. 1293 A.2.3 HTTP Redirection Removal 1295 The RADIUS serve can turn HTTP redirection off mid-session in two 1296 way. It can push new redirection rules within a NAS-Filter- 1297 Rule(TBD) attribute using a CoA message or it can send the NAS a 1298 CoA message requesting it to re-authorize. 1300 When using CoA message to return the redirection and filtering 1301 back to "normal," there needs to be either a filter rule (or 1302 filter-id) or redirection rule that corresponds to the "normal" 1303 state. If normally the session did not have any filter and or 1304 redirection rules applied, the RADIUS server can send a NAS- 1305 Filter-Rule(TBD) with the action of "flush" in the CoA message. 1306 This action will cause all the filter rules and redirection rules 1307 previously assigned to the session to be removed. 1309 A.3 Accounting 1311 Every time a session is redirected and every time the redirection 1312 is reverted back a new session is created and the old one is 1313 terminated. Therefore the NAS MUST generate and Accounting- 1314 Request(Stop) for the old session and an Accounting-Request(Start) 1315 for the new session. 1317 A.4 Example Scenarios 1319 The following two examples illustrate the user's experience when 1320 being redirected. 1322 For the first example assume an IEEE 8021X environment, whereby a 1323 user connects to the enterprise LAN and initiates an 1324 authentication handshake. As part of the overall authentication 1325 process, it is also possible to pass endpoint state such as patch 1326 level, virus signature status, etc., all of which can be verified 1327 by a back-end server for policy compliancy and alter the 1328 authentication and authorization decision. In instances that an 1329 end-host is not in compliancy, the NAS may be instructed to limit 1330 network access in some fashion (i.e. quarantine) and limit network 1331 access to remediation services and a web-based information site. 1332 A user may sense degraded network performance and open a web 1333 session, which the NAS would redirect to the web-based information 1334 site for compliancy status, remediation actions, etc. 1336 For the second example assume an ISP environment, whereby a 1337 prepaid user is roaming the net in their hotel room over WiFi is 1338 to be Hot-lined because their account has no more funds. The 1339 user's Service Provider instructs the NAS to block all traffic, 1340 and redirect any port 80 traffic to the Service Provider's Prepaid 1341 Portal. Upon detecting that there is no service, the user 1342 launches his browser and regardless of which web site is being 1343 accessed the browser traffic will arrive at the Prepaid Portal 1344 which will then return a page back to the subscriber indicating 1345 that he needs to replenish his account. 1347 Appendix B - NAS-Filter-Rule Filter Examples 1349 This appendix presents a variety of filter examples utilizing the 1350 syntax definition described in section 3.5 1352 Example #1: Permit all user traffic, regardless of type. 1354 permit inout any from any to any 1356 Example #2: Permit only L2 traffic coming from and going to a 1357 user's Ethernet MAC address. Block all other traffic. Assume 1358 user's MAC address is 00-10-A4-23-19-C0. 1360 permit in l2:ether2 from 00-10-A4-23-19-C0 to any 1361 permit out l2:ether2 from any to 00-10-A4-23-19-C0 1363 Example #3: Tunnel all L2 traffic coming from and going to a user. 1364 Assume tunnel name is: tunnel "1234". 1366 permit tunnel "tunnel \"1234\"" inout l2:ether2 from any to any 1368 Example #4: Permit only L3 traffic coming and going to from a 1369 user's IP address. Block all other traffic. Assume user's IP 1370 address is 192.0.2.128. 1372 permit in ip from 192.0.2.128 to any 1373 permit out ip from any to 192.0.2.128 1375 Example #5: Permit only L3 traffic coming and going to the user's 1376 assigned IP address. Block all other traffic. 1378 permit in ip from assigned to any 1379 permit out ip from any to assigned 1381 Example #6: Allow user to generate ARP requests, DNS requests, and 1382 HTTP (port 80) requests. Assume user's MAC address is 00-10-A4-23- 1383 19-C0 and IP address is 192.0.2.128. 1385 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any 1386 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 1387 permit in 17 from 192.0.2.168 to any 53 1388 permit out 17 from any 53 to 192.0.2.168 1389 permit in 6 from 192.0.2.168 80 to any 1390 permit out 6 from any 80 to 192.0.2.168 1392 Example #7: Allow user to generate ARP requests, DNS requests, and 1393 HTTP (port 80) requests, any of which are redirected to 1394 http://www.foo.org. Assume user's MAC address is 00-10-A4-23-19-C0 1395 and IP address is 192.0.2.128. 1397 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any 1398 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 1399 permit in 17 from 192.0.2.168 to any 53 1400 permit out 17 from any 53 to 192.0.2.168 1401 redirect http://www.foo.org in from 192.0.2.168 to any 80 1403 Example #8: Allow user to generate ARP requests, DNS requests, and 1404 HTTP (port 80) requests, of which only requests to 1405 http://www.foo.org are redirected to http://www.goo.org. Assume 1406 user's MAC address is 00-10-A4-23-19-C0 and IP address is 1407 192.0.2.128 1409 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any 1410 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 1411 permit in 17 from 192.0.2.168 to any 53 1412 permit out 17 from any 53 to 192.0.2.168 1413 redirect http://www.goo.org in from 192.0.2.168 to any 80 1414 http://www.foo.org 1416 Acknowledgments 1417 The authors would like to acknowledge Joseph Salowey of Cisco, 1418 David Nelson of Enterasys, Chuck Black of Hewlett Packard, and 1419 Ashwin Palekar of Microsoft. 1421 Authors' Addresses 1423 Paul Congdon 1424 Hewlett Packard Company 1425 HP ProCurve Networking 1426 8000 Foothills Blvd, M/S 5662 1427 Roseville, CA 95747 1429 EMail: paul.congdon@hp.com 1430 Phone: +1 916 785 5753 1431 Fax: +1 916 785 8478 1433 Mauricio Sanchez 1434 Hewlett Packard Company 1435 HP ProCurve Networking 1436 8000 Foothills Blvd, M/S 5559 1437 Roseville, CA 95747 1438 EMail: mauricio.sanchez@hp.com 1439 Phone: +1 916 785 1910 1440 Fax: +1 916 785 1815 1442 Avi Lior 1443 Bridgewater Systems Corporation 1444 303 Terry Fox Drive 1445 Suite 100 1446 Ottawa, Ontario K2K 3J1 1447 Canada 1449 Phone: (613) 591-6655 1450 EMail: avi@bridgewatersystems.com 1451 URI: TCP://.bridgewatersystems.com/ 1453 Farid Adrangi 1454 Intel Corporation 1455 2111 North East 25th 1456 Hillsboro, Oregon 97124 1457 United States 1459 Phone: (503) 712-1791 1460 EMail: farid.adrangi@intel.com 1462 Bernard Aboba 1463 Microsoft Corporation 1464 One Microsoft Way 1465 Redmond, WA 98052 1467 EMail: bernarda@microsoft.com 1468 Phone: +1 425 706 6605 1469 Fax: +1 425 936 7329 1471 Intellectual Property Statement 1473 The IETF takes no position regarding the validity or scope of 1474 any Intellectual Property Rights or other rights that might be 1475 claimed to pertain to the implementation or use of the 1476 technology described in this document or the extent to which 1477 any license under such rights might or might not be available; 1478 nor does it represent that it has made any independent effort 1479 to identify any such rights. Information on the procedures 1480 with respect to rights in RFC documents can be found in BCP 78 1481 and BCP 79. 1483 Copies of IPR disclosures made to the IETF Secretariat and any 1484 assurances of licenses to be made available, or the result of 1485 an attempt made to obtain a general license or permission for 1486 the use of such proprietary rights by implementers or users of 1487 this specification can be obtained from the IETF on-line IPR 1488 repository at http://www.ietf.org/ipr. 1490 The IETF invites any interested party to bring to its attention 1491 any copyrights, patents or patent applications, or other 1492 proprietary rights that may cover technology that may be 1493 required to implement this standard. Please address the 1494 information to the IETF at ietf-ipr@ietf.org. 1496 Disclaimer of Validity 1498 This document and the information contained herein are provided 1499 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 1500 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 1501 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1502 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1503 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1504 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1505 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1507 Copyright Statement 1509 Copyright (C) The Internet Society (2006). This document is 1510 subject to the rights, licenses and restrictions contained in 1511 BCP 78, and except as set forth therein, the authors retain all 1512 their rights.