Re: FW: HTTP digest and RADIUS; new version of the Sterman draft

["Alan DeKok" <aland@ox.org>]

Bernard Aboba <aboba@internaut.com> wrote:
> a. Efficiency.  The "tagged" approach taken in RFC 2867 and 2868 is
> more efficient than Grouped AVPs, and therefore is probably to be
> preferred, everything else being equal.  Do we have examples where the
> "tagged" approach would not work?

  Anywhere an IP address is required to be a member of a group.

  Even RFC 2868 hides this problem:

---
   Type
      66 for Tunnel-Client-Endpoint.
...
   String
      The format of the address represented by the String field depends
      upon the value of the Tunnel-Medium-Type attribute.

      If Tunnel-Medium-Type is IPv4 (1), then this string is either the
      fully qualified domain name (FQDN) of the tunnel client machine,
      or it is a "dotted-decimal" IP address.
---

  My only response is "yuck".  I understand why that was done, but
RADIUS already has an "IP address" fundamental data type.  It would
have been cleaner to define a "Tunnel-Client-Endpoint-IP-Address"
attribute, but that's impossible with the "tag" method of grouping
attributes.

  In this case, the goal for backwards compatibility resulted in the
addition of a *new* base type to RADIUS: IP addresses represented in
text as dotted quads, rather than as 32-bit entities.  It would have
arguable been cleaner to group the attributes into a new
"Tunnel-Message" attribute, like EAP-Message, but with VSA-style
sub-types.  But I don't want to get into re-designing those RFC's now.

> b. Length constraints.  Unlike Diameter, RADIUS attributes can only be 253
> octets in length.  If Grouped AVPs are in aggregate longer than this, then
> it will be necessary to support fragmentation and reassembly of
> Grouped AVPs which increases complexity.

  That is an issue.  But People have dealt with it for EAP-Message, so
I don't see any real difficulties with it.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>