idnits 2.17.1 draft-ietf-radext-filter-rules-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1281. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 717, 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: 6 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group Paul Congdon 2 INTERNET-DRAFT Mauricio Sanchez 3 Hewlett-Packard Company 4 A. Lior 5 22 June 2006 Bridgewater Systems 6 F. Adrangi 7 Intel 8 Bernard Aboba 9 Microsoft 11 RADIUS Attributes for Filtering and Redirection 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December, 22 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society 2006. All rights reserved. 41 Abstract 43 In certain scenarios it is desirable to limit user access using 44 filters or redirection. This document proposes additional 45 attributes for this purpose, for use with the Remote 46 Authentication Dial In User Server (RADIUS). The attributes 47 described in this document are expected to be useful in a variety 48 of environments, including enterprise and service provider 49 scenarios. 51 Table of Contents 53 1. Introduction........................................... 3 54 1.1. Terminology...................................... 4 55 1.2. Requirements Language............................ 4 56 1.3. Capability Advertisement ........................ 5 57 1.4. Attribute Interpretation......................... 5 58 2. RADIUS Authentication.................................. 6 59 2.5. NAS-Traffic-Rule.................................. 6 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............................... 18 69 Appendix A - Traffic Redirection............................ 19 70 Appendix B - NAS-Traffic-Rule Examples...................... 25 71 ACKNOWLEDGMENTS............................................... 26 72 AUTHORS' ADDRESSES............................................ 26 73 Intellectual Property Statement............................... 27 74 Disclaimer of Validity........................................ 28 75 Full Copyright Statement ..................................... 28 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 [RFC2865] Filter-ID attribute already exists for 90 provisioning filtering rules, it is not without drawbacks. The 91 Filter-ID attribute requires the NAS to be pre-populated with the 92 desired filters. This may be difficult to deploy in roaming 93 scenarios where the home operator may not know what filters have 94 been pre-populated by the local operator. The filtering 95 attributes specified in this document enable explicit description 96 of layer 2 and layer 3 filters as well as redirection, and 97 therefore extend the filter language described in [RFC3588]. The 98 attributes defined in this document may be used with RADIUS 99 dynamic authorization [RFC3576]. 101 Besides IEEE 802.1X environments, there is a corollary need within 102 Internet Service Provider (ISP) environments for the attributes 103 described in this document to perform hot-lining. For example, an 104 ISP may need to restrict a user's access to the Internet and 105 redirect their traffic to an alternate location because of 106 expiration of a prepaid plan. Another example is where the ISP 107 desires to restrict access and redirect a user that exhibited 108 fraudulent behavior. 110 User traffic redirection is supported with or without tunneling. 111 Tunneling support is provided using the tunnel attributes defined 112 in [RFC2868]. 114 1.1. Terminology 116 In this document when we refer to blocking of IP traffic we mean 117 filtering of IP traffic. Additionally, this document uses the 118 following terms: 120 Authenticator 121 An authenticator is an entity that requires 122 authentication from the supplicant. The authenticator 123 may be connected to the supplicant at the other end of a 124 point-to-point LAN segment or 802.11 wireless link. 126 Authentication server 127 An authentication server is an entity that provides an 128 authentication service to an authenticator. This service 129 verifies from the credentials provided by the supplicant, 130 the claim of identity made by the supplicant. 132 Hot-lining 133 Blocking and redirection of users traffic is known as 134 hot-lining of accounts. In this document, hot-lining is 135 used as the motivation for these attributes and an 136 illustration of how they would be used. However, the 137 attributes may be used together or separately to provide 138 other features. 140 Redirection 141 Refers to an action taken by the NAS to redirect the 142 user's traffic to an alternate location. 144 Supplicant 145 A supplicant is an entity that is being authenticated by 146 an authenticator. The supplicant may be connected to the 147 authenticator at one end of a point-to-point LAN segment 148 or 802.11 wireless link. 150 Terminal 151 A terminal is an endpoint, such as an 802.1X supplicant, 152 attached to the NAS port. 154 1.2. Requirements Language 156 In this document, several words are used to signify the 157 requirements of the specification. The key words "MUST", "MUST 158 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 159 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 160 interpreted as described in [RFC2119]. 162 An implementation is not compliant if it fails to satisfy one or 163 more of the must or must not requirements for the protocols it 164 implements. An implementation that satisfies all the must, must 165 not, should and should not requirements for its protocols is said 166 to be "unconditionally compliant"; one that satisfies all the must 167 and must not requirements but not all the should or should not 168 requirements for its protocols is said to be "conditionally 169 compliant". 171 1.3. Capability Advertisement 173 RADIUS does not currently define a method by which a NAS can 174 advertise its capabilities and in many instances, it would be 175 desirable for the home network to know what capabilities are 176 supported by the NAS to ensure proper operational behavior. The 177 attributes defined in this document are intended to be used to 178 enforce policy by the NAS. If a NAS does not recognize these 179 attributes it will most likely ignore them and the desired policy 180 will not be enforced. A method for the NAS advertising the 181 capability to support these attributes would help the RADIUS 182 server understand if the intended policies can be enforced. As a 183 result, the attributes in this document, in particular NAS- 184 Traffic-Rule(TBD), can benefit from capability advertisement, if 185 available. 187 1.4 Attribute Interpretation 189 If a NAS conforming to this specification receives an Access- 190 Accept packet containing an attribute defined in this document 191 which it cannot apply, it MUST act as though it had received an 192 Access-Reject. 194 Similarly, [RFC3576] requires that a NAS receiving a CoA-Request 195 containing an unsupported attribute reply with a CoA-NAK. It is 196 recommended that an Error-Cause attribute with value set to 197 "Unsupported Attribute" (401) be included in the packet. As 198 noted in [RFC3576], authorization changes are atomic so that this 199 situation does not result in session termination and the pre- 200 existing configuration remains unchanged. As a result, no 201 accounting packets should be generated. 203 2. RADIUS Authentication 204 This specification introduces one new RADIUS authentication 205 attribute. 207 2.5. NAS-Traffic-Rule 209 Description 211 The NAS-Traffic-Rule attribute is derived from the Diameter 212 IPFilterRule and enables provisioning of base encapsulation 213 (Layer 2) rules, Internet Protocol (Layer 3-4) rules, and HTTP 214 (Layer 5+) rules on the NAS by the RADIUS server. Compared to 215 Diameter's IPFilterRule, NAS-Traffic-Rule is a superset in 216 functionality, but is largely based on the same syntax 217 foundations. 219 For each rule and depending on the rule type, the NAS can be 220 instructed to take a single action as follows: 222 Rule Type Allowable rule action 223 ------------------- --------------------- 224 Base Encapsulation filter, tunnel 225 Internet Protocol filter, tunnel 226 HTTP filter, redirect 228 When specifying a base encapsulation rule, NAS-Traffic-Rule 229 processes packets based on the following information that is 230 associated with it: 232 Direction (in and/or out) 233 Base encapsulation type 234 Source and destination MAC address (possibly masked) 236 For a base encapsulation rule, the filter action entails having 237 the NAS permit (i.e. forward) or deny (i.e. block) a user's 238 traffic. The tunnel action entails having the NAS forward user 239 traffic to or from a named tunnel that has been established per 240 [RFC2868]. 242 When specifying an Internet Protocol rule, NAS-Traffic-Rule 243 processes packets based on the following information that is 244 associated with it: 246 Direction (in and/or out) 247 Source and destination IP address (possibly masked) 248 Protocol 249 Source and destination port (lists or ranges) 250 TCP flags 251 IP fragment flag 252 IP options 253 ICMP types 255 For an Internet Protocol rule, the filter action entails having 256 the NAS permit (i.e. forward) or deny (i.e. block) a user's 257 traffic. The tunnel action entails having the NAS forward user 258 traffic to or from a named tunnel that has been established per 259 [RFC2868]. 261 When specifying an HTTP rule, NAS-Traffic-Rule processes 262 packets based on the following information that is associated 263 with it: 265 HTTP URL 266 Source and destination IP address (possibly masked) 268 For an HTTP rule, the filter action entails having the NAS 269 permit (i.e. forward) or deny (i.e. block) a user's [RFC2616] 270 request message. For a deny action, the NAS MAY respond to the 271 request message with a code 403 (Forbidden) response in 272 accordance with [RFC2616]. For a redirect action the NAS SHOULD 273 respond to the user's request with a code 302 (Found) response 274 in accordance with [RFC2616]. 276 For the HTTP redirection action, it is also possible to have 277 redirection automatically removed by including a redir-cnt 278 count parameter along with the rule. The rule will be removed 279 from the active rule set when the rule matches redir-cnt number 280 of times. Upon removal from the active rule set, traffic is no 281 longer evaluated against this rule. 283 It should be noted that an HTTP filter or redirect rule is only 284 useful with plain-text HTTP and not [RFC2818] HTTPS. 285 Redirection or filtering of HTTPS is outside the scope of this 286 document. 288 As per the requirements of RFC 2865, Section 2.3, if multiple 289 NAS-Traffic-Rule attributes are contained within an Access- 290 Accept or CoA-Request packet, they MUST be maintained in order. 291 The attributes MUST be consecutive attributes in the packet. 292 RADIUS proxies MUST NOT reorder NAS-Traffic-Rule attributes. 294 The RADIUS server can return multiple NAS-Traffic-Rule 295 attributes in an Access-Accept or CoA-Request packet. Where 296 more than one NAS-Traffic-Rule attribute is included, it is 297 assumed that the attributes are to be concatenated to form a 298 single filter list. Furthermore, if the list contains different 299 types of rules, they MUST appear in the following order: flush 300 rules, base encapsulation tunnel rules, base encapsulation 301 filter rules, IP tunnel rules, HTTP redirect rules, IP filter 302 rules, and HTTP filter rules. 304 Rules are evaluated in order, with the first matched rule 305 terminating the evaluation. Each packet is evaluated once. If 306 no rule matches, then packet is dropped (implicit deny all). 308 When an HTTP redirect rule matches, the NAS shall reply to the 309 HTTP request with an HTTP redirect in accordance with [RFC2616] 310 redirecting traffic to specific URL. 312 Filter-ID (11) and NAS-Traffic-Rule both define how filters are 313 to be applied in the NAS. These attributes are not intended to 314 be used concurrently and SHOULD NOT appear in the same RADIUS 315 message. Only one type of filtering attribute must be 316 processed. If a Filter-ID (11) is present, then the NAS- 317 Traffic-Rule MUST be ignored, if present. 319 The NAS-Traffic-Rule attribute is shown below. The fields are 320 transmitted from left to right: 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type (TBD) | Length | Text 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Text (cont.) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Type 332 TBD 334 Length 336 >= 3 338 Text 340 The text conforms to the following ABNF [RFC2234] formatted syntax 341 specification: 343 ; Start of ABNF description of NAS-Traffic-Rule 345 rule = (flush-rule / permit-all-rule 346 / l2-filter-rule / l2-tunnel-rule 347 / ip-filter-rule / ip-tunnel-rule 348 / http-filter-rule / http-redir-rule) 349 rule-delim 351 ; Flush Rule 352 flush-rule = "flush" 354 ; Permit all rule 355 permit-all-rule = "permit inout any from any to any" 357 ; Base encapsulation filter rule 358 l2-filter-rule = ("permit" / "deny") " " 359 ("in" / "out" / "inout") " " 360 l2-filter-body [" " log-rule] 361 l2-filter-body = (l2-proto " from " l2-address " to " 362 l2-address) / l2-rmon-str 363 l2-proto = "l2:ether2" [":0x" 1*4HEXDIG] 364 l2-rmon-str = "l2:" 1*DIGIT *("." 1*DIGIT) 365 l2-address = ["!"] (macaddr / (macaddr "/" macmask) 366 / "any") 367 macaddr = 2HEXDIG 5("-" 2HEXDIG) 368 macmask = DIGIT ; 0-9 369 / %x31-33 DIGIT ; 10-39 370 / "4" %x30-38 ; 40-48 372 ;Base encapsulation tunnel rule 373 l2-tunnel-rule = "tunnel " tunnel-id " " 374 ("in" / "out" / "inout") " " 375 l2-filter-body [" " log-rule] 377 ;IP Filter Rule 378 ip-filter-rule = ("permit" / "deny") " " 379 ("in" / "out" / "inout") " " 380 ("ip" / ip-proto) filter-body 381 [" " ip-option] [" " log-rule] 382 ip-proto = d8 383 ip-address = ["!"] (ipv4-address ["/" ipv4mask] / 384 ipv6-address ["/" ipv6mask] / 385 "any" / 386 "assigned") 387 ipv4-address = d8 "." d8 "." d8 "." d8 388 ipv4mask = DIGIT ; 0-9 389 / %x31-32 DIGIT ; 10-29 390 / "3" %x30-32 ; 30-32 391 ipv6-address = 1*4HEXDIG 7(":" 1*4HEXDIG) 392 ipv6mask = DIGIT ; 0-9 393 / %x31-39 DIGIT ; 10-99 394 / "1" %x30-31 DIGIT ; 100-119 395 / "1" %x32 %x30-38 ; 120-128 397 layer4-ports = layer4-port *("," layer4-port) 398 layer4-port = d16 / d16 "-" d16 399 ip-option = "frag" / 400 ["ipoptions " ["!"] ipopt *("," ["!"] ipopt)] 401 ["tcpoptions " ["!"] tcpopt 402 *("," ["!"] tcpopt)] 403 ["established"] 404 ["setup"] 405 ["tcpflags " ["!"] tcpflag 406 *("," ["!"] tcpflag)] 407 ["icmptypes " icmptype *("," icmptype)] 408 ipopt = "ssrr" / "lsrr" / "rr" / "ts" 409 tcpopt = "mss" / "window" / "sack" / "ts" / "cc" 410 tcpflag = "fin" / "syn" / "rst" / "psh" / "ack" / "urg" 412 icmptype = d8 / d8 "-" d8 413 / "echo reply" / "destination unreachable" 414 / "source quench" / "redirect" 415 / "echo request" / "router advertisement" 416 / "router solicit" / "time-to-live exceeded" 417 / "IP header bad" / "timestamp request" 418 / "timestamp reply" / "information request" 419 / "information reply" 420 / "address mask request" 421 / "address mask reply" 423 ;IP Tunnel Rule 424 ip-tunnel-rule = "tunnel " tunnel-id " " 425 ("in" / "out" / "inout") " " 426 ("ip" / ip-proto) filter-body 427 [" " ip-option] [" " log-rule] 429 ;HTTP Filter Rule 430 http-filter-rule= ("permit" / "deny") org-url " " 431 ("in" / "out" / "inout") filter-body 432 [" " log-rule] 434 ;HTTP Redirect Rule 435 http-redir-rule= "redirect " [redir-cnt " "] redir-url 436 filter-body [" " org-url] 437 [" " log-rule] 438 redir-cnt = 1*DIGIT 439 org-url = http_URL 440 ;Note: Syntax for http_URL defined in 441 ;[RFC2616], section 3.2.2 442 redir-url = http_URL 444 ;Common 445 filter-body = " from " ip-address [" " layer4-ports] 446 " to " ip-address [" " layer4-ports] 447 tunnel-id = DQUOTE 448 1*(TEXTDATA / ("%" 2HEXDIG)) 449 DQUOTE 450 log-rule = "cnt" 452 ;Primitives 453 LF = %x0A ; linefeed 454 DIGIT = %x30-39 ; 0-9 455 DQUOTE = %x22 ; " (Double Quote) 456 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 457 rule-delim = LF 458 d8 = DIGIT ; 0-9 459 / %x31-39 DIGIT ; 10-99 460 / "1" 2DIGIT ; 100-199 461 / "2" %x30-34 DIGIT ; 200-249 462 / "25" %x30-35 ; 250-255 463 d16 = DIGIT ; 0-9 464 / %x31-35 1*4DIGIT ; 10-59999 465 / "6" "4" 3DIGIT ; 60000-64999 466 / "6" "5" %x30-34 2DIGIT ; 65000-65499 467 / "6" "5" "5" %x30-32 1DIGIT ; 65500-65529 468 / "6" "5" "5" "3" %x30-36 ; 65530-65536 469 TEXTDATA = %x20-21 / %x23-24 / %x26-7E 471 ; End of ABNF description of NAS-Traffic-Rule 473 Descriptions of notable fields and keywords follow: 475 'permit' Allow packets that match the rule. 477 'deny' Drop packets that match the rule. 479 'redirect' Redirect packets that match the rule. 481 'tunnel' Tunnel packets that match the rule. 483 'flush' A flush rule removes all previously assigned 484 filter rules. When flush is specified, it can be 485 followed by other NAS-Traffic-Rule attributes. This 486 allows for an atomic change of authorization with a 487 single RADIUS message. 489 'permit inout any from any to any' 490 Special rule that matches against all traffic. This 491 allows the implicit deny at the end of a filter 492 list to be overridden. 494 'in' Is from the terminal. 496 "out" Is to the terminal. 498 'inout' Is from and to the terminal. 500 ipv4-address An IPv4 number in dotted-quad form. Only this 501 exact IP number will match the rule. 502 ipv6-address An IPv6 number in canonical IPv6 form. Only 503 this exact IP number will match the rule. 504 ipv4-address/ipv4mask 505 An IP number with a mask width of the form 506 192.0.2.0/24. In this case, all IP numbers from 507 192.0.2.0 to 192.0.2.255 will match. 509 The bit width MUST be valid for the IP version and 510 the IP number MUST NOT have bits set beyond the 511 mask. For a match to occur, the same IP version 512 MUST be present in the packet that was used in 513 describing the IP address. To test for a 514 particular IP version, the bits part can be set to 515 zero. 517 'any' Keyword for 0.0.0.0/0 or the IPv6 equivalent. 519 'assigned' Keyword for the address or set of addresses 520 assigned to the terminal. For IPv4, a typical 521 first rule is often "deny in ip !assigned" 523 The sense of the match can be inverted by preceding 524 an address with the not modifier (!), causing all 525 other addresses to be matched instead. This does 526 not affect the selection of port numbers. 528 layer4-port With the TCP, UDP and SCTP protocols, this field 529 specifies ports to match. 531 Note: The '-' notation specifies a range of ports 532 (including boundaries). Fragmented packets that 533 have a non-zero offset (i.e., not the first 534 fragment) will never match a rule that has one or 535 more port specifications. See the 'frag' keyword 536 for details on matching fragmented packets. 538 log-rule Increments rule hit counter by one every time a 539 packet matches on rule. Counters start with a zero 540 value at session start and are reset back to a zero 541 value every time a successful authorization change 542 occurs due to a CoA message being received by the 543 NAS. 545 For base encapsulation rules: 546 'l2:' Prefix to designate a rule as a base encapsulation 547 rule. 549 'l2:ether2' Keyword means any Ethernet-II (DIX Ethernet) will 550 match. 552 ether2:val Used to specify an Ethernet-II type by hexadecimal 553 number, whereby 'val' is replaced by desired 554 number. Example: 'l2:ether2:0x800' for IP ethertype 555 (0x0800). 557 l2-rmon-str Used to specify base encapsulation per the octet 558 string format defined in [RFC2895], section 4.2. 559 Example: 'l2:0.0.0.2.0.0.0.240' for Netbios over 560 LLC. 562 macaddr For base encapsulation filter rules of 'l2:ether2' 563 type, the Ethernet MAC address with octet values 564 separated by a '-'. Example: '00-10-A4-23-19-C0'. 566 macaddr/mask An Ethernet number as above with a mask width of 567 the form '00-10-A4-23-00-00/32'. In this case, all 568 MAC addresses from 00-10-A4-23-00-00 to 00-10-A4- 569 23-FF-FF will match. The MAC address MUST NOT have 570 bits set beyond the mask. The keyword 'any' is 571 00-00-00-00-00-00/0. 573 The sense of the match can be inverted by preceding 574 an address with the not modifier (!), causing all 575 other addresses to be matched instead. 577 Note: macaddr nor macaddr/mask argument is not used 578 for 'l2:rmon' type rules. 580 For IP rules: 581 "ip" Keyword means any IP protocol will match. 583 ip-proto An IP protocol specified by number. 585 'frag' Match if the packet is a fragment and this is not 586 the first fragment of the datagram. frag may not 587 be used in conjunction with either tcpflags or 588 TCP/UDP port specifications. 590 'ipoptions' Match if the IP header contains the comma separated 591 list of options specified in spec. The supported 592 IP options are: ssrr (strict source route), lsrr 593 (loose source route), rr (record packet route) and 594 ts(timestamp). The absence of a particular option 595 may be denoted with a '!'. 597 'tcpoptions' Match if the TCP header contains the comma 598 separated list of options specified in spec. The 599 supported TCP options are: 601 mss (maximum segment size), window (tcp window 602 advertisement), sack (selective ack), ts (rfc1323 603 timestamp) and cc (rfc1644 t/tcp connection count). 604 The absence of a particular option may be denoted 605 with a '!'. 607 'established' TCP packets only. Match packets that have the 608 RST or ACK bits set. 610 'setup' TCP packets only. Match packets that have the SYN 611 bit set but no ACK bit. 613 'tcpflags' TCP packets only. Match if the TCP header contains 614 the comma separated list of flags specified in 615 spec. The supported TCP flags are: 617 fin, syn, rst, psh, ack and urg. The absence of a 618 particular flag may be denoted with a '!'. A rule 619 that contains a tcpflags specification can never 620 match a fragmented packet that has a non-zero 621 offset. See the 'frag' option for details on 622 matching fragmented packets. 624 'icmptypes' ICMP packets only. Match if the ICMP type is in 625 the list types. The list may be specified as any 626 combination of ranges or individual types separated 627 by commas. Both the numeric values and the 628 symbolic values listed below can be used. The 629 supported ICMP types are: 631 echo reply (0), destination unreachable (3), source 632 quench (4), redirect (5), echo request(8), router 633 advertisement (9), router solicitation (10), time- 634 to-live exceeded (11), IP header bad (12), 635 timestamp request (13), timestamp reply (14), 636 information request (15), information reply (16), 637 address mask request (17) and address mask reply 638 (18). 640 For HTTP redirection rules: 641 redir-cnt Specifies the number of HTTP redirect rule matches 642 that should transpire before removing this rule 643 from the active rule set. Upon removal from the 644 active rule set, traffic is no longer evaluated 645 against this rule. 647 redir-url An HTTP URL. When the 'redirect' rule matches 648 (src/dst and/or org_URL ), HTTP requests are 649 redirected to redir_URL address in accordance with 650 [RFC2616] redirection traffic to specific URL. 652 org-url An HTTP URL. Specifies the HTTP URL against which 653 user HTTP requests will be evaluated. If user HTTP 654 request matches org_URL, then redirection action is 655 taken. 657 For base encapsulation and IP tunnel rules: 658 tunnel_id A tunnel id. When the 'tunnel' rule matches, 659 traffic is redirected over the tunnel with the 660 specified tunnel_id. Traffic can only be redirected 661 to or from named tunnels that have been established 662 per [RFC2868] and named using the Tunnel- 663 Assignment-ID attribute described therein. 665 The tunnel id MUST be encapsulated in double quotes 666 and follow the labeling convention defined by the 667 TEXTDATA. 668 Example: A tunnel with the name of tunnel "ppp%1" 669 would be specified as "%22ppp%251%22" 671 A NAS that is unable to interpret or apply a deny rule MUST 672 terminate the session. A NAS MAY apply deny rules of its own 673 before the supplied rules, for example to protect the access 674 device owner's infrastructure. 676 3. RADIUS Accounting 678 This specification introduces one new RADIUS accounting attribute. 680 3.1. Acct-NAS-Traffic-Rule 682 Description 684 Acct-NAS-Traffic-Rule enables a RADIUS client to include NAS- 685 Traffic-Rule[TBD] rule match counters as part of the accounting 686 message. 688 The Acct-NAS-Traffic-Rule attribute is shown below. The fields 689 are transmitted from left to right: 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Type | Length | Counter (64-bits) 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Counter (cont.) 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Counter (cont.) | Text (NAS-Traffic-Rule) | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Type 702 TBD 704 Length 705 >=11 707 Counter 709 The Counter field is eight octets in length and contains the 710 64-bit hit count for the rule specified in the Text field. 712 Text 714 The Text field is greater than one octet in length and is used 715 to specify the rule for which a hit count is associated with. 716 The Text field MUST conform to the syntax rules specified for 717 the Text field of the NAS-Traffic-Rule[TBD] attribute. 719 4. Table of Attributes 721 The following table provides a guide to which attributes may be 722 found in which kinds of packets, and in what quantity. 724 Access- Access- Access- Access- CoA- 725 Request Accept Reject Challenge Req # Attribute 726 0 0+ 0 0 0+ TBD NAS-Traffic-Rule 728 Actng- Actng- 729 Request Response # Attribute 730 0-1 0 TBD Acct-NAS-Traffic-Rule 732 The following table defines the meaning of the above table 733 entries. 735 0 This attribute MUST NOT be present in packet. 736 0+ Zero or more instances of this attribute MAY be present in 737 the packet. 738 0-1 Zero or one instance of this attribute MAY be 739 present in the packet. 741 5. Diameter Considerations 743 Diameter needs to define identical attributes with the same Type 744 values. The attributes should be available as part of the NASREQ 745 application [RFC4005], as well as the Diameter EAP application 746 [RFC4072]. 748 6. IANA Considerations 750 This document uses the RADIUS [RFC2865] namespace, see 751 . Allocation of two 752 updates for the section 'RADIUS Attribute Types' is requested. The 753 RADIUS attributes for which values are requested are: 755 TBD - NAS-Traffic-Rule 756 TBD - Acct-NAS-Traffic-Rule 758 7. Security Considerations 760 Since this document describes the use of RADIUS for purposes of 761 authentication, authorization, and accounting in [IEEE8021X] 762 enabled networks, it is vulnerable to all of the threats that are 763 present in other RADIUS applications. For a discussion of these 764 threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580]. 766 This document specifies new attributes that can be included in 767 existing RADIUS messages. These messages are protected using 768 existing security mechanisms; see [RFC2865] and [RFC3576] for a 769 more detailed description and related security considerations. 771 The security mechanisms in [RFC2865] and [RFC3576] are primarily 772 concerned with an outside attacker who modifies messages in 773 transit, inserts new messages, or deletes messages. They do not 774 prevent an authorized RADIUS server or proxy from inserting or 775 deleting attributes with a malicious purpose in messages it sends. 777 An attacker who compromises an authorized RADIUS server or proxy 778 can use the attributes defined in this document to influence the 779 behavior of the NAS in ways that previously may not have been 780 possible. For example, inserting suitable redirection rules to the 781 NAS-Traffic-Rule attribute may allow the attacker to eavesdrop or 782 modify packets sent by a legitimate client. 784 In general, the NAS cannot know whether the attribute values it 785 receives from an authenticated and authorized server are well- 786 intentioned or malicious, and thus it is not possible to 787 completely protect against attacks by compromised nodes. In some 788 cases, the extent of the possible attacks can be limited by 789 performing more fine-grained authorization checks at the NAS. 790 For instance, a NAS could be configured not to accept any 791 redirection rules if it is known they are not used in this 792 environment. 794 8. References 796 8.1. Normative references 798 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 799 Requirement Levels", RFC 2119, March, 1997. 801 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 802 L., Leach P., Berners-Lee T., 'Hypertext Transfer Protocol 803 -- HTTP/1.1', RFC 2616, June 1999. 805 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 806 Authentication Dial In User Service (RADIUS)", RFC 2865, 807 June 2000. 809 [RFC2895] Bierman, A., Bucci, C., Iddon, R., 'Remote Network 810 Monitoring MIB Protocol Identifier Reference', RFC 811 2895, August 2000 813 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko, 814 J., "Diameter Base Protocol", RFC 3588, September 2003. 816 [RFC4005] Calhoun, P., Zorn, G., Spence, D., Mitton, D., 'Diameter 817 Network Access Server Application', RFC 4005, August 2005. 819 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 820 Overview and Architecture, ANSI/IEEE Std 802, 1990. 822 [IEEE8021X] 823 IEEE Standards for Local and Metropolitan Area Networks: 824 Port based Network Access Control, IEEE Std 802.1X-2004, 825 August 2004. 827 8.2. Informative references 829 [RFC2234] Croker, E., Overell, P., 'Augmented BNF for Syntax 830 Specifications: ABNF', RFC 2234, November 1997. 832 [RFC2607] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy 833 Implementation in Roaming", RFC 2607, June 1999. 835 [RFC2818] Rescorla, E., 'HTTP Over TLS', RFC2818, May 2000. 837 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 838 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 839 Support", RFC 2868, June 2000. 841 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 842 3162, August 2001. 844 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 845 Aboba,"Dynamic Authorization Extensions to Remote 846 Authentication Dial In User Service (RADIUS)", RFC 3576, 847 July 2003. 849 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 850 Authentication Protocol (EAP)", RFC 3579, September 2003. 852 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., 853 'IEEE 802.1X Remote Authentication Dial In User Service 854 (RADIUS) Usage Guidelines', RFC3580, September 2003. 856 [RFC4072] Eronen, P., Hiller, T., Zorn G., 'Diameter Extensible 857 Authentication Protocol (EAP) Application', RFC4072, August 858 2005. 860 [IEEE8023] 861 ISO/IEC 8802-3 Information technology - Telecommunications 862 And information exchange between systems - Local and 863 metropolitan area networks - Common specifications - Part 864 3: Carrier Sense Multiple Access with Collision Detection 865 (CSMA/CD) Access Method and Physical Layer Specifications, 866 (also ANSI/IEEE Std 802.3- 1996), 1996. 868 [IEEE80211] 869 Information technology - Telecommunications and information 870 exchange between systems - Local and metropolitan area 871 networks - Specific Requirements Part 11: Wireless LAN 872 Medium Access Control (MAC) and Physical Layer (PHY) 873 Specifications, IEEE Std. 802.11-1999, 1999. 875 [IEEE80211i] 876 Institute of Electrical and Electronics Engineers, 877 "Supplement to Standard for Telecommunications and 878 Information Exchange Between Systems - LAN/MAN Specific 879 Requirements - Part 11:Wireless LAN Medium Access Control 880 (MAC) and Physical Layer 881 (PHY) Specifications: Specification for Enhanced Security", 882 June 2004. 884 Appendix A - Traffic Redirection 886 There are several ways to redirect the user's traffic. Which 887 method will be used depends on the capabilities available at the 888 NAS and Service Provider's preference. This Appendix describes 889 various methods to redirect user traffic by using the new 890 attributes outlined in this document in conjunction with existing 891 attributes, which are: 893 1) Tunneling; and 894 2) HTTP Redirection; 896 For each method we describe how redirection is done at service 897 initiation and mid-session. We also describe how redirection is 898 removed when it is no longer desired. 900 A.1 Tunneling 902 User traffic can be redirected by tunneling the user's traffic to 903 an alternate location. Tunneling will typically redirect all of 904 the user's traffic for the Service. When tunneling is used to 905 redirect all the traffic, then filtering may not be necessary. 907 A.1.1 Service Initiation 909 Redirect using tunnels at service initiation requires that the 910 RADIUS server send the appropriate [RFC2868] tunnel attributes and 911 NAS-Traffic-Rule attributes to the NAS. The [RFC2868] tunnel 912 attributes describe the tunnel endpoint and the type of tunnel to 913 construct. The 'tunnel ' option for the NAS-Traffic- 914 Rule allows the specification of a traffic rule for which to 915 redirect traffic to a named tunnel. 917 A.1.2 Mid-session Tunnel Redirection 919 Redirection of traffic using tunnels mid-session involves sending 920 the tunnel attributes as per [RFC2868] to the NAS using Change-of- 921 Authorization (CoA) message. The operation is described in 922 [RFC3576]. Careful attention should be paid to the security 923 issues in [RFC3576]. 925 Note that if the session is already tunneled (eg. Mobile-IP) then 926 the CoA message with a new tunnel specification can be sent to the 927 NAS or alternatively the redirection can occur at the tunnel 928 endpoint (the Home Agent) using any one of these methods. 930 A.1.3 Tunnel Redirection Removal 932 If the normal mode for the session was to tunnel the session and 933 redirection was sent to the NAS, the RADIUS Server can send the 934 original tunnel attributes to the NAS in a CoA message. The NAS 935 will tear down the tunnel and establish a connection back to the 936 original tunnel endpoint. 938 However, if the normal mode for the session is not to use 939 tunneling then there is a problem because RADIUS does not have a 940 mechanism whereby it can de-tunnel. Receiving a CoA message 941 without tunnel attributes would not have an effect on an existing 942 tunnel. In order to de-tunnel the session, the RADIUS server has 943 to send the NAS a CoA message with Service-Type(6) set to 944 "Authorize-Only" causing the NAS to perform a re-Authorization. 945 In response to the re-Authorization, the RADIUS server will send 946 an Access-Accept packet without the tunneling information. Upon 947 receiving the corresponding Access-Accept packet the NAS MUST 948 apply the new authorization attributes. If these do not contain 949 tunnel attributes, then the NAS MUST tear down the tunnel. 951 A.1.4 Tunnel Redirection Examples 953 The following examples illustrate how traffic flows when subjected 954 to a NAS-Traffic-Rule using tunnel redirection. In these 955 scenarios, the following notation is used to represent traffic 956 flows: 958 ------> Flow in one direction 959 <-----> Flow in two directions 960 ======> Flow in a tunnel in one direction 961 <=====> Flow in a tunnel in two directions 963 A RADIUS server that wishes all IP traffic to flow between the 964 client and a selected redirection destination will issue an 965 Access-Accept that contains the specification for the tunnel using 966 the attributes defined by RFC 2868 and a NAS-Traffic-Rule 967 attribute using the tunnel action and arguments. 969 An example NAS-Traffic-Rule will look like: 971 tunnel "t1" in ip from assigned to any 973 This will cause all traffic that flows from the client to any 974 destination to be tunneled over the named tunnel 't1' to the 975 tunnel endpoint (TEP). 977 +-------+ +------+ +------+ +------+ 978 | | | | |Tunnel| | | 979 |client +<---------->+ NAS +<==t1===>+ End +<----->+ Dest | 980 | | | | |Point | | | 981 +-------+ +------+ +------+ +------+ 983 The direction argument takes the values of 'in', 'out' or 'inout' 984 and is important because it controls how information is routed. 985 The following diagram demonstrates how traffic is routed. In all 986 these diagrams time is increasing as we proceed down the page. 988 When rule direction is 'in': 990 client NAS TEP DESTINATION 991 | | | | 992 |---------->|===t1===>|--------->| 993 | | | | 994 |<----------|<-------------------| (flows directly to NAS) 995 | | | | 997 The inbound traffic from the client matches the specified filter 998 rule and the IP packet is placed in the tunnel to the TEP. The TEP 999 forwards the packet to the Destination using the destination IP 1000 address in the packet header. Note that the source address of the 1001 packet is the address assigned at the NAS. Therefore if the 1002 destination were to reply to the packet it would use the NAS 1003 source address and the packet would flow directly to the NAS and 1004 to the client bypassing the TEP. The Home network would use this 1005 capability if it was only interested in metering or seeing the 1006 inbound traffic from the client. 1008 However, if the home network wanted to see the traffic in both 1009 directions it could deploy a NAT function at the TEP. 1011 Here is the flow when the TEP is acting like a NAT: 1013 client NAS TEP/NAT DESTINATION 1014 | | | | 1015 |---------->|===t1===>|--------->| 1016 | | | | 1017 |<----------|<==t1====|<---------| 1019 The client establishes a connection to the Destination, but the 1020 TEP acting as NAT, changes the source address of the IP packet (as 1021 NATs do) to that of the TEP/NAT. Now any replies from the 1022 Destination are sent to the TEP/NAT. The TEP/NAT then forwards 1023 these packets to the client through the NAS. 1025 When the TEP is acting as a NAT, using the direction argument 'in' 1026 is important. The direction argument set to 'out' will have no 1027 effect on traffic coming from the tunnel since all traffic to the 1028 client should come from the TEP/NAT inside the tunnel. The 1029 direction argument set to 'inout' will have the same effect as if 1030 it were set to 'in'. 1032 The TEP/NAT forwards all traffic for the client into the tunnel to 1033 the NAS. The NAS always forwards any egressing traffic from the 1034 tunnel to the client. It does not apply any redirection rules on 1035 traffic egressing a tunnel. The NAS does not care whether the TEP 1036 is transparent or is acting as a NAT. 1038 A.2 HTTP Redirection 1040 Another method of redirection is at the application layer, 1041 specifically the HTTP layer. An HTTP aware NAS redirects traffic 1042 by issuing an HTTP Redirect response causing the user's browser to 1043 navigate to an alternate Web Portal. 1045 The call flow associated with performing redirection at the HTTP 1046 layer is very similar with the call flow associated with 1047 redirection done at the IP layer. 1049 The same NAS-Traffic-Rule(TBD) attribute described above is used 1050 to convey the redirection rules to use for HTTP redirection. HTTP 1051 redirection rules within the NAS-Traffic-Rule attribute supports 1052 the encoding of a redirection URL to apply when a rule is matched. 1054 A.2.1 Service Initiation 1056 As with previous call flows, the RADIUS server MAY send multiple 1057 HTTP redirect or filtering rules within a NAS-Traffic-Rule(TBD) 1058 attribute to the NAS in the Access-Accept message. 1060 A.2.2 Mid-session HTTP Redirection 1062 If HTTP redirection is required to be applied to a service that 1063 has already been started then the RADIUS server can push the 1064 redirection rules, and optionally the filter rules, to the NAS 1065 within a NAS-Traffic-Rule(TBD) attribute using a CoA-Request 1066 message. The NAS will then commence to apply the redirection rules 1067 and/or the filter rules. 1069 Alternatively, the RADIUS server can request that the NAS re- 1070 authorize the session using the procedures defined in [RFC3576]. 1071 The RADIUS server responds with an Access-Accept message (with 1072 Service-Type(6) set to 'Authorize Only' that will contain the 1073 redirection and optionally filtering rules within a NAS-Traffic- 1074 Rule(TBD) attribute. 1076 A.2.3 HTTP Redirection Removal 1078 HTTP Redirection rules can be automatically removed mid-session 1079 from the NAS using the redir-cnt parameter or explicitly removed 1080 from the RADIUS server. The RADIUS server can explicitly turn HTTP 1081 redirection off mid-session in two ways. It can push new 1082 redirection rules within a NAS-Traffic-Rule(TBD) attribute using a 1083 CoA-Request message or it can send the NAS a CoA-Request message 1084 requesting it to re-authorize. 1086 When using CoA-Request message to return the redirection and 1087 filtering back to 'normal,' there needs to be either a filter rule 1088 (or filter-id) or redirection rule that corresponds to the 1089 'normal' state. If normally the session did not have any filter 1090 and or redirection rules applied, the RADIUS server can send a 1091 NAS-Traffic-Rule(TBD) with the action of 'flush' in the CoA- 1092 Request message. This action will cause all the filter rules and 1093 redirection rules previously assigned to the session to be 1094 removed. 1096 A.3 Accounting 1098 Every time a session is redirected and every time the redirection 1099 is reverted back a new session is created and the old one is 1100 terminated. Therefore the NAS MUST generate and Accounting- 1101 Request(Stop) for the old session and an Accounting-Request(Start) 1102 for the new session. 1104 A.4 Example Scenarios 1106 The following two examples illustrate the user's experience when 1107 being redirected. 1109 For the first example assume an [IEEE8021X] environment, whereby a 1110 user connects to the enterprise LAN and initiates an 1111 authentication handshake. As part of the overall authentication 1112 process, it is also possible to pass endpoint state such as patch 1113 level, virus signature status, etc., all of which can be verified 1114 by a back-end server for policy compliancy and alter the 1115 authentication and authorization decision. In instances that an 1116 end-host is not in compliancy, the NAS may be instructed to limit 1117 network access in some fashion (i.e. quarantine) and limit network 1118 access to remediation services and a web-based information site. 1119 A user may sense degraded network performance and open a web 1120 session, which the NAS would redirect to the web-based information 1121 site for compliancy status, remediation actions, etc. 1123 For the second example assume an ISP environment, whereby a 1124 prepaid user is roaming the net in their hotel room over WiFi and 1125 is to be Hot-lined because their account has no more funds. The 1126 user's Service Provider instructs the NAS to block all traffic, 1127 and redirect any port 80 traffic to the Service Provider's Prepaid 1128 Portal. Upon detecting that there is no service, the user 1129 launches his browser and regardless of which web site is being 1130 accessed the browser traffic will arrive at the Prepaid Portal 1131 which will then return a page back to the subscriber indicating 1132 that he needs to replenish his account. 1134 Appendix B - NAS-Traffic-Rule Filter Examples 1136 This appendix presents a variety of filter examples utilizing the 1137 syntax definition described in section 3.5 1139 Example #1: Permit all user traffic, regardless of type. 1141 permit inout any from any to any 1143 Example #2: Permit only L2 traffic coming from and going to a 1144 user's Ethernet MAC address. Block all other traffic. Assume 1145 user's MAC address is 00-10-A4-23-19-C0. 1147 permit in l2:ether2 from 00-10-A4-23-19-C0 to any 1148 permit out l2:ether2 from any to 00-10-A4-23-19-C0 1150 Example #3: Tunnel all L2 traffic coming from and going to a user. 1151 Assume tunnel name is: tunnel '1234'. 1153 permit tunnel 'tunnel \'1234\'' inout l2:ether2 from any to any 1155 Example #4: Permit only L3 traffic coming and going to from a 1156 user's IP address. Block all other traffic. Assume user's IP 1157 address is 192.0.2.128. 1159 permit in ip from 192.0.2.128 to any 1160 permit out ip from any to 192.0.2.128 1162 Example #5: Permit only L3 traffic coming and going to the user's 1163 assigned IP address. Block all other traffic. 1165 permit in ip from assigned to any 1166 permit out ip from any to assigned 1168 Example #6: Allow user to generate ARP requests, DNS requests, and 1169 HTTP (port 80) requests. Assume user's MAC address is 00-10-A4-23- 1170 19-C0 and IP address is 192.0.2.128. 1172 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any 1173 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 1174 permit in 17 from 192.0.2.168 to any 53 1175 permit out 17 from any 53 to 192.0.2.168 1176 permit in 6 from 192.0.2.168 80 to any 1177 permit out 6 from any 80 to 192.0.2.168 1179 Example #7: Allow user to generate ARP requests, DNS requests, and 1180 HTTP (port 80) requests, any of which are redirected to 1181 http://www.goo.org. Assume user's MAC address is 00-10-A4-23-19-C0 1182 and IP address is 192.0.2.128. 1184 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any 1185 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 1186 permit in 17 from 192.0.2.168 to any 53 1187 permit out 17 from any 53 to 192.0.2.168 1188 redirect http://www.goo.org in from 192.0.2.168 to any 80 1190 Example #8: Allow user to generate ARP requests, DNS requests, and 1191 HTTP (port 80) requests, of which only requests to 1192 http://www.goo.org are redirected to http://www.goo.org. Assume 1193 user's MAC address is 00-10-A4-23-19-C0 and IP address is 1194 192.0.2.128 1196 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any 1197 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 1198 permit in 17 from 192.0.2.168 to any 53 1199 permit out 17 from any 53 to 192.0.2.168 1200 redirect http://www.goo.org in from 192.0.2.168 to any 80 1201 http://www.goo.org 1203 Acknowledgments 1204 The authors would like to acknowledge Joseph Salowey of Cisco, 1205 David Nelson of Enterasys, Chuck Black of Hewlett Packard, and 1206 Ashwin Palekar of Microsoft. 1208 Authors' Addresses 1210 Paul Congdon 1211 Hewlett Packard Company 1212 HP ProCurve Networking 1213 8000 Foothills Blvd, M/S 5662 1214 Roseville, CA 95747 1216 EMail: paul.congdon@hp.com 1217 Phone: +1 916 785 5753 1218 Fax: +1 916 785 8478 1220 Mauricio Sanchez 1221 Hewlett Packard Company 1222 HP ProCurve Networking 1223 8000 Foothills Blvd, M/S 5559 1224 Roseville, CA 95747 1226 EMail: mauricio.sanchez@hp.com 1227 Phone: +1 916 785 1910 1228 Fax: +1 916 785 1815 1230 Avi Lior 1231 Bridgewater Systems Corporation 1232 303 Terry Fox Drive 1233 Suite 100 1234 Ottawa, Ontario K2K 3J1 1235 Canada 1237 Phone: (613) 591-6655 1238 EMail: avi@bridgewatersystems.com 1239 URI: TCP://.bridgewatersystems.com/ 1241 Farid Adrangi 1242 Intel Corporation 1243 2111 North East 25th 1244 Hillsboro, Oregon 97124 1245 United States 1247 Phone: (503) 712-1791 1248 EMail: farid.adrangi@intel.com 1250 Bernard Aboba 1251 Microsoft Corporation 1252 One Microsoft Way 1253 Redmond, WA 98052 1255 EMail: bernarda@microsoft.com 1256 Phone: +1 425 706 6605 1257 Fax: +1 425 936 7329 1259 Intellectual Property Statement 1260 The IETF takes no position regarding the validity or scope of 1261 any Intellectual Property Rights or other rights that might be 1262 claimed to pertain to the implementation or use of the 1263 technology described in this document or the extent to which 1264 any license under such rights might or might not be available; 1265 nor does it represent that it has made any independent effort 1266 to identify any such rights. Information on the procedures 1267 with respect to rights in RFC documents can be found in BCP 78 1268 and BCP 79. 1270 Copies of IPR disclosures made to the IETF Secretariat and any 1271 assurances of licenses to be made available, or the result of 1272 an attempt made to obtain a general license or permission for 1273 the use of such proprietary rights by implementers or users of 1274 this specification can be obtained from the IETF on-line IPR 1275 repository at http://www.ietf.org/ipr. 1277 The IETF invites any interested party to bring to its attention 1278 any copyrights, patents or patent applications, or other 1279 proprietary rights that may cover technology that may be 1280 required to implement this standard. Please address the 1281 information to the IETF at ietf-ipr@ietf.org. 1283 Disclaimer of Validity 1285 This document and the information contained herein are provided 1286 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 1287 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 1288 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1289 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1290 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1291 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1292 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1294 Copyright Statement 1296 Copyright (C) The Internet Society (2006). This document is 1297 subject to the rights, licenses and restrictions contained in 1298 BCP 78, and except as set forth therein, the authors retain all 1299 their rights.