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