[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
David B. Nelson wrote:
> Glen Zorn writes...
>> ... Any Extended
>> Attributes containing multiple fragments of the same value MUST be
>> in order and MUST be consecutive attributes in the packet.
> It's the last sentence that I claim adds new requirements to RADIUS. This
> is not required for EAP-Message Attributes,
Nope. See RFC 3579 Section 3.1:
EAP-Message attributes are contained within an Access-Request or
Access-Challenge packet, they MUST be in order and they MUST be
consecutive attributes in the Access-Request or Access-Challenge
MUST be consecutive attributes would seem pretty clear.
> nor any others that I'm aware
> of. I'm stopping short of claiming that this new requirement isn't backward
> compatible. I can easily envision implementations where this would not be
> any sort of burden to enforce. I'm just wondering if there are any
> implementations where it would be a burden? I also see the advantage in
> terms of ease of implementation of parsing and reconstruction.
It's a PITA to root through the packet, looking for the next attribute
which *might* be the same... and which isn't consecutive. I've done
this for the previous version of the Extended-Attributes. It's awkward.
It's much easier just to check: Next attribute is the same? Nope?
Dump the packet as malformed.
It makes for less code, and fewer chances for programming errors.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.