idnits 2.17.1 draft-ietf-radext-filter-rules-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1283. ** 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 713, but not defined == Unused Reference: 'IEEE80211' is defined on line 869, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** 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 (~~), 4 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 24 February 2006 Bridgewater Systems 6 F. Adrangi 7 Intel 8 Bernard Aboba 9 Microsoft 11 Filter Attributes 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August, 24 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 or redirection. 83 For example, in IEEE 802.1X [IEEE8021X] environments, which 84 provides "network port authentication" for IEEE 802 [IEEE802] 85 media, including Ethernet [IEEE8023] and 802.11 [IEEE80211i] 86 wireless LANS, there exists a strong desire to control 87 authorization beyond just the untagged VLAN parameter based on 88 tunnel attributes in [RFC2868] and usage of these in [RFC3580]. 90 This document describes filtering and redirection attributes that 91 may prove useful in IEEE 802.1X and a variety of situations. The 92 attributes defined in this document may be used with RADIUS 93 dynamic authorization [RFC3576]. 95 The Filter-ID attribute defined in [RFC2865] requires the NAS to 96 be pre-populated with the desired filters. This may be difficult 97 to deploy in roaming scenarios where the home realm may not know 98 what filters have been pre-populated by the local operator. The 99 filtering attributes specified in this document enable explicit 100 description of layer 2 and layer 3 filters as well as redirection, 101 and therefore extend the filter language described in [RFC3588]. 103 User traffic redirection is supported with or without tunneling. 104 Tunneling support is provided using the tunnel attributes defined 105 in [RFC2868]. Redirection of traffic in mid-session may break 106 applications. 108 1.1. Terminology 110 In this document when we refer to blocking of IP traffic we mean 111 filtering of IP traffic. Additionally, this document uses the 112 following terms: 114 Authenticator 115 An authenticator is an entity that requires 116 authentication from the supplicant. The authenticator 117 may be connected to the supplicant at the other end of a 118 point-to-point LAN segment or 802.11 wireless link. 120 Authentication server 121 An authentication server is an entity that provides an 122 authentication service to an authenticator. This service 123 verifies from the credentials provided by the supplicant, 124 the claim of identity made by the supplicant. 126 Hot-lining 127 Blocking and redirection of users traffic is known as 128 hot-lining of accounts. In this document, hot-lining is 129 used as the motivation for these attributes and an 130 illustration of how they would be used. However, the 131 attributes may be used together or separately to provide 132 other features. 134 Redirection 135 Refers to an action taken by the NAS to redirect the 136 user's traffic to an alternate location. 138 Supplicant 139 A supplicant is an entity that is being authenticated by 140 an authenticator. The supplicant may be connected to the 141 authenticator at one end of a point-to-point LAN segment 142 or 802.11 wireless link. 144 Terminal 145 A terminal is an endpoint, such as an 802.1X 146 supplicant, attached to the NAS port. 148 1.2. Requirements Language 150 In this document, several words are used to signify the 151 requirements of the specification. The key words "MUST", "MUST 152 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 153 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 154 interpreted as described in [RFC2119]. 156 An implementation is not compliant if it fails to satisfy one or 157 more of the must or must not requirements for the protocols it 158 implements. An implementation that satisfies all the must, must 159 not, should and should not requirements for its protocols is said 160 to be "unconditionally compliant"; one that satisfies all the must 161 and must not requirements but not all the should or should not 162 requirements for its protocols is said to be "conditionally 163 compliant". 165 1.3. Capability Advertisement 167 RADIUS does not currently define a method by which a NAS can 168 advertise its capabilities and in many instances, it would be 169 desirable for the home network to know what capabilities are 170 supported by the NAS to ensure proper operational behavior. The 171 attributes defined in this document are intended to be used to 172 enforce policy by the NAS. If a NAS does not recognize these 173 attributes it will most likely ignore them and the desired policy 174 will not be enforced. A method for the NAS advertising the 175 capability to support these attributes would help the RADIUS 176 server understand if the intended policies can be enforced. As a 177 result, the attributes in this document, in particular NAS- 178 Traffic-Rule(TBD), can benefit from capability advertisement, if 179 available. 181 1.4 Attribute Interpretation 183 Unless otherwise noted in the individual description of an 184 attribute contained herein, a NAS that conforms to this 185 specification and receives an Access-Accept message that contains 186 an attribute from this document that it cannot apply MUST 187 interpret this though an Access-Reject had been sent and MUST 188 terminate the session. If accounting is enabled on the NAS, it 189 MUST generate an Accounting-Request(Stop) message upon session 190 termination. 192 Similarly, if a NAS conforming to this specification and also 193 conforming to RFC 3576 [RFC3576] receives a CoA-Request message 194 that contains an attribute from this document that it cannot 195 apply, it MUST NOT terminate the session and MUST generate a CoA- 196 NAK packet with ERROR-CAUSE(101) set to "Unsupported 197 Attribute"(401). If accounting is enabled on the NAS, it MUST NOT 198 generate an Accounting-Request(Stop) message in such instances. 200 2. RADIUS Authentication 202 This specification introduces one new RADIUS authentication 203 attributes. 205 2.5. NAS-Traffic-Rule 207 Description 209 The NAS-Traffic-Rule attribute is derived from the Diameter 210 IPFilterRule and enables provisioning of base encapsulation 211 (Layer 2) rules, Internet Protocol (Layer 3-4) rules, and HTTP 212 (Layer 5+) rules on the NAS by the RADIUS server. Compared to 213 Diameter's IPFilterRule, NAS-Traffic-Rule is a superset in 214 functionality, but is largely based on the same syntax 215 foundations. 217 For each rule and depending on the rule type, the NAS can be 218 instructed to take a single action as follows: 220 Rule Type Allowable rule action 221 ------------------- --------------------- 222 Base Encapsulation filter, tunnel 223 Internet Protocol filter, tunnel 224 HTTP filter, redirect 226 When specifying a base encapsulation rule, NAS-Traffic-Rule 227 processes packets based on the following information that is 228 associated with it: 230 Direction (in and/or out) 231 Base encapsulation type 232 Source and destination MAC address (possibly masked) 234 For a base encapsulation rule, the filter action entails having 235 the NAS permit (i.e. forward) or deny (i.e. block) a user's 236 traffic. The tunnel action entails having the NAS forward user 237 traffic to or from a named tunnel that has been established per 238 [RFC2868]. 240 When specifying an Internet Protocol rule, NAS-Traffic-Rule 241 processes packets based on the following information that is 242 associated with it: 244 Direction (in and/or out) 245 Source and destination IP address (possibly masked) 246 Protocol 247 Source and destination port (lists or ranges) 248 TCP flags 249 IP fragment flag 250 IP options 251 ICMP types 253 For an Internet Protocol rule, the filter action entails having 254 the NAS permit (i.e. forward) or deny (i.e. block) a user's 255 traffic. The tunnel action entails having the NAS forward user 256 traffic to or from a named tunnel that has been established per 257 [RFC2868]. 259 When specifying an HTTP rule, NAS-Traffic-Rule processes 260 packets based on the following information that is associated 261 with it: 263 HTTP URL 264 Source and destination IP address (possibly masked) 266 For an HTTP rule, the filter action entails having the NAS 267 permit (i.e. forward) or deny (i.e. block) a user's [RFC2616] 268 request message. For a deny action, the NAS MAY respond to the 269 request message with a code 403 (Forbidden) response in 270 accordance with [RFC2616]. For a redirect action the NAS SHOULD 271 respond to the user's request with a code 302 (Found) response 272 in accordance with [RFC2616]. 274 For the HTTP redirection action, it is also possible to have 275 redirection automatically removed by including a redir-cnt 276 count parameter along with the rule. The rule will be removed 277 from the active rule set when the rule matches redir-cnt number 278 of times. Upon removal from the active rule set, traffic is no 279 longer evaluated against this rule. 281 It should be noted that an HTTP filter or redirect rule is only 282 useful with plain-text HTTP and not [RFC2818] HTTPS. 283 Redirection or filtering of HTTPS is outside the scope of this 284 document. 286 As per the requirements of RFC 2865, Section 2.3, if multiple 287 NAS-Traffic-Rule attributes are contained within an Access- 288 Accept or CoA-Request packet, they MUST be maintained in order. 289 The attributes MUST be consecutive attributes in the packet. 290 RADIUS proxies MUST NOT reorder NAS-Traffic-Rule attributes. 292 The RADIUS server can return multiple NAS-Traffic-Rule 293 attributes in an Access-Accept or CoA-Request packet. Where 294 more than one NAS-Traffic-Rule attribute is included, it is 295 assumed that the attributes are to be concatenated to form a 296 single filter list. Furthermore, if the list contains different 297 types of rules, they MUST appear in the following order: flush 298 rules, base encapsulation tunnel rules, base encapsulation 299 filter rules, IP tunnel rules, HTTP redirect rules, IP filter 300 rules, and HTTP filter rules. 302 Rules are evaluated in order, with the first matched rule 303 terminating the evaluation. Each packet is evaluated once. If 304 no rule matches, then packet is dropped (implicit deny all). 306 When an HTTP redirect rule matches, the NAS shall reply to the 307 HTTP request with an HTTP redirect in accordance with [RFC2616] 308 redirecting traffic to specific URL. 310 Filter-ID (11) and NAS-Traffic-Rule both define how filters are 311 to be applied in the NAS. These attributes are not intended to 312 be used concurrently and SHOULD NOT appear in the same RADIUS 313 message. Only one type of filtering attribute must be 314 processed. If a Filter-ID (11) is present, then the NAS- 315 Traffic-Rule MUST be ignored, if present. 317 The NAS-Traffic-Rule attribute is shown below. The fields are 318 transmitted from left to right: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type (TBD) | Length | Text 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Text (cont.) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Type 330 TBD 332 Length 334 >= 3 336 Text 338 The text conforms to the following ABNF [RFC2234] formatted syntax 339 specification: 341 ; Start of ABNF description of NAS-Traffic-Rule 343 rule = (flush-rule / permit-all-rule 344 / l2-filter-rule / l2-tunnel-rule 345 / ip-filter-rule / ip-tunnel-rule 346 / http-filter-rule / http-redir-rule) 347 rule-delim 349 ; Flush Rule 350 flush-rule = "flush" 352 ; Permit all rule 353 permit-all-rule = "permit inout any from any to any" 355 ; Base encapsulation filter rule 356 l2-filter-rule = ("permit" / "deny") " " 357 ("in" / "out" / "inout") " " 358 l2-filter-body [" " log-rule] 359 l2-filter-body = (l2-proto " from " l2-address " to " 360 l2-address) / l2-rmon-str 361 l2-proto = "l2:ether2" [":0x" 1*4HEXDIG] 362 l2-rmon-str = "l2:" 1*DIGIT *("." 1*DIGIT) 363 l2-address = ["!"] (macaddr / (macaddr "/" macmask) 364 / "any") 365 macaddr = 2HEXDIG 5("-" 2HEXDIG) 366 macmask = DIGIT ; 0-9 367 / %x31-33 DIGIT ; 10-39 368 / "4" %x30-38 ; 40-48 370 ;Base encapsulation tunnel rule 371 l2-tunnel-rule = "tunnel " tunnel-id " " 372 ("in" / "out" / "inout") " " 373 l2-filter-body [" " log-rule] 375 ;IP Filter Rule 376 ip-filter-rule = ("permit" / "deny") " " 377 ("in" / "out" / "inout") " " 378 ("ip" / ip-proto) filter-body 379 [" " ip-option] [" " log-rule] 380 ip-proto = d8 381 ip-address = ["!"] (ipv4-address ["/" ipv4mask] / 382 ipv6-address ["/" ipv6mask] / 383 "any" / 384 "assigned") 385 ipv4-address = d8 "." d8 "." d8 "." d8 386 ipv4mask = DIGIT ; 0-9 387 / %x31-32 DIGIT ; 10-29 388 / "3" %x30-32 ; 30-32 389 ipv6-address = 1*4HEXDIG 7(":" 1*4HEXDIG) 390 ipv6mask = DIGIT ; 0-9 391 / %x31-39 DIGIT ; 10-99 392 / "1" %x30-31 DIGIT ; 100-119 393 / "1" %x32 %x30-38 ; 120-128 394 tcp-ports = tcp-port *("," tcp-port) 395 tcp-port = d16 / d16 "-" d16 396 ip-option = "frag" / 397 ["ipoptions " ["!"] ipopt *("," ["!"] ipopt)] 398 ["tcpoptions " ["!"] tcpopt 399 *("," ["!"] tcpopt)] 400 ["established"] 401 ["setup"] 402 ["tcpflags " ["!"] tcpflag 403 *("," ["!"] tcpflag)] 404 ["icmptypes " icmptype *("," icmptype)] 405 ipopt = "ssrr" / "lsrr" / "rr" / "ts" 406 tcpopt = "mss" / "window" / "sack" / "ts" / "cc" 407 tcpflag = "fin" / "syn" / "rst" / "psh" / "ack" / "urg" 409 icmptype = d8 / d8 "-" d8 410 / "echo reply" / "destination unreachable" 411 / "source quench" / "redirect" 412 / "echo request" / "router advertisement" 413 / "router solicit" / "time-to-live exceeded" 414 / "IP header bad" / "timestamp request" 415 / "timestamp reply" / "information request" 416 / "information reply" 417 / "address mask request" 418 / "address mask reply" 420 ;IP Tunnel Rule 421 ip-tunnel-rule = "tunnel " tunnel-id " " 422 ("in" / "out" / "inout") " " 423 ("ip" / ip-proto) filter-body 424 [" " ip-option] [" " log-rule] 426 ;HTTP Filter Rule 427 http-filter-rule= ("permit" / "deny") org-url " " 428 ("in" / "out" / "inout") filter-body 429 [" " log-rule] 431 ;HTTP Redirect Rule 432 http-redir-rule= "redirect " [redir-cnt " "] redir-url 433 filter-body [" " org-url] 434 [" " log-rule] 435 redir-cnt = 1*DIGIT 436 org-url = http_URL 437 ;Note: Syntax for http_URL defined in 438 ;[RFC2616], section 3.2.2 439 redir-url = http_URL 441 ;Common 442 filter-body = " from " ip-address [" " tcp-ports] 443 " to " ip-address [" " tcp-ports] 445 tunnel-id = DQUOTE 446 1*(TEXTDATA / ("%" 2HEXDIG)) 447 DQUOTE 448 log-rule = "cnt" 450 ;Primitives 451 LF = %x0A ; linefeed 452 DIGIT = %x30-39 ; 0-9 453 DQUOTE = %x22 ; " (Double Quote) 454 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 455 rule-delim = LF 456 d8 = DIGIT ; 0-9 457 / %x31-39 DIGIT ; 10-99 458 / "1" 2DIGIT ; 100-199 459 / "2" %x30-34 DIGIT ; 200-249 460 / "25" %x30-35 ; 250-255 461 d16 = DIGIT ; 0-9 462 / %x31-35 1*4DIGIT ; 10-59999 463 / "6" "4" 3DIGIT ; 60000-64999 464 / "6" "5" %x30-34 2DIGIT ; 65000-65499 465 / "6" "5" "5" %x30-32 1DIGIT ; 65500-65529 466 / "6" "5" "5" "3" %x30-36 ; 65530-65536 467 TEXTDATA = %x20-21 / %x23-24 / %x26-7E 469 ; End of ABNF description of NAS-Traffic-Rule 471 Descriptions of notable fields and keywords follow: 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 tcp-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: 545 "l2:" Prefix to designate a rule as a base encapsulation 546 rule. 548 "l2:ether2" keyword means any Ethernet-II (DIX Ethernet) will 549 match. 551 ether2:val Used to specify an Ethernet-II type by hexadecimal 552 number, whereby "val" is replaced by desired 553 number. Example: "l2:ether2:0x800" for IP ethertype 554 (0x0800). 556 l2-rmon-str Used to specify base encapsulation per the octet 557 string format defined in [RFC2895], section 4.2. 558 Example: "l2:0.0.0.2.0.0.0.240" for Netbios over 559 LLC. 561 macaddr For base encapsulation filter rules of "l2:ether2" 562 type, the Ethernet MAC address with octet values 563 separated by a "-". Example: "00-10-A4-23-19-C0". 565 macaddr/mask An Ethernet number as above with a mask width of 566 the form "00-10-A4-23-00-00/32". In this case, all 567 MAC addresses from 00-10-A4-23-00-00 to 00-10-A4- 568 23-FF-FF will match. The MAC address MUST NOT have 569 bits set beyond the mask. The keyword "any" is 570 00-00-00-00-00-00/0. 572 The sense of the match can be inverted by preceding 573 an address with the not modifier (!), causing all 574 other addresses to be matched instead. 576 Note: macaddr nor macaddr/mask argument is not used 577 for "l2:rmon" type rules. 579 For IP rules: 580 "ip" Keyword means any IP protocol will match. 582 ip-proto An IP protocol specified by number. 584 "frag" Match if the packet is a fragment and this is not 585 the first fragment of the datagram. frag may not 586 be used in conjunction with either tcpflags or 587 TCP/UDP port specifications. 589 "ipoptions" Match if the IP header contains the comma separated 590 list of options specified in spec. The supported 591 IP options are: ssrr (strict source route), lsrr 592 (loose source route), rr (record packet route) and 593 ts(timestamp). The absence of a particular option 594 may be denoted with a '!'. 596 "tcpoptions" Match if the TCP header contains the comma 597 separated list of options specified in spec. The 598 supported TCP options are: 600 mss (maximum segment size), window (tcp window 601 advertisement), sack (selective ack), ts (rfc1323 602 timestamp) and cc (rfc1644 t/tcp connection count). 603 The absence of a particular option may be denoted 604 with a '!'. 606 "established" TCP packets only. Match packets that have the 607 RST or ACK bits set. 609 "setup" TCP packets only. Match packets that have the SYN 610 bit set but no ACK bit. 612 "tcpflags" TCP packets only. Match if the TCP header contains 613 the comma separated list of flags specified in 614 spec. The supported TCP flags are: 616 fin, syn, rst, psh, ack and urg. The absence of a 617 particular flag may be denoted with a '!'. A rule 618 that contains a tcpflags specification can never 619 match a fragmented packet that has a non-zero 620 offset. See the "frag" option for details on 621 matching fragmented packets. 623 "icmptypes" ICMP packets only. Match if the ICMP type is in 624 the list types. The list may be specified as any 625 combination of ranges or individual types separated 626 by commas. Both the numeric values and the 627 symbolic values listed below can be used. The 628 supported ICMP types are: 630 echo reply (0), destination unreachable (3), source 631 quench (4), redirect (5), echo request(8), router 632 advertisement (9), router solicitation (10), time- 633 to-live exceeded (11), IP header bad (12), 634 timestamp request (13), timestamp reply (14), 635 information request (15), information reply (16), 636 address mask request (17) and address mask reply 637 (18). 639 For HTTP redirection rules: 640 redir-cnt Specifies the number of HTTP redirect rule matches 641 that should transpire before removing this rule 642 from the active rule set. Upon removal from the 643 active rule set, traffic is no longer evaluated 644 against this rule. 646 redir-url An HTTP URL. When the 'redirect' rule matches 647 (src/dst and/or org_URL ), HTTP requests are 648 redirected to redir_URL address in accordance with 649 [RFC2616] redirection traffic to specific URL. 651 org-url An HTTP URL. Specifies the HTTP URL against which 652 user HTTP requests will be evaluated. If user HTTP 653 request matches org_URL, then redirection action is 654 taken. 656 For base encapsulation and IP tunnel rules: 657 tunnel_id A tunnel id. When the 'tunnel' rule matches, 658 traffic is redirected over the tunnel with the 659 specified tunnel_id. Traffic can only be redirected 660 to or from named tunnels that have been established 661 per [RFC2868] and named using the Tunnel- 662 Assignment-ID attribute described therein. 664 The tunnel id MUST be encapsulated in double quotes 665 and follow the labeling convention defined by the 666 TEXTDATA. 667 Example: A tunnel with the name of tunnel "ppp%1" 668 would be specified as "%22ppp%251%22" 670 A NAS that is unable to interpret or apply a deny rule MUST 671 terminate the session. A NAS MAY apply deny rules of its own 672 before the supplied rules, for example to protect the access 673 device owner's infrastructure. 675 3. RADIUS Accounting 677 This specification introduces one new RADIUS accounting attribute. 679 3.1. Acct-NAS-Traffic-Rule 681 Description 683 Acct-NAS-Traffic-Rule enables a RADIUS client to include NAS- 684 Traffic-Rule[TBD] rule match counters as part of the accounting 685 message. 687 The Acct-NAS-Traffic-Rule attribute is shown below. The fields 688 are transmitted from left to right: 690 0 1 2 3 691 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 >=3 707 String 709 The first eight octets of this string are used for a 64-bit 710 value of the rule counter. The remaining octets are used to 711 specify for which filter rule the counter is for a value. The 712 rule specification MUST conform to the syntax rules specified 713 for NAS-Traffic-Rule[TBD]. 715 4. Table of Attributes 717 The following table provides a guide to which attributes may be 718 found in which kinds of packets, and in what quantity. 720 Access- Access- Access- Access- CoA- 721 Request Accept Reject Challenge Req # Attribute 722 0 0+ 0 0 0+ TBD NAS-Traffic-Rule 724 Actng- Actng- 725 Request Response # Attribute 726 0-1 0 TBD Acct-NAS-Traffic-Rule 728 The following table defines the meaning of the above table 729 entries. 731 0 This attribute MUST NOT be present in packet. 732 0+ Zero or more instances of this attribute MAY be present in 733 the packet. 734 0-1 Zero or one instance of this attribute MAY be 735 present in the packet. 737 5. Diameter Considerations 739 Diameter needs to define identical attributes with the same Type 740 values. The attributes should be available as part of the NASREQ 741 application [RFC4005], as well as the Diameter EAP application 742 [RFC4072]. 744 6. IANA Considerations 746 This document uses the RADIUS [RFC2865] namespace, see 747 . Allocation of six 748 updates for the section "RADIUS Attribute Types" is requested. The 749 RADIUS attributes for which values are requested are: 751 TBD - NAS-Traffic-Rule 752 TBD - Acct-NAS-Traffic-Rule 754 7. Security Considerations 756 Since this document describes the use of RADIUS for purposes of 757 authentication, authorization, and accounting in [IEEE8021X] 758 enabled networks, it is vulnerable to all of the threats that are 759 present in other RADIUS applications. For a discussion of these 760 threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580]. 762 This document specifies new attributes that can be included in 763 existing RADIUS messages. These messages are protected using 764 existing security mechanisms; see [RFC2865] and [RFC3576] for a 765 more detailed description and related security considerations. 767 The security mechanisms in [RFC2865] and [RFC3576] are primarily 768 concerned with an outside attacker who modifies messages in 769 transit or inserts new messages. They do not prevent an authorized 770 RADIUS server or proxy from inserting or deleting attributes with 771 a malicious purpose in messages it sends. 773 An attacker who compromises an authorized RADIUS server or proxy 774 can use the attributes defined in this document to influence the 775 behavior of the NAS in ways that previously may not have been 776 possible. For example, modifications to the VLAN-related 777 attributes may cause the NAS to permit access to other VLANs that 778 were intended. To give another example, inserting suitable 779 redirection rules to the NAS-Traffic-Rule attribute may allow the 780 attacker to eavesdrop or modify packets sent by a legitimate 781 client. 783 In general, the NAS cannot know whether the attribute values it 784 receives from an authenticated and authorized server are well- 785 intentioned or malicious, and thus it is not possible to 786 completely protect against attacks by compromised nodes. In some 787 cases, the extent of the possible attacks can be limited by 788 performing more fine-grained authorization checks at the NAS. 790 For instance, a NAS could be configured to accept only certain 791 VLAN IDs from a certain RADIUS server/proxy, or not to accept any 792 redirection rules if it is known they are not used in this 793 environment. 795 8. References 797 8.1. Normative references 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", RFC 2119, March, 1997. 802 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 803 L., Leach P., Berners-Lee T., "Hypertext Transfer Protocol 804 -- HTTP/1.1", RFC 2616, June 1999. 806 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 807 Authentication Dial In User Service (RADIUS)", RFC 2865, 808 June 2000. 810 [RFC2895] Bierman, A., Bucci, C., Iddon, R., "Remote Network 811 Monitoring MIB Protocol Identifier Reference", RFC 812 2895, August 2000 814 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko, 815 J., "Diameter Base Protocol", RFC 3588, September 2003. 817 [RFC4005] Calhoun, P., Zorn, G., Spence, D., Mitton, D., "Diameter 818 Network Access Server Application", RFC 4005, August 2005. 820 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 821 Overview and Architecture, ANSI/IEEE Std 802, 1990. 823 [IEEE8021X] 824 IEEE Standards for Local and Metropolitan Area Networks: 825 Port based Network Access Control, IEEE Std 802.1X-2004, 826 August 2004. 828 8.2. Informative references 830 [RFC2234] Croker, E., Overell, P., "Augmented BNF for Syntax 831 Specifications: ABNF", RFC 2234, November 1997. 833 [RFC2607] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy 834 Implementation in Roaming", RFC 2607, June 1999. 836 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC2818, May 2000. 838 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 839 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 840 Support", RFC 2868, June 2000. 842 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 843 3162, August 2001. 845 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. 846 Aboba,"Dynamic Authorization Extensions to Remote 847 Authentication Dial In User Service (RADIUS)", RFC 3576, 848 July 2003. 850 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 851 Authentication Protocol (EAP)", RFC 3579, September 2003. 853 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., 854 "IEEE 802.1X Remote Authentication Dial In User Service 855 (RADIUS) Usage Guidelines", RFC3580, September 2003. 857 [RFC4072] Eronen, P., Hiller, T., Zorn G., "Diameter Extensible 858 Authentication Protocol (EAP) Application", RFC4072, August 859 2005. 861 [IEEE8023] 862 ISO/IEC 8802-3 Information technology - Telecommunications 863 And information exchange between systems - Local and 864 metropolitan area networks - Common specifications - Part 865 3: Carrier Sense Multiple Access with Collision Detection 866 (CSMA/CD) Access Method and Physical Layer Specifications, 867 (also ANSI/IEEE Std 802.3- 1996), 1996. 869 [IEEE80211] 870 Information technology - Telecommunications and information 871 exchange between systems - Local and metropolitan area 872 networks - Specific Requirements Part 11: Wireless LAN 873 Medium Access Control (MAC) and Physical Layer (PHY) 874 Specifications, IEEE Std. 802.11-1999, 1999. 876 [IEEE80211i] 877 Institute of Electrical and Electronics Engineers, 878 "Supplement to Standard for Telecommunications and 879 Information Exchange Between Systems - LAN/MAN Specific 880 Requirements - Part 11:Wireless LAN Medium Access Control 881 (MAC) and Physical Layer 882 (PHY) Specifications: Specification for Enhanced Security", 883 June 2004. 885 Appendix A - Traffic Redirection 887 There are several ways to redirect the user's traffic. Which 888 method will be used depends on the capabilities available at the 889 NAS and Service Provider's preference. This Appendix describes 890 various methods to redirect user traffic by using the new 891 attributes outlined in this document in conjunction with existing 892 attributes, which are: 894 1) Tunneling; and 895 2) HTTP Redirection; 897 For each method we describe how redirection is done at service 898 initiation and mid-session. We also describe how redirection is 899 removed when it is no longer desired. 901 A.1 Tunneling 903 User traffic can be redirected by tunneling the user's traffic to 904 an alternate location. Tunneling will typically redirect all of 905 the user's traffic for the Service. When tunneling is used to 906 redirect all the traffic, then filtering may not be necessary. 908 A.1.1 Service Initiation 910 Redirect using tunnels at service initiation requires that the 911 RADIUS server send the appropriate [RFC2868] tunnel attributes and 912 NAS-Traffic-Rule attributes to the NAS. The [RFC2868] tunnel 913 attributes describe the tunnel endpoint and the type of tunnel to 914 construct. The 'tunnel ' option for the NAS-Traffic- 915 Rule allows the specification of a traffic rule for which to 916 redirect traffic to a named tunnel. 918 A.1.2 Mid-session Tunnel Redirection 920 Redirection of traffic using tunnels mid-session involves sending 921 the tunnel attributes as per [RFC2868] to the NAS using Change-of- 922 Authorization (CoA) message. The operation is described in 923 [RFC3576]. Careful attention should be paid to the security 924 issues in [RFC3576]. 926 Note that if the session is already tunneled (eg. Mobile-IP) then 927 the CoA message with a new tunnel specification can be sent to the 928 NAS or alternatively the redirection can occur at the tunnel 929 endpoint (the Home Agent) using any one of these methods. 931 A.1.3 Tunnel Redirection Removal 933 If the normal mode for the session was to tunnel the session and 934 redirection was sent to the NAS, the RADIUS Server can send the 935 original tunnel attributes to the NAS in a CoA message. The NAS 936 will tear down the tunnel and establish a connection back to the 937 original tunnel endpoint. 939 However, if the normal mode for the session is not to use 940 tunneling then there is a problem because RADIUS does not have a 941 mechanism whereby it can de-tunnel. Receiving a CoA message 942 without tunnel attributes would not have an effect on an existing 943 tunnel. In order to de-tunnel the session, the RADIUS server has 944 to send the NAS a CoA message with Service-Type(6) set to 945 "Authorize-Only" causing the NAS to perform a re-Authorization. 946 In response to the re-Authorization, the RADIUS server will send 947 an Access-Accept packet without the tunneling information. Upon 948 receiving the corresponding Access-Accept packet the NAS MUST 949 apply the new authorization attributes. If these do not contain 950 tunnel attributes, then the NAS MUST tear down the tunnel. 952 A.1.4 Tunnel Redirection Examples 954 The following examples illustrate how traffic flows when subjected 955 to a NAS-Traffic-Rule using tunnel redirection. In these 956 scenarios, the following notation is used to represent traffic 957 flows: 959 ------> Flow in one direction 960 <-----> Flow in two directions 961 ======> Flow in a tunnel in one direction 962 <=====> Flow in a tunnel in two directions 964 A RADIUS server that wishes all IP traffic to flow between the 965 client and a selected redirection destination will issue an 966 Access-Accept that contains the specification for the tunnel using 967 the attributes defined by RFC 2868 and a NAS-Traffic-Rule 968 attribute using the tunnel action and arguments. 970 An example NAS-Traffic-Rule will look like: 972 tunnel "t1" in ip from assigned to any 974 This will cause all traffic that flows from the client to any 975 destination to be tunneled over the named tunnel "t1" to the 976 tunnel endpoint (TEP). 978 +-------+ +------+ +------+ +------+ 979 | | | | |Tunnel| | | 980 |client +<---------->+ NAS +<==t1===>+ End +<----->+ Dest | 981 | | | | |Point | | | 982 +-------+ +------+ +------+ +------+ 984 The direction argument takes the values of "in", "out" or "inout" 985 and is important because it controls how information is routed. 986 The following diagram demonstrates how traffic is routed. In all 987 these diagrams time is increasing as we proceed down the page. 989 When rule direction is "in": 991 client NAS TEP DESTINATION 992 | | | | 993 |---------->|===t1===>|--------->| 994 | | | | 995 |<----------|<-------------------| (flows directly to NAS) 996 | | | | 998 The inbound traffic from the client matches the specified filter 999 rule and the IP packet is placed in the tunnel to the TEP. The TEP 1000 forwards the packet to the Destination using the destination IP 1001 address in the packet header. Note that the source address of the 1002 packet is the address assigned at the NAS. Therefore if the 1003 destination were to reply to the packet it would use the NAS 1004 source address and the packet would flow directly to the NAS and 1005 to the client bypassing the TEP. The Home network would use this 1006 capability if it was only interested in metering or seeing the 1007 inbound traffic from the client. 1009 However, if the home network wanted to see the traffic in both 1010 directions it could deploy a NAT function at the TEP. 1012 Here is the flow when the TEP is acting like a NAT: 1014 client NAS TEP/NAT DESTINATION 1015 | | | | 1016 |---------->|===t1===>|--------->| 1017 | | | | 1018 |<----------|<==t1====|<---------| 1020 The client establishes a connection to the Destination, but the 1021 TEP acting as NAT, changes the source address of the IP packet (as 1022 NATs do) to that of the TEP/NAT. Now any replies from the 1023 Destination are sent to the TEP/NAT. The TEP/NAT then forwards 1024 these packets to the client through the NAS. 1026 When the TEP is acting as a NAT, using the direction argument "in" 1027 is important. The direction argument set to "out" will have no 1028 effect on traffic coming from the tunnel since all traffic to the 1029 client should come from the TEP/NAT inside the tunnel. The 1030 direction argument set to "inout" will have the same effect as if 1031 it were set to "in". 1033 The TEP/NAT forwards all traffic for the client into the tunnel to 1034 the NAS. The NAS always forwards any egressing traffic from the 1035 tunnel to the client. It does not apply any redirection rules on 1036 traffic egressing a tunnel. The NAS does not care whether the TEP 1037 is transparent or is acting as a NAT. 1039 A.2 HTTP Redirection 1041 Another method of redirection is at the application layer, 1042 specifically the HTTP layer. An HTTP aware NAS redirects traffic 1043 by issuing an HTTP Redirect response causing the user's browser to 1044 navigate to an alternate Web Portal. 1046 The call flow associated with performing redirection at the HTTP 1047 layer is very similar with the call flow associated with 1048 redirection done at the IP layer. 1050 The same NAS-Traffic-Rule(TBD) attribute described above is used 1051 to convey the redirection rules to use for HTTP redirection. HTTP 1052 redirection rules within the NAS-Traffic-Rule attribute supports 1053 the encoding of a redirection URL to apply when a rule is matched. 1055 A.2.1 Service Initiation 1057 As with previous call flows, the RADIUS server MAY send multiple 1058 HTTP redirect or filtering rules within a NAS-Traffic-Rule(TBD) 1059 attribute to the NAS in the Access-Accept message. 1061 A.2.2 Mid-session HTTP Redirection 1063 If HTTP redirection is required to be applied to a service that 1064 has already been started then the RADIUS server can push the 1065 redirection rules, and optionally the filter rules, to the NAS 1066 within a NAS-Traffic-Rule(TBD) attribute using a CoA-Request 1067 message. The NAS will then commence to apply the redirection rules 1068 and/or the filter rules. 1070 Alternatively, the RADIUS server can request that the NAS re- 1071 authorize the session using the procedures defined in [RFC3576]. 1072 The RADIUS server responds with an Access-Accept message (with 1073 Service-Type(6) set to "Authorize Only" that will contain the 1074 redirection and optionally filtering rules within a NAS-Traffic- 1075 Rule(TBD) attribute. 1077 A.2.3 HTTP Redirection Removal 1079 HTTP Redirection rules can be automatically removed mid-session 1080 from the NAS using the redir-cnt parameter or explicitly removed 1081 from the RADIUS server. The RADIUS server can explicitly turn HTTP 1082 redirection off mid-session in two ways. It can push new 1083 redirection rules within a NAS-Traffic-Rule(TBD) attribute using a 1084 CoA-Request message or it can send the NAS a CoA-Request message 1085 requesting it to re-authorize. 1087 When using CoA-Request message to return the redirection and 1088 filtering back to "normal," there needs to be either a filter rule 1089 (or filter-id) or redirection rule that corresponds to the 1090 "normal" state. If normally the session did not have any filter 1091 and or redirection rules applied, the RADIUS server can send a 1092 NAS-Traffic-Rule(TBD) with the action of "flush" in the CoA- 1093 Request message. This action will cause all the filter rules and 1094 redirection rules previously assigned to the session to be 1095 removed. 1097 A.3 Accounting 1099 Every time a session is redirected and every time the redirection 1100 is reverted back a new session is created and the old one is 1101 terminated. Therefore the NAS MUST generate and Accounting- 1102 Request(Stop) for the old session and an Accounting-Request(Start) 1103 for the new session. 1105 A.4 Example Scenarios 1107 The following two examples illustrate the user's experience when 1108 being redirected. 1110 For the first example assume an [IEEE8021X] environment, whereby a 1111 user connects to the enterprise LAN and initiates an 1112 authentication handshake. As part of the overall authentication 1113 process, it is also possible to pass endpoint state such as patch 1114 level, virus signature status, etc., all of which can be verified 1115 by a back-end server for policy compliancy and alter the 1116 authentication and authorization decision. In instances that an 1117 end-host is not in compliancy, the NAS may be instructed to limit 1118 network access in some fashion (i.e. quarantine) and limit network 1119 access to remediation services and a web-based information site. 1120 A user may sense degraded network performance and open a web 1121 session, which the NAS would redirect to the web-based information 1122 site for compliancy status, remediation actions, etc. 1124 For the second example assume an ISP environment, whereby a 1125 prepaid user is roaming the net in their hotel room over WiFi and 1126 is to be Hot-lined because their account has no more funds. The 1127 user's Service Provider instructs the NAS to block all traffic, 1128 and redirect any port 80 traffic to the Service Provider's Prepaid 1129 Portal. Upon detecting that there is no service, the user 1130 launches his browser and regardless of which web site is being 1131 accessed the browser traffic will arrive at the Prepaid Portal 1132 which will then return a page back to the subscriber indicating 1133 that he needs to replenish his account. 1135 Appendix B - NAS-Traffic-Rule Filter Examples 1137 This appendix presents a variety of filter examples utilizing the 1138 syntax definition described in section 3.5 1140 Example #1: Permit all user traffic, regardless of type. 1142 permit inout any from any to any 1144 Example #2: Permit only L2 traffic coming from and going to a 1145 user's Ethernet MAC address. Block all other traffic. Assume 1146 user's MAC address is 00-10-A4-23-19-C0. 1148 permit in l2:ether2 from 00-10-A4-23-19-C0 to any 1149 permit out l2:ether2 from any to 00-10-A4-23-19-C0 1151 Example #3: Tunnel all L2 traffic coming from and going to a user. 1152 Assume tunnel name is: tunnel "1234". 1154 permit tunnel "tunnel \"1234\"" inout l2:ether2 from any to any 1156 Example #4: Permit only L3 traffic coming and going to from a 1157 user's IP address. Block all other traffic. Assume user's IP 1158 address is 192.0.2.128. 1160 permit in ip from 192.0.2.128 to any 1161 permit out ip from any to 192.0.2.128 1163 Example #5: Permit only L3 traffic coming and going to the user's 1164 assigned IP address. Block all other traffic. 1166 permit in ip from assigned to any 1167 permit out ip from any to assigned 1169 Example #6: Allow user to generate ARP requests, DNS requests, and 1170 HTTP (port 80) requests. Assume user's MAC address is 00-10-A4-23- 1171 19-C0 and IP address is 192.0.2.128. 1173 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any 1174 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 1175 permit in 17 from 192.0.2.168 to any 53 1176 permit out 17 from any 53 to 192.0.2.168 1177 permit in 6 from 192.0.2.168 80 to any 1178 permit out 6 from any 80 to 192.0.2.168 1180 Example #7: Allow user to generate ARP requests, DNS requests, and 1181 HTTP (port 80) requests, any of which are redirected to 1182 http://www.goo.org. Assume user's MAC address is 00-10-A4-23-19-C0 1183 and IP address is 192.0.2.128. 1185 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any 1186 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 1187 permit in 17 from 192.0.2.168 to any 53 1188 permit out 17 from any 53 to 192.0.2.168 1189 redirect http://www.goo.org in from 192.0.2.168 to any 80 1191 Example #8: Allow user to generate ARP requests, DNS requests, and 1192 HTTP (port 80) requests, of which only requests to 1193 http://www.goo.org are redirected to http://www.goo.org. Assume 1194 user's MAC address is 00-10-A4-23-19-C0 and IP address is 1195 192.0.2.128 1197 permit in l2:ether:0x0806 from 00-10-A4-23-19-C0 to any 1198 permit out l2:ether:0x806 from any to 00-10-A4-23-19-C0 1199 permit in 17 from 192.0.2.168 to any 53 1200 permit out 17 from any 53 to 192.0.2.168 1201 redirect http://www.goo.org in from 192.0.2.168 to any 80 1202 http://www.goo.org 1204 Acknowledgments 1205 The authors would like to acknowledge Joseph Salowey of Cisco, 1206 David Nelson of Enterasys, Chuck Black of Hewlett Packard, and 1207 Ashwin Palekar of Microsoft. 1209 Authors' Addresses 1211 Paul Congdon 1212 Hewlett Packard Company 1213 HP ProCurve Networking 1214 8000 Foothills Blvd, M/S 5662 1215 Roseville, CA 95747 1217 EMail: paul.congdon@hp.com 1218 Phone: +1 916 785 5753 1219 Fax: +1 916 785 8478 1221 Mauricio Sanchez (editor) 1222 Hewlett Packard Company 1223 HP ProCurve Networking 1224 8000 Foothills Blvd, M/S 5559 1225 Roseville, CA 95747 1227 EMail: mauricio.sanchez@hp.com 1228 Phone: +1 916 785 1910 1229 Fax: +1 916 785 1815 1231 Avi Lior 1232 Bridgewater Systems Corporation 1233 303 Terry Fox Drive 1234 Suite 100 1235 Ottawa, Ontario K2K 3J1 1236 Canada 1238 Phone: (613) 591-6655 1239 EMail: avi@bridgewatersystems.com 1240 URI: TCP://.bridgewatersystems.com/ 1242 Farid Adrangi 1243 Intel Corporation 1244 2111 North East 25th 1245 Hillsboro, Oregon 97124 1246 United States 1248 Phone: (503) 712-1791 1249 EMail: farid.adrangi@intel.com 1251 Bernard Aboba 1252 Microsoft Corporation 1253 One Microsoft Way 1254 Redmond, WA 98052 1256 EMail: bernarda@microsoft.com 1257 Phone: +1 425 706 6605 1258 Fax: +1 425 936 7329 1260 Intellectual Property Statement 1262 The IETF takes no position regarding the validity or scope of 1263 any Intellectual Property Rights or other rights that might be 1264 claimed to pertain to the implementation or use of the 1265 technology described in this document or the extent to which 1266 any license under such rights might or might not be available; 1267 nor does it represent that it has made any independent effort 1268 to identify any such rights. Information on the procedures 1269 with respect to rights in RFC documents can be found in BCP 78 1270 and BCP 79. 1272 Copies of IPR disclosures made to the IETF Secretariat and any 1273 assurances of licenses to be made available, or the result of 1274 an attempt made to obtain a general license or permission for 1275 the use of such proprietary rights by implementers or users of 1276 this specification can be obtained from the IETF on-line IPR 1277 repository at http://www.ietf.org/ipr. 1279 The IETF invites any interested party to bring to its attention 1280 any copyrights, patents or patent applications, or other 1281 proprietary rights that may cover technology that may be 1282 required to implement this standard. Please address the 1283 information to the IETF at ietf-ipr@ietf.org. 1285 Disclaimer of Validity 1287 This document and the information contained herein are provided 1288 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 1289 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 1290 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1291 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1292 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1293 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1294 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1296 Copyright Statement 1298 Copyright (C) The Internet Society (2006). This document is 1299 subject to the rights, licenses and restrictions contained in 1300 BCP 78, and except as set forth therein, the authors retain all 1301 their rights.