Network Working Group A. Lior Internet-Draft Bridgewater Systems Expires: August 6, 2004 F. Adrangi Intel February 6, 2004 Remote Authentication Dial In User Service (RADIUS) Redirection draft-lior-radius-redirection-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 6, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract In certain scenarios there needs to be a method to force the users traffic to a specific location. This document describes several methods that are available to be used with Remote Authentication Dial In User Service (RADIUS) Protocol and defines three new RADIUS attributes: NAS-Filter-Rule, Redirect-Id and Redirect-Rule. Lior & Adrangi Expires August 6, 2004 [Page 1] Internet-Draft RADIUS Redirection February 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Requirements Language . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1 Service Initiation . . . . . . . . . . . . . . . . . . . . . 7 3.1.2 Mid-session Redirection . . . . . . . . . . . . . . . . . . 7 3.1.3 Redirection Removal . . . . . . . . . . . . . . . . . . . . 7 3.2 Layer-3 Redirection . . . . . . . . . . . . . . . . . . . . 8 3.2.1 Service Initiation . . . . . . . . . . . . . . . . . . . . . 8 3.2.2 Mid-session Layer-3 Redirection . . . . . . . . . . . . . . 8 3.2.3 Layer-3 Redirection Removal . . . . . . . . . . . . . . . . 9 3.3 Application Redirection . . . . . . . . . . . . . . . . . . 9 3.3.1 Service Initiation . . . . . . . . . . . . . . . . . . . . . 10 3.3.2 Mid-session Application Redirection . . . . . . . . . . . . 10 3.3.3 Application Redirection Removal . . . . . . . . . . . . . . 10 3.4 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 NAS-Filter-Rule Attribute . . . . . . . . . . . . . . . . . 11 4.2 Redirection-Id . . . . . . . . . . . . . . . . . . . . . . . 15 4.3 Redirection-Rule . . . . . . . . . . . . . . . . . . . . . . 15 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 23 Normative References . . . . . . . . . . . . . . . . . . . . 24 Informative References . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . 26 Lior & Adrangi Expires August 6, 2004 [Page 2] Internet-Draft RADIUS Redirection February 2004 1. Introduction From time to time an Internet Service Provider (ISP) requires to restrict a user's access to the Internet and redirect their traffic to an alternate location. For example, the user maybe on a prepaid plan and all the resources have been used up. In this case the ISP would block the user's access to the Internet and redirect them to a portal where the user can replenish their account. Another example where the ISP would want to restrict access and redirect a user that was involved in some fraudulent behavior. Again the ISP would want to block the user's access to the Internet and redirect to a portal where they can inform the user as to their state and allow them to inform the user of their concerns and potentially rectify the situation. In the examples above it is important to note that the ability to block and redirect user's traffic is required at service initiation and once service has been established. These capabilities must also be available across access technologies and various business scenarios. For example, the ability to block and redirect traffic is required for TCP users, cell phone users, WiFi users. As well, this capability must work whether the user is in their home network or roaming in a visited network which may or may not have a direct roaming relationship with the user's home network. This document describes a protocol extension to the Remote Authentication Dial In User Service (RADIUS) Protocol RFC2865 [3] by which the aforementioned requirements can be addressed. To meet these needs three new RADIUS attributes are required. One option for providing these capabilities is to utilize RADIUS attributes for tunneling protocol specified in RFC2868 [5]. This document describes how to provide capabilities for users traffic redirection with or without using tunnels. Finally, the document describes how to provide for these capabilities dynamically (mid-service) using the RADIUS procotol extension described in RFC3576 [8]. Blocking and redirection of users traffic is known as hotlining of accounts. In this document, hotlining is used as the motivation for these attributes and an illustration of how they would be used. However, the NAS-Filter-Rule(TBD), Redirection-Id(TBD) and Redirection-Rule(TBD) may be used together or separately to provide other features. 1.1 Terminology In this document when we refer to Blocking we mean Filtering. Lior & Adrangi Expires August 6, 2004 [Page 3] Internet-Draft RADIUS Redirection February 2004 1.2 Requirements Language In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [2]. An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant". Lior & Adrangi Expires August 6, 2004 [Page 4] Internet-Draft RADIUS Redirection February 2004 2. Overview As described in the Introduction section, from time to time an ISP requires to control users access to the Internet by blocking their access and/or redirecting them to a specific location. In this section we will examine these requirements in more detail. Blocking access refers to setting up some rules at the NAS such that when the user initiates IP traffic, the NAS examines the set of rules associated with the Service granted to the subscriber. These rules determine what traffic is allowed to proceed through the NAS and what traffic will be blocked. Today this capability is supported in RADIUS and is configurable during service establishment and mid-service via the Filter-Id(11) attribute. To use Filter-Id to control access to the Internet the rules need to be configured at each NAS. Filter-Id(11) is used in an Access-Accept to specify the name of the filter rule(s) to apply to this session. To effect a change mid-service (dynamically) the Filter-Id(11) is included in a Change-of-Authorization (COA) packet. Upon receiving the Filter-Id(11) the NAS start to apply the rules specified by the Filter-Id(11). As pointed out by NASREQ the use Filter-Id is not roaming friendly and it is recommended that instead one should use NAS-Filter-Rule(400) AVP. For this reason, this document introduces NAS-Filter-Rule(TBD) to RADIUS. Redirection refers to an action taken by the NAS to redirect the user's traffic to an alternate location. Redirecting traffic in mid-session will most probably break some applications. However, Redirection at the start of a Service will most certainly work. For hotlining, the purpose of redirection is not to continue to provide the service at this alternate location. Rather the purpose is to facilitate a mechanism whereby the user is informed of their state, and is provided for a way to rectify the situation. In some cases redirection could be used to redirect traffic to another location where service can continue. The following illustrates the user's experience when being redirected. A valued prepaid user is roaming the net in their hotel room over WiFi is to be Hotlined (this is the term used by 3GPP2) because their account has no more funds. The user's Service Provider instructs the NAS to block all traffic, and redirect any port 80 traffic to the Service Provider's Prepaid Portal. Upon detecting that there is no service, the user launches his browser and regardless of which web site is being accessed the browser traffic will arrive at the Prepaid Portal which will then return a page back to the Lior & Adrangi Expires August 6, 2004 [Page 5] Internet-Draft RADIUS Redirection February 2004 subscriber indicating that he needs to replenish his account. There are several ways to redirect the users traffic. Which method will be used depends on the capabilities available at the NAS and Service Provider's perferrence. User traffic can be redirected by tunneling the user's traffic to an alternate location. Tunneling can be used at layer-2 or layer-3. Tunneling will typically redirect all the users traffic for the Service. When tunneling is used to redirect all the traffic then blocking is not necessary. Another method available for redirection is to have the NAS re-write the IP header in accordance with a redirection rule. We call this method Layer-3 Redirection. As the NAS receives packets from the user's device; if the packets match the redirection rule, the destination address and (optionally) the port is re-written causing them to arrive at the alternate location. As packets from that location arrive back at the NAS, the NAS rewrites the source address with the original destination address. This is similar to what a NAT will do. This method of redirection provides more flexibility than tunneling in that we can control which layer-3 flows are to be redirected. Another method of redirection is redirection in the application layer. In this method, the NAS is aware of application flows and redirects traffic based on an application specific method. For example, if the application is based on HTTP then an HTTP aware NAS would redirect traffic by issuing an HTTP Redirect response causing the users browser to navigate to an alternate Web Portal. Finally, redirection can be achieved by utilizing the RADIUS Framed-Route(22) attribute. Using this attribute the NAS can be instructed to route the packet over a specific path. Due to the security risks associated with Framed-Routing, the use of this attribute for redirection is discouraged and hence we will not deal with this method in this document. Lior & Adrangi Expires August 6, 2004 [Page 6] Internet-Draft RADIUS Redirection February 2004 3. Operations In this section we present the various methods used for redirecting user traffic, which are: 1) Tunneling; 2) Layer-3 Redirection; and 3) Application Redirection For each method, we describe how redirection is done at service initiation and mid-sesssion. We also describe how redirection is removed when it is no longer desired. 3.1 Tunneling When tunneling is used it will typically be used to redirect the entire traffic associated with the Service. Therefore, blocking (or filtering) will not be necessary at the NAS. As discussed above, tunneling can be used to redirect traffic at either layer-2 or layer-3. Regardless, the message flows presented in the following sections are the same. 3.1.1 Service Initiation Redirect using tunnels at service initiation requires that the RADIUS server send the appropriate tunnel attributes to the NAS. The tunnel attributes will describe the tunnel endpoint and the type of tunnel to construct. The operation is as specified in RFC2868 [5]. 3.1.2 Mid-session Redirection Redirection of traffic using tunnel mid-session involves sending the tunnel attributes as per RFC2868 [5] to the NAS using Change-of-Authorization (COA) packet. The operation is described in RFC3576 [8]. Careful attention should be paid to the security issues in RFC3576. Note that if the session is already tunneled (eg. Mobile-IP) then the COA packet with a new tunnel specification can be sent to the NAS or alternatively the redirection can occur at the tunnel endpoint (the Home Agent) using any one of these methods. 3.1.3 Redirection Removal If the normal mode for the session was to tunnel the session and Lior & Adrangi Expires August 6, 2004 [Page 7] Internet-Draft RADIUS Redirection February 2004 redirection was sent to the NAS, the RADIUS Server can send the original tunnel attributes to the NAS in a COA packet. The NAS will tear down the original tunnel and establish a connection back to the original tunnel endpoint. However, if the normal mode for the session is not to use tunneling then we have a problem because RADIUS does not have a mechanism where by it can de-tunnel. Receiving a COA message without tunnel attributes should not cause an existing tunnel to be collapsed. In order to de-tunnel the session, the RADIUS server has to send the NAS a COA message requesting it to perform a re-Authorization. The RADIUS server will send an Access-Accept packet without the tunneling information. Upon receiving the corresponding Access-Accept packet the NAS MUST apply the new authorization attributes. If these do not contain tunnel attributes, then the NAS MUST tear down the tunnel. 3.2 Layer-3 Redirection This document proposes two methods to convery redirection rules at layer-3. One is by using a Redirection-Id(TBD) attribute, the other to use Redirection-Rule(TBD) attribute. The message flows is the same regardless of which attribute is used. However, in order to use the Redirection-Id(TBD) attribute the RADIUS server and the NAS MUST have common knowledge as to the available Redirection Rules. When the administrative domains are not the same this could be a problem and hence the use of Redirection-Id(TBD) is not roaming friendly. Layer-3 Redirection may require the use of blocking. If only some of the flows are redirected then the other flows will have to be blocked. In this case, the RADIUS server MUST communicate to the NAS the blocking rules. Blocking rules can be conveyed to the NAS using either Filter-Id(11) or NAS-Filter-Rule(TBD) attribute. These attributes will be carried along side the redirection attributes. 3.2.1 Service Initiation If redirection is required during service initiation then the RADIUS server will send the redirection attributes and optionally the blocking attributes in the Access-Accept. The NAS will then start the service as usual with the traffic redirect and blocked as per the received redirection and blocking attributes. If the NAS receives a Redirection-Id(TBD) attribute and or a Filter-Id(11) attribute that it does not recognize, the NAS should interpret the Access-Accept message as an Access-Reject message. 3.2.2 Mid-session Layer-3 Redirection Lior & Adrangi Expires August 6, 2004 [Page 8] Internet-Draft RADIUS Redirection February 2004 If Layer-3 redirection is required to be applied to a service that has already been started then the RADIUS server can push the redirection attributes and optionally the filter attributes to the NAS using a COA packets. The NAS will then commence to apply the redirecting rules and/or the filter rules. If the NAS receives a COA message that contains a Redirection-Id(TBD) and or a Filter-Id(11) that it does not recognize it MUST generate a COA-NAK packet with ERROR-CAUSE(101) set to "Invalid Request"(404). Alternatively, the RADIUS server can request that the NAS re-authorize the session using the procedures defined in RFC3576 [8]. The RADIUS server responds with an Access-Accept message (with Service-Type(6) set to "Authorize Only" that will contain the redirection and optionally filtering attributes. If the NAS receives an Access-Accept message that contains a Redirection-Id(TBD) and or a Filter-Id(11) that it doesn't recognize it MUST treat the Access-Accept as an Access-Reject and terminate the session immediately generating an Accounting-Request(Stop) packet. 3.2.3 Layer-3 Redirection Removal The RADIUS server can turn redirection off mid-session in two ways. It can push a new redirection attributes to the NAS using a COA packet; or it can send the NAS a COA packet requesting it to re-authorize. If the NAS receives a Redirection-Id in the COA packet that it does not recognize then the NAS MUST respond with a COA-NAK with Error-Cause(101) set to "Invalid Request"(404). If the NAS receives an Access-Accept message sent in response to its Authorize-Only Access-Request, that contains an unrecognizable Redirection-Id(TBD), then the NAS MUST treat the Access-Accept as an Access-Reject and terminate the session immediately. 3.3 Application Redirection The call flow associated with performing redirection at the application layer is very similar with the call flow associated with redirection done at the IP layer. What is different here is the number of different possible applications that must be considered. Fortunately, the most common application (and the one that we will consider here) is HTTP based applications, or browser based application. The redirection attributes described above are used to convey the redirection rules to use for Application Redirection. The Lior & Adrangi Expires August 6, 2004 [Page 9] Internet-Draft RADIUS Redirection February 2004 Redirection-Rule(TBD) attribute supports the encoding of a redirection URL to apply when a rule is matched. 3.3.1 Service Initiation As with previous call flows. The RADIUS MAY send a Redirection-Id(TBD) or Redirection-Rule(TBD) attributes to the NAS in the Access-Accept message. If the NAS receives a Redirection-Id(TBD) attribute which it does not understand then the NAS MUST treat the Access-Accept as an Access-Reject packet. 3.3.2 Mid-session Application Redirection Mid-session initiated Application Based Redirection is similar to the call flows of IP based redirection method discussed above. 3.3.3 Application Redirection Removal Redirection removal based on Application Based Redirection is similar to the call flows of IP based redirection method discussed above. 3.4 Accounting Every time a session is redirected and every time the redirection is reverted back a new session is created and the old one is terminated. Therefore the NAS MUST generate and Accounting-Request(Stop) for the old session and an Accounting-Request(Start) for the new session. As described above, when the NAS receives redirection attributes that it does not understand in an Access-Accept packet it MUST terminate the session and MUST generate an Accounting-Request(Stop) packet. Note, in the case where it receives redirection/filtering attributes in a COA packet that it does not understand, then it responds with a COA-NAK packet and does not terminate the session and therefore it MUST NOT generate an Accounting-Request(Stop) packet. Lior & Adrangi Expires August 6, 2004 [Page 10] Internet-Draft RADIUS Redirection February 2004 4. Attributes This specification introduces three new RADIUS attributes. NAS-Filter-Rule(TBD) Redirection-ID(TBD) Redirection-Rule(TBD) 4.1 NAS-Filter-Rule Attribute The NAS-Filter-Rule(TBD) matches its Diameter counter part (that is its of type IPFilterRule), and provides filter rules that need to be configured on the NAS for the user. One or more such AVPs MAY be present in an Access-Accept packet or Change-of-Authorization packet. NAS-Filter-Rule(TBD) can be used to filter packets based on the following information that is associated with it: Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) TCP flags IP fragment flag IP options ICMP types Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny. +---------------------------------------------------------------+ | 1 2 3 | |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| +---------------+---------------+-------------------------------+ | Type (TBD) | Length | Text | +---------------+---------------+-------------------------------+ Lior & Adrangi Expires August 6, 2004 [Page 11] Internet-Draft RADIUS Redirection February 2004 | Text +---------------+---------------+---------------+---------------+ Type TBD for NAS-Filter-Rule. Length >= 3 Text The text conforms to the following specification (taken from Diameter IPFilterRule Type): NAS-Filter-Rule MUST follow the format: action dir proto from src to dst [options] action permit - Allow packets that match the rule. deny - Drop packets that match the rule. dir "in" is from the terminal, "out" is to the terminal. proto An IP protocol specified by number. The "ip" keyword means any protocol will match. src and dst
[ports] The
may be specified as: ipno An IPv4 or IPv6 number in dotted- quad or canonical IPv6 form. Only this exact IP number will match the rule. ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask. For a match to occur, the same IP version MUST be present in the packet that was used in describing the IP address. To test for a particular IP version, the bits part can be set to zero. The keyword "any" is 0.0.0.0/0 or the IPv6 Lior & Adrangi Expires August 6, 2004 [Page 12] Internet-Draft RADIUS Redirection February 2004 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. For IPv4, a typical first rule is often "deny in ip! assigned" The sense of the match can be inverted by preceding an address with the not modifier (!), causing all other addresses to be matched instead. This does not affect the selection of port numbers. With the TCP, UDP and SCTP protocols, optional ports may be specified as: {port/port-port}[,ports[,...]] The '-' notation specifies a range of ports (including boundaries). Fragmented packets that have a non-zero offset (i.e., not the first fragment) will never match a rule that has one or more port specifications. See the frag option for details on matching fragmented packets. options: frag Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications. ipoptions spec Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route) and ts (timestamp). The absence of a particular option may be denoted with a '!'. tcpoptions spec Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are: mss (maximum segment size), window (tcp window Lior & Adrangi Expires August 6, 2004 [Page 13] Internet-Draft RADIUS Redirection February 2004 advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a '!'. established TCP packets only. Match packets that have the RST or ACK bits set. setup TCP packets only. Match packets that have the SYN bit set but no ACK bit. tcpflags spec TCP packets only. Match if the TCP header contains the comma separated list of flags specified in spec. The supported TCP flags are: fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a '!'. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero offset. See the frag option for details on matching fragmented packets. icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. Both the numeric values and the symbolic values listed below can be used. The supported ICMP types are: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18) There is one kind of packet that the access device MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls. A NAS that is unable to interpret or apply a deny rule MUST terminate the session. A NAS that is unable to interpret or apply a permit rule Lior & Adrangi Expires August 6, 2004 [Page 14] Internet-Draft RADIUS Redirection February 2004 MAY apply a more restrictive rule. A NAS MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure. The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations. 4.2 Redirection-Id The Redirection-Id(TBD) attribute indicates the name of the redirection list to apply to this session. Zero or more Redirection-Id attributes MAY be sent in an Access-Accept packet or an COA packet. Identifying a redirection list by name allows the redirection to be used on different NASes without regard to redirection implementation details. On the other hand, using Redirection-Id is not roaming friendly. If the NAS does not recognize the Redirection-Id(TBD) then it MUST reject the request. +---------------------------------------------------------------+ | 1 2 3 | |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| +---------------+---------------+-------------------------------+ | Type TBD | Length | Text | +---------------+---------------+-------------------------------+ | Text +---------------+---------------+---------------+---------------+ Type TBD for Redirection-Id. Length >= 3 Text: The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters. 4.3 Redirection-Rule The Redirection-Rule(TBD) is very similar to the NAS-Filter-Rule and its Diameter counter part (that is its of type IPFilterRule), and provides redirection rules that need to be configured on the NAS for the user. One or more such attribute MAY be present in an Lior & Adrangi Expires August 6, 2004 [Page 15] Internet-Draft RADIUS Redirection February 2004 Access-Accept packet or Change-of-Authorization packet. Redirection-Rule(TBD) can be used to redirect IP packets based on the following information that is associated with it: Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) TCP flags IP fragment flag IP options ICMP types Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny. +---------------------------------------------------------------+ | 1 2 3 | |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| +---------------+---------------+-------------------------------+ | Type (TBD) | Length | Text | +---------------+---------------+-------------------------------+ | Text +---------------+---------------+---------------+---------------+ Type TBD for Redirection-Rule. Length >= 3 Text The text conforms to the following specification (taken from Diameter IPFilterRule Type) and modified to introduce redirection: Redirect-Filter-Rule MUST follow the format: action [ redir | url] dir proto from src to dst [options] Lior & Adrangi Expires August 6, 2004 [Page 16] Internet-Draft RADIUS Redirection February 2004 action: redirect - redirect packets that match the rule to either the specified redir ip address or the specified url. redirectoff - turn the matching redirection rule of. The matching redirection rule has to match exactly in every parameter. dir "in" is from the terminal, "out" is to the terminal. proto An IP protocol specified by number. The "ip" keyword means any protocol will match. redir, src and dst
[ports] The
may be specified as: ipno An IPv4 or IPv6 number in dotted- quad or canonical IPv6 form. Only this exact IP number will match the rule. ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask. For a match to occur, the same IP version MUST be present in the packet that was used in describing the IP address. To test for a particular IP version, the bits part can be set to zero. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. For IPv4, a typical first rule is often "deny in ip! assigned" The sense of the match can be inverted by preceding an address with the not modifier (!), causing all other addresses to be matched instead. This does not affect the selection of port numbers. With the TCP, UDP and SCTP protocols, optional ports may be specified as: Lior & Adrangi Expires August 6, 2004 [Page 17] Internet-Draft RADIUS Redirection February 2004 {port/port-port}[,ports[,...]] The '-' notation specifies a range of ports (including boundaries). Fragmented packets that have a non-zero offset (i.e., not the first fragment) will never match a rule that has one or more port specifications. See the frag option for details on matching fragmented packets. options: frag Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications. ipoptions spec Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route) and ts (timestamp). The absence of a particular option may be denoted with a '!'. tcpoptions spec Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are: mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a '!'. established TCP packets only. Match packets that have the RST or ACK bits set. setup TCP packets only. Match packets that have the SYN bit set but no ACK bit. tcpflags spec TCP packets only. Match if the TCP header contains the comma separated list of flags Lior & Adrangi Expires August 6, 2004 [Page 18] Internet-Draft RADIUS Redirection February 2004 specified in spec. The supported TCP flags are: fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a '!'. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero offset. See the frag option for details on matching fragmented packets. icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. Both the numeric values and the symbolic values listed below can be used. The supported ICMP types are: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18) An NAS that is unable to interpret or apply a deny rule MUST terminate the session. A NAS that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. A NAS MAY apply deny rules of its own before the supplied rules, for example to protect the NAS owner's infrastructure. The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations. Lior & Adrangi Expires August 6, 2004 [Page 19] Internet-Draft RADIUS Redirection February 2004 5. Table of Attributes The following tables provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Access packets: Request Accept Reject Challenge # Attribute 0 0+ 0 0 TBD NAS-Filter-Rule 0 0+ 0 0 TBD Redirection-Id 0 0+ 0 0 TBD Redirection-Rule Change-of-Authorization packet: Request ACK NAK # Attribute 0+ 0 0 TBD NAS-Filter-Rule [note 1] 0+ 0 0 TBD Redirection-Id [note 1] 0+ 0 0 TBD Redirection-Rule[note 1] [note 1] When included within a CoA-Request, these attributes represent an authorization change request. When one of these attributes is omitted from a CoA-Request, the NAS assumes that the attribute value is to remain unchanged. Attributes included in a CoA-Request replace all existing value(s) of the same attribute(s). Lior & Adrangi Expires August 6, 2004 [Page 20] Internet-Draft RADIUS Redirection February 2004 6. Security Considerations TBD Lior & Adrangi Expires August 6, 2004 [Page 21] Internet-Draft RADIUS Redirection February 2004 7. IANA Considerations This document uses the RADIUS [RFC2865] namespace, see . There are three updates for the section: RADIUS Packet Type Codes. These Packet Types are allocated in [RADIANA]: TBD - NAS-Filter-Rule TBD - Redirection-Id TBD - Redirection-Rule Lior & Adrangi Expires August 6, 2004 [Page 22] Internet-Draft RADIUS Redirection February 2004 8. Open Issues Lior & Adrangi Expires August 6, 2004 [Page 23] Internet-Draft RADIUS Redirection February 2004 Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [5] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [6] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003. Lior & Adrangi Expires August 6, 2004 [Page 24] Internet-Draft RADIUS Redirection February 2004 Informative References [7] Calhoun, P., "Diameter Network Access Server Application". [8] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Authors' Addresses Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Suite 100 Ottawa, Ontario K2K 3J1 Canada Phone: (613) 591-6655 EMail: avi@bridgewatersystems.com URI: TCP://.bridgewatersystems.com/ Farid Adrangi Intel Corporation 2111 North East 25th Hillsboro, Oregon 97124 United States Phone: (503) 712-1791 EMail: farid.adrangi@intel.com Lior & Adrangi Expires August 6, 2004 [Page 25] Internet-Draft RADIUS Redirection February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Lior & Adrangi Expires August 6, 2004 [Page 26] Internet-Draft RADIUS Redirection February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lior & Adrangi Expires August 6, 2004 [Page 27]