1 / 9

RADIUS Issues and Fixes

RADIUS Issues and Fixes. David B. Nelson IETF 60, RADEXT WG August 5, 2004. Mandatory vs. Optional Attributes in RFC2865. RADIUS does not have any explicit attribute tagging as to optional or mandatory RFC2865 does say (text “A”):

williamwalls
Download Presentation

RADIUS Issues and Fixes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RADIUS Issues and Fixes David B. Nelson IETF 60, RADEXT WG August 5, 2004

  2. Mandatory vs. Optional Attributes in RFC2865 • RADIUS does not have any explicit attribute tagging as to optional or mandatory • RFC2865 does say (text “A”): • “A RADIUS server MAY ignore Attributes with an unknown Type.” • “A RADIUS client MAY ignore Attributes with an unknown Type.” • “Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.”

  3. Mandatory vs. Optional Attributes in RFC2865 • RFC2586 also says (text “B”): • This Attribute indicates the type of service the user has requested, or the type of service to be provided. It MAY be used in both Access-Request and Access-Accept packets. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead. • This text applies only to the Service-Type attribute.

  4. Mandatory vs. Optional Attributes in RFC2865 • However, RFC2865 also says (text “C”): • A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A NASMUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead. • In this case it is more clear that the “treat as a reject” action applies to any collection of attributes that constitute a service definition.

  5. Mandatory vs. Optional Attributes in RFC2865 • It is apparent, therefore, that RADIUS has a general category of optional attributes (i.e. ones that MAY be ignored) • RADIUS also has a general category of attributes that are mandatory (i.e. ones that MUST not be ignored) • There seems to be an internal inconsistency between the text of (A) and the text of (B) and (C). • The text of (A) and (B) dates back to RFC2058. • The text of (C) appears in RFC2865. • It would seem that the “MAY ignore” text applies to any attributes that the NAS does not recognize except for those defining services. • Attributes defining services are implicitly mandatory attributes. • This clarification should probably be added to a RADIUS Issues and Fixes draft.

  6. Request ID Supplementation • In RFC 3579, the recommended practices to supplement the Request-ID are described: • “In EAP, each session has its own unique Identifier space. RADIUS server implementations MUST be able to distinguish between EAP packets with the same Identifier existing within distinct sessions, originating on the same NAS. For this purpose, sessions can be distinguished based on NAS and session identification attributes. NAS identification attributes include NAS-Identifier, NAS-IPv6-Address and NAS-IPv4-Address. Session identification attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id, Called-Station-Id, Calling-Station-Id and Originating-Line-Info.”

  7. Request ID Supplementation • This practice applies to other types of RADIUS requests, other than those involving EAP. • It is commonly a problem on high port density devices. • Is this practice clearly defined? • Is it commonly implemented? • Is it sufficient to address the Request-ID number space “wrap-around” issue?

  8. What the heck is an SSA? • There has been discussion on the RADEXT WG mailing list about an SDO-Specific Attribute (SSA). • It is similar in concept to a Vendor-Specific Attribute (VSA). • There are three key differences. SSAs: • Are defined by Standards Definition Organizations • Have a more formal syntax than VSAs • Are expected to have wider interoperability than VSAs • While is it feasible for VSAs to exhibit global interoperability, they are not required to do so. • VSAs are totally “free format” with respect to syntax.

  9. What the heck is an SSA? • Standard RADIUS Attributes are expected to use the basic data types defined in the base RADIUS RFCs. • The various RADIUS extension RFCs have added to the list of basic RADIUS data types for use in attributes. • SSAs would be required to use a recognized set of RADIUS data types (to be defined by the RADIUS Data Model work). • SSAs may potentially use an extended RADIUS attribute format, to enhance interoperability with Diameter (such as a Mandatory flag bit). • SSAs would leverage the powerful implementation concept of RADIUS data dictionaries. • SSAs would exist “in between” full standard attributes and VSAs.

More Related