--- layout: default ---
Network Working Group M. Chiba Request for Comments: 5176 G. Dommety Obsoletes: 3576 M. Eklund Category: Informational Cisco Systems, Inc. D. Mitton RSA, Security Division of EMC B. Aboba Microsoft Corporation January 2008 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. 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 5176 Dynamic Authorization Extensions to RADIUS January 2008 Table of Contents 1. Introduction ....................................................2 1.1. Applicability ..............................................3 1.2. Requirements Language ......................................4 1.3. Terminology ................................................4 2. Overview ........................................................4 2.1. Disconnect Messages (DMs) ..................................5 2.2. Change-of-Authorization (CoA) Messages .....................5 2.3. Packet Format ..............................................6 3. Attributes .....................................................10 3.1. Proxy State ...............................................12 3.2. Authorize Only ............................................13 3.3. State .....................................................14 3.4. Message-Authenticator .....................................15 3.5. Error-Cause ...............................................16 3.6. Table of Attributes .......................................20 4. Diameter Considerations ........................................24 5. IANA Considerations ............................................26 6. Security Considerations ........................................26 6.1. Authorization Issues ......................................26 6.2. IPsec Usage Guidelines ....................................27 6.3. Replay Protection .........................................28 7. Example Traces .................................................28 8. References .....................................................29 8.1. Normative References ......................................29 8.2. Informative References ....................................30 9. Acknowledgments ................................................30 Appendix A ........................................................311. 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 user session(s) in progress. Alternatively, if the user changes authorization level, this may require that authorization attributes be added/deleted from user session(s). To overcome these limitations, several vendors have implemented additional RADIUS commands in order to enable unsolicited messages to be sent to the NAS. These extended commands provide support for Disconnect and Change-of-Authorization (CoA) packets. Disconnect Chiba, et al. Informational [Page 2] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 packets cause user session(s) to be terminated immediately, whereas CoA packets 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 described; see Section 6.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 6.2 for details. Existing implementations lack replay protection. In order to support replay detection, it is recommended that an Event-Timestamp Attribute be added to all packets in situations where IPsec replay protection is not employed. See Section 6.3 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 the Diameter protocol [RFC3588], in which server-initiated authorization change is initiated using a Re-Auth-Request (RAR) command identifying the session via User-Name and Session-Id Attribute Value Pairs (AVPs) and containing a Re-Auth-Request-Type AVP with value "AUTHORIZE_ONLY". This results 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. Chiba, et al. Informational [Page 3] RFC 5176 Dynamic Authorization Extensions to RADIUS January 20081.2. Requirements Language
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: Dynamic Authorization Client (DAC) The entity originating Change of Authorization (CoA) Requests or Disconnect-Requests. While it is possible that the DAC is co-resident with a RADIUS authentication or accounting server, this need not necessarily be the case. Dynamic Authorization Server (DAS) The entity receiving CoA-Request or Disconnect-Request packets. The DAS may be a NAS or a RADIUS proxy. 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 Point-to-Point Protocol (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 (CoA) packets. Chiba, et al. Informational [Page 4] RFC 5176 Dynamic Authorization Extensions to RADIUS January 20082.1. Disconnect Messages (DMs)
A Disconnect-Request packet is sent by the Dynamic Authorization Client in order to terminate user session(s) 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(s) to be terminated by inclusion of the identification attributes described in Section 3. +----------+ +----------+ | | Disconnect-Request | | | | <-------------------- | | | NAS | | DAC | | | Disconnect-ACK/NAK | | | | ---------------------> | | +----------+ +----------+ The NAS responds to a Disconnect-Request packet sent by a Dynamic Authorization Client with a Disconnect-ACK if all associated session context is discarded and the user session(s) are no longer connected, or a Disconnect-NAK, if the NAS was unable to disconnect one or more sessions and discard all associated session context. A Disconnect- ACK MAY contain the Acct-Terminate-Cause (49) Attribute [RFC2866] with the value set to 6 for Admin-Reset.2.2. Change-of-Authorization (CoA) Messages
CoA-Request packets contain information for dynamically changing session authorizations. Typically, this is 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 those for Disconnect-Request packets. The following attributes MAY be sent in a CoA-Request: Filter-ID (11) - Indicates the name of a data filter list to be applied for the session(s) that the identification attributes map to. NAS-Filter-Rule (92) - Provides a filter list to be applied for the session(s) that the identification attributes map to [RFC4849]. Chiba, et al. Informational [Page 5] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 +----------+ +----------+ | | CoA-Request | | | | <-------------------- | | | NAS | | DAC | | | CoA-ACK/NAK | | | | ---------------------> | | +----------+ +----------+ The NAS responds to a CoA-Request sent by a Dynamic Authorization Client with a CoA-ACK if the NAS is able to successfully change the authorizations for the user session(s), or a CoA-NAK if the CoA- Request is unsuccessful. 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" SHOULD be included.2.3. Packet Format
For either Disconnect-Request or CoA-Request packets 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 following 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+- Chiba, et al. Informational [Page 6] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 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 [RFC3575] 41 - Disconnect-ACK [RFC3575] 42 - Disconnect-NAK [RFC3575] 43 - CoA-Request [RFC3575] 44 - CoA-ACK [RFC3575] 45 - CoA-NAK [RFC3575] Identifier The Identifier field is one octet, and aids in matching requests and replies. A Dynamic Authorization Server implementing this specification MUST be capable of detecting a duplicate request if it has the same source IP address, source UDP port, and Identifier within a short span of time. The responsibility for retransmission of Disconnect-Request and CoA-Request packets lies with the Dynamic Authorization Client. If after sending these packets, the Dynamic Authorization Client 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 Dynamic Authorization Client is retransmitting a Disconnect-Request or CoA-Request to the same Dynamic Authorization Server as before, and the attributes haven't 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. If the Request to a primary Dynamic Authorization Server fails, a secondary Dynamic Authorization Server must be queried, if available; issues relating to failover algorithms are described in [RFC3539]. Since this represents a new request, a new Request Authenticator and Identifier MUST be used. However, where the Dynamic Authorization Client is sending directly to the NAS, failover typically does not make sense, since CoA-Request or Disconnect-Request packets need to be delivered to the NAS where the session resides. Chiba, et al. Informational [Page 7] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 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 maximum length is 4096. Authenticator The Authenticator field is sixteen (16) octets. The most significant octet is transmitted first. This value is used to authenticate packets between the Dynamic Authorization Client and the Dynamic Authorization Server. 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 CoA-Request or Disconnect-Request cannot be computed the same way as the Request Authenticator of a RADIUS Access-Request, because there is no User-Password Attribute in a CoA-Request or Disconnect- 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 Dynamic Authorization Client and the Dynamic Authorization Server) SHOULD be at least as large and unguessable as a well-chosen password. The Dynamic Authorization Chiba, et al. Informational [Page 8] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 Server 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 CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory. If one or more authorization changes specified in a CoA-Request cannot be carried out, the NAS MUST send a CoA-NAK. A NAS MUST respond to a CoA-Request containing one or more unsupported attributes or Attribute values with a CoA-NAK; an Error-Cause Attribute with value 401 (Unsupported Attribute) or 407 (Invalid Attribute Value) MAY be included. A NAS MUST respond to a Disconnect-Request containing one or more unsupported attributes or Attribute values with a Disconnect-NAK; an Error-Cause Attribute with value 401 (Unsupported Attribute) or 407 (Invalid Attribute Value) MAY be included. State changes resulting from a CoA-Request MUST be atomic: if the CoA-Request is successful for all matching sessions, the NAS MUST send a CoA-ACK in reply, and all requested authorization changes MUST be made. If the CoA-Request is unsuccessful for any matching sessions, the NAS MUST send a CoA-NAK in reply, and the requested authorization changes MUST NOT be made for any of the matching sessions. Similarly, a state change MUST NOT occur as a result of a Disconnect-Request that is unsuccessful with respect to any of the matching sessions; a NAS MUST send a Disconnect-NAK in reply if any of the matching sessions cannot be successfully terminated. A NAS that does not support dynamic authorization changes applying to multiple sessions MUST send a CoA-NAK or Disconnect-NAK in reply; an Error-Cause Attribute with value 508 (Multiple Session Selection Unsupported) SHOULD be included. Within this specification, attributes can be used for identification, authorization, or other purposes. RADIUS Attribute specifications created after publication of this document SHOULD state whether an attribute can be included in CoA or Disconnect messages, and if so, which messages it can be included in and whether it serves as an identification or authorization attribute. Even if a NAS implements an attribute for use with RADIUS authentication and accounting, it is possible that it will not support inclusion of that attribute within CoA-Request and Disconnect-Request packets, given the difference in attribute semantics. This is true even for attributes specified as Chiba, et al. Informational [Page 9] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 allowable within Access-Accept packets (such as those defined within [RFC2865], [RFC2868], [RFC2869], [RFC3162], [RFC3579], [RFC4372], [RFC4675], [RFC4818], and [RFC4849]).3. Attributes
In Disconnect-Request and CoA-Request packets, certain attributes are used to uniquely identify the NAS as well as user session(s) on the NAS. The combination of NAS and session identification attributes included in a CoA-Request or Disconnect-Request packet MUST match at least one session in order for a Request to be successful; otherwise a Disconnect-NAK or CoA-NAK MUST be sent. If all NAS identification attributes match, and more than one session matches all of the session identification attributes, then a CoA-Request or Disconnect- Request MUST apply to all matching sessions. 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. Session identification attributes Attribute # Reference Description --------- --- --------- ----------- User-Name 1 [RFC2865] The name of the user associated with one or more sessions. NAS-Port 5 [RFC2865] The port on which a session is terminated. Framed-IP-Address 8 [RFC2865] The IPv4 address associated with a session. Vendor-Specific 26 [RFC2865] One or more vendor-specific identification attributes. Called-Station-Id 30 [RFC2865] The link address to which a session is connected. Calling-Station-Id 31 [RFC2865] The link address from which one or more sessions are connected. Acct-Session-Id 44 [RFC2866] The identifier uniquely identifying a session on the NAS. Chiba, et al. Informational [Page 10] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely identifying related sessions. NAS-Port-Id 87 [RFC2869] String identifying the port where a session is. Chargeable-User- 89 [RFC4372] The CUI associated with one Identity or more sessions. Needed where a privacy Network Access Identifier (NAI) is used, since in this case the User-Name (e.g., "anonymous") may not identify sessions belonging to a given user. Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier associated with a session, always sent with Framed-IPv6-Prefix. Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated with a session, always sent with Framed-Interface-Id. To address security concerns described in Section 6.1, either the User-Name or Chargeable-User-Identity attribute SHOULD be present in Disconnect-Request and CoA-Request packets. Where a Diameter client utilizes the same Session-Id for both authorization and accounting, inclusion of an Acct-Session-Id Attribute in a Disconnect-Request or CoA-Request can assist with Diameter/RADIUS translation, since Diameter RAR and ASR commands include a Session-Id AVP. An Acct-Session-Id Attribute SHOULD be included in Disconnect-Request and CoA-Request packets. A NAS implementing this specification SHOULD send an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an Access-Request. Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included within an Access-Request, the Dynamic Authorization Client will not know the Acct-Session-Id or Acct-Multi-Session-Id of the session it is attempting to target, unless it also has access to the accounting data for that session. Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not present in a CoA-Request or Disconnect-Request, it is possible that the User-Name or Chargeable-User-Identity attributes will not be sufficient to uniquely identify a single session (e.g., if the same user has multiple sessions on the NAS, or if the privacy NAI is used). In this case, if it is desired to identify a single session, session identification MAY be performed by using one or more of the Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called- Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes. Chiba, et al. Informational [Page 11] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 To assist RADIUS proxies in routing Request packets to their destination, one or more of the NAS-IP-Address or NAS-IPv6-Address attributes SHOULD be present in CoA-Request and Disconnect-Request packets; the NAS-Identifier Attribute MAY be present. Impersonation issues with NAS Identification attributes are discussed in [RFC3579], Section 4.3.7. A Disconnect-Request MUST contain only NAS and session identification attributes. If other attributes are included in a Disconnect- Request, implementations MUST send a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included. The DAC may require access to data from RADIUS authentication or accounting packets. It uses this data to compose compliant CoA- Request or Disconnect-Request packets. For example, as described in Section 3.3, a CoA-Request packet containing a Service-Type Attribute with a value of "Authorize Only" is required to contain a State Attribute. The NAS will subsequently transmit this attribute to the RADIUS server in an Access-Request. In order for the DAC to include a State Attribute that the RADIUS server will subsequently accept, some coordination between the two parties may be required. This coordination can be achieved in multiple ways. The DAC may be co-located with a RADIUS server, in which case it is presumed to have access to the necessary data. The RADIUS server may also store that information in a common database. The DAC can then be separated from the RADIUS server, so long as it has access to that common database. Where the DAC is not co-located with a RADIUS server, and does not have access to a common database, the DAC SHOULD send CoA-Request or Disconnect-Request packets to a RADIUS server acting as a proxy, rather than sending them directly to the NAS. A RADIUS server receiving a CoA-Request or Disconnect-Request packet from the DAC MAY then add or update attributes (such as adding NAS or session identification attributes or appending a State Attribute), prior to forwarding the packet. Having CoA/Disconnect-Requests forwarded by a RADIUS server can also enable upstream RADIUS proxies to perform a Reverse Path Forwarding (RPF) check (see Section 6.1).3.1. Proxy State
If there are any Proxy-State attributes in a Disconnect-Request or CoA-Request received from the Dynamic Authorization Client, the Dynamic Authorization Server MUST include those Proxy-State attributes in its response to the Dynamic Authorization Client. Chiba, et al. Informational [Page 12] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 A forwarding proxy or NAS MUST NOT modify existing Proxy-State, State, or Class attributes present in the packet. The forwarding proxy or NAS MUST treat any Proxy-State attributes already in the packet as opaque data. Its operation MUST NOT depend on the content of Proxy-State attributes added by previous proxies. The forwarding proxy MUST NOT modify any other Proxy-State attributes that were in the packet; it may choose not to forward them, but it MUST NOT change their contents. If the forwarding proxy omits the Proxy-State attributes in the request, it MUST attach them to the response before sending it. When the proxy forwards a Disconnect-Request or CoA-Request, it MAY add a Proxy-State Attribute, but it MUST NOT add more than one. If a Proxy-State Attribute is added to a packet when forwarding the packet, the Proxy-State Attribute MUST be added after any existing Proxy-State attributes. The forwarding proxy MUST NOT change the order of any attributes of the same type, including Proxy-State. Other attributes can be placed before, after, or even between the Proxy-State attributes. When the proxy receives a response to a CoA-Request or Disconnect- Request, it MUST remove its own Proxy-State Attribute (the last Proxy-State in the packet) before forwarding the response. 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 MUST recompute it.3.2. Authorize Only
To simplify translation between RADIUS and Diameter, Dynamic Authorization Clients can include a Service-Type Attribute with value "Authorize Only" within a CoA-Request; see Section 4 for details on Diameter considerations. Support for a CoA-Request including a Service-Type Attribute with value "Authorize Only" is OPTIONAL on the NAS and Dynamic Authorization Client. A Service-Type Attribute MUST NOT be included within a Disconnect-Request. A NAS MUST respond to a CoA-Request including a Service-Type Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be sent. If the NAS does not support a Service-Type value of "Authorize Only", then it MUST respond with a CoA-NAK; an Error-Cause Attribute with a value of 405 (Unsupported Service) SHOULD be included. A CoA-Request containing a Service-Type Attribute with value "Authorize Only" MUST in addition contain only NAS or session identification attributes, as well as a State Attribute. If other Chiba, et al. Informational [Page 13] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 attributes are included in such a CoA-Request, a CoA-NAK MUST be sent; an Error-Cause Attribute with value 401 (Unsupported Attribute) SHOULD be included. If a CoA-Request packet including a Service-Type value of "Authorize Only" is successfully processed, the NAS MUST respond with a CoA-NAK containing a Service-Type Attribute with value "Authorize Only", and an Error-Cause Attribute with value 507 (Request Initiated). The NAS then MUST send an Access-Request to the RADIUS server including a Service-Type Attribute with value "Authorize Only", along with a State Attribute. This Access-Request SHOULD contain the NAS identification attributes from the CoA-Request, as well as the session identification attributes from the CoA-Request permitted in an Access-Request; it also MAY contain other attributes permitted in an Access-Request. 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 then will respond to the Access-Request with an Access-Accept to (re-)authorize the session or an Access- Reject to refuse to (re-)authorize it.3.3. State
The State Attribute is available to be sent by the Dynamic Authorization Client to the NAS in a CoA-Request packet and MUST be sent unmodified from the NAS to the Dynamic Authorization Client in a subsequent ACK or NAK packet. [RFC2865], Section 5.44 states: An Access-Request MUST contain either a User-Password or a CHAP-Password or State. An Access-Request MUST NOT contain both a User-Password and a CHAP-Password. If future extensions allow other kinds of authentication information to be conveyed, the attribute for that can be used in an Access-Request instead of User-Password or CHAP-Password. In order to satisfy the requirements of [RFC2865], Section 5.44, an Access-Request with Service-Type Attribute with value "Authorize Only" MUST contain a State Attribute. In order to provide a State Attribute to the NAS, a Dynamic Authorization Client sending a CoA-Request with a Service-Type Attribute with a value of "Authorize Only" MUST include a State Attribute, and the NAS MUST send the State Attribute unmodified to the RADIUS server in the resulting Access-Request, if any. A NAS Chiba, et al. Informational [Page 14] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 receiving a CoA-Request containing a Service-Type Attribute with a value of "Authorize Only" but lacking a State Attribute MUST send a CoA-NAK and SHOULD include an Error-Cause Attribute with a value of 402 (Missing Attribute). The State Attribute is also available to be sent by the Dynamic Authorization Client to the NAS in a CoA-Request that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the NAS performs the Termination-Action by sending a new Access- Request upon termination of the current session, it MUST include the State Attribute unchanged in that Access-Request. In either usage, the Dynamic Authorization Server MUST NOT interpret the Attribute locally. A CoA-Request packet MUST have only zero or one State Attribute. Usage of the State Attribute is implementation dependent.3.4. Message-Authenticator
The Message-Authenticator Attribute MAY be used to authenticate and integrity-protect CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, Disconnect-ACK, and Disconnect-NAK packets in order to prevent spoofing. A Dynamic Authorization Server receiving a CoA-Request or Disconnect-Request with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent. A Dynamic Authorization Client receiving a CoA/Disconnect-ACK or CoA/Disconnect-NAK with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent. When a Message-Authenticator Attribute is included within a CoA- Request or Disconnect-Request, it is calculated as follows: Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) When the HMAC-MD5 message integrity check is calculated the Request Authenticator field and Message-Authenticator Attribute MUST each be considered to be sixteen octets of zero. The Message-Authenticator Attribute is calculated and inserted in the packet before the Request Authenticator is calculated. Chiba, et al. Informational [Page 15] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 When a Message-Authenticator Attribute is included within a CoA- ACK, CoA-NAK, Disconnect-ACK, or Disconnect-NAK, it is calculated as follows: Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) When the HMAC-MD5 message integrity check is calculated, the Message-Authenticator Attribute MUST be considered to be sixteen octets of zero. The Request Authenticator is taken from the corresponding CoA/Disconnect-Request. The Message-Authenticator is calculated and inserted in the packet before the Response Authenticator is calculated.3.5. Error-Cause
Description It is possible that a Dynamic Authorization Server cannot honor Disconnect-Request or CoA-Request packets for some reason. The Error-Cause Attribute provides more detail on the cause of the problem. It MAY be included within CoA-NAK and Disconnect-NAK packets. 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 Chiba, et al. Informational [Page 16] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 values may only be sent within CoA-ACK or Disconnect-ACK packets and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet. Values 400-499 represent fatal errors committed by the Dynamic Authorization Client, so that they MAY be sent within CoA-NAK or Disconnect-NAK packets, and MUST NOT be sent within CoA-ACK or Disconnect-ACK packets. Values 500-599 represent fatal errors occurring on a Dynamic Authorization Server, so that they MAY be sent within CoA-NAK and Disconnect-NAK packets, and MUST NOT be sent within CoA-ACK or Disconnect-ACK packets. Error-Cause values SHOULD be logged by the Dynamic Authorization Client. 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 407 Invalid Attribute Value 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 508 Multiple Session Selection Unsupported "Residual Session Context Removed" is sent in response to a Disconnect-Request if one or more user sessions are 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. Chiba, et al. Informational [Page 17] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 "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. "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. This error cannot be sent in response to a Disconnect-Request. "Unsupported Extension" is a fatal error sent due to lack of support for an extension such as Disconnect and/or CoA packets. This will typically be sent by a proxy receiving an ICMP port unreachable message after attempting to forward a CoA-Request or Disconnect-Request to the NAS. "Invalid Attribute Value" is a fatal error sent if a CoA-Request or Disconnect-Request contains an attribute with an unsupported value. "Administratively Prohibited" is a fatal error sent if the NAS is configured to prohibit honoring of CoA-Request or Disconnect- Request packets for the specified session. "Request Not Routable" is a fatal error that MAY be sent by a proxy and MUST NOT be sent by a NAS. It indicates that the proxy was unable to determine how to route a CoA-Request or Disconnect- 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 CoA-Request or Disconnect-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 CoA or Disconnect-Request that could not be processed by a proxy, for reasons other than routing. Chiba, et al. Informational [Page 18] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 "Resources Unavailable" is a fatal error sent when a CoA or Disconnect-Request could not be honored due to lack of available NAS resources (memory, non-volatile storage, etc.). "Request Initiated" is a fatal error sent by a NAS in response to a CoA-Request including a Service-Type Attribute with a value of "Authorize Only". It indicates that the CoA-Request has not been honored, but that the NAS is sending one or more RADIUS Access- Requests including a Service-Type Attribute with value "Authorize Only" to the RADIUS server. "Multiple Session Selection Unsupported" is a fatal error sent by a NAS in response to a CoA-Request or Disconnect-Request whose session identification attributes match multiple sessions, where the NAS does not support Requests applying to multiple sessions. Chiba, et al. Informational [Page 19] RFC 5176 Dynamic Authorization Extensions to RADIUS January 20083.6. 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 0-1 0 0 7 Framed-Protocol (Note 3) 0-1 0 0 8 Framed-IP-Address (Notes 1, 6) 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 0+ 0 0 25 Class (Note 3) 0+ 0 0 26 Vendor-Specific (Note 7) 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) Request ACK NAK # Attribute Chiba, et al. Informational [Page 20] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 Request ACK NAK # Attribute 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+ 0 0 56 Egress-VLANID (Note 3) 0-1 0 0 57 Ingress-Filters (Note 3) 0+ 0 0 58 Egress-VLAN-Name (Note 3) 0-1 0 0 59 User-Priority-Table (Note 3) 0-1 0 0 61 NAS-Port-Type (Note 3) 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-1 0 0 89 Chargeable-User-Identity (Note 1) 0+ 0 0 90 Tunnel-Client-Auth-ID (Note 5) 0+ 0 0 91 Tunnel-Server-Auth-ID (Note 5) 0-1 0 0 92 NAS-Filter-Rule (Note 3) 0 0 0 94 Originating-Line-Info 0-1 0 0 95 NAS-IPv6-Address (Note 1) 0-1 0 0 96 Framed-Interface-Id (Notes 1, 6) 0+ 0 0 97 Framed-IPv6-Prefix (Notes 1, 6) 0+ 0 0 98 Login-IPv6-Host (Note 3) 0+ 0 0 99 Framed-IPv6-Route (Note 3) Request ACK NAK # Attribute Chiba, et al. Informational [Page 21] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 Request ACK NAK # Attribute 0-1 0 0 100 Framed-IPv6-Pool (Note 3) 0 0 0+ 101 Error-Cause 0+ 0 0 123 Delegated-IPv6-Prefix (Note 3) 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 0 0 6 Service-Type 0 0 0 8 Framed-IP-Address (Note 1) 0+ 0 0 18 Reply-Message (Note 2) 0 0 0 24 State 0+ 0 0 25 Class (Note 4) 0+ 0 0 26 Vendor-Specific (Note 7) 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 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 0 0 61 NAS-Port-Type 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 89 Chargeable-User-Identity (Note 1) 0-1 0 0 95 NAS-IPv6-Address (Note 1) 0 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 The following 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. Chiba, et al. Informational [Page 22] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 (Note 1) Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request packets, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g., within CoA-Request packets 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 Extension Authentication Protocol (EAP) is used for authentication, an EAP- Message/Notification-Request Attribute is sent instead, and Disconnect-ACK or CoA-ACK packets 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 values 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 NAS to the RADIUS 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 attributes are included within a successful CoA-Request, all existing tunnel attributes are removed and replaced by the new attribute(s). (Note 6) Since the Framed-IP-Address, Framed-IPv6-Prefix, and Framed-Interface-Id attributes are used for session identification, renumbering cannot be accomplished by including values of these attributes within a CoA-Request. Instead, a CoA-Request including a Service-Type Attribute with a value of "Authorize Only" is sent; new values can be supplied in an Access-Accept sent in response to the ensuing Access-Request. Note that renumbering will not be possible in all situations. For example, in order to change an IP address, IPCP or IPv6CP re-negotiation could be required, which is not supported by all PPP implementations. (Note 7) Within Disconnect-Request packets, Vendor-Specific Attributes (VSAs) MAY be used for session identification. Within CoA-Request packets, VSAs MAY be used for either session identification or authorization change. However, the same Attribute MUST NOT be used for both purposes simultaneously. Chiba, et al. Informational [Page 23] RFC 5176 Dynamic Authorization Extensions to RADIUS January 20084. Diameter Considerations
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 a Diameter Re-Auth-Request (RAR) to a CoA-Request and vice versa. For example, since a CoA-Request only initiates an authorization change but does not initiate re-authentication, a RAR command containing a Re-Auth-Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot be directly translated to a CoA-Request. A Diameter/RADIUS gateway receiving a CoA-Request containing authorization changes will need to translate this into two Diameter exchanges. First, the Diameter/RADIUS gateway will issue a RAR command including a Session-Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". Then the Diameter/RADIUS gateway will respond to the ensuing access request with a response including the authorization attributes gleaned from the CoA-Request. To enable translation, the CoA-Request SHOULD include a Acct-Session-Id Attribute. If the Diameter client uses the same Session-Id for both authorization and accounting, then the Diameter/RADIUS gateway can copy the contents of the Acct- Session-Id Attribute into the Session-Id AVP; otherwise, it will need to map the Acct-Session-Id value to an equivalent Session-Id for use within a RAR command. Where an Acct-Session-Id Attribute is not present in a CoA-Request or Disconnect-Request, a Diameter/RADIUS gateway will either need to determine the appropriate Acct-Session-Id or, if it cannot do so, it can send a CoA-NAK or Disconnect-NAK in reply, possibly including an Error-Cause Attribute with a value of 508 (Multiple Session Selection Unsupported). To simplify translation between RADIUS and Diameter, Dynamic Authorization Clients can include a Service-Type Attribute with value "Authorize Only" within a CoA-Request, as described in Section 3.2. A Diameter/RADIUS gateway receiving a CoA-Request containing a Service-Type Attribute with a value "Authorize Only" translates this to a RAR with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". The received RAA is then translated to a CoA-NAK with a Service-Type Attribute with value "Authorize Only". If the Result-Code AVP in the RAA has a value in the success category, then an Error-Cause Attribute with value "Request Initiated" is included in the CoA-NAK. If the Result-Code AVP in the RAA has a value indicating a Protocol Error or a Transient or Permanent Failure, then an alternate Error- Cause Attribute is returned as suggested below. Within Diameter, a server can request that a session be aborted by sending an Abort-Session-Request (ASR), identifying the session to be terminated using Session-ID and User-Name AVPs. The ASR command is Chiba, et al. Informational [Page 24] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 translated to a Disconnect-Request containing Acct-Session-Id and User-Name attributes. If the Diameter client utilizes the same Session-Id in both authorization and accounting, then the value of the Session-ID AVP may be placed in the Acct-Session-Id Attribute; otherwise the value of the Session-ID AVP will need to be mapped to an appropriate Acct-Session-Id Attribute. To enable translation of a Disconnect-Request to an ASR, an Acct-Session-Id Attribute SHOULD be present. If the Diameter client utilizes the same Session-Id in both authorization and accounting, then the value of the Acct-Session-Id Attribute may be placed into the Session-ID AVP within the ASR; otherwise the value of the Acct-Session-Id Attribute will need to be mapped to an appropriate Session-ID AVP. An Abort-Session-Answer (ASA) command is sent in response to an ASR in order to indicate the disposition of the request. A Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS". A Disconnect-NAK received from the NAS is translated to an ASA command with a Result-Code AVP that depends on the value of the Error-Cause Attribute. Suggested translations between Error-Cause Attribute values and Result-Code AVP values are included below: # Error-Cause Attribute Value Result-Code AVP --- --------------------------- ------------------------ 201 Residual Session Context DIAMETER_SUCCESS Removed 202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS (Ignored) 401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED 402 Missing Attribute DIAMETER_MISSING_AVP 403 NAS Identification DIAMETER_REALM_NOT_SERVED Mismatch 404 Invalid Request DIAMETER_UNABLE_TO_COMPLY 405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED 406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED 407 Invalid Attribute Value DIAMETER_INVALID_AVP_VALUE 501 Administratively DIAMETER_AUTHORIZATION_REJECTED Prohibited 502 Request Not Routable (Proxy) DIAMETER_UNABLE_TO_DELIVER 503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID 504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED Removable 505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY Error 506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED 507 Request Initiated DIAMETER_SUCCESS Chiba, et al. Informational [Page 25] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 Since both the ASR/ASA and Disconnect-Request/Disconnect- NAK/Disconnect-ACK exchanges involve just a request and response, inclusion of an "Authorize Only" Service-Type within a Disconnect- Request is not needed to assist in Diameter/RADIUS translation, and may make translation more difficult. As a result, as noted in Section 3.2, the Service-Type Attribute MUST NOT be used within a Disconnect-Request.5. IANA Considerations
This document uses the RADIUS [RFC2865] namespace; see <http://www.iana.org/assignments/radius-types>. In addition to the allocations already made in [RFC3575] and [RFC3576], this specification allocates additional values of the Error-Cause Attribute (101): # Value --- ----- 407 Invalid Attribute Value 508 Multiple Session Selection Unsupported6. Security Considerations
6.1. Authorization Issues
Where a NAS is shared by multiple providers, it is undesirable for one provider to be able to send Disconnect-Requests or CoA-Requests affecting the sessions of another provider. A Dynamic Authorization Server MUST silently discard Disconnect- Request or CoA-Request packets from untrusted sources. In situations where the Dynamic Authorization Client is co-resident with a RADIUS authentication or accounting server, a proxy MAY perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized Dynamic Authorization Client. 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 packets relating to users within a set of realms. To perform the RPF check, the Dynamic Authorization Server uses the session identification attributes included in Disconnect-Request or CoA-Request packets, 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 CoA-Request or Disconnect-Request is forwarded; otherwise it MUST be silently discarded. Chiba, et al. Informational [Page 26] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 Typically, the Dynamic Authorization Server will extract the realm from the Network Access Identifier [RFC4282] included within the User-Name or Chargeable-User-Identity Attribute, and determine the corresponding RADIUS servers in the realm routing tables. If the Dynamic Authorization Server maintains long-term session state, it MAY perform the authorization check based on the session identification attributes in the CoA-Request. The session identification attributes can be used to tie a session to a particular proxy or set of proxies, as with the NAI realm. Where no proxy is present, the RPF check can only be performed by the NAS if it maintains its own a realm routing table. If the NAS does not maintain a realm routing table (e.g., it selects forwarding proxies based on primary/secondary configuration and/or liveness checks), then an RPF check cannot be performed. Since authorization to send a Disconnect-Request or CoA-Request is determined based on the source address and the corresponding shared secret, the Dynamic Authorization Server SHOULD configure a different shared secret for each Dynamic Authorization Client.6.2. IPsec Usage Guidelines
In addition to security vulnerabilities unique to Disconnect or CoA packets, 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, utilizing the profile described in [RFC3579], Section 4.2. For Dynamic Authorization Servers implementing this specification, the IPsec policy would be "Require IPsec, from any to me, destination port UDP 3799". This causes the Dynamic Authorization Server to require use of IPsec. If some Dynamic Authorization Clients do not support IPsec, then a more granular policy will be required: "Require IPsec, from IPsec-Capable-DAC to me". For Dynamic Authorization Clients implementing this specification, the IPsec policy would be "Initiate IPsec, from me to any, destination port UDP 3799". This causes the Dynamic Authorization Client to initiate IPsec when sending Dynamic Authorization traffic to any Dynamic Authorization Server. If some Dynamic Authorization Servers contacted by the Dynamic Authorization Client do not support IPsec, then a more granular policy will be required, such as "Initiate IPsec, from me to IPsec-Capable-DAS, destination port UDP 3799". Chiba, et al. Informational [Page 27] RFC 5176 Dynamic Authorization Extensions to RADIUS January 20086.3. Replay Protection
Where IPsec replay protection is not used, an Event-Timestamp (55) [RFC2869] Attribute SHOULD be included within CoA-Request and Disconnect-Request packets, and MAY be included within CoA-ACK, CoA- NAK, Disconnect-ACK, and Disconnect-NAK packets. When the Event-Timestamp Attribute is present, both the Dynamic Authorization Server and the Dynamic Authorization Client MUST check that the Event-Timestamp Attribute is current within an acceptable time window. If the Event-Timestamp Attribute is not current, then the packet MUST be silently discarded. This implies the need for loose time synchronization within the network, which can be achieved by a variety of means, including Simple Network Time Protocol (SNTP), as described in [RFC4330]. Implementations SHOULD be configurable to discard CoA-Request or Disconnect-Request packets not containing an Event-Timestamp Attribute. If the Event-Timestamp Attribute is included, it represents the time at which the original packet was sent, and therefore it SHOULD NOT be updated when the packet is retransmitted. If the Event-Timestamp Attribute is not updated, this implies that the Identifier is not changed in retransmitted packets. As a result, the ability to detect replay within the time window is dependent on support for duplicate detection within that same window. As noted in Section 2.3, duplicate detection is REQUIRED for Dynamic Authorization Servers implementing this specification. The time window used for duplicate detection MUST be the same as the window used to detect a stale Event-Timestamp Attribute. Since the RADIUS Identifier cannot be repeated within the selected time window, no more than 256 Requests can be accepted within the time window. As a result, the chosen time window will depend on the expected maximum volume of CoA/Disconnect-Requests, so that unnecessary discards can be avoided. A default time window of 300 seconds should be adequate in many circumstances.7. 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 Chiba, et al. Informational [Page 28] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 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 02038. References
8.1. Normative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "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. [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 2003. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. Chiba, et al. Informational [Page 29] RFC 5176 Dynamic Authorization Extensions to RADIUS January 20088.2. Informative References
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting Transport Profile", RFC 3539, June 2003. [RFC3576] 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. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006. [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006. [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. [RFC4849] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Filter Rule Attribute", RFC 4849, April 2007.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 valuable suggestions and feedback from Avi Lior, Randy Bush, Steve Bellovin, Glen Zorn, Mark Jones, Claudio Lapidus, Anurag Batta, Kuntal Chowdhury, Tim Moore, Russ Housley, Joe Salowey, Alan DeKok, and David Nelson. Chiba, et al. Informational [Page 30] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 Appendix A. Changes from RFC 3576 This Appendix lists the major changes between [RFC3576] and this document. Minor changes, including style, grammar, spelling, and editorial changes, are not mentioned here. o The term "Dynamic Authorization Client" is used instead of RADIUS server where it applies to the originator of CoA-Request and Disconnect-Request packets. The term "Dynamic Authorization Server" is used instead of NAS where it applies to the receiver of CoA- Request and Disconnect-Request packets. Definitions of these terms have been added (Section 1.3). o Added requirement for duplicate detection on the Dynamic Authorization Server (Section 2.3). o Clarified expected behavior when session identification attributes match more than one session (Sections 2.3, 3, 3.5, 4). o Added Chargeable-User-Identity as a session identification attribute. Removed NAS-Port-Type as a session identification attribute (Section 3). o Added recommendation that an Acct-Session-Id or Acct-Multi- Session-Id Attribute be included in an Access-Request (Section 3). o Added discussion of scenarios in which the "Dynamic Authorization Client" and RADIUS server are not co-located (Section 3). o Added details relating to handling of the Proxy-State Attribute (Section 3.1). o Added clarification that support for a Service-Type Attribute with value "Authorize Only" is optional on both the NAS and Dynamic Authorization Client (Section 3.2). Use of the Service-Type Attribute within a Disconnect-Request is prohibited (Sections 3.2, 3.6). o Added requirement for inclusion of the State Attribute in CoA- Request packets including a Service-Type Attribute with a value of "Authorize Only" (Section 3.3). o Added clarification on the calculation of the Message- Authenticator Attribute (Section 3.4). o Additional Error-Cause Attribute values are allocated for Invalid Attribute Value (407) and Multiple Session Selection Identification (508) (Sections 3.5, 4). Chiba, et al. Informational [Page 31] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 o Updated the CoA-Request Attribute Table to include Filter-Rule, Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress- VLAN-Name, and User-Priority attributes (Section 3.6). o Added the Chargeable-User-Identity Attribute to both the CoA- Request and Disconnect-Request Attribute table (Section 3.6). o Use of Vendor-Specific Attributes (VSAs) for session identification and authorization change has been clarified (Section 3.6). o Added Note 6 on the use of the CoA-Request for renumbering, and Note 7 on the use of Vendor-Specific attributes (Section 3.6). o Added Diameter Considerations (Section 4). o Event-Timestamp Attribute should not be recalculated on retransmission. The implications for replay and duplicate detection are discussed (Section 6.3). o Operation of the Reverse Path Forwarding (RPF) check has been clarified. Use of the RPF check is optional rather than recommended by default (Section 6.1). o Text on impersonation (included in [RFC3579], Section 4.3.7) and IPsec operation (included in [RFC3579], Section 4.2) has been removed, and is now referenced. Chiba, et al. Informational [Page 32] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 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 RSA, Security Division of EMC 174 Middlesex Turnpike Bedford, MA 01730 EMail<EMAIL_ADDRESS>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 33] RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.  Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at<EMAIL_ADDRESS>Chiba, et al. Informational [Page 34]


Copy RSS URL Copied!
Glenn McCoy by Glenn McCoy for May 10, 2018
Glenn McCoy by Glenn McCoy for May 7, 2018
Glenn McCoy by Glenn McCoy for May 4, 2018
Glenn McCoy by Glenn McCoy for May 3, 2018
Glenn McCoy by Glenn McCoy for May 2, 2018
Glenn McCoy by Glenn McCoy for Apr 30, 2018
Glenn McCoy by Glenn McCoy for Apr 20, 2018
Glenn McCoy by Glenn McCoy for Apr 16, 2018
Glenn McCoy by Glenn McCoy for Apr 13, 2018
Glenn McCoy by Glenn McCoy for Apr 12, 2018
Glenn McCoy by Glenn McCoy for Apr 11, 2018
Glenn McCoy by Glenn McCoy for Apr 10, 2018
Glenn McCoy by Glenn McCoy for Apr 5, 2018
Glenn McCoy by Glenn McCoy for Apr 4, 2018
View on GitHub -
Made by Joseph Dykstra -
Patreon
Generated on Mon May 21 2018


- PackageCompactConstructor - Class in org.yaml.snakeyaml.extensions.compactnotation
-
- PackageCompactConstructor(String) - Constructor for class org.yaml.snakeyaml.extensions.compactnotation.PackageCompactConstructor
-
- PAIRS - Static variable in class org.yaml.snakeyaml.nodes.Tag
-
- parse(Reader) - Method in class org.yaml.snakeyaml.Yaml
-
Parse a YAML stream and produce parsing events.
- Parser - Interface in org.yaml.snakeyaml.parser
-
This interface represents an input stream of
Events
.
- ParserException - Exception in org.yaml.snakeyaml.parser
-
Exception thrown by the
Parser
implementations in case of malformed
input.
- ParserException(String, Mark, String, Mark) - Constructor for exception org.yaml.snakeyaml.parser.ParserException
-
Constructs an instance.
- ParserImpl - Class in org.yaml.snakeyaml.parser
-
# The following YAML grammar is LL(1) and is parsed by a recursive descent
parser.
- ParserImpl(StreamReader) - Constructor for class org.yaml.snakeyaml.parser.ParserImpl
-
- peek() - Method in class org.yaml.snakeyaml.reader.StreamReader
-
- peek(int) - Method in class org.yaml.snakeyaml.reader.StreamReader
-
Peek the next index-th character
- peekEvent() - Method in interface org.yaml.snakeyaml.parser.Parser
-
Return the next event, but do not delete it from the stream.
- peekEvent() - Method in class org.yaml.snakeyaml.parser.ParserImpl
-
Get the next event.
- peekToken() - Method in interface org.yaml.snakeyaml.scanner.Scanner
-
Return the next token, but do not delete it from the stream.
- peekToken() - Method in class org.yaml.snakeyaml.scanner.ScannerImpl
-
Return the next token, but do not delete it from the queue.
- PercentEscaper - Class in org.yaml.snakeyaml.external.com.google.gdata.util.common.base
-
A UnicodeEscaper
that escapes some set of Java characters using the
URI percent encoding scheme.
- PercentEscaper(String, boolean) - Constructor for class org.yaml.snakeyaml.external.com.google.gdata.util.common.base.PercentEscaper
-
Constructs a URI escaper with the specified safe characters and optional
handling of the space character.
- pop() - Method in class org.yaml.snakeyaml.util.ArrayStack
-
- PREFIX - Static variable in class org.yaml.snakeyaml.nodes.Tag
-
- prefix(int) - Method in class org.yaml.snakeyaml.reader.StreamReader
-
peek the next length characters
- prefixForward(int) - Method in class org.yaml.snakeyaml.reader.StreamReader
-
prefix(length) immediately followed by forward(length)
- Property - Class in org.yaml.snakeyaml.introspector
-
A Property
represents a single member variable of a class,
possibly including its accessor methods (getX, setX).
- Property(String, Class<?>) - Constructor for class org.yaml.snakeyaml.introspector.Property
-
- PropertyUtils - Class in org.yaml.snakeyaml.introspector
-
- PropertyUtils() - Constructor for class org.yaml.snakeyaml.introspector.PropertyUtils
-
- push(T) - Method in class org.yaml.snakeyaml.util.ArrayStack
-
- putListPropertyType(String, Class<? extends Object>) - Method in class org.yaml.snakeyaml.TypeDescription
-
Specify that the property is a type-safe List
.
- putMapPropertyType(String, Class<? extends Object>, Class<? extends Object>) - Method in class org.yaml.snakeyaml.TypeDescription
-
Specify that the property is a type-safe Map
.


{# This template is not served, but written as a file to open in the browser, passing the token without putting it in a command-line argument. #}
This page should redirect you to Jupyter Notebook. If it doesn't, click here to go to Jupyter.


MK-BUILD-DEPS(1) MK-BUILD-DEPS(1) NAME mk-build-deps - build a package satisfying a package's build-dependencies SYNOPSIS mk-build-deps --help|--version mk-build-deps [options] control file | package name ... DESCRIPTION Given a package name and/or control file, mk-build-deps will use equivs to generate a binary package which may be installed to satisfy all the build dependencies of the given package. If --build-dep and/or --build-indep are given, then the resulting binary package(s) will depend solely on the Build-Depends/Build-Depends-Indep dependencies, respectively. OPTIONS -i, --install Install the generated packages and its build-dependencies. -t, --tool When installing the generated package use the specified tool. (default: apt-get --no-install-recommends) -r, --remove Remove the package file after installing it. Ignored if used without the --install switch. -a foo, --arch foo If the source package has architecture-specific build dependencies, produce a package for architecture foo, not for the system architecture. (If the source package does not have architecture- specific build dependencies, the package produced is always for the pseudo-architecture all.) -B, --build-dep Generate a package which only depends on the source package's Build- Depends dependencies. -A, --build-indep Generate a package which only depends on the source package's Build- Depends-Indep dependencies. -h, --help Show a summary of options. -v, --version Show version and copyright information. -s, --root-cmd Use the specified tool to gain root privileges before installing. Ignored if used without the --install switch. AUTHOR mk-build-deps is copyright by Vincent Fourmond and was modified for the devscripts package by Adam D. Barratt<EMAIL_ADDRESS>This program comes with ABSOLUTELY NO WARRANTY. You are free to redistribute this code under the terms of the GNU General Public License, version 2 or later. Debian Utilities 2013-12-23 MK-BUILD-DEPS(1)


Timecode: 00:00:00,00
RESET TIMER
Project: Untitled Project
Producer:
Onscreen Talent:
Project Date:
Current FPS:
UPDATE FPS
RESET OVERALL PROJECT INFORMATION
Comments:
START
RESET NOTES
SAVE as TEXT
SAVE as SRT
#
Timecode
Note


Hi!
A minor bugfix release to fix all old unsecure links to getbblog.com api and updated it to use https instead.
Also fixed a minor issue with bfstats api links to leaderboards
https://getbblog.com/en/board/topic/145444/1/bf4stats-com-stats-error-with-ranks-from-1-to-50
Have nice holidays and a happy new year if we don't hear us again before.


Soldier Who Shot Lebanese Protester Dead Charged With Murder
Lebanon´s state-run National News Agency said a soldier who shot and killed a protester in Beirut last week has been charged by a military prosecutor with murder.
The agency reported that a colonel who was on the scene with the soldier at the time of the shooting was also charged Thursday, according to AFP.
On Nov. 12, Alaa Abu Fakhr was shot dead by the soldier, who was trying to open a road closed by protesters in southern Beirut, marking the first death since widespread protests against Lebanon´s ruling elite began Oct. 17.
The soldier, who has been under detention since the day of the shooting, and the colonel were referred to a military investigative judge who will start questioning them on Monday, according to NNA.


|
Bullet Collision Detection & Physics Library
|
btGImpactCompoundShape allows to handle multiple btCollisionShape objects at once More...
#include <btGImpactShape.h>
Classes | |
| class | CompoundPrimitiveManager |
| compound primitive manager More... | |
Public Member Functions | |
| btGImpactCompoundShape (bool children_has_transform=true) | |
| virtual | ~btGImpactCompoundShape () |
| virtual bool | childrenHasTransform () const |
| if true, then its children must get transforms. More... | |
| virtual const btPrimitiveManagerBase * | getPrimitiveManager () const |
| Obtains the primitive manager. More... | |
| CompoundPrimitiveManager * | getCompoundPrimitiveManager () |
| Obtains the compopund primitive manager. More... | |
| virtual int | getNumChildShapes () const |
| Gets the number of children. More... | |
| void | addChildShape (const btTransform &localTransform, btCollisionShape *shape) |
| Use this method for adding children. Only Convex shapes are allowed. More... | |
| void | addChildShape (btCollisionShape *shape) |
| Use this method for adding children. Only Convex shapes are allowed. More... | |
| virtual btCollisionShape * | getChildShape (int index) |
| Gets the children. More... | |
| virtual const btCollisionShape * | getChildShape (int index) const |
| Gets the children. More... | |
| virtual void | getChildAabb (int child_index, const btTransform &t, btVector3 &aabbMin, btVector3 &aabbMax) const |
| Retrieves the bound from a child. More... | |
| virtual btTransform | getChildTransform (int index) const |
| Gets the children transform. More... | |
| virtual void | setChildTransform (int index, const btTransform &transform) |
| Sets the children transform. More... | |
| virtual bool | needsRetrieveTriangles () const |
| Determines if this shape has triangles. More... | |
| virtual bool | needsRetrieveTetrahedrons () const |
| Determines if this shape has tetrahedrons. More... | |
| virtual void | getBulletTriangle (int prim_index, btTriangleShapeEx &triangle) const |
| virtual void | getBulletTetrahedron (int prim_index, btTetrahedronShapeEx &tetrahedron) const |
| virtual void | calculateLocalInertia (btScalar mass, btVector3 &inertia) const |
| Calculates the exact inertia tensor for this shape. More... | |
| virtual const char * | getName () const |
| virtual eGIMPACT_SHAPE_TYPE | getGImpactShapeType () const |
| Subshape member functions. More... | |
| Public Member Functions inherited from btGImpactShapeInterface | |
| btGImpactShapeInterface () | |
| void | updateBound () |
| performs refit operation More... | |
| void | getAabb (const btTransform &t, btVector3 &aabbMin, btVector3 &aabbMax) const |
| If the Bounding box is not updated, then this class attemps to calculate it. More... | |
| virtual void | postUpdate () |
| Tells to this object that is needed to refit the box set. More... | |
| const btAABB & | getLocalBox () |
| Obtains the local box, which is the global calculated box of the total of subshapes. More... | |
| virtual int | getShapeType () const |
| virtual void | setLocalScaling (const btVector3 &scaling) |
| virtual const btVector3 & | getLocalScaling () const |
| virtual void | setMargin (btScalar margin) |
| virtual void | rayTest (const btVector3 &rayFrom, const btVector3 &rayTo, btCollisionWorld::RayResultCallback &resultCallback) const |
| virtual method for ray collision More... | |
| virtual void | processAllTriangles (btTriangleCallback *callback, const btVector3 &aabbMin, const btVector3 &aabbMax) const |
| Function for retrieve triangles. More... | |
| virtual void | processAllTrianglesRay (btTriangleCallback *, const btVector3 &, const btVector3 &) const |
| Function for retrieve triangles. More... | |
| const btGImpactBoxSet * | getBoxSet () const |
| gets boxset More... | |
| bool | hasBoxSet () const |
| Determines if this class has a hierarchy structure for sorting its primitives. More... | |
| virtual void | lockChildShapes () const |
| call when reading child shapes More... | |
| virtual void | unlockChildShapes () const |
| void | getPrimitiveTriangle (int index, btPrimitiveTriangle &triangle) const |
| if this trimesh More... | |
| Public Member Functions inherited from btConcaveShape | |
| BT_DECLARE_ALIGNED_ALLOCATOR () | |
| btConcaveShape () | |
| virtual | ~btConcaveShape () |
| virtual btScalar | getMargin () const |
| Public Member Functions inherited from btCollisionShape | |
| BT_DECLARE_ALIGNED_ALLOCATOR () | |
| btCollisionShape () | |
| virtual | ~btCollisionShape () |
| virtual void | getBoundingSphere (btVector3 ¢er, btScalar &radius) const |
| virtual btScalar | getAngularMotionDisc () const |
| getAngularMotionDisc returns the maximum radius needed for Conservative Advancement to handle time-of-impact with rotations. More... | |
| virtual btScalar | getContactBreakingThreshold (btScalar defaultContactThresholdFactor) const |
| void | calculateTemporalAabb (const btTransform &curTrans, const btVector3 &linvel, const btVector3 &angvel, btScalar timeStep, btVector3 &temporalAabbMin, btVector3 &temporalAabbMax) const |
| calculateTemporalAabb calculates the enclosing aabb for the moving object over interval [0..timeStep) result is conservative More... | |
| bool | isPolyhedral () const |
| bool | isConvex2d () const |
| bool | isConvex () const |
| bool | isNonMoving () const |
| bool | isConcave () const |
| bool | isCompound () const |
| bool | isSoftBody () const |
| bool | isInfinite () const |
| isInfinite is used to catch simulation error (aabb check) More... | |
| int | getShapeType () const |
| virtual btVector3 | getAnisotropicRollingFrictionDirection () const |
| the getAnisotropicRollingFrictionDirection can be used in combination with setAnisotropicFriction See Bullet/Demos/RollingFrictionDemo for an example More... | |
| void | setUserPointer (void *userPtr) |
| optional user data pointer More... | |
| void * | getUserPointer () const |
| void | setUserIndex (int index) |
| int | getUserIndex () const |
| virtual int | calculateSerializeBufferSize () const |
| virtual const char * | serialize (void *dataBuffer, btSerializer *serializer) const |
| fills the dataBuffer and returns the struct name (and 0 on failure) More... | |
| virtual void | serializeSingleShape (btSerializer *serializer) const |
Protected Attributes | |
| CompoundPrimitiveManager | m_primitive_manager |
| btAlignedObjectArray< btTransform > | m_childTransforms |
| btAlignedObjectArray< btCollisionShape * > | m_childShapes |
| Protected Attributes inherited from btGImpactShapeInterface | |
| btAABB | m_localAABB |
| bool | m_needs_update |
| btVector3 | localScaling |
| btGImpactBoxSet | m_box_set |
| Protected Attributes inherited from btConcaveShape | |
| btScalar | m_collisionMargin |
| Protected Attributes inherited from btCollisionShape | |
| int | m_shapeType |
| void * | m_userPointer |
| int | m_userIndex |
Additional Inherited Members | |
| Protected Member Functions inherited from btGImpactShapeInterface | |
| virtual void | calcLocalAABB () |
| use this function for perfofm refit in bounding boxes use this function for perfofm refit in bounding boxes More... | |
btGImpactCompoundShape allows to handle multiple btCollisionShape objects at once
This class only can manage Convex subshapes
Definition at line 294 of file btGImpactShape.h.
|
inline |
Definition at line 359 of file btGImpactShape.h.
|
inlinevirtual |
Definition at line 366 of file btGImpactShape.h.
|
inline |
Use this method for adding children. Only Convex shapes are allowed.
Definition at line 396 of file btGImpactShape.h.
|
inline |
Use this method for adding children. Only Convex shapes are allowed.
Definition at line 404 of file btGImpactShape.h.
|
virtual |
Calculates the exact inertia tensor for this shape.
Implements btCollisionShape.
Definition at line 78 of file btGImpactShape.cpp.
|
inlinevirtual |
if true, then its children must get transforms.
Implements btGImpactShapeInterface.
Definition at line 371 of file btGImpactShape.h.
|
inlinevirtual |
Implements btGImpactShapeInterface.
Definition at line 474 of file btGImpactShape.h.
|
inlinevirtual |
Implements btGImpactShapeInterface.
Definition at line 467 of file btGImpactShape.h.
|
inlinevirtual |
Retrieves the bound from a child.
Reimplemented from btGImpactShapeInterface.
Definition at line 425 of file btGImpactShape.h.
|
inlinevirtual |
Gets the children.
Implements btGImpactShapeInterface.
Definition at line 411 of file btGImpactShape.h.
|
inlinevirtual |
Gets the children.
Implements btGImpactShapeInterface.
Definition at line 417 of file btGImpactShape.h.
|
inlinevirtual |
Gets the children transform.
Implements btGImpactShapeInterface.
Definition at line 438 of file btGImpactShape.h.
|
inline |
Obtains the compopund primitive manager.
Definition at line 384 of file btGImpactShape.h.
|
inlinevirtual |
Subshape member functions.
Base method for determinig which kind of GIMPACT shape we get
Implements btGImpactShapeInterface.
Definition at line 489 of file btGImpactShape.h.
|
inlinevirtual |
Implements btCollisionShape.
Definition at line 484 of file btGImpactShape.h.
|
inlinevirtual |
Gets the number of children.
Implements btGImpactShapeInterface.
Definition at line 390 of file btGImpactShape.h.
|
inlinevirtual |
Obtains the primitive manager.
Implements btGImpactShapeInterface.
Definition at line 378 of file btGImpactShape.h.
|
inlinevirtual |
Determines if this shape has tetrahedrons.
Implements btGImpactShapeInterface.
Definition at line 462 of file btGImpactShape.h.
|
inlinevirtual |
Determines if this shape has triangles.
Implements btGImpactShapeInterface.
Definition at line 456 of file btGImpactShape.h.
|
inlinevirtual |
Sets the children transform.
Implements btGImpactShapeInterface.
Definition at line 448 of file btGImpactShape.h.
|
protected |
Definition at line 356 of file btGImpactShape.h.
|
protected |
Definition at line 355 of file btGImpactShape.h.
|
protected |
Definition at line 354 of file btGImpactShape.h.


Glad to see some love for the big screen. I always wondered why so many people optimize for mobile to the nth degree, and then ignore screens over 960px. So much real estate available to display great content, and less of a concern over bandwidth means you can serve up great imagery and typography.
Glad to see some love for the big screen. I always wondered why so many people optimize for mobile to the nth degree, and then ignore screens over 960px. So much real estate available to display great content, and less of a concern over bandwidth means you can serve up great imagery and typography.


Dilby III
Carrie, my wonderful wife, hasn’t had much luck with the frames I’ve made her over the years. In 2008, I made her a touring frame set she named Dilby. Carrie rode Dilby into a moving car and the car won. Carrie came out of the crash with just some scrapes. A few years later I made her Dilby II. Dilby II was an excellent companion until he was stolen while Carrie was grocery shopping.
Carrie uses her bike for transportation, day rides, and unsupported touring. She needs a bike that can brave all weather and carry heavy loads while handling predictably. Since she’s 5’2″, Carrie has had issues with severe toe overlap and front end instability with the production frames she’s ridden. She’s also a cautious descender. At the end of long descents her hands and upper body are fatigued from keeping her speed in check.
Although 26″ wheels aren’t popular these days, they’re a great option for shorter riders and tourists looking for strong wheels. I designed Dilby III for 26×1.8 tires and 60 mm fenders for maximum coverage. The smaller tire size also limits the impact of toe overlap.
Carrie likes using flat bars. More recently she’s enjoyed the excellent Jones Bar. However, the loop in the Jones Bar blocks access to a handlebar bag. Instead, Dilby III sports the Velo Orange Crazy Bar. The Crazy Bar has the same 45º swept back position as the Jones but goes one step crazier with the addition of bull horns. Since the Jones and Crazy bars sweeps back, I was able to push out the front to totally eliminate toe overlap.
To combat upper body fatigue on long descents, Dilby III will be sporting hydraulic disc brakes. Carrie will only have to use one finger on each brake to easily control her speed.
Using hydro brakes on a touring bike isn’t common because most tourists don’t want to deal with the hassle of bleeding brakes or a cut brake hose while on tour. Since the reliability of hydro brakes has improved dramatically, I’m not worried about any problems while on tour. I’ll plan to bleed the brakes before any long tour as part of routine bike maintenance prep.
Dilby III also has integrated dynamo lighting. A majority of the wiring runs inside the frame tubes to prevent damage and to keep the bike looking tidy. The B&M IQ-X headlight mounts to the custom front rack while the B&M Toplight Line Small taillight will eventually attach to a Tubus Vega rear rack.


Always check the initially compromised system first. There’s really no point is running around the network looking for Domain Admin processes if you already have one. Below is a simple way to check if any Domain Admin processes are running using native commands:
- Run the following command to get a list of domain admins: net group “Domain Admins” /domain
- Run the following command to list processes and process owners. The account running the process should be in the 7th column. Tasklist /v
- Cross reference the task list with the Domain Admin list to see if you have a winner.


{% extends "header.html" %} {% block content %}
Here at our important company, we value our employees!
We give our employees 50 days of paid vacation per year, and below are the current totals for our employees:
Hello, it's the Intern!
I'm excited to be here! I'm posting this message as a reminder that we will be getting your W2 forms handed back to you in the store this week! As I'm an intern and I don't know who all of you are, please make it simple and do the following on Friday:
Thanks, and have a great rest of your day!!! :)
I'm sure you've all heard of the pandemic by now, and we're working towards a solution as a company. For the time being, we're allowing our IT Staff to work from home. We had our Intern add this functionality into this site, so they can work remotely.
HR Tasks {% endblock %}


Hallmark Movies job: Watch 24 movies before Christmas Day, get $1,000
by Natalie Dreier, Cox Media Group National Content DeskMany people already do it for free, but how would you like to snuggle up with a glass of wine (or your favorite beverage) and binge-watch 24 of the 40 new Hallmark movies in the 12 days before Christmas Day and earn $1,000?
It's really a job, and Century Link Quote is looking for the perfect person for the gig.
You have to be 18 or older and know how to use Instagram, Twitter, Facebook and use them to document your viewing habits, sharing your honest opinions on each of the 24 movies to your followers with the hashtag #CountdowntoChristmas and #HallmarkDreamJob in each post.
You also should submit a 2- to 3-minute video showing all of your Christmas cheer.
If chosen, Century Link says you'll get a subscription to Hallmark Movies Channel streaming service, cocoa, Christmas cookies, twinkling lights, a mini Christmas tree and other Hallmark-branded gifts.
Click here to apply.


{% extends 'parts/layout.html' -%} {# INCLUDE HEADER #} {% block header -%} {% include 'parts/header.html' -%} {%- endblock %} {# Content Block #} {% block content -%} Not Found Ouch! We can't deliver your package. Do you requested a wrong package? {{ error }} {%- endblock %} {# FOOTER INJECTION #} {% block footer -%} {% set footclass = '' %} {% include 'parts/footer.html' -%} {%- endblock %}
{{ error }}


chocolate pizza
posted on 15 Dec 2013/DESSERTS
Position the oven rack on the bottom of the oven and preheat to 450 degrees then Line a heavy large baking sheet with parchment paper. Roll out the dough to a 9-inch-diameter round. Transfer the dough to the prepared baking sheet. Using your fingers, make indentations all over the dough. Brush the dough with butter, then bake until the crust is crisp and pale golden brown, about 20 minutes. Immediately spread the chocolate-hazelnut spread over the pizza then sprinkle all the chocolate chips over. Bake just until the chocolate begins to melt, about 1 minute. Sprinkle the hazelnuts over the pizza. Cut into wedges and serve then step 3 Mix the warm water and yeast in a small bowl to blend. Let stand until the yeast dissolves, about 5 minutes. Mix the flour and salt in a food processor to blend. Blend in the oil. With the machine running, add the yeast mixture and blend just until the dough forms. Turn the dough out onto lightly floured surface and knead until smooth, about 1 minute. Transfer the dough to a large oiled bowl and turn the dough to coat with the oil. Cover the bowl with plastic wrap and set aside in a warm draft-free area until the dough doubles in volume, about 1 hour. Punch the down dough and form into ball. The dough can be used immediately or stored airtight in the refrigerator for 1 day.