Subject: [AAA-WG]: Fwd: Clarification on RFC-2865 (fwd)

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Jan 2003 15:13:05 -0800 (PST)

---------- Forwarded message ----------
Date: Tue, 28 Jan 2003 12:20:29 -0800
From: Philip A. Prindeville <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Fwd: Clarification on RFC-2865

It seems the old Radius WG is disbanded.  I was hoping someone
could answer a couple of basic questions that the specs left
ambiguous.

Thanks,

-Philip

Subject: Clarification on RFC-2865
From: "Philip A. Prindeville" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Thu, 23 Jan 2003 15:33:36 -0800

I have a couple of questions regarding the exact
semantics of some Radius attributes.  I was hoping you
could set me straight.

In the case of Ascend attribute 104 (outside of the scope
of the document, I know):

Can this attribute have overlapping instances when it
occurs more than once?  And does it imply that the
routes must be tested in the order they are given by
the server?

For instance, in the (dubious) case of getting back:

Ascend-Private-Route="170.0.0.0/8 10.10.10.1"
Ascend-Private-Route="170.1.0.0/16 10.10.10.1"

Is this the same as:

Ascend-Private-Route="170.1.0.0/16 10.10.10.1"
Ascend-Private-Route="170.1.0.0/8 10.10.10.1"

(ordering by specificity) or just:

Ascend-Private-Route="170.0.0.0/8 10.10.10.1"

(since the less specific route would match both cases?)

There are implementation and performance implications
of doing it either way.  The more open interpretation
requires searching linearly for the first match (since this
would allow multiple matches).  The more restrictive
interpretation allows for an efficient tree-based search,
since the first match is also the only match.

And the next question is about the Framed-IP-Address
attribute (#8):  If the NAS receives this from the Radius
server with the value 255.255.255.255 (remote host
should select address), does this mean that the NAS
should balk if the remote host doesn't furnish a valid
address?  Or should it fall back on a local address pool,
and pick one from there?

This latter behaviour is not implied by the standard,
and introduces an ambiguity in the protocol that
relies entirely on the local state of the NAS (i.e.
whether it has a local address pool configured or
not).

I think that the correct interpretation is to fail the
negotiation, but this is obviously a more restrictive
interpretation.  What's your collective opinion?

Thanks,

-Philip