[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis
I have no objection to it being made standards track. On the other
hand, RFC 2866 (accounting) is still informational. It would be odd to
have a decade-old core RADIUS feature as informational, and a newer
feature as standards track.
A bit of RADIUS WG folklore. RFC 2866 was not allowed on the Standards
Track because Mike O'Dell pronounced its design "Criminally negligent"
(mostly due to lack of transport guidance).
There are aspects of RFC 3576's original design which probably merited a
similar judgment, such as lack of replay protection. RFC 3576bis doesn't
outlaw those old practices in order to maintain backward compatibility.
>> (2) The security considerations section on Impersonation (section 6.2)
>> seem to apply to
>> implementations of RFC 2865, rather than this specification:
>>
>> To address these vulnerabilities RADIUS proxies one hop from the NAS
>> SHOULD check whether NAS identification attributes (see Section 3)
>> match the packet source address. Where one or more attributes do
not
>>
>> As far as I can tell, the RADIUS proxy that SHOULD perform this check
may
>> be entirely unaware of this specification. Is that correct?
Yes.
>> This is a carryover from RFC 3576, so there is no value in blocking the
>> progression of this specification.
The text appears identical to RFC 3576, Section 5.2.
Similar text is also included in RFC 3579, Section 4.3.7:
" To address these vulnerabilities RADIUS proxies SHOULD check whether
NAS identification attributes (NAS-IP-Address, NAS-IPv6-Address,
NAS-Identifier) match the source address of packets originating from
the NAS. Where a match is not found, an Access-Reject SHOULD be
sent, and an error SHOULD be logged."
We could just quote from that.
--
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/>