Network Working Group M. Chiba Request for Comments: 3576 G. Dommety Category: Informational M. Eklund Cisco Systems, Inc. D. Mitton Circular Logic, UnLtd. B. Aboba Microsoft Corporation July 2003 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. Chiba, et al. Informational [Page 1] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 Table of Contents 1.                          Introduction
The RADIUS protocol, defined in [RFC2865], does not support unsolicited messages sent from the RADIUS server to the Network Access Server (NAS). However, there are many instances in which it is desirable for changes to be made to session characteristics, without requiring the NAS to initiate the exchange. For example, it may be desirable for administrators to be able to terminate a user session in progress. Alternatively, if the user changes authorization level, this may require that authorization attributes be added/deleted from a user session. To overcome these limitations, several vendors have implemented additional RADIUS commands in order to be able to support unsolicited messages sent from the RADIUS server to the NAS. These extended commands provide support for Disconnect and Change-of-Authorization (CoA) messages. Disconnect messages cause a user session to be terminated immediately, whereas CoA messages modify session authorization attributes such as data filters.1.1. Applicability
This protocol is being recommended for publication as an Informational RFC rather than as a standards-track RFC because of problems that cannot be fixed without creating incompatibilities with deployed implementations. This includes security vulnerabilities, as well as semantic ambiguities resulting from the design of the Change-of-Authorization (CoA) commands. While fixes are recommended, they cannot be made mandatory since this would be incompatible with existing implementations. Existing implementations of this protocol do not support authorization checks, so that an ISP sharing a NAS with another ISP could disconnect or change authorizations for another ISP's users. In order to remedy this problem, a "Reverse Path Forwarding" check is recommended. See Section 5.1. for details. Existing implementations utilize per-packet authentication and integrity protection algorithms with known weaknesses [MD5Attack]. To provide stronger per-packet authentication and integrity protection, the use of IPsec is recommended. See Section 5.3. for details. Chiba, et al. Informational [Page 3] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 Existing implementations lack replay protection. In order to support replay detection, it is recommended that the Event-Timestamp Attribute be added to all messages in situations where IPsec replay protection is not employed. Implementations should be configurable to silently discard messages lacking the Event-Timestamp Attribute. See Section 5.4. for details. The approach taken with CoA commands in existing implementations results in a semantic ambiguity. Existing implementations of the CoA-Request identify the affected session, as well as supply the authorization changes. Since RADIUS Attributes included within existing implementations of the CoA-Request can be used for session identification or authorization change, it may not be clear which function a given attribute is serving. The problem does not exist within [Diameter], in which authorization change is requested by a command using Attribute Value Pairs (AVPs) solely for identification, resulting in initiation of a standard Request/Response sequence where authorization changes are supplied. As a result, in no command can Diameter AVPs have multiple potential meanings. Due to differences in handling change-of-authorization requests in RADIUS and Diameter, it may be difficult or impossible for a Diameter/RADIUS gateway to successfully translate existing implementations of this specification to equivalent messages in Diameter. For example, a Diameter command changing any attribute used for identification within existing CoA-Request implementations cannot be translated, since such an authorization change is impossible to carry out in existing implementations. Similarly, translation between existing implementations of Disconnect-Request or CoA-Request messages and Diameter is tricky because a Disconnect- Request or CoA-Request message will need to be translated to multiple Diameter commands. To simplify translation between RADIUS and Diameter, a Service-Type Attribute with value "Authorize Only" can (optionally) be included within a Disconnect-Request or CoA-Request. Such a Request contains only identification attributes. A NAS supporting the "Authorize Only" Service-Type within a Disconnect-Request or CoA-Request responds with a NAK containing a Service-Type Attribute with value "Authorize Only" and an Error-Cause Attribute with value "Request Initiated". The NAS will then send an Access-Request containing a Service-Type Attribute with a value of "Authorize Only". This usage sequence is akin to what occurs in Diameter and so is more easily translated by a Diameter/RADIUS gateway. Chiba, et al. Informational [Page 4] RFC 3576 Dynamic Authorization Extensions to RADIUS July 20031.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].1.3. Terminology
This document frequently uses the following terms: Network Access Server (NAS): The device providing access to the network. service: The NAS provides a service to the user, such as IEEE 802 or PPP. session: Each service provided by the NAS to a user constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the session defined as the point where service is ended. A user may have multiple sessions in parallel or series if the NAS supports that. silently discard: This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.2. Overview
This section describes the most commonly implemented features of Disconnect and Change-of-Authorization messages.2.1. Disconnect Messages (DM)
A Disconnect-Request packet is sent by the RADIUS server in order to terminate a user session on a NAS and discard all associated session context. The Disconnect-Request packet is sent to UDP port 3799, and identifies the NAS as well as the user session to be terminated by inclusion of the identification attributes described in Section 3. Chiba, et al. Informational [Page 5] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 +----------+ Disconnect-Request +----------+ | | <-------------------- | | | NAS | | RADIUS | | | Disconnect-Response | Server | | | ---------------------> | | +----------+ +----------+ The NAS responds to a Disconnect-Request packet sent by a RADIUS server with a Disconnect-ACK if all associated session context is discarded and the user session is no longer connected, or a Disconnect-NAK, if the NAS was unable to disconnect the session and discard all associated session context. A NAS MUST respond to a Disconnect-Request including a Service-Type Attribute with value "Authorize Only" with a Disconnect-NAK; a Disconnect-ACK MUST NOT be sent. A NAS MUST respond to a Disconnect-Request including a Service-Type Attribute with an unsupported value with a Disconnect- NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be included. A Disconnect-ACK MAY contain the Attribute Acct-Terminate-Cause (49) [RFC2866] with the value set to 6 for Admin-Reset.2.2. Change-of-Authorization Messages (CoA)
CoA-Request packets contain information for dynamically changing session authorizations. This is typically used to change data filters. The data filters can be of either the ingress or egress kind, and are sent in addition to the identification attributes as described in section 3. The port used, and packet format (described in Section 2.3.), are the same as that for Disconnect-Request Messages. The following attribute MAY be sent in a CoA-Request: Filter-ID (11) - Indicates the name of a data filter list to be applied for the session that the identification attributes map to. +----------+ CoA-Request +----------+ | | <-------------------- | | | NAS | | RADIUS | | | CoA-Response | Server | | | ---------------------> | | +----------+ +----------+ The NAS responds to a CoA-Request sent by a RADIUS server with a CoA-ACK if the NAS is able to successfully change the authorizations for the user session, or a CoA-NAK if the Request is unsuccessful. A NAS MUST respond to a CoA-Request including a Service-Type Attribute Chiba, et al. Informational [Page 6] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be sent. A NAS MUST respond to a CoA-Request including a Service-Type Attribute with an unsupported value with a CoA-NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be included.2.3. Packet Format
For either Disconnect-Request or CoA-Request messages UDP port 3799 is used as the destination port. For responses, the source and destination ports are reversed. Exactly one RADIUS packet is encapsulated in the UDP Data field. A summary of the data format is shown below. The fields are transmitted from left to right. The packet format consists of the fields: Code, Identifier, Length, Authenticator, and Attributes in Type:Length:Value (TLV) format. All fields hold the same meaning as those described in RADIUS [RFC2865]. The Authenticator field MUST be calculated in the same way as is specified for an Accounting-Request in [RFC2866]. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code The Code field is one octet, and identifies the type of RADIUS packet. Packets received with an invalid Code field MUST be silently discarded. RADIUS codes (decimal) for this extension are assigned as follows: 40 - Disconnect-Request [RFC2882] 41 - Disconnect-ACK [RFC2882] 42 - Disconnect-NAK [RFC2882] 43 - CoA-Request [RFC2882] 44 - CoA-ACK [RFC2882] 45 - CoA-NAK [RFC2882] Chiba, et al. Informational [Page 7] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 Identifier The Identifier field is one octet, and aids in matching requests and replies. The RADIUS client can detect a duplicate request if it has the same server source IP address and source UDP port and Identifier within a short span of time. Unlike RADIUS as defined in [RFC2865], the responsibility for retransmission of Disconnect-Request and CoA-Request messages lies with the RADIUS server. If after sending these messages, the RADIUS server does not receive a response, it will retransmit. The Identifier field MUST be changed whenever the content of the Attributes field changes, or whenever a valid reply has been received for a previous request. For retransmissions where the contents are identical, the Identifier MUST remain unchanged. If the RADIUS server is retransmitting a Disconnect-Request or CoA-Request to the same client as before, and the Attributes have not changed, the same Request Authenticator, Identifier and source port MUST be used. If any Attributes have changed, a new Authenticator and Identifier MUST be used. Note that if the Event-Timestamp Attribute is included, it will be updated when the packet is retransmitted, changing the content of the Attributes field and requiring a new Identifier and Request Authenticator. If the Request to a primary proxy fails, a secondary proxy must be queried, if available. Issues relating to failover algorithms are described in [AAATransport]. Since this represents a new request, a new Request Authenticator and Identifier MUST be used. However, where the RADIUS server is sending directly to the client, failover typically does not make sense, since Disconnect or CoA messages need to be delivered to the NAS where the session resides. Length The Length field is two octets. It indicates the length of the packet including the Code, Identifier, Length, Authenticator and Attribute fields. Octets outside the range of the Length field MUST be treated as padding and ignored on reception. If the packet is shorter than the Length field indicates, it MUST be silently discarded. The minimum length is 20 and the maximum length is 4096. Chiba, et al. Informational [Page 8] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 Authenticator The Authenticator field is sixteen (16) octets. The most significant octet is transmitted first. This value is used to authenticate the messages between the RADIUS server and client. Request Authenticator In Request packets, the Authenticator value is a 16 octet MD5 [RFC1321] checksum, called the Request Authenticator. The Request Authenticator is calculated the same way as for an Accounting- Request, specified in [RFC2866]. Note that the Request Authenticator of a Disconnect or CoA-Request cannot be done the same way as the Request Authenticator of a RADIUS Access-Request, because there is no User-Password Attribute in a Disconnect-Request or CoA-Request. Response Authenticator The Authenticator field in a Response packet (e.g. Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response Authenticator, and contains a one-way MD5 hash calculated over a stream of octets consisting of the Code, Identifier, Length, the Request Authenticator field from the packet being replied to, and the response Attributes if any, followed by the shared secret. The resulting 16 octet MD5 hash value is stored in the Authenticator field of the Response packet. Administrative note: As noted in [RFC2865] Section 3, the secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well-chosen password. RADIUS clients MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that requests can be proxied. Attributes In Disconnect and CoA-Request messages, all Attributes are treated as mandatory. A NAS MUST respond to a CoA-Request containing one or more unsupported Attributes or Attribute values with a CoA-NAK; a Disconnect-Request containing one or more unsupported Attributes or Attribute values MUST be answered with a Disconnect-NAK. State changes resulting from a CoA-Request MUST be atomic: if the Request is successful, a CoA-ACK is sent, and all requested authorization changes MUST be made. If the CoA-Request is unsuccessful, a CoA-NAK MUST be sent, and the requested Chiba, et al. Informational [Page 9] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 authorization changes MUST NOT be made. Similarly, a state change MUST NOT occur as a result of an unsuccessful Disconnect-Request; here a Disconnect-NAK MUST be sent. Since within this specification attributes may be used for identification, authorization or other purposes, even if a NAS implements an attribute for use with RADIUS authentication and accounting, it may not support inclusion of that attribute within Disconnect-Request or CoA-Request messages, given the difference in attribute semantics. This is true even for attributes specified within [RFC2865], [RFC2868], [RFC2869] or [RFC3162] as allowable within Access-Accept messages. As a result, attributes beyond those specified in Section 3.2. SHOULD NOT be included within Disconnect or CoA messages since this could produce unpredictable results. When using a forwarding proxy, the proxy must be able to alter the packet as it passes through in each direction. When the proxy forwards a Disconnect or CoA-Request, it MAY add a Proxy-State Attribute, and when the proxy forwards a response, it MUST remove its Proxy-State Attribute if it added one. Proxy-State is always added or removed after any other Proxy-States, but no other assumptions regarding its location within the list of Attributes can be made. Since Disconnect and CoA responses are authenticated on the entire packet contents, the stripping of the Proxy-State Attribute invalidates the integrity check - so the proxy needs to recompute it. A forwarding proxy MUST NOT modify existing Proxy- State, State, or Class Attributes present in the packet. If there are any Proxy-State Attributes in a Disconnect-Request or CoA-Request received from the server, the forwarding proxy MUST include those Proxy-State Attributes in its response to the server. The forwarding proxy MAY include the Proxy-State Attributes in the Disconnect-Request or CoA-Request when it forwards the request, or it MAY omit them in the forwarded request. If the forwarding proxy omits the Proxy-State Attributes in the request, it MUST attach them to the response before sending it to the server. Chiba, et al. Informational [Page 10] RFC 3576 Dynamic Authorization Extensions to RADIUS July 20033. Attributes
In Disconnect-Request and CoA-Request packets, certain attributes are used to uniquely identify the NAS as well as a user session on the NAS. All NAS identification attributes included in a Request message MUST match in order for a Disconnect-Request or CoA-Request to be successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent. For session identification attributes, the User-Name and Acct- Session-Id Attributes, if included, MUST match in order for a Disconnect-Request or CoA-Request to be successful; other session identification attributes SHOULD match. Where a mismatch of session identification attributes is detected, a Disconnect-NAK or CoA-NAK SHOULD be sent. The ability to use NAS or session identification attributes to map to unique/multiple sessions is beyond the scope of this document. Identification attributes include NAS and session identification attributes, as described below. NAS identification attributes Attribute # Reference Description --------- --- --------- ----------- NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS. NAS-Identifier 32 [RFC2865] String identifying the NAS. NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS. Chiba, et al. Informational [Page 11] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 Session identification attributes Attribute # Reference Description --------- --- --------- ----------- User-Name 1 [RFC2865] The name of the user associated with the session. NAS-Port 5 [RFC2865] The port on which the session is terminated. Framed-IP-Address 8 [RFC2865] The IPv4 address associated with the session. Called-Station-Id 30 [RFC2865] The link address to which the session is connected. Calling-Station-Id 31 [RFC2865] The link address from which the session is connected. Acct-Session-Id 44 [RFC2866] The identifier uniquely identifying the session on the NAS. Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely identifying related sessions. NAS-Port-Type 61 [RFC2865] The type of port used. NAS-Port-Id 87 [RFC2869] String identifying the port where the session is. Originating-Line-Info 94 [NASREQ] Provides information on the characteristics of the line from which a session originated. Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier associated with the session; always sent with Framed-IPv6-Prefix. Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated with the session, always sent with Framed-Interface-Id. To address security concerns described in Section 5.1., the User-Name Attribute SHOULD be present in Disconnect-Request or CoA-Request packets; one or more additional session identification attributes MAY also be present. To address security concerns described in Section 5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present in Disconnect-Request or CoA-Request packets; the NAS-Identifier Attribute MAY be present in addition. If one or more authorization changes specified in a CoA-Request cannot be carried out, or if one or more attributes or attribute- values is unsupported, a CoA-NAK MUST be sent. Similarly, if there are one or more unsupported attributes or attribute values in a Disconnect-Request, a Disconnect-NAK MUST be sent. Chiba, et al. Informational [Page 12] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 Where a Service-Type Attribute with value "Authorize Only" is included within a CoA-Request or Disconnect-Request, attributes representing an authorization change MUST NOT be included; only identification attributes are permitted. If attributes other than NAS or session identification attributes are included in such a CoA- Request, implementations MUST send a CoA-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included. Similarly, if attributes other than NAS or session identification attributes are included in such a Disconnect-Request, implementations MUST send a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included.3.1. Error-Cause
Description It is possible that the NAS cannot honor Disconnect-Request or CoA-Request messages for some reason. The Error-Cause Attribute provides more detail on the cause of the problem. It MAY be included within Disconnect-ACK, Disconnect-NAK and CoA-NAK messages. A summary of the Error-Cause Attribute format is shown below. The fields are transmitted from left to right. 0 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 | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 101 for Error-Cause Length 6 Value The Value field is four octets, containing an integer specifying the cause of the error. Values 0-199 and 300-399 are reserved. Values 200-299 represent successful completion, so that these values may only be sent within Disconnect-ACK or CoA-ACK message and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values Chiba, et al. Informational [Page 13] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 400-499 represent fatal errors committed by the RADIUS server, so that they MAY be sent within CoA-NAK or Disconnect-NAK messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. Values 500-599 represent fatal errors occurring on a NAS or RADIUS proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. Error-Cause values SHOULD be logged by the RADIUS server. Error-Code values (expressed in decimal) include: # Value --- ----- 201 Residual Session Context Removed 202 Invalid EAP Packet (Ignored) 401 Unsupported Attribute 402 Missing Attribute 403 NAS Identification Mismatch 404 Invalid Request 405 Unsupported Service 406 Unsupported Extension 501 Administratively Prohibited 502 Request Not Routable (Proxy) 503 Session Context Not Found 504 Session Context Not Removable 505 Other Proxy Processing Error 506 Resources Unavailable 507 Request Initiated "Residual Session Context Removed" is sent in response to a Disconnect-Request if the user session is no longer active, but residual session context was found and successfully removed. This value is only sent within a Disconnect-ACK and MUST NOT be sent within a CoA-ACK, Disconnect-NAK or CoA-NAK. "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be sent by implementations of this specification. "Unsupported Attribute" is a fatal error sent if a Request contains an attribute (such as a Vendor-Specific or EAP-Message Attribute) that is not supported. "Missing Attribute" is a fatal error sent if critical attributes (such as NAS or session identification attributes) are missing from a Request. "NAS Identification Mismatch" is a fatal error sent if one or more NAS identification attributes (see Section 3.) do not match the identity of the NAS receiving the Request. Chiba, et al. Informational [Page 14] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 "Invalid Request" is a fatal error sent if some other aspect of the Request is invalid, such as if one or more attributes (such as EAP- Message Attribute(s)) are not formatted properly. "Unsupported Service" is a fatal error sent if a Service-Type Attribute included with the Request is sent with an invalid or unsupported value. "Unsupported Extension" is a fatal error sent due to lack of support for an extension such as Disconnect and/or CoA messages. This will typically be sent by a proxy receiving an ICMP port unreachable message after attempting to forward a Request to the NAS. "Administratively Prohibited" is a fatal error sent if the NAS is configured to prohibit honoring of Request messages for the specified session. "Request Not Routable" is a fatal error which MAY be sent by a RADIUS proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS proxy was unable to determine how to route the Request to the NAS. For example, this can occur if the required entries are not present in the proxy's realm routing table. "Session Context Not Found" is a fatal error sent if the session context identified in the Request does not exist on the NAS. "Session Context Not Removable" is a fatal error sent in response to a Disconnect-Request if the NAS was able to locate the session context, but could not remove it for some reason. It MUST NOT be sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a Disconnect-NAK. "Other Proxy Processing Error" is a fatal error sent in response to a Request that could not be processed by a proxy, for reasons other than routing. "Resources Unavailable" is a fatal error sent when a Request could not be honored due to lack of available NAS resources (memory, non- volatile storage, etc.). "Request Initiated" is a fatal error sent in response to a Request including a Service-Type Attribute with a value of "Authorize Only". It indicates that the Disconnect-Request or CoA-Request has not been honored, but that a RADIUS Access-Request including a Service-Type Attribute with value "Authorize Only" is being sent to the RADIUS server. Chiba, et al. Informational [Page 15] RFC 3576 Dynamic Authorization Extensions to RADIUS July 20033.2. Table of Attributes
The following table provides a guide to which attributes may be found in which packets, and in what quantity. Change-of-Authorization Messages Request ACK NAK # Attribute 0-1 0 0 1 User-Name [Note 1] 0-1 0 0 4 NAS-IP-Address [Note 1] 0-1 0 0 5 NAS-Port [Note 1] 0-1 0 0-1 6 Service-Type [Note 6] 0-1 0 0 7 Framed-Protocol [Note 3] 0-1 0 0 8 Framed-IP-Address [Note 1] 0-1 0 0 9 Framed-IP-Netmask [Note 3] 0-1 0 0 10 Framed-Routing [Note 3] 0+ 0 0 11 Filter-ID [Note 3] 0-1 0 0 12 Framed-MTU [Note 3] 0+ 0 0 13 Framed-Compression [Note 3] 0+ 0 0 14 Login-IP-Host [Note 3] 0-1 0 0 15 Login-Service [Note 3] 0-1 0 0 16 Login-TCP-Port [Note 3] 0+ 0 0 18 Reply-Message [Note 2] 0-1 0 0 19 Callback-Number [Note 3] 0-1 0 0 20 Callback-Id [Note 3] 0+ 0 0 22 Framed-Route [Note 3] 0-1 0 0 23 Framed-IPX-Network [Note 3] 0-1 0-1 0-1 24 State [Note 7] 0+ 0 0 25 Class [Note 3] 0+ 0 0 26 Vendor-Specific [Note 3] 0-1 0 0 27 Session-Timeout [Note 3] 0-1 0 0 28 Idle-Timeout [Note 3] 0-1 0 0 29 Termination-Action [Note 3] 0-1 0 0 30 Called-Station-Id [Note 1] 0-1 0 0 31 Calling-Station-Id [Note 1] 0-1 0 0 32 NAS-Identifier [Note 1] 0+ 0+ 0+ 33 Proxy-State 0-1 0 0 34 Login-LAT-Service [Note 3] 0-1 0 0 35 Login-LAT-Node [Note 3] 0-1 0 0 36 Login-LAT-Group [Note 3] 0-1 0 0 37 Framed-AppleTalk-Link [Note 3] 0+ 0 0 38 Framed-AppleTalk-Network [Note 3] 0-1 0 0 39 Framed-AppleTalk-Zone [Note 3] 0-1 0 0 44 Acct-Session-Id [Note 1] 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 0-1 0-1 0-1 55 Event-Timestamp 0-1 0 0 61 NAS-Port-Type [Note 1] Request ACK NAK # Attribute Chiba, et al. Informational [Page 16] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 Request ACK NAK # Attribute 0-1 0 0 62 Port-Limit [Note 3] 0-1 0 0 63 Login-LAT-Port [Note 3] 0+ 0 0 64 Tunnel-Type [Note 5] 0+ 0 0 65 Tunnel-Medium-Type [Note 5] 0+ 0 0 66 Tunnel-Client-Endpoint [Note 5] 0+ 0 0 67 Tunnel-Server-Endpoint [Note 5] 0+ 0 0 69 Tunnel-Password [Note 5] 0-1 0 0 71 ARAP-Features [Note 3] 0-1 0 0 72 ARAP-Zone-Access [Note 3] 0+ 0 0 78 Configuration-Token [Note 3] 0+ 0-1 0 79 EAP-Message [Note 2] 0-1 0-1 0-1 80 Message-Authenticator 0+ 0 0 81 Tunnel-Private-Group-ID [Note 5] 0+ 0 0 82 Tunnel-Assignment-ID [Note 5] 0+ 0 0 83 Tunnel-Preference [Note 5] 0-1 0 0 85 Acct-Interim-Interval [Note 3] 0-1 0 0 87 NAS-Port-Id [Note 1] 0-1 0 0 88 Framed-Pool [Note 3] 0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5] 0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5] 0-1 0 0 94 Originating-Line-Info [Note 1] 0-1 0 0 95 NAS-IPv6-Address [Note 1] 0-1 0 0 96 Framed-Interface-Id [Note 1] 0+ 0 0 97 Framed-IPv6-Prefix [Note 1] 0+ 0 0 98 Login-IPv6-Host [Note 3] 0+ 0 0 99 Framed-IPv6-Route [Note 3] 0-1 0 0 100 Framed-IPv6-Pool [Note 3] 0 0 0+ 101 Error-Cause Request ACK NAK # Attribute Disconnect Messages Request ACK NAK # Attribute 0-1 0 0 1 User-Name [Note 1] 0-1 0 0 4 NAS-IP-Address [Note 1] 0-1 0 0 5 NAS-Port [Note 1] 0-1 0 0-1 6 Service-Type [Note 6] 0-1 0 0 8 Framed-IP-Address [Note 1] 0+ 0 0 18 Reply-Message [Note 2] 0-1 0-1 0-1 24 State [Note 7] 0+ 0 0 25 Class [Note 4] 0+ 0 0 26 Vendor-Specific 0-1 0 0 30 Called-Station-Id [Note 1] 0-1 0 0 31 Calling-Station-Id [Note 1] 0-1 0 0 32 NAS-Identifier [Note 1] 0+ 0+ 0+ 33 Proxy-State Request ACK NAK # Attribute Chiba, et al. Informational [Page 17] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 Request ACK NAK # Attribute 0-1 0 0 44 Acct-Session-Id [Note 1] 0-1 0-1 0 49 Acct-Terminate-Cause 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] 0-1 0-1 0-1 55 Event-Timestamp 0-1 0 0 61 NAS-Port-Type [Note 1] 0+ 0-1 0 79 EAP-Message [Note 2] 0-1 0-1 0-1 80 Message-Authenticator 0-1 0 0 87 NAS-Port-Id [Note 1] 0-1 0 0 94 Originating-Line-Info [Note 1] 0-1 0 0 95 NAS-IPv6-Address [Note 1] 0-1 0 0 96 Framed-Interface-Id [Note 1] 0+ 0 0 97 Framed-IPv6-Prefix [Note 1] 0 0+ 0+ 101 Error-Cause Request ACK NAK # Attribute [Note 1] Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request messages, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g. within CoA-Request messages to request authorization changes). [Note 2] The Reply-Message Attribute is used to present a displayable message to the user. The message is only displayed as a result of a successful Disconnect-Request or CoA-Request (where a Disconnect-ACK or CoA-ACK is subsequently sent). Where EAP is used for authentication, an EAP-Message/Notification-Request Attribute is sent instead, and Disconnect-ACK or CoA-ACK messages contain an EAP- Message/Notification-Response Attribute. [Note 3] 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). [Note 4] When included within a successful Disconnect-Request (where a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be sent unmodified by the client to the accounting server in the Accounting Stop packet. If the Disconnect-Request is unsuccessful, then the Class Attribute is not processed. [Note 5] When included within a CoA-Request, these attributes represent an authorization change request. Where tunnel attribute(s) are sent within a successful CoA-Request, all existing tunnel attributes are removed and replaced by the new attribute(s). Chiba, et al. Informational [Page 18] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 [Note 6] When included within a Disconnect-Request or CoA-Request, a Service-Type Attribute with value "Authorize Only" indicates that the Request only contains NAS and session identification attributes, and that the NAS should attempt reauthorization by sending an Access- Request with a Service-Type Attribute with value "Authorize Only". This enables a usage model akin to that supported in Diameter, thus easing translation between the two protocols. Support for the Service-Type Attribute is optional within CoA-Request and Disconnect-Request messages; where it is not included, the Request message may contain both identification and authorization attributes. A NAS that does not support the Service-Type Attribute with the value "Authorize Only" within a Disconnect-Request MUST respond with a Disconnect-NAK including no Service-Type Attribute; an Error-Cause Attribute with value "Unsupported Service" MAY be included. A NAS that does not support the Service-Type Attribute with the value "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK including no Service-Type Attribute; an Error-Cause Attribute with value "Unsupported Service" MAY be included. A NAS supporting the "Authorize Only" Service-Type value within Disconnect-Request or CoA-Request messages MUST respond with a Disconnect-NAK or CoA-NAK respectively, containing a Service-Type Attribute with value "Authorize Only", and an Error-Cause Attribute with value "Request Initiated". The NAS then sends an Access-Request to the RADIUS server with a Service-Type Attribute with value "Authorize Only". This Access-Request SHOULD contain the NAS attributes from the Disconnect or CoA-Request, as well as the session attributes from the Request legal for inclusion in an Access-Request as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be included in an Access-Request that does not contain a User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. The RADIUS server should send back an Access-Accept to (re-)authorize the session or an Access-Reject to refuse to (re-)authorize it. [Note 7] The State Attribute is available to be sent by the RADIUS server to the NAS in a Disconnect-Request or CoA-Request message and MUST be sent unmodified from the NAS to the RADIUS server in a subsequent ACK or NAK message. If a Service-Type Attribute with value "Authorize Only" is included in a Disconnect-Request or CoA- Request along with a State Attribute, then the State Attribute MUST be sent unmodified from the NAS to the RADIUS server in the resulting Access-Request sent to the RADIUS server, if any. The State Attribute is also available to be sent by the RADIUS server to the NAS in a CoA-Request that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the client performs the Termination-Action by sending a new Access-Request upon termination of the current session, it MUST include the State Chiba, et al. Informational [Page 19] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 Attribute unchanged in that Access-Request. In either usage, the client MUST NOT interpret the Attribute locally. A Disconnect- Request or CoA-Request packet must have only zero or one State Attribute. Usage of the State Attribute is implementation dependent. If the RADIUS server does not recognize the State Attribute in the Access-Request, then it MUST send an Access-Reject. The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 1 Exactly one instance of this attribute MUST be present in packet.4. IANA Considerations
This document uses the RADIUS [RFC2865] namespace, see <http://www.iana.org/assignments/radius-types>. There are six updates for the section: RADIUS Packet Type Codes. These Packet Types are allocated in [RADIANA]: 40 - Disconnect-Request 41 - Disconnect-ACK 42 - Disconnect-NAK 43 - CoA-Request 44 - CoA-ACK 45 - CoA-NAK Allocation of a new Service-Type value for "Authorize Only" is requested. This document also uses the UDP [RFC768] namespace, see <http://www.iana.org/assignments/port-numbers>. The authors request a port assignment from the Registered ports range. Finally, this specification allocates the Error-Cause Attribute (101) with the following decimal values: # Value --- ----- 201 Residual Session Context Removed 202 Invalid EAP Packet (Ignored) 401 Unsupported Attribute 402 Missing Attribute 403 NAS Identification Mismatch 404 Invalid Request 405 Unsupported Service 406 Unsupported Extension 501 Administratively Prohibited 502 Request Not Routable (Proxy) Chiba, et al. Informational [Page 20] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 503 Session Context Not Found 504 Session Context Not Removable 505 Other Proxy Processing Error 506 Resources Unavailable 507 Request Initiated5. Security Considerations
5.1. Authorization Issues
Where a NAS is shared by multiple providers, it is undesirable for one provider to be able to send Disconnect-Request or CoA-Requests affecting the sessions of another provider. A NAS or RADIUS proxy MUST silently discard Disconnect-Request or CoA-Request messages from untrusted sources. By default, a RADIUS proxy SHOULD perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized RADIUS server. In addition, it SHOULD be possible to explicitly authorize additional sources of Disconnect-Request or CoA-Request packets relating to certain classes of sessions. For example, a particular source can be explicitly authorized to send CoA-Request messages relating to users within a set of realms. To perform the RPF check, the proxy uses the session identification attributes included in Disconnect-Request or CoA-Request messages, in order to determine the RADIUS server(s) to which an equivalent Access-Request could be routed. If the source address of the Disconnect-Request or CoA-Request is within this set, then the Request is forwarded; otherwise it MUST be silently discarded. Typically the proxy will extract the realm from the Network Access Identifier [RFC2486] included within the User-Name Attribute, and determine the corresponding RADIUS servers in the proxy routing tables. The RADIUS servers for that realm are then compared against the source address of the packet. Where no RADIUS proxy is present, the RPF check will need to be performed by the NAS itself. Since authorization to send a Disconnect-Request or CoA-Request is determined based on the source address and the corresponding shared secret, the NASes or proxies SHOULD configure a different shared secret for each RADIUS server. Chiba, et al. Informational [Page 21] RFC 3576 Dynamic Authorization Extensions to RADIUS July 20035.2. Impersonation
[RFC2865] Section 3 states: A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied. When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or NAS-IPv6-Address Attributes will typically not match the source address observed by the RADIUS server. Since the NAS-Identifier Attribute need not contain an FQDN, this attribute may not be resolvable to the source address observed by the RADIUS server, even when no proxy is present. As a result, the authenticity check performed by a RADIUS server or proxy does not verify the correctness of NAS identification attributes. This makes it possible for a rogue NAS to forge NAS-IP- Address, NAS-IPv6-Address or NAS-Identifier Attributes within a RADIUS Access-Request in order to impersonate another NAS. It is also possible for a rogue NAS to forge session identification attributes such as the Called-Station-Id, Calling-Station-Id, or Originating-Line-Info [NASREQ]. This could fool the RADIUS server into sending Disconnect-Request or CoA-Request messages containing forged session identification attributes to a NAS targeted by an attacker. To address these vulnerabilities RADIUS proxies SHOULD check whether NAS identification attributes (see Section 3.) match the source address of packets originating from the NAS. Where one or more attributes do not match, Disconnect-Request or CoA-Request messages SHOULD be silently discarded. Such a check may not always be possible. Since the NAS-Identifier Attribute need not correspond to an FQDN, it may not be resolvable to an IP address to be matched against the source address. Also, where a NAT exists between the RADIUS client and proxy, checking the NAS- IP-Address or NAS-IPv6-Address Attributes may not be feasible.5.3. IPsec Usage Guidelines
In addition to security vulnerabilities unique to Disconnect or CoA messages, the protocol exchanges described in this document are susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is RECOMMENDED that IPsec be employed to afford better security. Chiba, et al. Informational [Page 22] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 Implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with a non-null transform SHOULD be supported, and IPsec ESP with a non-null encryption transform and authentication support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management. Within RADIUS [RFC2865], a shared secret is used for hiding Attributes such as User-Password, as well as used in computation of the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used in computation of both the Request Authenticator and the Response Authenticator. Since in RADIUS a shared secret is used to provide confidentiality as well as integrity protection and authentication, only use of IPsec ESP with a non-null transform can provide security services sufficient to substitute for RADIUS application-layer security. Therefore, where IPsec AH or ESP null is used, it will typically still be necessary to configure a RADIUS shared secret. Where RADIUS is run over IPsec ESP with a non-null transform, the secret shared between the NAS and the RADIUS server MAY NOT be configured. In this case, a shared secret of zero length MUST be assumed. However, a RADIUS server that cannot know whether incoming traffic is IPsec-protected MUST be configured with a non-null RADIUS shared secret. When IPsec ESP is used with RADIUS, per-packet authentication, integrity and replay protection MUST be used. 3DES-CBC MUST be supported as an encryption transform and AES-CBC SHOULD be supported. AES-CBC SHOULD be offered as a preferred encryption transform if supported. HMAC-SHA1-96 MUST be supported as an authentication transform. DES-CBC SHOULD NOT be used as the encryption transform. A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate IPsec, from me to any destination port UDP 1812". This IPsec policy causes an IPsec SA to be set up by the RADIUS client prior to sending RADIUS traffic. If some RADIUS servers contacted by the client do not support IPsec, then a more granular policy will be required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812." For a client implementing this specification, the policy would be "Accept IPsec, from any to me, destination port UDP 3799". This causes the RADIUS client to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS servers connecting to an IPsec-enabled RADIUS client, since some RADIUS servers may not support IPsec. Chiba, et al. Informational [Page 23] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept IPsec, from any to me, destination port 1812". This causes the RADIUS server to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS clients connecting to an IPsec-enabled RADIUS server, since some RADIUS clients may not support IPsec. For servers implementing this specification, the policy would be "Initiate IPsec, from me to any, destination port UDP 3799". This causes the RADIUS server to initiate IPsec when sending RADIUS extension traffic to any RADIUS client. If some RADIUS clients contacted by the server do not support IPsec, then a more granular policy will be required, such as "Initiate IPsec, from me to IPsec- capable-RADIUS-client, destination port UDP 3799". Where IPsec is used for security, and no RADIUS shared secret is configured, it is important that the RADIUS client and server perform an authorization check. Before enabling a host to act as a RADIUS client, the RADIUS server SHOULD check whether the host is authorized to provide network access. Similarly, before enabling a host to act as a RADIUS server, the RADIUS client SHOULD check whether the host is authorized for that role. RADIUS servers can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS clients. Alternatively, if a separate Certification Authority (CA) exists for RADIUS clients, then the RADIUS server can configure this CA as a trust anchor [RFC3280] for use with IPsec. Similarly, RADIUS clients can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS servers. Alternatively, if a separate CA exists for RADIUS servers, then the RADIUS client can configure this CA as a trust anchor for use with IPsec. Since unlike SSL/TLS, IKE does not permit certificate policies to be set on a per-port basis, certificate policies need to apply to all uses of IPsec on RADIUS clients and servers. In IPsec deployment supporting only certificate authentication, a management station initiating an IPsec-protected telnet session to the RADIUS server would need to obtain a certificate chaining to the RADIUS client CA. Issuing such a certificate might not be appropriate if the management station was not authorized as a RADIUS client. Where RADIUS clients may obtain their IP address dynamically (such as an Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409] SHOULD NOT be used, since this requires use of a group Chiba, et al. Informational [Page 24] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 pre-shared key; instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses are statically assigned, either Aggressive Mode or Main Mode MAY be used. With certificate authentication, Main Mode SHOULD be used. Care needs to be taken with IKE Phase 1 Identity Payload selection in order to enable mapping of identities to pre-shared keys, even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned, mapping of identities to keys is not possible, so that group pre-shared keys are still a practical necessity. As a result, the ID_FQDN identity payload SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned. This approach also has other advantages, since it allows the RADIUS server and client to configure themselves based on the fully qualified domain name of their peers. Note that with IPsec, security services are negotiated at the granularity of an IPsec SA, so that RADIUS exchanges requiring a set of security services different from those negotiated with existing IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also advisable where quality of service considerations dictate different handling RADIUS conversations. Attempting to apply different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For a discussion of the issues, see [RFC2983].5.4. Replay Protection
Where IPsec replay protection is not used, the Event-Timestamp (55) Attribute [RFC2869] SHOULD be included within all messages. When this attribute is present, both the NAS and the RADIUS server MUST check that the Event-Timestamp Attribute is current within an acceptable time window. If the Event-Timestamp Attribute is not current, then the message MUST be silently discarded. This implies the need for time synchronization within the network, which can be achieved by a variety of means, including secure NTP, as described in [NTPAUTH]. Both the NAS and the RADIUS server SHOULD be configurable to silently discard messages lacking an Event-Timestamp Attribute. A default time window of 300 seconds is recommended. Chiba, et al. Informational [Page 25] RFC 3576 Dynamic Authorization Extensions to RADIUS July 20036. Example Traces
Disconnect Request with User-Name: 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....# 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^.. 32: 6d63 6869 6261 Disconnect Request with Acct-Session-ID: 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(..... 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,. 32: 3930 3233 3435 3637 90234567 Disconnect Request with Framed-IP-Address: 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(..... 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ... 32: 0a00 02037. References
7.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (version 3) Specification, Implementation and Analysis", RFC 1305, March 1992. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. Chiba, et al. Informational [Page 26] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.7.2. Informative References
[RFC2882] Mitton, D., "Network Access Server Requirements: Extended RADIUS Practices", RFC 2882, July 2000. [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000. [AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003. [Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in Progress. [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996. [NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", Work in Progress. Chiba, et al. Informational [Page 27] RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 [NTPAUTH] Mills, D., "Public Key Cryptography for the Network Time Protocol", Work in Progress.8. 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 implementers 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.9. Acknowledgments
This protocol was first developed and distributed by Ascend Communications. Example code was distributed in their free server kit. The authors would like to acknowledge the valuable suggestions and feedback from the following people: Avi Lior<EMAIL_ADDRESS>Randy Bush<EMAIL_ADDRESS>Steve Bellovin<EMAIL_ADDRESS>Glen Zorn<EMAIL_ADDRESS>Mark Jones<EMAIL_ADDRESS>Claudio Lapidus<EMAIL_ADDRESS>Anurag Batta<EMAIL_ADDRESS>Kuntal Chowdhury<EMAIL_ADDRESS>and Tim Moore<EMAIL_ADDRESS>Russ Housley<EMAIL_ADDRESS>Chiba, et al. Informational [Page 28] RFC 3576 Dynamic Authorization Extensions to RADIUS July 200310. Authors' Addresses
Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 EMail<EMAIL_ADDRESS>Phone: +1<PHONE_NUMBER> Gopal Dommety Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 EMail<EMAIL_ADDRESS>Phone: +1<PHONE_NUMBER> Mark Eklund Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 EMail<EMAIL_ADDRESS>Phone: +1<PHONE_NUMBER> David Mitton Circular Logic UnLtd. 733 Turnpike Street #154 North Andover, MA 01845 EMail<EMAIL_ADDRESS>Phone: +1<PHONE_NUMBER> Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail<EMAIL_ADDRESS>Phone: +1<PHONE_NUMBER> Fax: +1<PHONE_NUMBER> Chiba, et al. Informational [Page 29] RFC 3576 Dynamic Authorization Extensions to RADIUS July 200311. Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.  Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Chiba, et al. Informational [Page 30]


Intersections.
Creates an intersection line for graphic objects. Example.
Content
Quick start
- Create a folder on your localhost named as [folderName].
- Download three.js repository into your "[folderName]\three.js\dev" folder.
- Download commonNodeJS repository into your "[folderName]\commonNodeJS\master" folder.
- Add your web page into [folderName]. Example:
<!DOCTYPE html>

<title>Intersections</title>
<link type="text/css" rel="stylesheet" href="https://threejs.org/examples/main.css">

<link type="text/css" rel="stylesheet" href="commonNodeJS/master/css/main.css">

three.js
- Intersections.
By anhr

<canvas id="canvas"></canvas>

NOTE. Please include three.THREE = THREE; line into your project before use my library. See example above.
The easiest way to use Intersections in your code is import Intersections from Intersections.js file in your JavaScript module.
import Intersections from './commonNodeJS/master/Intersections/Intersections.js'
Now you can use Intersections in your javascript code for creating of an intersection line for graphic objects.
- First, create a graphical objects, for what you want to see the intersection line. For example plane and dodecahedron.
const planeGeom = new THREE.PlaneGeometry( 2, 2 );
const plane = new THREE.Mesh( planeGeom,
new THREE.MeshBasicMaterial( {
color: "lightgray",
opacity: 0.75,
transparent: true,
side: THREE.DoubleSide
} )
);
scene.add( plane );
const objGeom = new THREE.DodecahedronGeometry( 1, 0 );
const obj = new THREE.Mesh( objGeom, new THREE.MeshBasicMaterial( {
color: "green",
wireframe: true
} ) );
scene.add( obj );
Now you can see, dodecahedron is intersects with plane.
- Create a line of intersection.
new Intersections( obj, plane, { scene: scene } );
Also you can use new MyThree.Intersections instead of new Intersections. Import MyThree for it.
import MyThree from './commonNodeJS/master/myThree/myThree.js';
//import MyThree from './commonNodeJS/master/myThree/build/myThree.module.js';
//import MyThree from './commonNodeJS/master/myThree/build/myThree.module.min.js';
Example of your web page.
The following code is the result of this tutorial.
<!DOCTYPE html>

<title>Intersections</title>
<link type="text/css" rel="stylesheet" href="https://threejs.org/examples/main.css">

<link type="text/css" rel="stylesheet" href="commonNodeJS/master/css/main.css">

three.js
- Intersections.
By anhr

<canvas id="canvas"></canvas>


Link where the user has access: Example.com
Link where the user has access, translated: Example.com with “allow” protocol
Link where the user does not have access, hidden by default: Example.com with “deny” protocol
Link where the user does not have access, shown as plain text: Example.com with “deny” protocol


Toggle navigation
Northwell Health Dashboard
Patient Info Available
10 hours ago
Mr. Donald Trump
Check Now
Patient Info Available
14 hours ago
Mr. Barack Obama
Check Now
New Appointment
15 hours ago
Mr. Donald Trump
21 March 2017 1pm
Take Action
Read All Messages
Hello, Dr. Young
User Profile
Settings
Logout
Dashboard
My Patients
My Messages
My Widgets
Joe Zeke Zemaitis
513
Previous Diagnoses
12
Allergies / Medications
0
Exams / Reports
0
Appointments
Top Diagnosis
Description
Time
Status
`
Similar Medications
Search
Diagnosis Timeline


Main net has
0
total queries of which
0
resolved aliases!
Test net has
0
total queries of which
0
resolved aliases!


[§346-383] Meetings; quorum. (a) The Hawaii interagency council on homelessness shall meet quarterly, or more frequently as it deems necessary.
(b) A majority of the members of the Hawaii interagency council on homelessness shall constitute a quorum to do business and to validate any decision or act of the council. [L 2012, c 105, pt of §2]


This is a sample text using Poppins-Regular font with some random space filling words.
This is a sample which uses Poppins-Regular font with some random space filling words.
This is a sample which uses Poppins-Regular font with some random space filling words.
This is a sample which uses Poppins-Regular font with some random space filling words.
This is a sample which uses Poppins-Regular font with some random space filling words.


echoframework
/
org.echo.mobile.framework.model.operations
/
OperationType
/
OVERRIDE_TRANSFER_OPERATION
OVERRIDE_TRANSFER_OPERATION
OVERRIDE_TRANSFER_OPERATION


View Options:
Link Strength:
Size nodes by:
Betweenness
Degree
Strength
Word Count
Colour nodes by:
Gender
Modularity Class
Romantic Drama Unveiled
A Visualisation by
Michael Falk
Feel free to use my
code
and
data
.
View Another Play


Methods
"click .cas-login"(event) → {boolean}
Handle the click on the login link.
Parameters:
| Name | Type | Description |
|---|---|---|
event |
The click event. |
Returns:
False.
- Type
- boolean
"click .cas-logout"(event) → {boolean}
Handle the click on the logout link.
Parameters:
| Name | Type | Description |
|---|---|---|
event |
The click event. |
Returns:
False.
- Type
- boolean
authInProcess() → {*}
- Source:
Returns:
True if Meteor is in the process of logging in.
- Type
- *
authInProcess() → {*}
- Source:
Returns:
True if Meteor is in the process of logging in.
- Type
- *
canShow() → {boolean}
- Source:
Returns:
True if there is a logged in user.
- Type
- boolean
getDefinitions(restoreJSON, collection)
Returns the definition array associated with collectionName in the restoreJSON structure.
Parameters:
| Name | Type | Description |
|---|---|---|
restoreJSON |
The restore file contents. |
|
collection |
The collection of interest. |
isAuthorized() → {boolean}
- Source:
Determine if the user is authorized to view the current page.
If current user's username matches the
username in the URL, they are authorized.
Otherwise, they are not authorized.
Returns:
True if there is a logged in user and they are authorized to visit the page.
- Type
- boolean
profiles()
Returns a cursor to profiles, sorted by last name.
restoreCollection(collection, restoreJSON)
Given a collection and the restoreJSON structure, looks up the definitions and invokes define() on them.
Parameters:
| Name | Type | Description |
|---|---|---|
collection |
The collection to be restored. |
|
restoreJSON |
The structure containing all of the definitions. |


Web design blog bringing design inspiration, how to design a website, web design tutorials and much more.
How and in what presentation form they are shown on your computer, are the targets of web programming
Gives computers the ability to learn without being explicitly programmed.
It is a branch of machine learning based on a set of algorithms that attempt to model high level abstractions in data.
It is a process for obtaining raw data and converting it into information useful for decision-making by users
It refers to the techniques used to communicate data or information by encoding it as visual objects contained in graphics
Responsible for designing, developing, and implementing workflow management and tracking system
About Me{{admin_info.sign}}


Sonne is founded on transparency and simplicity. We operate on the belief that a perfect skincare system comes down to three things: actual science, safe ingredients, and a fair price.
UV rays are the #1 cause of skin cancer and aging. Sonne is formulated by doctors to protect your skin from these rays while perfecting it over time.
Only safe ingredients. All listed here.
Adequate shouldn’t equal expensive.
Sonne ships free to you every month for $45.


Implementation of dataflow analysis for checking whether obligations to close streams and other resources (e.g. database objects) are satisfied.
See Weimer and Necula, Finding and preventing run-time error handling mistakes.


FrontEnd Developer | Full Stack Developer | JSLOVER
Singapore
<EMAIL_ADDRESS>+65 9103 4008
Homeland - Kanpur, India
Skills
Javascript/Typescript
React.Js/React Native
Angular.Js/Angular 2
Jest/Karma/Jasmine/Protrctor
Node.Js/Loopback
Firebase/Aws/Azure
Webrtc/SocketIo
Data Structure and Algorithms
Solidity/Truffle/Web3.js
D3.Js/Vis.Js/Three.Js/Charts.Js
Languages
English
Hindi
Blockchain and Cryptocurrency
Aritifial Intelligance
Game Engine
Internet Of Things
Augmented Reality/ Virtual Reality
Working as a consultant to deliver the requirement.
Developed frontend for www.baltexs.io, a trading platform using react, redux , ssr etc
Woked on developing the frontend for www.exchangemalaysia.io a cryptocurrency exchange for malaysia using react, redux , websocket etc
Developed website and hybrid mobile application for Cryptorai, A cryptocurrency portfolio tracker app.
Worked on developing products for startups from scratch. Developed Skalera dashboard and Mist system analytic dashboard.
Worked on developing products with Javascript, angular, webgl, d3.js etc.
Bachelor Of technology - Computer Science
Subjects - Data Structure, Algorithms, Cryptography, Database, Operating System


Recipes¶
Each recipe in the SparseZoo is stored under the model created with it and has a specific stub that identifies it. The stubs are made up of the following structure:
DOMAIN/SUB_DOMAIN/ARCHITECTURE{-SUB_ARCHITECTURE}/FRAMEWORK/REPO/DATASET{-TRAINING_SCHEME}/OPTIM_NAME-OPTIM_CATEGORY-{OPTIM_TARGET}/RECIPE_NAME.[md|yaml]
The properties within each model stub are defined as the following:
| Model Property | Definition | Examples |
|---|---|---|
| DOMAIN | The type of solution the model is architected and trained for | cv, nlp |
| SUB_DOMAIN | The sub type of solution the model is architected and trained for | classification, segmentation |
| ARCHITECTURE | The name of the guiding setup for the network's graph | resnet_v1, mobilenet_v1 |
| SUB_ARCHITECTURE | (optional) The scaled version of the architecture such as width or depth | 50, 101, 152 |
| FRAMEWORK | The machine learning framework the model was defined and trained in | pytorch, tensorflow_v1 |
| REPO | The model repository the model and baseline weights originated from | sparseml, torchvision |
| DATASET | The dataset the model was trained on | imagenet, cifar10 |
| TRAINING_SCHEME | (optional) A description on how the model was trained | augmented, lower_lr |
| OPTIM_NAME | An overview of what was done to optimize the model | base, pruned, quant (quantized), pruned_quant, arch (architecture modified) |
| OPTIM_CATEGORY | Descriptor on the degree to which the model is optimized as compared with the baseline metric | none, conservative (100% baseline), moderate (>= 99% baseline), aggressive (< 99%) |
| OPTIM_TARGET | (optional) Descriptor for the target environment the model was optimized for | disk, edge, deepsparse, gpu |
| RECIPE_NAME | A named descriptor for the recipe signifying what the recipe is for | optimization, transfer_learning |
Image Classification¶
| Model Tag | Validation Baseline Metric |
|---|---|
| cv/classification/efficientnet-b0/pytorch/sparseml/imagenet/arch-moderate/optimization.md | 76.5% top1 accuracy |
| cv/classification/efficientnet-b4/pytorch/sparseml/imagenet/arch-moderate/optimization.md | 82.1% top1 accuracy |
| cv/classification/inception_v3/pytorch/sparseml/imagenet/pruned-conservative/optimization.md | 77.4% top1 accuracy |
| cv/classification/inception_v3/pytorch/sparseml/imagenet/pruned-moderate/optimization.md | 76.6% top1 accuracy |
| cv/classification/mobilenet_v1-1.0/pytorch/sparseml/imagenet/base-none/optimization.md | 70.9% top1 accuracy |
| cv/classification/mobilenet_v1-1.0/pytorch/sparseml/imagenet/pruned-conservative/optimization.md | 70.9% top1 accuracy |
| cv/classification/mobilenet_v1-1.0/pytorch/sparseml/imagenet/pruned-moderate/optimization.md | 70.1% top1 accuracy |
| cv/classification/mobilenet_v1-1.0/pytorch/sparseml/imagenet/pruned_quant-moderate/optimization.md | 70.1% top1 accuracy |
| cv/classification/resnet_v1-101/pytorch/sparseml/imagenet/pruned-moderate/optimization.md | 76.6% top1 accuracy |
| cv/classification/resnet_v1-152/pytorch/sparseml/imagenet/pruned-moderate/optimization.md | 77.5% top1 accuracy |
| cv/classification/resnet_v1-18/pytorch/sparseml/imagenet/sparse-conservative/optimization.md | 69.8% top1 accuracy |
| cv/classification/resnet_v1-34/pytorch/sparseml/imagenet/sparse-conservative/optimization.md | 73.3% top1 accuracy |
| cv/classification/resnet_v1-50/pytorch/sparseml/imagenet/pruned-conservative/optimization.md | 76.1% top1 accuracy |
| cv/classification/resnet_v1-50/pytorch/sparseml/imagenet/pruned-moderate/optimization.md | 75.3% top1 accuracy |
| cv/classification/resnet_v1-50/pytorch/sparseml/imagenet-augmented/pruned_quant-aggressive/optimization.md | 76.1% top1 accuracy |
| cv/classification/resnet_v1-50/pytorch/sparseml/imagenette/pruned-conservative/optimization.md | 99.9% top1 accuracy |
| cv/classification/resnet_v1-50/pytorch/torchvision/imagenette/pruned-conservative/optimization.md | 99.9% top1 accuracy |
| cv/classification/vgg-11/pytorch/sparseml/imagenet/pruned-moderate/optimization.md | 68.3% top1 accuracy |
| cv/classification/vgg-16/pytorch/sparseml/imagenet/pruned-conservative/optimization.md | 71.6% top1 accuracy |
| cv/classification/vgg-16/pytorch/sparseml/imagenet/pruned-moderate/optimization.md | 70.8% top1 accuracy |
| cv/classification/vgg-19/pytorch/sparseml/imagenet/pruned-moderate/optimization.md | 71.7% top1 accuracy |
Object Detection¶
| Model Tag | Validation Baseline Metric |
|---|---|
| cv/detection/ssd-resnet50_300/pytorch/sparseml/coco/pruned-moderate/optimization.md | 41.8<EMAIL_ADDRESS>|
| cv/detection/ssd-resnet50_300/pytorch/sparseml/voc/pruned-moderate/optimization.md | 51.5<EMAIL_ADDRESS>|
| cv/detection/yolo_v3-spp/pytorch/ultralytics/coco/pruned-aggressive/optimization.md | 62.1<EMAIL_ADDRESS>|


I grew up in a little town called Allyn, on the Olympic Penninsula. It is pretty much 2 coffee shops, 2 restaurants, a gas station, and your gone. Now I live on Capitol Hill, with my S.O. and a cat, Minerva. My family is local, with my little brother and newphew across the Puget Sound and my mother in Olympia. I love to read. Exploring new worlds within books is the closest I can get to my other passion, traveling, while I am here in Seattle. I travel as much and as often as I can. I try and travel locally, regionally, and internationaly every year. Travel teaches me something new each time I go someplace, whether it is a new custom or parts of a new langauge, I am constantly learning while getting myself out of my comfort zone.
Washington State University 2006-2011 BS in Food Science Human Nutrition, Dietetics 3.48 GPA
CodeFellows April - July 2015, April 2016 - Present Programming, with a focus in the JavaScript Language
Classes Taken
Barista October 2015 - Present Uptown Espresso -- Seattle, WA
Registered Dietitian/Nutrition Associate January 2013 - August 2015 Axxya Systems -- Redmond, WA
Bartender and Server May 2006 - August 2015 Lennard K's Boathouse Restaurant and Bar -- Allyn, WA
Clerical Assistant August 2007 - May 2010 Washington State University -- Pullman, WA
My main goal is to complete Code 201, Code 301, and Code 401 at CodeFellows and get a job around the Seattle area as a JavaScript programmer.


{% extends "main.html" %} {% block maincontent %}
If you see this page, it means that you managed to log in successfully.


Hindi Tutorial
Hindi Tutorials
This is new work done by ax shivam sharma in the date of 09/09/2019................
def greeting(request): pass
hii this is shivam sharma from kanpur


I have always been very excited about the possibilities that the internet brings us. Now as a computer science student I know of the possibilities that I can achieve. I am enthusiastic about what the future brings and I am going to do my very best for there to be an exciting future ahead of us. I am a Junior at the University of Texas at El Paso, and I am well versed in Java and Python, and very excited to keep learning more.


Please wait...
This is your unique unsubscribe link, we're sad to see you go. Thank you for your time


Check if you wish build information published to Artifactory to include implicit project dependencies
(for example, poms and parent poms of the project dependencies)
as well as build-time dependencies (for example, maven plugins used during the build).


| Home |
| About Me |
| Blogs |
| My Projects |
| Contact Me! |
| Version Control | Restaurant v Table | Class v ID | Arrays v Hashes | Thinking Styles | The Map Method | Diversity in Tech | The Dog Class |
| Feedback | Stereotype Threat | Object vs Functional Programing | JavaScript vs Ruby | Values | Computer Memory | Conflict | Blog 16 |
The idea of "mapping" over an array or a hash seems to confuse a lot of people. What does it do? What happens to the contents? When should I do this? Why can't I use ".each"? All of these are valid questions, and the subject of this post.
What does ".map" do? The answer is fairly simple: .map goes through the contents of an array or a hash and executes a block of code for each item. YOu might do this if you wanted to capitalize a list of names, double a list of numbers, or anything else you might need to do. If you call ".map" on an object, you are required to include the block of code that you want to execute.
x.map {|item| thing I want to do to each item}
If you try to map over an object without a block of code, you will receive an error message for your troubles.
What happens to the contents of the original object? The answer is: nothing! When you run ".map" you are running a non-destructive method, which means that the original object goes untouched. ".map" returns a brand new object that contains a copy of the original, but with the changes made by the code block. This is great if you need to preserve the original for any other use. If you wanted to turn an array into a hash, but you still needed the original array for something else, maybe another hash, then this would be perfect. Say you wanted to categorize a list of movies by Parental Rating, Rotten Tomatoes Rating, and your friends' opinions. You would start with the same array of movie, but create a different hash for each situation. This would mean that you could map over the original and create 3 copies with different purposes.
What is the difference between ".map" and ".each"? Both iterate over an object and execute a block of code on each item. But while ".map" returns a new object with the code executed, ".each" returns the original object. The other thing to keep in mind is the difference between ".map" and ".map!". Generally speaking, haivng a "!" on the end of a method signifies that it is destructive. Remember earlier when I said that ".map" does not modify the original object? Well, ".map!" does. The fact that it does this makes it destructive.
The ".map" Enumerable method is very useful in Ruby. It allows you to modify, transform, or even replace objects while keeping the originals intact.


|
code.google.com home | ||||||||
| PREV NEXT | FRAMES NO FRAMES |
| Packages that use HtmlChangeListener | |
|---|---|
| org.owasp.html | An efficient HtmlSanitizer
configurable via a flexible
HtmlPolicyBuilder . |
| Uses of HtmlChangeListener in org.owasp.html |
|---|
| Methods in org.owasp.html with parameters of type HtmlChangeListener | ||
|---|---|---|
|
PolicyFactory.apply(HtmlStreamEventReceiver out,
HtmlChangeListener<CTX> listener,
CTX context)
Produces a sanitizer that emits tokens to out and that notifies
any listener of any dropped tags and attributes. |
|
|
HtmlPolicyBuilder.build(HtmlStreamEventReceiver out,
HtmlChangeListener<? super CTX> listener,
CTX context)
Produces a policy based on the allow and disallow calls previously made. |
|
|
PolicyFactory.sanitize(java.lang.String html,
HtmlChangeListener<CTX> listener,
CTX context)
A convenience function that sanitizes a string of HTML and reports the names of rejected element and attributes to listener. |
| Constructors in org.owasp.html with parameters of type HtmlChangeListener | |
|---|---|
HtmlChangeReporter(HtmlStreamEventReceiver renderer,
HtmlChangeListener<? super T> listener,
T context)
|
|
code.google.com home | ||||||||
| PREV NEXT | FRAMES NO FRAMES |


Get a discounted CHUWI tablet or laptop on Black Friday - Gizchina.com
by Ying HuaRate this post
Big sales day is coming once again with the emergence of Black Friday in a week, but most of the e-shops and manufacturers are already prepared for the big day in advance. And the famous laptop and tablet makers CHUWI are of course no exception and will be offering quite a sizable discounts for most of their product portfolio. The price slashes can go as high as $76 so it’s certainly worth checking out their Black Friday offers.
Most of the CHUWI’s major sales deals will kick off directly on Black Friday on November 28th and will last until December 2nd. So you will have few days to fully decide about the best deals out there, but it’s still recommended to scout the deals in advance so you know what to aim for. Full details are of course available on their official website, so make sure to visit that too. And now for the comprehensive table of the available CHUWI products on sale, you will see Mini PC models sprinkled there too in between the usual laptop and tablet pieces.
| Activity project | product | Activity price/Original price | Date |
| Black Friday | Hi9 Pro | $111.99/$139.99 | Nov 28 PST-Dec 02 PST |
| Black Friday | Hipad LTE | $127.99/$159.99 | Nov 28 PST-Dec 02 PST |
| Black Friday | HeroBook (4+256) | $183.99/$229.99 | Nov 28 PST-Dec 02 PST |
| Black Friday | Gbox Pro | $151.99/$189.99 | Nov 28 PST-Dec 02 PST |
| Black Friday | LapBook Pro | $303.2/$379 | Nov 28 PST-Dec 02 PST |
| Black Friday | Hi9 Pro | $111.99/$139.99 | Nov 28 PST-Dec 02 PST |
| Black Friday | GTBOX | $239.99/$299.99 | Nov 28 PST-Dec 02 PST |
| Black Friday | HI10 AIR | $135.99/$169.99 | Nov 28 PST-Dec 02 PST |
| Black Friday | Herobook | $159.99/$199.99 | Nov 28 PST-Dec 02 PST |
| Black Friday | HI9 PLUS set | $175.99/$219.99 | Nov 28 PST-Dec 02 PST |
| Black Friday | HIPAD LTEset | $143.99/$179.99 | Nov 28 PST-Dec 02 PST |
There is also a simple wish list promo running up until November 29th, where you can easily just apply for a discount coupon to a particular product and you will receive it in the mail. Furthermore you can win one of the three free UBook Pro tablets (N4100 processor version) in the Gleam giveaway so check that out on the official website too.
Probably the most appealing category of CHUWI products are the laptop models and most of them are in the $200-$400 price range. So we can easily divide them into simple recommendations : if you want a cheap durable one with good price/performance ratio and under $200 then go for the HeroBook model. Under $300 section will give you LapBook Pro with better specs and design, but the pinacle will be reached with under $400 with the great looking AeroBook sporting the Core M processor. HappyBlack Friday hunting !


Plugin Information |
|---|
View Synergy on the plugin site for more information. |
This plugin provide integrations with IBM Rational CM/Synergy 6.5a Version Manager SCM
Features
Development and testing projects
Those features applies to projects in the working or prep state.
- Set the workarea path of an existing project to the location of the Hudson project workspace
- Update the workarea
- Detect conflicts
- Create a changelog
This feature apply to projects in the prep state.
- Create and publish a baseline (always, never or only if the build is successful)
- Copy the tasks from a Synergy folder to another
Baselined projects
Those features applies to static projects.
- Copy a snapshot of a project
- Copy a snapshot of all projects in a baseline
- Copy a snapshot of added or changed files between two projects
- Copy a snapshot of added ot changed files between two baselines
- Create a changelog
Requirements
This plugin is using the CLI interface. It has been developed and tested with Synergy 6.5
Using multiple nodes
It is possible to build a project on multiple nodes, by creating a copy of the project for each node. The name of the node must be in the Synergy project name, and a dynamic project name must be set in the Synergy plugin.
For example, if the project names match a pattern like "project-NODE" (where "NODE" is the name of the node), the name of the project in the Synergy plugin must be "project-${COMPUTERNAME}".
Configuration
The location of the ccm executable must be set in the system configuration page.
Depending on the server, a location for the ccm ui and ccm eng log may also need to be set.
Changelog
1.7 (17 Sep 2013)
- Handle spaces inside object names (pull #8)
- Updated to 1.424 baseline (pull #10)
- Keep passwords secret (pull #11)
- Corrected Unix vs. Windows determination on slaves (pull #12)
1.6
Improve change polling : if configured to do so, check change applies to the project and not only the release.
Fix starting when a warning is returned by Synergy at login.
Only auto-configure the workarea if configured to do so.
Allow to update a project grouping.
Improve changelog computation speed.
Fix use of dynamic project name, allowing to build on multiple nodes.
Don't required the build manager role if not needed.
Fix subproject path in change log.
Improve error detection.
Bug fixes
Baseline "Release" and "Purposes" will be based on the project's if the fields are left blank (JENKINS-8613)
1.5
Add option to reuse a session.
Add option to keep or update subprojects when updating a project.
Add option to abort the build if there are update warnings.
Add "copy folder" post build function.
Add "pathname" start parameter.
Fix location of subproject.
Fix detection of "No task" conflict.
Fix checkout of baselined project because the changelog is not computed.
1.4
Fix conflict detection.
1.3
Support conflict detection. The build fails if conflicts are detected.
Fix use of the "-rc" flag.
Fix baseline creation.
Fail the build if the Synergy update command returns 1.
Reset workarea path if an obsolete workarea is found (may not handle all cases)
1.2
Support change pooling.
Support the "-rc" start flag.
Improve the computation of the modified file paths in the changelog for subprojects (still needs some work).
Allow to use the baseline objectname as the baseline name.
1.1
Fix end of line handling on UNIX server, which was causing a failure in the detection of the project state.
Don't assume the database version delimiter is '~'
1.0
Initial release


--template or -t — Specifies the base template to use to create items through the CLI. Supported values include:
The template's repo requires a versioned branch that the SKY UX CLI controls. It follows the [SKY UX CLI major version].x.x format. As of SKY UX 4, the 4.x.x branch must exist.


Dallas Buyers Club
Mar 16, 2013 RnB star, Darey Art Alade has denied rumour that went viral last month that he paid the sum of 500000 to Kim Kardashian to appear in Nigeria Apr 4, 2013 Kim Kardashian Talks About Her Visit To Nigeria - Video Last February, Kanye West's Kim K was in Nigeria for Darey's Concert: Love Like a Movie, and her visit was the JIM IYKE GOES "GAGA" OVER PATERNITY MESS


Search
Preparing search index...
The search index is not available
data-gatherer
Options
All
Public
Public/Protected
All
Inherited
Externals
Only exported
Menu
Globals
QuoteBuilder
Class QuoteBuilder
Hierarchy
QuoteBuilder
Index
Properties
average
change
Over
Time
close
date
high
low
market
Average
market
Change
Over
Time
market
Close
market
High
market
Low
market
Notional
market
Number
OfTrades
market
Open
market
Volume
notional
number
OfTrades
open
symbol
volume
Methods
build
get
Average
OrDefault
get
Change
Over
Time
OrDefault
get
Close
OrDefault
get
Date
OrDefault
get
High
OrDefault
get
Low
OrDefault
get
Market
Average
OrDefault
get
Market
Change
Over
Time
OrDefault
get
Market
Close
OrDefault
get
Market
High
OrDefault
get
Market
Low
OrDefault
get
Market
Notional
OrDefault
get
Market
Number
OfTrades
OrDefault
get
Market
Open
OrDefault
get
Market
Volume
OrDefault
get
Notional
OrDefault
get
Number
OfTrades
OrDefault
get
Open
OrDefault
get
Symbol
OrDefault
get
Volume
OrDefault
with
Average
with
Change
Over
Time
with
Close
with
Date
with
High
with
Low
with
Market
Average
with
Market
Change
Over
Time
with
Market
Close
with
Market
High
with
Market
Low
with
Market
Notional
with
Market
Number
OfTrades
with
Market
Open
with
Market
Volume
with
Notional
with
Number
OfTrades
with
Open
with
Symbol
with
Volume
Properties
Private
average
average
:
number
Private
change
Over
Time
change
Over
Time
:
number
Private
close
close
:
number
Private
date
date
:
Date
Private
high
high
:
number
Private
low
low
:
number
Private
market
Average
market
Average
:
number
Private
market
Change
Over
Time
market
Change
Over
Time
:
number
Private
market
Close
market
Close
:
number
Private
market
High
market
High
:
number
Private
market
Low
market
Low
:
number
Private
market
Notional
market
Notional
:
number
Private
market
Number
OfTrades
market
Number
OfTrades
:
number
Private
market
Open
market
Open
:
number
Private
market
Volume
market
Volume
:
number
Private
notional
notional
:
number
Private
number
OfTrades
number
OfTrades
:
number
Private
open
open
:
number
Private
symbol
symbol
:
string
Private
volume
volume
:
number
Methods
build
build
(
)
:
Quote
Returns
Quote
get
Average
OrDefault
get
Average
OrDefault
(
)
:
number
Returns
number
get
Change
Over
Time
OrDefault
get
Change
Over
Time
OrDefault
(
)
:
number
Returns
number
get
Close
OrDefault
get
Close
OrDefault
(
)
:
number
Returns
number
get
Date
OrDefault
get
Date
OrDefault
(
)
:
Date
Returns
Date
get
High
OrDefault
get
High
OrDefault
(
)
:
number
Returns
number
get
Low
OrDefault
get
Low
OrDefault
(
)
:
number
Returns
number
get
Market
Average
OrDefault
get
Market
Average
OrDefault
(
)
:
number
Returns
number
get
Market
Change
Over
Time
OrDefault
get
Market
Change
Over
Time
OrDefault
(
)
:
number
Returns
number
get
Market
Close
OrDefault
get
Market
Close
OrDefault
(
)
:
number
Returns
number
get
Market
High
OrDefault
get
Market
High
OrDefault
(
)
:
number
Returns
number
get
Market
Low
OrDefault
get
Market
Low
OrDefault
(
)
:
number
Returns
number
get
Market
Notional
OrDefault
get
Market
Notional
OrDefault
(
)
:
number
Returns
number
get
Market
Number
OfTrades
OrDefault
get
Market
Number
OfTrades
OrDefault
(
)
:
number
Returns
number
get
Market
Open
OrDefault
get
Market
Open
OrDefault
(
)
:
number
Returns
number
get
Market
Volume
OrDefault
get
Market
Volume
OrDefault
(
)
:
number
Returns
number
get
Notional
OrDefault
get
Notional
OrDefault
(
)
:
number
Returns
number
get
Number
OfTrades
OrDefault
get
Number
OfTrades
OrDefault
(
)
:
number
Returns
number
get
Open
OrDefault
get
Open
OrDefault
(
)
:
number
Returns
number
get
Symbol
OrDefault
get
Symbol
OrDefault
(
)
:
string
Returns
string
get
Volume
OrDefault
get
Volume
OrDefault
(
)
:
number
Returns
number
with
Average
with
Average
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Change
Over
Time
with
Change
Over
Time
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Close
with
Close
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Date
with
Date
(
value
:
Date
)
:
QuoteBuilder
Parameters
value:
Date
Returns
QuoteBuilder
with
High
with
High
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Low
with
Low
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Market
Average
with
Market
Average
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Market
Change
Over
Time
with
Market
Change
Over
Time
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Market
Close
with
Market
Close
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Market
High
with
Market
High
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Market
Low
with
Market
Low
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Market
Notional
with
Market
Notional
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Market
Number
OfTrades
with
Market
Number
OfTrades
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Market
Open
with
Market
Open
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Market
Volume
with
Market
Volume
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Notional
with
Notional
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Number
OfTrades
with
Number
OfTrades
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Open
with
Open
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
with
Symbol
with
Symbol
(
value
:
string
)
:
QuoteBuilder
Parameters
value:
string
Returns
QuoteBuilder
with
Volume
with
Volume
(
value
:
number
)
:
QuoteBuilder
Parameters
value:
number
Returns
QuoteBuilder
Globals
EOperation
State
ESymbol
Type
App
Gathered
Symbol
Helper
Quote
Quote
Adapter
Quote
Builder
average
change
Over
Time
close
date
high
low
market
Average
market
Change
Over
Time
market
Close
market
High
market
Low
market
Notional
market
Number
OfTrades
market
Open
market
Volume
notional
number
OfTrades
open
symbol
volume
build
get
Average
OrDefault
get
Change
Over
Time
OrDefault
get
Close
OrDefault
get
Date
OrDefault
get
High
OrDefault
get
Low
OrDefault
get
Market
Average
OrDefault
get
Market
Change
Over
Time
OrDefault
get
Market
Close
OrDefault
get
Market
High
OrDefault
get
Market
Low
OrDefault
get
Market
Notional
OrDefault
get
Market
Number
OfTrades
OrDefault
get
Market
Open
OrDefault
get
Market
Volume
OrDefault
get
Notional
OrDefault
get
Number
OfTrades
OrDefault
get
Open
OrDefault
get
Symbol
OrDefault
get
Volume
OrDefault
with
Average
with
Change
Over
Time
with
Close
with
Date
with
High
with
Low
with
Market
Average
with
Market
Change
Over
Time
with
Market
Close
with
Market
High
with
Market
Low
with
Market
Notional
with
Market
Number
OfTrades
with
Market
Open
with
Market
Volume
with
Notional
with
Number
OfTrades
with
Open
with
Symbol
with
Volume
Quote
Controller
Stock
Stock
Symbol
Symbol
Adapter
Symbol
Controller
Symbol
Watcher
Symbol
Watchers
Manager
Symbol
Watchers
Manager
Symbol
Already
Monitored
Symbol
Watchers
Manager
Symbol
Not
Monitored
Adapter
Error
Message
IQuoteAPI
IStock
Data
ISymbolAPI
Constants
Values
Gathered
Symbol
Schema
Quote
Schema
configuration
lightship
Constants
Generated using
TypeDoc