Subject: [AAA-WG]: Re: Clarification on RFC 2865

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Jan 2003 16:55:40 -0800

Since the attributes you cite can also be used with Diameter NASREQ, I'm posting your questions to the AAA WG list, so that we can make sure that NASREQ includes the clarifications. 

==================================================

Message-ID: <[email-masked]>
Date: Thu, 23 Jan 2003 15:33:36 -0800
From: "Philip A. Prindeville" <[email-masked]>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en,fr-FR
MIME-Version: 1.0
To: [email-masked], [email-masked], [email-masked],
 	[email-masked]
Subject: Clarification on RFC-2865
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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?

[BA] I think this may depend on the media. Within PPP, the address would be negotiated within IPCP, and presumably if the NAS did not like the address suggested by the peer, it could assign its own. However, for other media such as IEEE 802, the NAS is not directly involved in address assignment (e.g. most switches/APs just forward DHCP packets) so it may be harder to give guidance (unless the switch/AP can also act as a DHCP server). 
---------------------------------------------

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

---------- Original message ----------
Date: Tue, 28 Jan 2003 12:20:29 -0800
From: Philip A. Prindeville <[email-masked]>
Reply-To: 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

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 28 Jan 2003 18:57:50 -0800

>occurs more than once?

FWIW, we (Ascend) always allowed overlapping instances.

>And does it imply that the

No.