Check RFC compliance #16

MikhailMS · 2021-05-28T17:17:51Z

There are a number of RFCs describing protocol and standards around it, so it is better to ensure I follow them all (or as many as possible)

Right now, I only took into account (explicitly, but possibly some bits are coming from other RFCs):

RFC 2865 Server only capable to have 1 secret for all hosts #19
RFC 2866 compliant
RFC 2867 compliant
RFC 2868 RFC 2868 compliance #21
RFC 2869 compliant
RFC 3162 compliant
RFC 3576 RFC 3576 compliance #20
RFC 3580 compliant
RFC 4072 compliant
RFC 4372 compliant
RFC 4603 compliant
RFC 4675 compliant
RFC 4679 compliant
RFC 4818 compliant
RFC 4849 compliant
RFC 5090 compliant
RFC 5176 compliant
RFC 5447 compliant
RFC 5580 compliant
RFC 5607 compliant
RFC 5904 compliant
RFC 6158 compliant
RFC 6519 compliant
RFC 6572 compliant
RFC 6677 compliant
RFC 6911 compliant
RFC 6929 Implement data types from RFC 8044 #15 (RFC8044 expands on 6929)
RFC 6930 compliant
RFC 7055 compliant
RFC 7155 (doesn't belong here, talks about Diameter)
RFC 7268 compliant
RFC 7499 (experimental request)
RFC 7930 (experimental request)
RFC 8044 Implement data types from RFC 8044 #15
RFC 8045 compliant
RFC 8559 compliant

MikhailMS · 2021-05-28T17:33:11Z

This issue doesn't involve coding and rather focuses on identifying what is missing from the current implementation of RADIUS

MikhailMS · 2021-06-03T16:45:16Z

In RFC 2865

      A RADIUS server MUST use the source IP address of the RADIUS UDP
      packet to decide which shared secret to use, so that RADIUS
      requests can be proxied.

Seems like I'd need to change allowed_hosts from list to dictionary, so we can store IP & secret

MikhailMS · 2021-06-10T13:32:40Z

In RFC 3576

Implementations of this specification SHOULD support IPsec [RFC2401]
along with IKE [RFC2409] for key management.  IPsec ESP [RFC2406]
with a non-null transform SHOULD be supported, and IPsec ESP with a
non-null encryption transform and authentication support SHOULD be
used to provide per-packet confidentiality, authentication, integrity
and replay protection.  IKE SHOULD be used for key management.

and

Where IPsec replay protection is not used, the Event-Timestamp (55)
Attribute [RFC2869] SHOULD be included within all messages.  When
this attribute is present, both the NAS and the RADIUS server MUST
check that the Event-Timestamp Attribute is current within an
acceptable time window.  If the Event-Timestamp Attribute is not
current, then the message MUST be silently discarded.  This implies
the need for time synchronization within the network, which can be
achieved by a variety of means, including secure NTP, as described in
[NTPAUTH].

Seems like I am missing small bits from RFC 3576, so need to check on if it is beneficial to priorotise them into the next release

The rest of the RFC is either implemented or not appicable because it is more about application logic (RADIUS Server/Client) then RADIUS protocol per se

MikhailMS · 2021-06-10T14:11:31Z

In RFC 2866


      text     1-253 octets containing UTF-8 encoded 10646 [7]
               characters.  Text of length zero (0) MUST NOT be sent;
               omit the entire attribute instead.

      string   1-253 octets containing binary data (values 0 through 255
               decimal, inclusive).  Strings of length zero (0) MUST NOT
               be sent; omit the entire attribute instead.

      address  32 bit value, most significant octet first.

      integer  32 bit unsigned value, most significant octet first.

      time     32 bit unsigned value, most significant octet first --
               seconds since 00:00:00 UTC, January 1, 1970.  The
               standard Attributes do not use this data type but it is
               presented here for possible use in future attributes.

and

   Request Authenticator
      In Accounting-Request Packets, the Authenticator value is a 16
      octet MD5 [5] checksum, called the Request Authenticator.

      The NAS and RADIUS accounting server share a secret.  The Request
      Authenticator field in Accounting-Request packets contains a one-
      way MD5 hash calculated over a stream of octets consisting of the
      Code + Identifier + Length + 16 zero octets + request attributes +
      shared secret (where + indicates concatenation).  The 16 octet MD5
      hash value is stored in the Authenticator field of the
      Accounting-Request packet.

      Note that the Request Authenticator of an Accounting-Request can
      not be done the same way as the Request Authenticator of a RADIUS
      Access-Request, because there is no User-Password attribute in an
      Accounting-Request.

   Response Authenticator
      The Authenticator field in an Accounting-Response packet is called
      the Response Authenticator, and contains a one-way MD5 hash
      calculated over a stream of octets consisting of the Accounting-
      Response Code, Identifier, Length, the Request Authenticator field
      from the Accounting-Request 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 Accounting-Response packet.

Seems like:

I am missing string data type outline in the RFC (implemented in Add: primitive RFC 8044 datatypes to dict parser #14)
Authenticator is not calculated the way it should be, but could be done by users when they implement Server/Client since all functions for that are implemented

The rest of the RFC is either implemented or not appicable because it is more about application logic (RADIUS Server/Client) then RADIUS protocol per se

MikhailMS · 2021-06-10T14:41:23Z

In RFC 2867

Introduces new attribute, so nothing to implement here

MikhailMS · 2021-06-10T14:58:41Z

In RFC 2868

Tunnel-Password
    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     |     Tag       |   Salt
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Salt (cont)  |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  Valid values for this field are 0x01 through 0x1F,
      inclusive.  If the value of the Tag field is greater than 0x00 and
      less than or equal to 0x1F, it SHOULD be interpreted as indicating
      which tunnel (of several alternatives) this attribute pertains;
      otherwise, the Tag field SHOULD be ignored.

   Salt
      The Salt field is two octets in length and is used to ensure the
      uniqueness of the encryption key used to encrypt each instance of
      the Tunnel-Password attribute occurring in a given Access-Accept
      packet.  The most significant bit (leftmost) of the Salt field
      MUST be set (1).  The contents of each Salt field in a given
      Access-Accept packet MUST be unique.

   String
      The plaintext String field consists of three logical sub-fields:
      the Data-Length and Password sub-fields (both of which are
      required), and the optional Padding sub-field.  The Data-Length
      sub-field is one octet in length and contains the length of the
      unencrypted Password sub-field.  The Password sub-field contains



Zorn, et al.                 Informational                      [Page 8]


RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


      the actual tunnel password.  If the combined length (in octets) of
      the unencrypted Data-Length and Password sub-fields is not an even
      multiple of 16, then the Padding sub-field MUST be present.  If it
      is present, the length of the Padding sub-field is variable,
      between 1 and 15 octets.  The String field MUST be encrypted as
      follows, prior to transmission:

         Construct a plaintext version of the String field by
         concatenating the Data-Length and Password sub-fields.  If
         necessary, pad the resulting string until its length (in
         octets) is an even multiple of 16.  It is recommended that zero
         octets (0x00) be used for padding.  Call this plaintext P.

         Call the shared secret S, the pseudo-random 128-bit Request
         Authenticator (from the corresponding Access-Request packet) R,
         and the contents of the Salt field A.  Break P into 16 octet
         chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
         ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
         Intermediate values b(1), b(2)...c(i) are required.  Encryption
         is performed in the following manner ('+' indicates
         concatenation):

            b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
            b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
                        .                      .
                        .                      .
                        .                      .
            b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)

         The resulting encrypted String field will contain
         c(1)+c(2)+...+c(i).

      On receipt, the process is reversed to yield the plaintext String.

and

## Taken from https://github.com/FreeRADIUS/freeradius-server/blob/master/share/dictionary/radius/dictionary.rfc2868
   ATTRIBUTE	Tunnel-Type				64	integer	has_tag  
   ATTRIBUTE	Tunnel-Medium-Type		65	integer	has_tag   
   ATTRIBUTE	Tunnel-Client-Endpoint		66	string	has_tag   
   ATTRIBUTE	Tunnel-Server-Endpoint	67	string	has_tag  
   ATTRIBUTE	Tunnel-Password			69	string	has_tag,encrypt=2
   ATTRIBUTE	Tunnel-Private-Group-Id	81	string	has_tag
   ATTRIBUTE	Tunnel-Assignment-Id		82	string	has_tag
   ATTRIBUTE	Tunnel-Preference			83	integer	has_tag
   ATTRIBUTE	Tunnel-Client-Auth-Id		90	string	has_tag
   ATTRIBUTE	Tunnel-Server-Auth-Id		91	string	has_tag

Introduces new attributtes with new logic around it, so need to ensure

Dictionary parser can handle it
Salt for Tunnel-Password is implemented (we do have salt/unsalt functions already, so need to make sure they work here)

MikhailMS · 2021-06-10T15:16:58Z

In RFC 2869

Introduces:

new attribute (so no changes to be done here)
talks about ARAP (Apple REmote Access Protocol) - not sure if ARAP still in use, so won't be looking into it

MikhailMS · 2021-06-12T13:15:36Z

In RFC 3162

Introduces new:

attribute, so nothing to implement here
new data types, which are implemented in Add: primitive RFC 8044 datatypes to dict parser #14, so nothing to implement here

MikhailMS · 2021-06-12T13:25:34Z

In RFC 3580

No new things to implement for RADIUS protocol

MikhailMS · 2021-06-12T13:32:51Z

In RFC 4072

Mainly goes about Diameter protocol & how Radius talks to Diameter, so nothing to implement here

MikhailMS · 2021-06-12T13:38:59Z

In RFC 4372

Introduces new attribute, so nothing to implement here

MikhailMS · 2021-06-12T13:41:24Z

In RFC 4603

Introduces new values for Nas-Port-Type attribute, so nothing to implement here

MikhailMS · 2021-06-12T13:48:53Z

In RFC 4675

Introduces new attributes, so nothing to implement here

MikhailMS · 2021-06-12T13:50:41Z

In RFC 4679

Introduces new attributes, so nothing to implement here

MikhailMS · 2021-06-12T13:54:54Z

In RFC 4818

Introduces new attribute, so nothing to implement here

MikhailMS · 2021-06-12T13:55:21Z

In RFC 4849

Introduces new attribute, so nothing to implement here

MikhailMS · 2021-06-13T12:12:39Z

In RFC 5090

Introduces new attributes, so nothing to implement here

MikhailMS · 2021-06-13T19:20:16Z

In RFC 5176

Mentiones RADIUS Client/Server logic, so nothing to implement here

MikhailMS · 2021-06-13T19:24:09Z

In RFC 5447

Talks about support for Network Access Server to Diameter Server Interaction (Diameter Mobile IPv6), so nothing to implement here

MikhailMS · 2021-06-13T19:27:03Z

In RFC 5580

Mentiones RADIUS Client/Server logic, so nothing to implement here

MikhailMS · 2021-06-13T19:28:10Z

In RFC 5607

Introduces new attributes & values, so nothing to implement here

MikhailMS · 2021-06-13T19:30:50Z

In RFC 5904

Introduces new attributes, so nothing to implement here

MikhailMS · 2021-06-14T18:14:33Z

In RFC 6158

Talks about RADIUS Design Guidelines, so nothing to implement here

MikhailMS · 2021-06-14T18:18:42Z

In RFC 6519

Introduces new attribute, so nothing to implement here

MikhailMS · 2021-06-14T18:19:24Z

In RFC 6572

Introduces new attributes, so nothing to implement here

MikhailMS · 2021-06-14T18:21:18Z

In RFC 6911

Introduces new attributes, so nothing to implement here

MikhailMS · 2021-06-14T18:22:12Z

In RFC 6930

Introduces new attribute, so nothing to implement here

MikhailMS · 2021-06-19T14:35:59Z

In RFC 6677

Talks about Channel-Binding support to tackle "lying NAS" problem. This relates to actual RADIUS Client/Server implementations, so there is nothing to add to this crate

MikhailMS · 2021-06-19T14:47:47Z

In RFC 6929

Extended Type
     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     | Extended-Type |  Value ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      This field is identical to the Type field of the Attribute format
      defined in [RFC2865] Section 5.

   Length

      The Length field is one octet and indicates the length of this
      Attribute, including the Type, Length, "Extended-Type", and
      "Value" fields.  Permitted values are between 4 and 255.  If a
      client or server receives an Extended Attribute with a Length of 2
      or 3, then that Attribute MUST be considered to be an "invalid
      attribute" and handled as per Section 2.8, below.

   Extended-Type

      The Extended-Type field is one octet.  Up-to-date values of this
      field are specified according to the policies and rules described
      in Section 10.  Unlike the Type field defined in [RFC2865]
      Section 5, no values are allocated for experimental or
      implementation-specific use.  Values 241-255 are reserved and MUST
      NOT be used.

      The Extended-Type is meaningful only within a context defined by
      the Type field.  That is, this field may be thought of as defining
      a new type space of the form "Type.Extended-Type".  See
      Section 3.5, below, for additional discussion.

      A RADIUS server MAY ignore Attributes with an unknown
      "Type.Extended-Type".

      A RADIUS client MAY ignore Attributes with an unknown
      "Type.Extended-Type".

   Value

      This field is similar to the "Value" field of the Attribute format
      defined in [RFC2865] Section 5.  The format of the data MUST be a
      valid RADIUS data type.

      The "Value" field is one or more octets.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type" to determine the interpretation
      of the "Value" field.

      The addition of the Extended-Type field decreases the maximum
      length for attributes of type "text" or "string" from 253 to
      252 octets.  Where an Attribute needs to carry more than
      252 octets of data, the "Long Extended Type" format MUST be used.
--------

Long Extended Type

   It leverages the "Extended Type" format in order to permit
   the transport of attributes encapsulating more than 253 octets of
   data.  A summary of the 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     | Extended-Type |M|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      This field is identical to the Type field of the Attribute format
      defined in [RFC2865] Section 5.

   Length

      The Length field is one octet and indicates the length of this
      Attribute, including the Type, Length, Extended-Type, and "Value"
      fields.  Permitted values are between 5 and 255.  If a client or
      server receives a "Long Extended Type" with a Length of 2, 3, or
      4, then that Attribute MUST be considered to be an "invalid
      attribute" and handled as per Section 2.8, below.

      Note that this Length is limited to the length of this fragment.
      There is no field that gives an explicit value for the total size
      of the fragmented attribute.

   Extended-Type

      This field is identical to the Extended-Type field defined above
      in Section 2.1.

   M (More)

      The More field is one (1) bit in length and indicates whether or
      not the current attribute contains "more" than 251 octets of data.
      The More field MUST be clear (0) if the Length field has a value
      of less than 255.  The More field MAY be set (1) if the Length
      field has a value of 255.

      If the More field is set (1), it indicates that the "Value" field
      has been fragmented across multiple RADIUS attributes.  When the
      More field is set (1), the Attribute MUST have a Length field of
      value 255, there MUST be an attribute following this one, and the
      next attribute MUST have both the same Type and "Extended Type".
      That is, multiple fragments of the same value MUST be in order and
      MUST be consecutive attributes in the packet, and the last
      attribute in a packet MUST NOT have the More field set (1).

      That is, a packet containing a fragmented attribute needs to
      contain all fragments of the Attribute, and those fragments need
      to be contiguous in the packet.  RADIUS does not support
      inter-packet fragmentation, which means that fragmenting an
      attribute across multiple packets is impossible.

      If a client or server receives an attribute fragment with the
      "More" field set (1) but for which no subsequent fragment can be
      found, then the fragmented attribute is considered to be an
      "invalid attribute" and handled as per Section 2.8, below.

   Reserved

      This field is 7 bits long and is reserved for future use.
      Implementations MUST set it to zero (0) when encoding an attribute
      for sending in a packet.  The contents SHOULD be ignored on
      reception.

      Future specifications may define additional meaning for this
      field.  Implementations therefore MUST NOT treat this field as
      invalid if it is non-zero.

   Value

      This field is similar to the "Value" field of the Attribute format
      defined in [RFC2865] Section 5.  It may contain a complete set of
      data (when the Length field has a value of less than 255), or it
      may contain a fragment of data.

      The "Value" field is one or more octets.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type" to determine the interpretation
      of the "Value" field.

      Any interpretation of the resulting data MUST occur after the
      fragments have been reassembled.  The length of the data MUST be
      taken as the sum of the lengths of the fragments (i.e., "Value"
      fields) from which it is constructed.  The format of the data
      SHOULD be a valid RADIUS data type.  If the reassembled data does
      not match the expected format, all fragments MUST be treated as
      "invalid attributes", and the reassembled data MUST be discarded.

      We note that the maximum size of a fragmented attribute is limited
      only by the RADIUS packet length limitation (i.e., 4096 octets,
      not counting various headers and overhead).  Implementations MUST
      be able to handle the case where one fragmented attribute
      completely fills the packet.

   This definition increases the RADIUS Attribute Type space as above
   but also provides for transport of Attributes that could contain more
   than 253 octets of data.
--------

TLV Data Type

   We define a new data type in RADIUS, called "tlv".  The "tlv" data
   type is an encapsulation layer that permits the "Value" field of an
   Attribute to contain new sub-Attributes.  These sub-Attributes can in
   turn contain "Value"s of data type TLV.  This capability both extends
   the Attribute space and permits "nested" attributes to be used.  This
   nesting can be used to encapsulate or group data into one or more
   logical containers.

   The "tlv" data type reuses the RADIUS Attribute format, as given
   below:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TLV-Type    |  TLV-Length   |     TLV-Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV-Type

      The TLV-Type field is one octet.  Up-to-date values of this field
      are specified according to the policies and rules described in
      Section 10.  Values 254-255 are "Reserved" for use by future
      extensions to RADIUS.  The value 26 has no special meaning and
      MUST NOT be treated as a Vendor-Specific Attribute.

      As with the Extended-Type field defined above, the TLV-Type is
      meaningful only within the context defined by "Type" fields of the
      encapsulating Attributes.  That is, the field may be thought of as
      defining a new type space of the form
      "Type.Extended-Type.TLV-Type".  Where TLVs are nested, the type
      space is of the form "Type.Extended-Type.TLV-Type.TLV-Type", etc.

      A RADIUS server MAY ignore Attributes with an unknown "TLV-Type".

      A RADIUS client MAY ignore Attributes with an unknown "TLV-Type".

      A RADIUS proxy SHOULD forward Attributes with an unknown
      "TLV-Type" verbatim.

   TLV-Length

      The TLV-Length field is one octet and indicates the length of this
      TLV, including the TLV-Type, TLV-Length, and TLV-Value fields.  It
      MUST have a value between 3 and 255.  If a client or server
      receives a TLV with an invalid TLV-Length, then the Attribute that
      encapsulates that TLV MUST be considered to be an "invalid
      attribute" and handled as per Section 2.8, below.

   TLV-Value

      The TLV-Value field is one or more octets and contains information
      specific to the Attribute.  The format and length of the TLV-Value
      field are determined by the TLV-Type and TLV-Length fields.

      The TLV-Value field SHOULD encapsulate a standard RADIUS data
      type.  Non-standard data types SHOULD NOT be used within TLV-Value
      fields.  We note that the TLV-Value field MAY also contain one or
      more attributes of data type TLV; data type TLV allows for simple
      grouping and multiple layers of nesting.

      The TLV-Value field is limited to containing 253 or fewer octets
      of data.  Specifications that require a TLV to contain more than
      253 octets of data are incompatible with RADIUS and need to be
      redesigned.  Specifications that require the transport of empty
      "Value"s (i.e., Length = 2) are incompatible with RADIUS and need
      to be redesigned.

      The TLV-Value field MUST NOT contain data using the "Extended
      Type" formats defined in this document.  The base Extended
      Attributes format allows for sufficient flexibility that nesting
      them inside of a TLV offers little additional value.

   This TLV definition is compatible with the suggested format of the
   "String" field of the Vendor-Specific Attribute, as defined in
   [RFC2865] Section 5.26, though that specification does not discuss
   nesting.
--------

EVS Data Type

   We define a new data type in RADIUS, called "evs", for "Extended-
   Vendor-Specific".  The "evs" data type is an encapsulation layer that
   permits the EVS-Value field of an Attribute to contain a Vendor-Id,
   followed by an EVS-Type, and then vendor-defined data.  This data can
   in turn contain valid RADIUS data types or any other data as
   determined by the vendor.

   This data type is intended for use in attributes that carry vendor-
   specific information, as is done with the Vendor-Specific Attribute
   (Attribute number 26).  It is RECOMMENDED that this data type be used
   by a vendor only when the Vendor-Specific Attribute Type space has
   been fully allocated.

   Where [RFC2865] Section 5.26 makes a recommendation for the format of
   the data following the Vendor-Id, we give a strict definition.
   Experience has shown that many vendors have not followed the
   [RFC2865] recommendations, leading to interoperability issues.  We
   hope here to give vendors sufficient flexibility as to meet their
   needs while minimizing the use of non-standard VSA formats.

   The "evs" data type MAY be used in Attributes having the format of
   "Extended Type" or "Long Extended Type".  It MUST NOT be used in any
   other Attribute definition, including standard RADIUS attributes,
   TLVs, and VSAs.

   A summary of the "evs" data type 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Vendor-Id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  EVS-Type      |  EVS-Value ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor-Id

      The 4 octets of the Vendor-Id field are the Network Management
      Private Enterprise Code [PEN] of the vendor in network byte order.

   EVS-Type

      The EVS-Type field is one octet.  Values are assigned at the sole
      discretion of the vendor.

   EVS-Value

      The EVS-Value field is one or more octets.  It SHOULD encapsulate
      a standard RADIUS data type.  Using non-standard data types is NOT
      RECOMMENDED.  We note that the EVS-Value field may be of data type
      TLV.  However, it MUST NOT be of data type "evs", as the use cases
      are unclear for one vendor delegating Attribute Type space to
      another vendor.

      The actual format of the information is site or application
      specific, and a robust implementation SHOULD support the field as
      undistinguished octets.  While we recognize that vendors have
      complete control over the contents and format of the EVS-Value
      field, we recommend that good practices be followed.

      Further codification of the range of allowed usage of this field
      is outside the scope of this specification.

   Note that unlike the format described in [RFC2865] Section 5.26, this
   data type has no "Vendor-Length" field.  The length of the EVS-Value
   field is implicit and is determined by taking the "Length" of the
   encapsulating RADIUS attribute and then subtracting the length of the
   Attribute header (2 octets), the "Extended Type" (1 octet), the
   Vendor-Id (4 octets), and the EVS-Type (1 octet).  That is, for
   "Extended Type" Attributes the length of the EVS-Value field is eight
   (8) less than the value of the Length field, and for "Long Extended
   Type" Attributes the length of the EVS-Value field is nine (9) less
   than the value of the Length field.
--------

Introduces new data types: Extended, Long Extended, TLV, EVS & Integer64
Introduces new field: Vendor-Id
Introduces new attributes
Introduces new vendor specific attributes

MikhailMS · 2021-06-19T15:02:31Z

In RFC 7055

Introduces GSS-API mechanism for EAP. THis is strictly for actual RADIUS Client/Server implementation and not for the present crate

MikhailMS · 2021-06-19T15:04:10Z

In RFC 7155

Talks about Diameter protocol, nothing to do here

MikhailMS · 2021-06-19T15:06:31Z

In RFC 7268

Introduces new attributes, so nothing to implement here

MikhailMS · 2021-06-19T15:09:56Z

In RFC 7499

Experimental - talks about potential support for fragmented RADIUS packets

MikhailMS · 2021-06-19T15:11:10Z

In RFC 7930

Experimental - talks about potential usage of TCP protocol to carry RADIUS packets to avoid UDP limitation and usage of fragmented RADIUS packets over UDP protocol

MikhailMS · 2021-09-21T18:58:53Z

In RFC 8044

integer

   The "integer" data type encodes a 32-bit unsigned integer in network
   byte order.  Where the range of values for a particular attribute is
   limited to a subset of the values, specifications MUST define the
   valid range.  Attributes with Values outside of the allowed ranges
   SHOULD be treated as invalid attributes.

   Name

      integer

   Value

      1

   Length

      Four octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Value                                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

enum

   The "enum" data type encodes a 32-bit unsigned integer in network
   byte order.  It differs from the "integer" data type only in that it
   is used to define enumerated types, such as Service-Type (Section 5.6
   of [RFC2865]).  Specifications MUST define a valid set of enumerated
   values, along with a unique name for each value.  Attributes with
   Values outside of the allowed enumerations SHOULD be treated as
   invalid attributes.

   Name

      enum

   Value

      2

   Length

      Four octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Value                                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

time

   The "time" data type encodes time as a 32-bit unsigned value in
   network byte order and in seconds since 00:00:00 UTC, January 1,
   1970.  We note that dates before the year 2017 are likely to indicate
   configuration errors or lack of access to the correct time.

   Note that the "time" attribute is defined to be unsigned, which means
   that it is not subject to a signed integer overflow in the year 2038.

   Name

      time

   Value

      3

   Length

      Four octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Time                                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

text

   The "text" data type encodes UTF-8 text [RFC3629].  The maximum
   length of the text is given by the encapsulating attribute.  Where
   the range of lengths for a particular attribute is limited to a
   subset of possible lengths, specifications MUST define the valid
   range(s).  Attributes with lengths outside of the allowed values
   SHOULD be treated as invalid attributes.

   Attributes of type "text" that are allocated in the standard space
   (Section 1.2 of [RFC6929]) are limited to no more than 253 octets of
   data.  Attributes of type "text" that are allocated in the extended
   space can be longer.  In both cases, these limits are reduced when
   the data is encapsulated inside of another attribute.

   Where the text is intended to carry data in a particular format
   (e.g., Framed-Route), the format MUST be given.  The specification
   SHOULD describe the format in a machine-readable way, such as via the
   Augmented Backus-Naur Form (ABNF) [RFC5234].  Attributes with
   Values not matching the defined format SHOULD be treated as
   invalid attributes.

   Note that the "text" data type does not terminate with a NUL octet
   (hex 00).  The Attribute has a Length field and does not use a
   terminator.  Texts of length zero (0) MUST NOT be sent; omit the
   entire attribute instead.

   Name

      text

   Value

      4

   Length

      One or more octets

   Format

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-
      |  Value    ...
      +-+-+-+-+-+-+-+-

string

   The "string" data type encodes binary data as a sequence of
   undistinguished octets.  Where the range of lengths for a particular
   attribute is limited to a subset of possible lengths, specifications
   MUST define the valid range(s).  Attributes with lengths outside of
   the allowed values SHOULD be treated as invalid attributes.

   Attributes of type "string" that are allocated in the standard space
   (Section 1.2 of [RFC6929]) are limited to no more than 253 octets of
   data.  Attributes of type "string" that are allocated in the extended
   space can be longer.  In both cases, these limits are reduced when
   the data is encapsulated inside of another attribute.

   Note that the "string" data type does not terminate with a NUL octet
   (hex 00).  The Attribute has a Length field and does not use a
   terminator.  Strings of length zero (0) MUST NOT be sent; omit the
   entire attribute instead.  Where there is a need to encapsulate
   complex data structures and TLVs cannot be used, the "string"
   data type MUST be used.  This requirement includes encapsulation of
   data structures defined outside of RADIUS that are opaque to the
   RADIUS infrastructure.  It also includes encapsulation of some data
   structures that are not opaque to RADIUS, such as the contents of
   CHAP-Password.

   There is little reason to define a new RADIUS data type for only one
   attribute.  However, where the complex data type cannot be
   represented as TLVs and is expected to be used in many attributes, a
   new data type SHOULD be defined.

   These requirements are stronger than [RFC6158], which makes the above
   encapsulation a "SHOULD".  This document defines data types for use
   in RADIUS, so there are few reasons to avoid using them.

   Name

      string

   Value

      5

   Length

      One or more octets

   Format

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-
      |  Octets    ...
      +-+-+-+-+-+-+-+-

concat

   The "concat" data type permits the transport of more than 253 octets
   of data in a "standard space" [RFC6929] attribute.  It is otherwise
   identical to the "string" data type.

   If multiple attributes of this data type are contained in a packet,
   all attributes of the same type code MUST be in order, and they MUST
   be consecutive attributes in the packet.

   The amount of data transported in a "concat" data type can be no more
   than the RADIUS packet size.  In practice, the requirement to
   transport multiple attributes means that the limit may be
   substantially smaller than one RADIUS packet.  As a rough guide, it
   is RECOMMENDED that this data type transport no more than 2048 octets
   of data.

   The "concat" data type MAY be used for "standard space" attributes.
   It MUST NOT be used for attributes in the "short extended space" or
   the "long extended space".  It MUST NOT be used in any field or
   subfields of the following data types: "tlv", "vsa", "extended",
   "long-extended", or "evs".

   Name

      concat

   Value

      6

   Length

      One or more octets

   Format

       0
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-
      |  Octets    ...
      +-+-+-+-+-+-+-+-

ifid

   The "ifid" data type encodes an Interface-Id as an 8-octet IPv6
   Interface Identifier in network byte order.

   Name

      ifid

   Value

      7

   Length

      Eight octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Interface-Id ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Interface-Id                                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ipv4addr

   The "ipv4addr" data type encodes an IPv4 address in network byte
   order.  Where the range of addresses for a particular attribute is
   limited to a subset of possible addresses, specifications MUST define
   the valid range(s).  Attributes with Address values outside of the
   allowed range(s) SHOULD be treated as invalid attributes.

   Name

      ipv4addr

   Value

      8

   Length

      Four octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Address                                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ipv6addr

   The "ipv6addr" data type encodes an IPv6 address in network byte
   order.  Where the range of addresses for a particular attribute is
   limited to a subset of possible addresses, specifications MUST define
   the valid range(s).  Attributes with Address values outside of the
   allowed range(s) SHOULD be treated as invalid attributes.

   Name

      ipv6addr

   Value

      9

   Length

      Sixteen octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Address ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Address ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Address ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Address                                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ipv6prefix

   The "ipv6prefix" data type encodes an IPv6 prefix, using both a
   prefix length and an IPv6 address in network byte order.  Where the
   range of prefixes for a particular attribute is limited to a subset
   of possible prefixes, specifications MUST define the valid range(s).
   Attributes with Address values outside of the allowed range(s) SHOULD
   be treated as invalid attributes.

   Attributes with a Prefix-Length field having a value greater than 128
   MUST be treated as invalid attributes.

   Name

      ipv6prefix

   Value

      10

   Length

      At least two, and no more than eighteen, octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   | Prefix-Length |  Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix                                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Reserved

         This field, which is reserved and MUST be present, is always
         set to zero.  This field is one octet in length.

      Prefix-Length

         The length of the prefix, in bits.  At least 0 and no larger
         than 128.  This field is one octet in length.

      Prefix

         The Prefix field is up to 16 octets in length.  Bits outside of
         the Prefix-Length, if included, MUST be zero.

         The Prefix field SHOULD NOT contain more octets than necessary
         to encode the Prefix field.

ipv4prefix

   The "ipv4prefix" data type encodes an IPv4 prefix, using both a
   prefix length and an IPv4 address in network byte order.  Where the
   range of prefixes for a particular attribute is limited to a subset
   of possible prefixes, specifications MUST define the valid range(s).
   Attributes with Address values outside of the allowed range(s) SHOULD
   be treated as invalid attributes.

   Attributes with a Prefix-Length field having a value greater than 32
   MUST be treated as invalid attributes.

   Name

      ipv4prefix

   Value

      11

   Length

      Six octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   | Prefix-Length |  Prefix ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ... Prefix                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Reserved

         This field, which is reserved and MUST be present, is always
         set to zero.  This field is one octet in length.

         Note that this definition differs from that given in [RFC6572].
         See "Prefix-Length", below, for an explanation.

      Prefix-Length

         The length of the prefix, in bits.  The values MUST be no
         larger than 32.  This field is one octet in length.  Note that
         this definition differs from that given in [RFC6572].

         As compared to [RFC6572], the Prefix-Length field has increased
         in size by two bits, both of which must be zero.  The
         Reserved field has decreased in size by two bits.  The result
         is that both fields are aligned on octet boundaries, which
         removes the need for bit masking of the fields.
         Since [RFC6572] required the Reserved field to be zero, the
         definition here is compatible with the definition in the
         original specification.

      Prefix

         The Prefix field is 4 octets in length.  Bits outside of the
         Prefix-Length MUST be zero.  Unlike the "ipv6prefix" data type,
         this field is fixed length.  If the address is all zeros (i.e.,
         "0.0.0.0"), then the Prefix-Length MUST be set to 32.

integer64

   The "integer64" data type encodes a 64-bit unsigned integer in
   network byte order.  Where the range of values for a particular
   attribute is limited to a subset of the values, specifications MUST
   define the valid range(s).  Attributes with Values outside of the
   allowed range(s) SHOULD be treated as invalid attributes.

   Name

      integer64

   Value

      12

   Length

      Eight octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Value ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ... Value                                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

tlv

   The "tlv" data type encodes a Type-Length-Value, as defined in
   [RFC6929], Section 2.3.

   Name

      tlv

   Value

      13

   Length

      Three or more octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   TLV-Type    |  TLV-Length   |     TLV-Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      TLV-Type

         This field is one octet.  Up-to-date values of this field are
         specified according to the policies and rules described in
         [RFC6929], Section 10.  Values of 254-255 are reserved for use
         by future extensions to RADIUS.  The value 26 has no special
         meaning and MUST NOT be treated as a Vendor-Specific Attribute.

         The TLV-Type is meaningful only within the context defined by
         Type fields of the encapsulating Attributes, using the
         dotted-number notation introduced in [RFC6929].

         A RADIUS server MAY ignore Attributes with an unknown
         "TLV-Type".

         A RADIUS client MAY ignore Attributes with an unknown
         "TLV-Type".

         A RADIUS proxy SHOULD forward Attributes with an unknown
         "TLV-Type" verbatim.

      TLV-Length

         The TLV-Length field is one octet and indicates the length of
         this TLV, including the TLV-Type, TLV-Length, and TLV-Value
         fields.  It MUST have a value between 3 and 255.  If a client
         or server receives a TLV with an invalid TLV-Length, then the
         attribute that encapsulates that TLV MUST be considered to be
         an invalid attribute and is handled as per
         [RFC6929], Section 2.8.

         TLVs having a TLV-Length of two (2) MUST NOT be sent; omit the
         entire TLV instead.

      TLV-Data

         The TLV-Data field is one or more octets and contains
         information specific to the attribute.  The format and length
         of the TLV-Data field are determined by the TLV-Type and
         TLV-Length fields.

         The TLV-Data field MUST contain only known RADIUS data types.
         The TLV-Data field MUST NOT contain any of the following
         data types: "concat", "vsa", "extended", "long-extended",
         or "evs".

vsa

   The "vsa" data type encodes vendor-specific data, as given in
   [RFC2865], Section 5.26.  It is used only in the Attr-Data field of a
   Vendor-Specific Attribute.  It MUST NOT appear in the contents of any
   other data type.

   Where an implementation determines that an attribute of data type
   "vsa" contains data that does not match the expected format, it
   SHOULD treat that attribute as being an invalid attribute.

   Name

      vsa

   Value

      14

   Length

      Five or more octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Vendor-Id                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  VSA-Data ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Vendor-Id

         The 4 octets are the Network Management Private Enterprise Code
         [PEN] of the vendor in network byte order.

      VSA-Data

         The VSA-Data field is one or more octets.  The actual format of
         the information is site specific or application specific, and a
         robust implementation SHOULD support the field as
         undistinguished octets.

         The codification of the range of allowed usage of this field is
         outside the scope of this specification.

         The "vsa" data type SHOULD contain a sequence of "tlv"
         data types.  The interpretation of the TLV-Type and TLV-Data
         fields is dependent on the vendor's definition of that
         attribute.

         The "vsa" data type MUST be used as the contents of the
         Attr-Data field of the Vendor-Specific Attribute.  The "vsa"
         data type MUST NOT appear in the contents of any other
         data type.


extended

   The "extended" data type encodes the "Extended Type" format, as given
   in [RFC6929], Section 2.1.  It is used only in the Attr-Data field of
   an attribute allocated from the standard space.  It MUST NOT appear
   in the contents of any other data type.

   Name

      extended

   Value

      15

   Length

      Two or more octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Extended-Type | Ext-Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Extended-Type

         The Extended-Type field is one octet.  Up-to-date values of
         this field are specified according to the policies and rules
         described in [RFC6929], Section 10.  Unlike the Type field
         defined in [RFC2865], Section 5, no values are allocated for
         experimental or implementation-specific use.  Values 241-255
         are reserved and MUST NOT be used.

         The Extended-Type is meaningful only within a context defined
         by the Type field.  That is, this field may be thought of as
         defining a new type space of the form "Type.Extended-Type".
         See [RFC6929], Section 2.1 for additional discussion.

         A RADIUS server MAY ignore Attributes with an unknown
         "Type.Extended-Type".

         A RADIUS client MAY ignore Attributes with an unknown
         "Type.Extended-Type".

      Ext-Data

         The Ext-Data field is one or more octets.

         The contents of this field MUST be a valid data type as defined
         in the RADIUS "Data Type" registry.  The Ext-Data field
         MUST NOT contain any of the following data types: "concat",
         "vsa", "extended", "long-extended", or "evs".

         Implementations supporting this specification MUST use the
         Identifier of "Type.Extended-Type" to determine the
         interpretation of the Ext-Data field.

long-extended

   The "long-extended" data type encodes the "Long Extended Type"
   format, as given in [RFC6929], Section 2.2.  It is used only in the
   Attr-Data field of an attribute.  It MUST NOT appear in the contents
   of any other data type.

   Name

      long-extended

   Value

      16

   Length

      Three or more octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Extended-Type |M|T| Reserved  | Ext-Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Extended-Type

         This field is identical to the Extended-Type field defined
         above in Section 3.15.

      M (More)

         The More field (M flag) is one (1) bit in length and indicates
         whether or not the current attribute contains "more" than
         251 octets of data.  The More field MUST be clear (0) if the
         Length field has a value less than 255.  The More field MAY be
         set (1) if the Length field has a value of 255.

         If the More field is set (1), it indicates that the Ext-Data
         field has been fragmented across multiple RADIUS attributes.

         When the More field is set (1), the Attribute MUST have a
         Length field value of 255; there MUST be an attribute following
         this one; and the next attribute MUST have both the same Type
         and Extended-Type.  That is, multiple fragments of the same
         value MUST be in order and MUST be consecutive attributes in
         the packet, and the last attribute in a packet MUST NOT have
         the More field set (1).

         That is, a packet containing a fragmented attribute needs to
         contain all fragments of the attribute, and those fragments
         need to be contiguous in the packet.  RADIUS does not support
         inter-packet fragmentation, which means that fragmenting an
         attribute across multiple packets is impossible.

         If a client or server receives an attribute fragment with the
         More field set (1), but for which no subsequent fragment can be
         found, then the fragmented attribute is considered to be an
         invalid attribute and is handled as per [RFC6929], Section 2.8.

      T (Truncation)

         This field is one bit in size and is called "T" for Truncation.
         It indicates that the attribute is intentionally truncated in
         this chunk and is to be continued in the next chunk of the
         sequence.  The combination of the M flag and the T flag
         indicates that the attribute is fragmented (M flag) but that
         all of the fragments are not available in this chunk (T flag).
         Proxies implementing [RFC6929] will see these attributes as
         invalid (they will not be able to reconstruct them), but they
         will still forward them, as Section 5.2 of [RFC6929] indicates
         that they SHOULD forward unknown attributes anyway.

         Please see [RFC7499] for further discussion of the uses of
         this flag.

      Reserved

         This field is six bits long and is reserved for future use.
         Implementations MUST set it to zero (0) when encoding an
         attribute for sending in a packet.  The contents SHOULD be
         ignored on reception.

         Future specifications may define one or more additional
         meanings for this field.  Implementations therefore MUST NOT
         treat this field as invalid if it is non-zero.

      Ext-Data

         The Ext-Data field is one or more octets.

         The contents of this field MUST be a valid data type as defined
         in the RADIUS "Data Type" registry.  The Ext-Data field MUST
         NOT contain any of the following data types: "concat", "vsa",
         "extended", "long-extended", or "evs".

         Implementations supporting this specification MUST use the
         Identifier of "Type.Extended-Type" to determine the
         interpretation of the Ext-Data field.

         The length of the data MUST be taken as the sum of the lengths
         of the fragments (i.e., Ext-Data fields) from which it is
         constructed.  Any interpretation of the resulting data MUST
         occur after the fragments have been reassembled.  If the
         reassembled data does not match the expected format, each
         fragment MUST be treated as an invalid attribute, and the
         reassembled data MUST be discarded.

         We note that the maximum size of a fragmented attribute is
         limited only by the RADIUS packet length limitation.
         Implementations MUST be able to handle the case where one
         fragmented attribute completely fills the packet.

evs

   The "evs" data type encodes an Extended-Vendor-Specific Attribute, as
   given in [RFC6929], Section 2.4.  The "evs" data type is used solely
   to extend the vendor-specific space.  It MAY appear inside of an
   "extended" data type or a "long-extended" data type.  It MUST NOT
   appear in the contents of any other data type.

   Where an implementation determines that an attribute of data type
   "evs" contains data that does not match the expected format, it
   SHOULD treat that attribute as being an invalid attribute.

   Name

      evs

   Value

      17

   Length

      Six or more octets

   Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Vendor-Id                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Vendor-Type   |  EVS-Data ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subfields

      Vendor-Id

         The 4 octets are the Network Management Private Enterprise Code
         [PEN] of the vendor in network byte order.

      Vendor-Type

         The Vendor-Type field is one octet.  Values are assigned at the
         sole discretion of the vendor.

      EVS-Data

         The EVS-Data field is one or more octets.  It SHOULD
         encapsulate a previously defined RADIUS data type.
         Non-standard data types SHOULD NOT be used.  We note that the
         EVS-Data field may be of data type "tlv".

         The actual format of the information is site specific or
         application specific, and a robust implementation SHOULD
         support the field as undistinguished octets.  We recognize that
         vendors have complete control over the contents and format of
         the Ext-Data field; at the same time, we recommend that good
         practices be followed.

         Further codification of the range of allowed usage of this
         field is outside the scope of this specification.

This RFC states clear data types and tries to ensure those to be uniform, so there is no confusing what string, text and etc are
Looking at this RFC, looks like I may need to ensure dictionary.rs is all good for old data types (defined in the first RADIUS RFCs)

MikhailMS · 2021-09-21T19:12:32Z

In RFC 8045

Defines a number of new attributes, not sure anything should be added to library from this RFC

MikhailMS · 2021-09-21T19:18:47Z

In RFC 8559

Talks about Proxying CoA requests in RADIUS system. Nothing to be implemented in this library from this RFC

MikhailMS · 2021-09-21T19:34:18Z

All RFCs have been looked at, all missing things resolved into new issues, so can close this one :)

MikhailMS self-assigned this May 28, 2021

MikhailMS added documentation Improvements or additions to documentation enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed labels May 28, 2021

MikhailMS closed this as completed Sep 21, 2021

Check RFC compliance #16

Check RFC compliance #16

Comments

MikhailMS commented May 28, 2021 • edited Loading

MikhailMS commented May 28, 2021

MikhailMS commented Jun 3, 2021 • edited Loading

MikhailMS commented Jun 10, 2021

MikhailMS commented Jun 10, 2021 • edited Loading

MikhailMS commented Jun 10, 2021 • edited Loading

MikhailMS commented Jun 10, 2021

MikhailMS commented Jun 10, 2021 • edited Loading

MikhailMS commented Jun 12, 2021 • edited Loading

MikhailMS commented Jun 12, 2021

MikhailMS commented Jun 12, 2021

MikhailMS commented Jun 12, 2021 • edited Loading

MikhailMS commented Jun 12, 2021

MikhailMS commented Jun 12, 2021

MikhailMS commented Jun 12, 2021

MikhailMS commented Jun 12, 2021

MikhailMS commented Jun 12, 2021

MikhailMS commented Jun 13, 2021

MikhailMS commented Jun 13, 2021

MikhailMS commented Jun 13, 2021

MikhailMS commented Jun 13, 2021

MikhailMS commented Jun 13, 2021

MikhailMS commented Jun 13, 2021

MikhailMS commented Jun 14, 2021

MikhailMS commented Jun 14, 2021

MikhailMS commented Jun 14, 2021

MikhailMS commented Jun 14, 2021

MikhailMS commented Jun 14, 2021 • edited Loading

MikhailMS commented Jun 19, 2021

MikhailMS commented Jun 19, 2021 • edited Loading

MikhailMS commented Jun 19, 2021

MikhailMS commented Jun 19, 2021

MikhailMS commented Jun 19, 2021

MikhailMS commented Jun 19, 2021

MikhailMS commented Jun 19, 2021

MikhailMS commented Sep 21, 2021

MikhailMS commented Sep 21, 2021

MikhailMS commented Sep 21, 2021

MikhailMS commented Sep 21, 2021

MikhailMS commented May 28, 2021 •

edited

Loading

MikhailMS commented Jun 3, 2021 •

edited

Loading

MikhailMS commented Jun 10, 2021 •

edited

Loading

MikhailMS commented Jun 10, 2021 •

edited

Loading

MikhailMS commented Jun 10, 2021 •

edited

Loading

MikhailMS commented Jun 12, 2021 •

edited

Loading

MikhailMS commented Jun 12, 2021 •

edited

Loading

MikhailMS commented Jun 14, 2021 •

edited

Loading

MikhailMS commented Jun 19, 2021 •

edited

Loading