idnits 2.17.1 draft-ietf-radext-filter-rules-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1337. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document 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 IETF Trust 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: 'TBD' is mentioned on line 726, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** 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. 'IEEE802' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021X' -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 4234 (Obsoleted by RFC 5234) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Paul Congdon 3 INTERNET-DRAFT Mauricio Sanchez 4 Hewlett-Packard Company 5 A. Lior 6 3 July 2007 Bridgewater Systems 7 F. Adrangi 8 Intel 9 Bernard Aboba 10 Microsoft 12 RADIUS Attributes for Filtering and Redirection 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 3, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust 2007. All rights reserved. 42 Abstract 44 This document defines the NAS-Traffic-Rule and Acct-NAS-Traffic- 45 Rule attributes within Remote Authentication Dial In User Service 46 (RADIUS) that is based on and extends on the filtering capability 47 defined by Diameter's NAS-Filter-Rule Attribute Value Pair (AVP) 48 described in RFC 4005, and the IPFilterRule syntax defined in RFC 49 3588. 51 Table of Contents 53 1. Introduction........................................... 3 54 1.1. Terminology...................................... 3 55 1.2. Requirements Language............................ 4 56 1.3. Capability Advertisement ........................ 4 57 1.4. Attribute Interpretation......................... 5 58 2. RADIUS Authentication.................................. 5 59 2.5. NAS-Traffic-Rule.................................. 5 60 3. RADIUS Accounting...................................... 16 61 3.1. Acct-NAS-Traffic-Rule............................. 16 62 4. Table of Attributes.................................... 17 63 5. Diameter Considerations................................ 17 64 6. IANA Considerations.................................... 18 65 7. Security Considerations................................ 18 66 8. References............................................. 19 67 8.1 Normative References................................... 19 68 8.2 Informative References................................. 20 69 Appendix A - Traffic Redirection.............................. 22 70 Appendix B - NAS-Traffic-Rule Examples........................ 27 71 ACKNOWLEDGMENTS............................................... 28 72 AUTHORS' ADDRESSES............................................ 28 73 Intellectual Property Statement............................... 29 74 Disclaimer of Validity........................................ 30 75 Full Copyright Statement ..................................... 30 76 1. Introduction 78 Within the confines of RADIUS authentication, authorization, and 79 accounting (AAA) environments, there is a requirement for 80 standardized RADIUS attributes to limit user access using filters 81 and/or redirection. 83 This document describes filtering and redirection attributes that 84 may prove useful in IEEE 802.1X [IEEE8021X] environments, which 85 provides "network port authentication" for IEEE 802 [IEEE802] 86 media (including Ethernet [IEEE8023] and 802.11 [IEEE80211], 87 [IEEE80211i] wireless LANS), and a variety of other situations. 89 While various filtering attributes already exist for RADIUS, such 90 as the [RFC2865] Filter-ID or [RFC4849] NAS-Filter-Rule 91 attributes, they have drawbacks or lack functionality. The 92 Filter-ID attribute requires the NAS to be pre-populated with the 93 desired filters. This may be difficult to deploy in roaming 94 scenarios where the home operator may not know what filters have 95 been pre-populated by the local visited operator. The NAS-Filer- 96 Rule attribute only offers the same functionality as the Diameter 97 [RFC4005] NAS-Filter-Rule AVP, which is limited to layer 3 98 filtering. 100 The filtering attributes specified in this document enable 101 description of layer 2 and layer 3 filters as well as redirection, 102 and therefore extend the filter language described in [RFC3588]. 103 Layer 2 filters are useful in filtering Protocol Data Unit (PDU) 104 traffic, such as IEEE 802.1D's [IEEE8021D] Bridge Protocol Data 105 Units (BPDU), for which layer 3 filters have no effect. The 106 attributes defined in this document may be used with RADIUS 107 dynamic authorization [RFC3576]. 109 User traffic redirection is supported with or without tunneling. 110 Tunneling support is provided using the tunnel attributes defined 111 in [RFC2868]. 113 1.1. Terminology 115 In this document when we refer to blocking of IP traffic we mean 116 filtering of IP traffic. Additionally, this document uses the 117 following terms: 119 Authenticator 120 An authenticator is an entity that requires authentication from 121 the supplicant. The authenticator may be connected to the 122 supplicant at the other end of a point-to-point LAN segment or 123 802.11 wireless link. 125 Authentication server 126 An authentication server is an entity that provides an 127 authentication service to an authenticator. This service 128 verifies from the credentials provided by the supplicant, the 129 claim of identity made by the supplicant. 131 Redirection 132 Refers to an action taken by the NAS to redirect the user's 133 traffic to an alternate location. 135 Supplicant 136 A supplicant is an entity that is being authenticated by an 137 authenticator. The supplicant may be connected to the 138 authenticator at one end of a point-to-point LAN segment or 139 802.11 wireless link. 141 Terminal 142 A terminal is an endpoint, such as an 802.1X supplicant, 143 attached to the NAS port. 145 1.2. Requirements Language 147 In this document, several words are used to signify the 148 requirements of the specification. The key words "MUST", "MUST 149 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 150 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 151 interpreted as described in [RFC2119]. 153 An implementation is not compliant if it fails to satisfy one or 154 more of the must or must not requirements for the protocols it 155 implements. An implementation that satisfies all the must, must 156 not, should and should not requirements for its protocols is said 157 to be "unconditionally compliant"; one that satisfies all the must 158 and must not requirements but not all the should or should not 159 requirements for its protocols is said to be "conditionally 160 compliant". 162 1.3. Capability Advertisement 164 RADIUS does not currently define a method by which a NAS can 165 advertise its capabilities and in many instances, it would be 166 desirable for the home network to know what capabilities are 167 supported by the NAS to ensure proper operational behavior. The 168 attributes defined in this document are intended to be used to 169 enforce policy by the NAS. If a NAS does not recognize these 170 attributes it will most likely ignore them and the desired policy 171 will not be enforced. A method for the NAS advertising the 172 capability to support these attributes would help the RADIUS 173 server understand if the intended policies can be enforced. As a 174 result, the attributes in this document, in particular NAS- 175 Traffic-Rule(TBD), can benefit from capability advertisement, if 176 available. 178 1.4 Attribute Interpretation 180 If a NAS conforming to this specification receives an Access- 181 Accept packet containing an attribute defined in this document 182 which it cannot apply, it MUST act as though it had received an 183 Access-Reject. 185 Similarly, [RFC3576] requires that a NAS receiving a CoA-Request 186 containing an unsupported attribute reply with a CoA-NAK. It is 187 RECOMMENDED that an Error-Cause attribute with value set to 188 "Unsupported Attribute" (401) be included in the packet. As 189 noted in [RFC3576], authorization changes are atomic so that this 190 situation does not result in session termination and the pre- 191 existing configuration remains unchanged. As a result, no 192 accounting packets should be generated. 194 2. RADIUS Authentication 196 This specification introduces one new RADIUS authentication 197 attribute. 199 2.5. NAS-Traffic-Rule 201 Description 203 The NAS-Traffic-Rule attribute is derived from the Diameter 204 IPFilterRule syntax and enables provisioning of base 205 encapsulation (Layer 2) rules, Internet Protocol (Layer 3-4) 206 rules, and HTTP (Layer 5+) rules on the NAS by the RADIUS 207 server. Compared to Diameter's IPFilterRule syntax, NAS- 208 Traffic-Rule is a superset in functionality, but is largely 209 based on the same syntax foundations. 211 Note: This document defines version 1 (v1) of the syntax for 212 the traffic rule attribute. The facility exists to extend the 213 syntax by using a new version number as noted in the ABNF 214 description. Future syntax revisions of this attribute may use 215 an incremented version number (e.g. v2). 217 For each rule and depending on the rule type, the NAS can be 218 instructed to take a single action as follows: 220 Rule Type Allowable rule action 221 ------------------- --------------------- 222 Base Encapsulation filter, tunnel 223 Internet Protocol filter, tunnel 224 HTTP filter, redirect 226 When specifying a base encapsulation rule, NAS-Traffic-Rule 227 processes packets based on the following information that is 228 associated with it: 230 Direction (in and/or out) 231 Base encapsulation type 232 Source and destination MAC address (possibly masked) 234 For a base encapsulation rule, the filter action entails having 235 the NAS permit (i.e. forward) or deny (i.e. block) a user's 236 traffic. The tunnel action entails having the NAS forward user 237 traffic to or from a named tunnel that has been established per 238 [RFC2868]. 240 When specifying an Internet Protocol rule, NAS-Traffic-Rule 241 processes packets based on the following information that is 242 associated with it: 244 Direction (in and/or out) 245 Source and destination IP address (possibly masked) 246 Protocol 247 Source and destination port (lists or ranges) 248 TCP flags 249 IP fragment flag 250 IP options 251 ICMP types 253 For an Internet Protocol rule, the filter action entails having 254 the NAS permit (i.e. forward) or deny (i.e. block) a user's 255 traffic. The tunnel action entails having the NAS forward user 256 traffic to or from a named tunnel that has been established per 257 [RFC2868]. 259 When specifying an HTTP rule, NAS-Traffic-Rule processes 260 packets based on the following information that is associated 261 with it: 263 HTTP URL 264 Source and destination IP address (possibly masked) 266 For an HTTP rule, the filter action entails having the NAS 267 permit (i.e. forward) or deny (i.e. block) a user's [RFC2616] 268 request message. For a deny action, the NAS MAY respond to the 269 request message with a code 403 (Forbidden) response in 270 accordance with [RFC2616]. For a redirect action the NAS SHOULD 271 respond to the user's request with a code 302 (Found) response 272 in accordance with [RFC2616]. 274 For the HTTP redirection action, it is also possible to have 275 redirection automatically removed by including a redir-cnt 276 count parameter along with the rule. The rule will be removed 277 from the active rule set when the rule matches redir-cnt number 278 of times. Upon removal from the active rule set, traffic is no 279 longer evaluated against this rule. 281 It should be noted that an HTTP filter or redirect rule is only 282 useful with plain-text HTTP and not [RFC2818] HTTPS. 283 Redirection or filtering of HTTPS is outside the scope of this 284 document. 286 As per the requirements of RFC 2865, Section 2.3, if multiple 287 NAS-Traffic-Rule attributes are contained within an Access- 288 Accept or CoA-Request packet, they MUST be maintained in order. 289 The attributes MUST be consecutive attributes in the packet. 290 RADIUS proxies MUST NOT reorder NAS-Traffic-Rule attributes. 292 The RADIUS server can return multiple NAS-Traffic-Rule 293 attributes in an Access-Accept or CoA-Request packet. Where 294 more than one NAS-Traffic-Rule attribute is included, it is 295 assumed that the attributes are to be concatenated to form a 296 single filter list. As noted in [RFC2865] Section 2.3, "the 297 forwarding server MUST NOT change the order of any attributes 298 of the same type", so that RADIUS proxies will no reorder NAS- 299 Traffic-Rule attributes. 301 Rules are evaluated in order, with the first matched rule 302 terminating the evaluation. Each packet is evaluated once. If 303 no rule matches, then packet is dropped (implicit deny all). 305 When an HTTP redirect rule matches, the NAS shall reply to the 306 HTTP request with an HTTP redirect in accordance with [RFC2616] 307 redirecting traffic to specific URL. 309 Filter-ID (11), NAS-Filter-Rule [RFC4849] and NAS-Traffic-Rule 310 attributes define how filters are to be applied in the NAS. 311 These attributes are not intended to be used concurrently and 312 SHOULD NOT appear in the same RADIUS message. Only one type of 313 filtering attribute must be processed. If a Filter-ID (11) is 314 present, then the NAS-Traffic-Rule MUST be ignored, if present. 316 A NAS-Traffic-Rule attribute may contain a partial rule, one 317 rule, or more than one rule. Rules may be contained across 318 attribute boundaries, so implementations cannot assume that 319 individual traffic rules begin or end on attribute boundaries. 321 The NAS-Traffic-Rule attribute is shown below. The fields are 322 transmitted from left to right: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type (TBD) | Length | Text 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Text (cont.) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Type 334 TBD 336 Length 338 >= 3 340 Text 342 The text conforms to the following ABNF [RFC4234] formatted syntax 343 specification: 345 ; Start of ABNF description of NAS-Traffic-Rule 347 rule = "v1" " " (flush-rule / permit-all-rule 348 / l2-filter-rule / l2-tunnel-rule 349 / ip-filter-rule / ip-tunnel-rule 350 / http-filter-rule / http-redir-rule) 351 rule-delim 353 ; Flush Rule 354 flush-rule = "flush" 356 ; Permit all rule 357 permit-all-rule = "permit inout any from any to any" 358 [" " log-rule] 360 ; Base encapsulation filter rule 361 l2-filter-rule = ("permit" / "deny") " " 362 ("in" / "out" / "inout") " " 363 l2-filter-body [" " log-rule] 365 l2-filter-body = (l2-proto " from " l2-address " to " 366 l2-address) / l2-rmon-str 367 l2-proto = "l2:ether2" [":0x" 1*4HEXDIG] 368 l2-rmon-str = "l2:" 1*DIGIT *("." 1*DIGIT) 369 l2-address = ["!"] (macaddr / (macaddr "/" macmask) 370 / "any") 371 macaddr = 2HEXDIG 5("-" 2HEXDIG) 372 macmask = DIGIT ; 0-9 373 / %x31-33 DIGIT ; 10-39 374 / "4" %x30-38 ; 40-48 376 ;Base encapsulation tunnel rule 377 l2-tunnel-rule = "tunnel " tunnel-id " " 378 ("in" / "out" / "inout") " " 379 l2-filter-body [" " log-rule] 381 ;IP Filter Rule 382 ip-filter-rule = ("permit" / "deny") " " 383 ("in" / "out" / "inout") " " 384 ("ip" / ip-proto) filter-body 385 [" " ip-option] [" " log-rule] 386 ip-proto = d8 387 ip-address = ["!"] (ipv4-address ["/" ipv4mask] / 388 ipv6-address ["/" ipv6mask] / 389 "any" / 390 "assigned") 391 ipv4-address = d8 "." d8 "." d8 "." d8 392 ipv4mask = DIGIT ; 0-9 393 / %x31-32 DIGIT ; 10-29 394 / "3" %x30-32 ; 30-32 395 ipv6-address = 1*4HEXDIG 7(":" 1*4HEXDIG) 396 ipv6mask = DIGIT ; 0-9 397 / %x31-39 DIGIT ; 10-99 398 / "1" %x30-31 DIGIT ; 100-119 399 / "1" %x32 %x30-38 ; 120-128 400 layer4-ports = layer4-port *("," layer4-port) 401 layer4-port = d16 / d16 "-" d16 402 ip-option = "frag" / 403 ["ipoptions " ["!"] ipopt *("," ["!"] ipopt)] 404 ["tcpoptions " ["!"] tcpopt 405 *("," ["!"] tcpopt)] 406 ["established"] 407 ["setup"] 408 ["tcpflags " ["!"] tcpflag 409 *("," ["!"] tcpflag)] 410 ["icmptypes " icmptype *("," icmptype)] 411 ipopt = "ssrr" / "lsrr" / "rr" / "ts" 412 tcpopt = "mss" / "window" / "sack" / "ts" / "cc" 413 tcpflag = "fin" / "syn" / "rst" / "psh" / "ack" / "urg" 414 icmptype = d8 / d8 "-" d8 415 / "echo reply" / "destination unreachable" 416 / "source quench" / "redirect" 417 / "echo request" / "router advertisement" 418 / "router solicit" / "time-to-live exceeded" 419 / "IP header bad" / "timestamp request" 420 / "timestamp reply" / "information request" 421 / "information reply" 422 / "address mask request" 423 / "address mask reply" 425 ;IP Tunnel Rule 426 ip-tunnel-rule = "tunnel " tunnel-id " " 427 ("in" / "out" / "inout") " " 428 ("ip" / ip-proto) filter-body 429 [" " ip-option] [" " log-rule] 431 ;HTTP Filter Rule 432 http-filter-rule= ("permit" / "deny") org-url " " 433 ("in" / "out" / "inout") filter-body 434 [" " log-rule] 436 ;HTTP Redirect Rule 437 http-redir-rule= "redirect " [redir-cnt " "] redir-url 438 filter-body [" " org-url] 439 [" " log-rule] 440 redir-cnt = 1*DIGIT 441 org-url = http-URL 442 ;Note: Syntax for http-URL defined in 443 ;[RFC2616], section 3.2.2 444 redir-url = http-URL 446 ;Common 447 filter-body = " from " ip-address [" " layer4-ports] 448 " to " ip-address [" " layer4-ports] 449 tunnel-id = DQUOTE 450 1*(TEXTDATA / ("%" 2HEXDIG)) 451 DQUOTE 452 log-rule = "cnt" 454 ;Primitives 455 LF = %x0A ; linefeed 456 DIGIT = %x30-39 ; 0-9 457 DQUOTE = %x22 ; " (Double Quote) 458 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 459 rule-delim = LF 460 d8 = DIGIT ; 0-9 461 / %x31-39 DIGIT ; 10-99 462 / "1" 2DIGIT ; 100-199 463 / "2" %x30-34 DIGIT ; 200-249 464 / "25" %x30-35 ; 250-255 465 d16 = DIGIT ; 0-9 466 / %x31-35 1*4DIGIT ; 10-59999 467 / "6" "4" 3DIGIT ; 60000-64999 468 / "6" "5" %x30-34 2DIGIT ; 65000-65499 469 / "6" "5" "5" %x30-32 1DIGIT ; 65500-65529 470 / "6" "5" "5" "3" %x30-36 ; 65530-65536 471 TEXTDATA = %x20-21 / %x23-24 / %x26-7E 473 ; End of ABNF description of NAS-Traffic-Rule 475 Descriptions of notable fields and keywords follow: 477 "v1" Required in every rule to mark rule as being 478 of 'v1' version of syntax. Future updates to 479 the rule syntax will be differentiated through 480 increments to this field (i.e. 'v2', 'v3', etc.). 482 "permit" Allow packets that match the rule. 484 "deny" Drop packets that match the rule. 486 "redirect" Redirect packets that match the rule. 488 "tunnel" Tunnel packets that match the rule. 490 "flush" A flush rule removes all previously assigned 491 filter rules. When flush is specified, it can be 492 followed by other NAS-Traffic-Rule attributes. This 493 allows for an atomic change of authorization with a 494 single RADIUS message. 496 "permit inout any from any to any" 497 Special rule that matches against all traffic. This 498 allows the implicit deny at the end of a filter 499 list to be overridden. 501 "in" Is from the terminal. 503 "out" Is to the terminal. 505 "inout" Is from and to the terminal. 507 ipv4-address An IPv4 number in dotted-quad form. Only this 508 exact IP number will match the rule. 509 ipv6-address An IPv6 number in canonical IPv6 form. Only 510 this exact IP number will match the rule. 512 ipv4-address/ipv4mask 513 An IP number with a mask width of the form 514 192.0.2.0/24. In this case, all IP numbers from 515 192.0.2.0 to 192.0.2.255 will match. 517 The bit width MUST be valid for the IP version and 518 the IP number MUST NOT have bits set beyond the 519 mask. For a match to occur, the same IP version 520 MUST be present in the packet that was used in 521 describing the IP address. To test for a 522 particular IP version, the bits part can be set to 523 zero. 525 "any" Keyword for 0.0.0.0/0 or the IPv6 equivalent. 527 "assigned" Keyword for the address or set of addresses 528 assigned to the terminal. For IPv4, a typical 529 first rule is often "deny in ip !assigned" 531 The sense of the match can be inverted by preceding 532 an address with the not modifier (!), causing all 533 other addresses to be matched instead. This does 534 not affect the selection of port numbers. 536 layer4-port With the TCP, UDP and SCTP protocols, this field 537 specifies ports to match. If not specified, the 538 rule will match against all ports. 540 Note: The '-' notation specifies a range of ports 541 (including boundaries). Fragmented packets that 542 have a non-zero offset (i.e., not the first 543 fragment) will never match a rule that has one or 544 more port specifications. See the "frag" keyword 545 for details on matching fragmented packets. 547 log-rule Increments rule hit counter by one every time a 548 packet matches on rule. Counters start with a zero 549 value at session start and are reset back to a zero 550 value every time a successful authorization change 551 occurs due to a CoA message being received by the 552 NAS. 554 For base encapsulation rules: 555 "l2:" Prefix to designate a rule as a base encapsulation 556 rule. 558 "l2:ether2" Keyword means any Ethernet-II (DIX Ethernet) will 559 match. 561 ether2:val Used to specify an Ethernet-II type by hexadecimal 562 number, whereby "val" is replaced by desired 563 number. Example: "l2:ether2:0x800" for IP ethertype 564 (0x0800). 566 l2-rmon-str Used to specify base encapsulation per the octet 567 string format defined in [RFC2895], section 4.2. 568 Example: "l2:0.0.0.2.0.0.0.240" for Netbios over 569 LLC. 571 macaddr For base encapsulation filter rules of "l2:ether2" 572 type, the Ethernet MAC address with octet values 573 separated by a "-". Example: "00-10-A4-23-19-C0". 575 macaddr/mask An Ethernet number as above with a mask width of 576 the form "00-10-A4-23-00-00/32". In this case, all 577 MAC addresses from 00-10-A4-23-00-00 to 00-10-A4- 578 23-FF-FF will match. The MAC address MUST NOT have 579 bits set beyond the mask. The keyword "any" is 580 00-00-00-00-00-00/0. 582 The sense of the match can be inverted by preceding 583 an address with the not modifier (!), causing all 584 other addresses to be matched instead. 586 Note: macaddr nor macaddr/mask argument is not used 587 for "l2:rmon" type rules. 589 For IP rules: 590 "ip" Keyword means any IP protocol will match. 592 ip-proto An IP protocol specified by number. 594 "frag" Match if the packet is a fragment and this is not 595 the first fragment of the datagram. frag may not 596 be used in conjunction with either tcpflags or 597 TCP/UDP port specifications. 599 "ipoptions" Match if the IP header contains the comma separated 600 list of options specified in spec. The supported 601 IP options are: ssrr (strict source route), lsrr 602 (loose source route), rr (record packet route) and 603 ts(timestamp). The absence of a particular option 604 may be denoted with a '!'. 606 "tcpoptions" Match if the TCP header contains the comma 607 separated list of options specified in spec. The 608 supported TCP options are: 610 mss (maximum segment size), window (tcp window 611 advertisement), sack (selective ack), ts (rfc1323 612 timestamp) and cc (rfc1644 t/tcp connection count). 613 The absence of a particular option may be denoted 614 with a '!'. 616 "established" TCP packets only. Match packets that have the 617 RST or ACK bits set. 619 "setup" TCP packets only. Match packets that have the SYN 620 bit set but no ACK bit. 622 "tcpflags" TCP packets only. Match if the TCP header contains 623 the comma separated list of flags specified in 624 spec. The supported TCP flags are: 626 fin, syn, rst, psh, ack and urg. The absence of a 627 particular flag may be denoted with a '!'. A rule 628 that contains a tcpflags specification can never 629 match a fragmented packet that has a non-zero 630 offset. See the "frag" option for details on 631 matching fragmented packets. 633 "icmptypes" ICMP packets only. Match if the ICMP type is in 634 the list types. The list may be specified as any 635 combination of ranges or individual types separated 636 by commas. Both the numeric values and the 637 symbolic values listed below can be used. The 638 supported ICMP types are: 640 echo reply (0), destination unreachable (3), source 641 quench (4), redirect (5), echo request(8), router 642 advertisement (9), router solicitation (10), time- 643 to-live exceeded (11), IP header bad (12), 644 timestamp request (13), timestamp reply (14), 645 information request (15), information reply (16), 646 address mask request (17) and address mask reply 647 (18). 649 For HTTP redirection rules: 650 redir-cnt Specifies the number of HTTP redirect rule matches 651 that should transpire before removing this rule 652 from the active rule set. Upon removal from the 653 active rule set, traffic is no longer evaluated 654 against this rule. 656 redir-url An HTTP URL. When the 'redirect' rule matches 657 (src/dst and/or org_URL ), HTTP requests are 658 redirected to redir_URL address in accordance with 659 [RFC2616] redirection traffic to specific URL. 661 org-url An HTTP URL. Specifies the HTTP URL against which 662 user HTTP requests will be evaluated. If user HTTP 663 request matches org_URL, then redirection action is 664 taken. 666 For base encapsulation and IP tunnel rules: 667 tunnel_id A tunnel id. When the 'tunnel' rule matches, 668 traffic is redirected over the tunnel with the 669 specified tunnel_id. Traffic can only be redirected 670 to or from named tunnels that have been established 671 per [RFC2868] and named using the Tunnel- 672 Assignment-ID attribute described therein. 674 The tunnel id MUST be encapsulated in double quotes 675 and follow the labeling convention defined by the 676 TEXTDATA. 677 Example: A tunnel with the name of tunnel "ppp%1" 678 would be specified as "%22ppp%251%22" 680 A NAS that is unable to interpret or apply a deny rule MUST 681 terminate the session. A NAS MAY apply deny rules of its own 682 before the supplied rules, for example to protect the access 683 device owner's infrastructure. 685 3. RADIUS Accounting 687 This specification introduces one new RADIUS accounting attribute. 689 3.1. Acct-NAS-Traffic-Rule 691 Description 693 Acct-NAS-Traffic-Rule enables a RADIUS client to include NAS- 694 Traffic-Rule[TBD] rule match counters as part of the accounting 695 message. 697 The Acct-NAS-Traffic-Rule attribute is shown below. The fields 698 are transmitted from left to right: 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Type | Length | Counter (64-bits) 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Counter (cont.) 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Counter (cont.) | Text (NAS-Traffic-Rule) | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Type 711 TBD 713 Length 714 >=11 716 Counter 718 The Counter field is eight octets in length and contains the 719 64-bit hit count for the rule specified in the Text field. 721 Text 723 The Text field is greater than one octet in length and is used 724 to specify the rule for which a hit count is associated with. 725 The Text field MUST conform to the syntax rules specified for 726 the Text field of the NAS-Traffic-Rule[TBD] attribute. 728 4. Table of Attributes 730 The following table provides a guide to which attributes may be 731 found in which kinds of packets, and in what quantity. 733 Access- Access- Access- Access- CoA- 734 Request Accept Reject Challenge Req # Attribute 735 0 0+ 0 0 0+ TBD NAS-Traffic-Rule 737 Actng- Actng- 738 Request Response # Attribute 739 0-1 0 TBD Acct-NAS-Traffic-Rule 741 The following table defines the meaning of the above table 742 entries. 744 0 This attribute MUST NOT be present in packet. 745 0+ Zero or more instances of this attribute MAY be present in 746 the packet. 747 0-1 Zero or one instance of this attribute MAY be 748 present in the packet. 750 5. Diameter Considerations 752 When used in Diameter, the attributes defined in this 753 specification can be used as Diameter attribute-value pair (AVPs) 754 from the Code space 1-255 (RADIUS attribute compatibility space). 755 No additional Diameter Code values are therefore allocated. The 756 data types and flag rules for the attributes are as follows: 758 +---------------------+ 759 | AVP Flag rules | 760 |----+-----+----+-----|----+ 761 | | |SHLD| MUST| | 762 Attribute Name Value Type |MUST| MAY | NOT| NOT |Encr| 763 ---------------------------------|----+-----+----+-----|----| 764 NAS-Traffic-Rule OctetString| M | P | | V | Y | 765 Acct-NAS-Traffic-Rule OctetString| M | P | | V | Y | 766 ---------------------------------|----+-----+----+-----|----| 768 The attributes in this specification have no special translation 769 requirements for Diameter to RADIUS or RADIUS To Diameter 770 gateways; they are copied as is, except for changes relating to 771 headers, alignment, and padding. See also [RFC3588] Section 4.1 772 and [RFC4005] Section 9. 774 What this specification says about the applicability of the 775 attributes for RADIUS Access-Request packets applies in Diameter 776 to AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is 777 said about Access-Challenge applies in Diameter to AA-Answer 778 [RFC4005] or Diameter-EAP-Answer [RFC4072] with Result-Code AVP 779 set to DIAMETER_MULTI_ROUND_AUTH. 781 What is said about Access-Accept applies in Diameter to AA-Answer 782 or Diameter-EAP-Answer messages that indicate success. Similarly, 783 what is said about RADIUS Access-Reject packets applies in 784 Diameter to AA-Answer or Diameter-EAP-Answer messages that 785 indicate failure. 787 What is said about COA-Request applies in Diameter to Re-Auth- 788 Request [RFC4005]. 790 What is said about Accounting-Request applies to Diameter 791 Accounting-Request [RFC4005] as well. 793 6. IANA Considerations 795 This specification does not create any new registries. 797 This document uses the RADIUS [RFC2865] namespace, see 798 . Allocation of two 799 updates for the section "RADIUS Attribute Types" is requested. The 800 RADIUS attributes for which values are requested are: 802 TBD - NAS-Traffic-Rule 803 TBD - Acct-NAS-Traffic-Rule 805 7. Security Considerations 807 Since this document describes the use of RADIUS for purposes of 808 authentication, authorization, and accounting in [IEEE8021X] 809 enabled networks, it is vulnerable to all of the threats that are 810 present in other RADIUS applications. For a discussion of these 811 threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580]. 813 This document specifies new attributes that can be included in 814 existing RADIUS messages. These messages are protected using 815 existing security mechanisms; see [RFC2865] and [RFC3576] for a 816 more detailed description and related security considerations. 818 The security mechanisms in [RFC2865] and [RFC3576] are primarily 819 concerned with an outside attacker who modifies messages in 820 transit, inserts new messages, or deletes messages. They do not 821 prevent an authorized RADIUS server or proxy from inserting or 822 deleting attributes with a malicious purpose in messages it sends. 824 An attacker who compromises an authorized RADIUS server or proxy 825 can use the attributes defined in this document to influence the 826 behavior of the NAS in ways that previously may not have been 827 possible. For example, inserting suitable redirection rules to the 828 NAS-Traffic-Rule attribute may allow the attacker to eavesdrop or 829 modify packets sent by a legitimate client. 831 In general, the NAS cannot know whether the attribute values it 832 receives from an authenticated and authorized server are well- 833 intentioned or malicious, and thus it is not possible to 834 completely protect against attacks by compromised nodes. In some 835 cases, the extent of the possible attacks can be limited by 836 performing more fine-grained authorization checks at the NAS. 837 For instance, a NAS could be configured not to accept any 838 redirection rules if it is known they are not used in this 839 environment. 841 8. References 843 8.1. Normative references 845 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 846 Requirement Levels", RFC 2119, March, 1997. 848 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 849 L., Leach P., Berners-Lee T., "Hypertext Transfer Protocol 850 -- HTTP/1.1", RFC 2616, June 1999. 852 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 853 Authentication Dial In User Service (RADIUS)", RFC 2865, 854 June 2000. 856 [RFC2895] Bierman, A., Bucci, C., Iddon, R., "Remote Network 857 Monitoring MIB Protocol Identifier Reference", RFC 858 2895, August 2000 860 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko, 861 J., "Diameter Base Protocol", RFC 3588, September 2003. 863 [RFC4005] Calhoun, P., Zorn, G., Spence, D., Mitton, D., "Diameter 864 Network Access Server Application", RFC 4005, August 2005. 866 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 867 Overview and Architecture, ANSI/IEEE Std 802, 1990. 869 [IEEE8021X] 870 IEEE Standards for Local and Metropolitan Area Networks: 871 Port based Network Access Control, IEEE Std 802.1X-2004, 872 August 2004. 874 8.2. Informative references 876 [RFC2607] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy 877 Implementation in Roaming", RFC 2607, June 1999. 879 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 881 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 882 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 883 Support", RFC 2868, June 2000. 885 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 886 3162, August 2001. 888 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 889 Aboba,"Dynamic Authorization Extensions to Remote 890 Authentication Dial In User Service (RADIUS)", RFC 3576, 891 July 2003. 893 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 894 Authentication Protocol (EAP)", RFC 3579, September 2003. 896 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., 897 "IEEE 802.1X Remote Authentication Dial In User Service 898 (RADIUS) Usage Guidelines", RFC3580, September 2003. 900 [RFC4072] Eronen, P., Hiller, T., Zorn G., "Diameter Extensible 901 Authentication Protocol (EAP) Application", RFC4072, August 902 2005. 904 [RFC4234] Croker, E., Overell, P., "Augmented BNF for Syntax 905 Specifications: ABNF", RFC 4234, October 2005. 907 [RFC4849] Congdon, P., Aboba B., and Mauricio S., "Filter Rule 908 Attribute", RFC4849, April 2007. 910 [IEEE8023] 911 ISO/IEC 8802-3 Information technology - Telecommunications 912 And information exchange between systems - Local and 913 metropolitan area networks - Common specifications - Part 914 3: Carrier Sense Multiple Access with Collision Detection 915 (CSMA/CD) Access Method and Physical Layer Specifications, 916 (also ANSI/IEEE Std 802.3- 1996), 1996. 918 [IEEE80211] 919 Information technology - Telecommunications and information 920 exchange between systems - Local and metropolitan area 921 networks - Specific Requirements Part 11: Wireless LAN 922 Medium Access Control (MAC) and Physical Layer (PHY) 923 Specifications, IEEE Std. 802.11-1999, 1999. 925 [IEEE80211i] 926 Institute of Electrical and Electronics Engineers, 927 "Supplement to Standard for Telecommunications and 928 Information Exchange Between Systems - LAN/MAN Specific 929 Requirements - Part 11:Wireless LAN Medium Access Control 930 (MAC) and Physical Layer 931 (PHY) Specifications: Specification for Enhanced Security", 932 June 2004. 934 [IEEE8021D] 935 IEEE Standard for Local and Metropolitan Area Networks: 936 Media Access Control (MAC) Bridges, IEEE St. 802.1D-2004, 937 June 2004. 939 Appendix A - Traffic Redirection 941 There are several ways to redirect the user's traffic. Which 942 method will be used depends on the capabilities available at the 943 NAS and Service Provider's preference. This Appendix describes 944 various methods to redirect user traffic by using the new 945 attributes outlined in this document in conjunction with existing 946 attributes, which are: 948 1) Tunneling; and 949 2) HTTP Redirection; 951 For each method we describe how redirection is done at service 952 initiation and mid-session. We also describe how redirection is 953 removed when it is no longer desired. 955 A.1 Tunneling 957 User traffic can be redirected by tunneling the user's traffic to 958 an alternate location. Tunneling will typically redirect all of 959 the user's traffic for the Service. When tunneling is used to 960 redirect all the traffic, then filtering may not be necessary. 962 A.1.1 Service Initiation 964 Redirect using tunnels at service initiation requires that the 965 RADIUS server send the appropriate [RFC2868] tunnel attributes and 966 NAS-Traffic-Rule attributes to the NAS. The [RFC2868] tunnel 967 attributes describe the tunnel endpoint and the type of tunnel to 968 construct. The 'tunnel ' option for the NAS-Traffic- 969 Rule allows the specification of a traffic rule for which to 970 redirect traffic to a named tunnel. 972 A.1.2 Mid-session Tunnel Redirection 974 Redirection of traffic using tunnels mid-session involves sending 975 the tunnel attributes as per [RFC2868] to the NAS using Change-of- 976 Authorization (CoA) message. The operation is described in 977 [RFC3576]. Careful attention should be paid to the security 978 issues in [RFC3576]. 980 Note that if the session is already tunneled (eg. Mobile-IP) then 981 the CoA message with a new tunnel specification can be sent to the 982 NAS or alternatively the redirection can occur at the tunnel 983 endpoint (the Home Agent) using any one of these methods. 985 A.1.3 Tunnel Redirection Removal 986 If the normal mode for the session was to tunnel the session and 987 redirection was sent to the NAS, the RADIUS Server can send the 988 original tunnel attributes to the NAS in a CoA message. The NAS 989 will tear down the tunnel and establish a connection back to the 990 original tunnel endpoint. 992 However, if the normal mode for the session is not to use 993 tunneling then there is a problem because RADIUS does not have a 994 mechanism whereby it can de-tunnel. Receiving a CoA message 995 without tunnel attributes would not have an effect on an existing 996 tunnel. In order to de-tunnel the session, the RADIUS server has 997 to send the NAS a CoA message with Service-Type(6) set to 998 "Authorize-Only" causing the NAS to perform a re-Authorization. 999 In response to the re-Authorization, the RADIUS server will send 1000 an Access-Accept packet without the tunneling information. Upon 1001 receiving the corresponding Access-Accept packet the NAS MUST 1002 apply the new authorization attributes. If these do not contain 1003 tunnel attributes, then the NAS MUST tear down the tunnel. 1005 A.1.4 Tunnel Redirection Examples 1007 The following examples illustrate how traffic flows when subjected 1008 to a NAS-Traffic-Rule using tunnel redirection. In these 1009 scenarios, the following notation is used to represent traffic 1010 flows: 1012 ------> Flow in one direction 1013 <-----> Flow in two directions 1014 ======> Flow in a tunnel in one direction 1015 <=====> Flow in a tunnel in two directions 1017 A RADIUS server that wishes all IP traffic to flow between the 1018 client and a selected redirection destination will issue an 1019 Access-Accept that contains the specification for the tunnel using 1020 the attributes defined by RFC 2868 and a NAS-Traffic-Rule 1021 attribute using the tunnel action and arguments. 1023 An example NAS-Traffic-Rule will look like: 1025 tunnel "t1" in ip from assigned to any 1027 This will cause all traffic that flows from the client to any 1028 destination to be tunneled over the named tunnel "t1" to the 1029 tunnel endpoint (TEP). 1031 +-------+ +------+ +------+ +------+ 1032 | | | | |Tunnel| | | 1033 |client +<---------->+ NAS +<==t1===>+ End +<----->+ Dest | 1034 | | | | |Point | | | 1035 +-------+ +------+ +------+ +------+ 1037 The direction argument takes the values of "in", "out" or "inout" 1038 and is important because it controls how information is routed. 1039 The following diagram demonstrates how traffic is routed. In all 1040 these diagrams time is increasing as we proceed down the page. 1042 When rule direction is "in": 1044 client NAS TEP DESTINATION 1045 | | | | 1046 |---------->|===t1===>|--------->| 1047 | | | | 1048 |<----------|<-------------------| (flows directly to NAS) 1049 | | | | 1051 The inbound traffic from the client matches the specified filter 1052 rule and the IP packet is placed in the tunnel to the TEP. The TEP 1053 forwards the packet to the Destination using the destination IP 1054 address in the packet header. Note that the source address of the 1055 packet is the address assigned at the NAS. Therefore if the 1056 destination were to reply to the packet it would use the NAS 1057 source address and the packet would flow directly to the NAS and 1058 to the client bypassing the TEP. The Home network would use this 1059 capability if it was only interested in metering or seeing the 1060 inbound traffic from the client. 1062 However, if the home network wanted to see the traffic in both 1063 directions it could deploy a NAT function at the TEP. 1065 Here is the flow when the TEP is acting like a NAT: 1067 client NAS TEP/NAT DESTINATION 1068 | | | | 1069 |---------->|===t1===>|--------->| 1070 | | | | 1071 |<----------|<==t1====|<---------| 1073 The client establishes a connection to the Destination, but the 1074 TEP acting as NAT, changes the source address of the IP packet (as 1075 NATs do) to that of the TEP/NAT. Now any replies from the 1076 Destination are sent to the TEP/NAT. The TEP/NAT then forwards 1077 these packets to the client through the NAS. 1079 When the TEP is acting as a NAT, using the direction argument "in" 1080 is important. The direction argument set to "out" will have no 1081 effect on traffic coming from the tunnel since all traffic to the 1082 client should come from the TEP/NAT inside the tunnel. The 1083 direction argument set to "inout" will have the same effect as if 1084 it were set to "in". 1086 The TEP/NAT forwards all traffic for the client into the tunnel to 1087 the NAS. The NAS always forwards any egressing traffic from the 1088 tunnel to the client. It does not apply any redirection rules on 1089 traffic egressing a tunnel. The NAS does not care whether the TEP 1090 is transparent or is acting as a NAT. 1092 A.2 HTTP Redirection 1094 Another method of redirection is at the application layer, 1095 specifically the HTTP layer. An HTTP aware NAS redirects traffic 1096 by issuing an HTTP Redirect response causing the user's browser to 1097 navigate to an alternate Web Portal. 1099 The call flow associated with performing redirection at the HTTP 1100 layer is very similar with the call flow associated with 1101 redirection done at the IP layer. 1103 The same NAS-Traffic-Rule(TBD) attribute described above is used 1104 to convey the redirection rules to use for HTTP redirection. HTTP 1105 redirection rules within the NAS-Traffic-Rule attribute supports 1106 the encoding of a redirection URL to apply when a rule is matched. 1108 A.2.1 Service Initiation 1110 As with previous call flows, the RADIUS server MAY send multiple 1111 HTTP redirect or filtering rules within a NAS-Traffic-Rule(TBD) 1112 attribute to the NAS in the Access-Accept message. 1114 A.2.2 Mid-session HTTP Redirection 1116 If HTTP redirection is required to be applied to a service that 1117 has already been started then the RADIUS server can push the 1118 redirection rules, and optionally the filter rules, to the NAS 1119 within a NAS-Traffic-Rule(TBD) attribute using a CoA-Request 1120 message. The NAS will then commence to apply the redirection rules 1121 and/or the filter rules. 1123 Alternatively, the RADIUS server can request that the NAS re- 1124 authorize the session using the procedures defined in [RFC3576]. 1125 The RADIUS server responds with an Access-Accept message (with 1126 Service-Type(6) set to "Authorize Only" that will contain the 1127 redirection and optionally filtering rules within a NAS-Traffic- 1128 Rule(TBD) attribute. 1130 A.2.3 HTTP Redirection Removal 1132 HTTP Redirection rules can be automatically removed mid-session 1133 from the NAS using the redir-cnt parameter or explicitly removed 1134 from the RADIUS server. The RADIUS server can explicitly turn HTTP 1135 redirection off mid-session in two ways. It can push new 1136 redirection rules within a NAS-Traffic-Rule(TBD) attribute using a 1137 CoA-Request message or it can send the NAS a CoA-Request message 1138 requesting it to re-authorize. 1140 When using CoA-Request message to return the redirection and 1141 filtering back to "normal," there needs to be either a filter rule 1142 (or filter-id) or redirection rule that corresponds to the 1143 "normal" state. If normally the session did not have any filter 1144 and or redirection rules applied, the RADIUS server can send a 1145 NAS-Traffic-Rule(TBD) with the action of "flush" in the CoA- 1146 Request message. This action will cause all the filter rules and 1147 redirection rules previously assigned to the session to be 1148 removed. 1150 A.3 Accounting 1152 Every time a session is redirected and every time the redirection 1153 is reverted back a new session is created and the old one is 1154 terminated. Therefore the NAS MUST generate and Accounting- 1155 Request(Stop) for the old session and an Accounting-Request(Start) 1156 for the new session. 1158 A.4 Example Scenarios 1160 The following two examples illustrate the user's experience when 1161 being redirected. 1163 For the first example assume an [IEEE8021X] environment, whereby a 1164 user connects to the enterprise LAN and initiates an 1165 authentication handshake. As part of the overall authentication 1166 process, it is also possible to pass endpoint state such as patch 1167 level, virus signature status, etc., all of which can be verified 1168 by a back-end server for policy compliancy and alter the 1169 authentication and authorization decision. In instances that an 1170 end-host is not in compliancy, the NAS may be instructed to limit 1171 network access in some fashion (i.e. quarantine) and limit network 1172 access to remediation services and a web-based information site. 1173 A user may sense degraded network performance and open a web 1174 session, which the NAS would redirect to the web-based information 1175 site for compliancy status, remediation actions, etc. 1177 For the second example assume an ISP environment, whereby a 1178 prepaid user is roaming the net in their hotel room over WiFi and 1179 is to be Hot-lined because their account has no more funds. The 1180 user's Service Provider instructs the NAS to block all traffic, 1181 and redirect any port 80 traffic to the Service Provider's Prepaid 1182 Portal. Upon detecting that there is no service, the user 1183 launches his browser and regardless of which web site is being 1184 accessed the browser traffic will arrive at the Prepaid Portal 1185 which will then return a page back to the subscriber indicating 1186 that he needs to replenish his account. 1188 Appendix B - NAS-Traffic-Rule Filter Examples 1190 This appendix presents a variety of filter examples utilizing the 1191 NAS-Traffic-Rule syntax. 1193 Example #1: Permit all user traffic, regardless of type. 1195 v1 permit inout any from any to any 1197 Example #2: Permit only L2 traffic coming from and going to a 1198 user's Ethernet MAC address. Block all other traffic. Assume 1199 user's MAC address is 00-10-A4-23-19-C0. 1201 v1 permit in l2:ether2 from 00-10-A4-23-19-C0 to any 1202 v1 permit out l2:ether2 from any to 00-10-A4-23-19-C0 1204 Example #3: Tunnel all L2 traffic coming from and going to a user. 1205 Assume tunnel name is: tunnel "1234". 1207 v1 permit tunnel "tunnel \"1234\"" inout l2:ether2 from any to 1208 any 1210 Example #4: Permit only L3 traffic coming and going to from a 1211 user's IP address. Block all other traffic. Assume user's IP 1212 address is 192.0.2.128. 1214 v1 permit in ip from 192.0.2.128 to any 1215 v1 permit out ip from any to 192.0.2.128 1217 Example #5: Permit only L3 traffic coming and going to the user's 1218 assigned IP address. Block all other traffic. 1220 v1 permit in ip from assigned to any 1221 v1 permit out ip from any to assigned 1223 Example #6: Allow user to generate ARP requests to anyone, DNS 1224 requests to any DNS server, and HTTP (port 80) requests to any 1225 HTTP server. Assume user's MAC address is 00-10-A4-23-19-C0 and IP 1226 address is 192.0.2.128. 1228 v1 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any 1229 v1 permit out l2:ether:0x0806 from any to 00-10-A4-23-19-C0 1230 v1 permit in 17 from 192.0.2.168 to any 53 1231 v1 permit out 17 from any 53 to 192.0.2.168 1232 v1 permit in 6 from 192.0.2.168 to any 80 1233 v1 permit out 6 from any 80 to 192.0.2.168 1235 Example #7: Allow user to generate ARP requests, DNS requests, and 1236 HTTP (port 80) requests, any of which are redirected to 1237 http://www.goo.org. Assume user's MAC address is 00-10-A4-23-19-C0 1238 and IP address is 192.0.2.128. 1240 v1 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any 1241 v1 permit out l2:ether:0x0806 from any to 00-10-A4-23-19-C0 1242 v1 permit in 17 from 192.0.2.168 to any 53 1243 v1 permit out 17 from any 53 to 192.0.2.168 1244 v1 redirect http://www.goo.org in from 192.0.2.168 to any 80 1246 Example #8: Allow user to generate ARP requests, DNS requests, and 1247 HTTP (port 80) requests, of which only requests to 1248 http://www.goo.org are redirected to http://www.goo.org. Assume 1249 user's MAC address is 00-10-A4-23-19-C0 and IP address is 1250 192.0.2.128 1252 v1 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any 1253 v1 permit out l2:ether:0x0806 from any to 00-10-A4-23-19-C0 1254 v1 permit in 17 from 192.0.2.168 to any 53 1255 v1 permit out 17 from any 53 to 192.0.2.168 1256 v1 redirect http://www.goo.org in from 192.0.2.168 to any 80 1257 http://www.goo.org 1259 Acknowledgments 1260 The authors would like to acknowledge Joseph Salowey of Cisco, 1261 David Nelson of Enterasys, Chuck Black of Hewlett Packard, and 1262 Ashwin Palekar of Microsoft. 1264 Authors' Addresses 1266 Paul Congdon 1267 Hewlett Packard Company 1268 HP ProCurve Networking 1269 8000 Foothills Blvd, M/S 5662 1270 Roseville, CA 95747 1272 EMail: paul.congdon@hp.com 1273 Phone: +1 916 785 5753 1274 Fax: +1 916 785 8478 1276 Mauricio Sanchez 1277 Hewlett Packard Company 1278 HP ProCurve Networking 1279 8000 Foothills Blvd, M/S 5559 1280 Roseville, CA 95747 1282 EMail: mauricio.sanchez@hp.com 1283 Phone: +1 916 785 1910 1284 Fax: +1 916 785 1815 1286 Avi Lior 1287 Bridgewater Systems Corporation 1288 303 Terry Fox Drive 1289 Suite 100 1290 Ottawa, Ontario K2K 3J1 1291 Canada 1293 Phone: (613) 591-6655 1294 EMail: avi@bridgewatersystems.com 1295 URI: TCP://.bridgewatersystems.com/ 1297 Farid Adrangi 1298 Intel Corporation 1299 2111 North East 25th 1300 Hillsboro, Oregon 97124 1301 United States 1303 Phone: (503) 712-1791 1304 EMail: farid.adrangi@intel.com 1306 Bernard Aboba 1307 Microsoft Corporation 1308 One Microsoft Way 1309 Redmond, WA 98052 1311 EMail: bernarda@microsoft.com 1312 Phone: +1 425 706 6605 1313 Fax: +1 425 936 7329 1315 Intellectual Property Statement 1317 The IETF takes no position regarding the validity or scope of any 1318 Intellectual Property Rights or other rights that might be claimed 1319 to pertain to the implementation or use of the technology 1320 described in this document or the extent to which any license 1321 under such rights might or might not be available; nor does it 1322 represent that it has made any independent effort to identify any 1323 such rights. Information on the procedures with respect to rights 1324 in RFC documents can be found in BCP 78 and BCP 79. 1326 Copies of IPR disclosures made to the IETF Secretariat and any 1327 assurances of licenses to be made available, or the result of an 1328 attempt made to obtain a general license or permission for the use 1329 of such proprietary rights by implementers or users of this 1330 specification can be obtained from the IETF on-line IPR repository 1331 at http://www.ietf.org/ipr. 1333 The IETF invites any interested party to bring to its attention 1334 any copyrights, patents or patent applications, or other 1335 proprietary rights that may cover technology that may be required 1336 to implement this standard. Please address the information to the 1337 IETF at ietf-ipr@ietf.org. 1339 Disclaimer of Validity 1341 This document and the information contained herein are provided on 1342 an 1343 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1344 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1345 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1346 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1347 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1348 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1349 FOR A PARTICULAR PURPOSE. 1351 Copyright Statement 1353 Copyright (C) The IETF Trust (2007). 1355 This document is subject to the rights, licenses and restrictions 1356 contained in BCP 78, and except as set forth therein, the authors 1357 retain all their rights. 1359 Open issues 1361 Open issues relating to this specification are tracked on the 1362 following web site: 1364 http://www.drizzle.com/~aboba/RADEXT/