Subject: Re: (radius) More detail on Proxy

From: David Bolen <[email-masked]>
Date: Fri, 26 Feb 99 16:02:17 EST

> 1.  A NAS sends its access-request to the forwarding server.  (...)
>
> The forwarding server MAY add one Proxy-State attribute to the packet.
> If it does, the Proxy-State MUST appear after any other Proxy-States in
> the packet.  The forwarding server MUST NOT modify any other
> Proxy-States that were in the packet and MUST NOT change the order of
> any attributes of the same type, including Proxy State.

This seems a bit restrictive to me.  It seems to me that what must be
done is limited to returning any set of Proxy-State attributes that
were received in the request in the identical order on any generated
response.  However, any means that provides this functionality should
be acceptable.

For example, in my server I strip out any Proxy-State attributes from
a received request and hold onto them internally.  When I replicate
the request to the next target server, I add my own Proxy-State
attribute, but that is the only one that will be seen by that next hop
server.  When the reply comes back, I use my Proxy-State to match
things up, remove it, and then replace any saved Proxy-State
attributes for the client to which I am replying.

It's not totally clear if doing the above would really violate your
proposed paragraph since it's not truly a "modification" of the
Proxy-States in the received packet but I'd be happier if the actual
phrases were more oriented towards what the server MUST do with
respect to returning the attributes unchanged and un-reordered to the
client, then what the packet must look like to the next server.

> 4.  The forwarding server verifies the Response Authenticator using (...)
>
> A forwarding server may need to modify attributes to enforce local
> policy.  Such policy is outside the scope of this document, with the
> following restrictions.  A forwarding server MUST not modify existing
> Proxy-State, State, or Class attributes present in the packet.

It seems that a clause such as this may be appropriate for the
forwarding path (step 2 probably) as well, since a forwarding server
may wish to enforce policy (hiding NAS addresses, for example) or
attribute modification for inter-domain forwarding of requests in
addition to the NAS reply case here.

-- David

/-----------------------------------------------------------------------\
 \               David Bolen              \  Internet: [email-masked]    /
  |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
 / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
\-----------------------------------------------------------------------/

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Jeff Weisberg <[email-masked]>
Date: Mon, 1 Mar 1999 09:35:39 -0500 (EST)

| RADIUS requirement:
| A server must reply to a client with the same Proxy-State attributes (and in
| the same order?) as it received in the request.
| 
| Server implementation:
[...]
| 2. the server stores the received Proxy-States but does not forward them to the
| next hop server. The server retrieves the Proxy-States when replying to the
| client.

someone last week mentioned that their implementation did this. it has
been (uncomfortably) sitting in my mind. I do not like it.

I use Proxy-State for 2 things, (1) loop detection, and (2) debugging.

this defeats both (loop detection being the more important)

	--jeff

-

---

From: David Bolen <[email-masked]>
Date: Mon, 1 Mar 99 13:00:45 EST

> I use Proxy-State for 2 things, (1) loop detection, and (2) debugging.

But Proxy-State is geared for saving state from a proxy server across
a forwarded request to the next server in line, so the only hard
requirement on it is that it be included unmodified in the response
from that next hop server.  While your implementation is certainly
free to impose other uses on the attribute, I don't think it should
force implementation requirements on other implementations other than
that specified in the RFC.

While we could redefine the attribute to enforce its inclusion in all
forwarded packets, I think that would be stretching its purpose too
far.

> this defeats both (loop detection being the more important)

There are other methods to do both as well, which is an implementation
choice.

Loop detection based strictly on Proxy-State makes too many
assumptions, to my mind, not all of which are RADIUS based.  What if
the set of domains performing authentication are not all RADIUS?
Crossing a non-RADIUS domain is certainly likely to keep all the
important aspects of a request (username, password, etc..), but if it
loops around back to you it's unlikely to maintain something like the
original Proxy-State attributes as it will be a re-formed request from
the edge of the non-RADIUS domain.

But if you specifically want to do it based on an attribute, then
perhaps it would be better (safer across multiple implementations) to
insert your own vendor-specific attribute and use that.  That way you
wouldn't depend on semantics for an attribute like Proxy-State that
isn't required by the protocol.

-- David

---

From: David Bolen <[email-masked]>
Date: Mon, 1 Mar 99 15:42:25 EST

"Dale E. Reed Jr." <[email-masked]> writes:

> Yes we did.  However, I still wasn't able to pursuade the vendor
> that they were incorrect, because the RFC doesn't say that (I know,
> I know...).

I know you know, but the RFC _does_ say that - or rather it explicitly
specifies a rule that does not require that behavior so I can't see
how anyone would read the lack of further clarification as explicitly
setting out the rule (e.g., its not MUST in the RFC...)

>              I just thought a quick one liner who save us from 
> this in the future.

I guess the only general comment is that I don't think we should
expect to have to include statements within the RFC on every way that
you can break the RFC soley to state those approaches as bad.

> They say that the current RFC to is vague for Proxy behavior and 
> the generic attribute description doesn't pertain to proxy. 

Hmm - I guess I think they're sniffing funny stuff when they are
reading the RFC.  General attribute behavior is just that - general,
and that's why it's in the general discussion of attributes right up
near the front of the RFC.  Not requiring the order of attributes of
different types to be preserved seems pretty clear.

So unless text explicitly excluded Proxy-State from the earlier
discussion (which it doesn't, that I can see), they have no reason to
believe it is not covered.  Besides which, without such a clause,
clearly making such a limiting assumption about Proxy-State is a bad
implementation practice.

But of course I'm talking to the choir - unless maybe they read this
list too :-)

> The more of the known implementation problems that are causing 
> interoperability issues we can document and state, the better
> the protocol will be in the future.

In general I agree, although I'm not sure how cluttered I'd want the
protocol RFC to become with stuff like this.  Perhaps a separate usage
document, or something documenting the results of interoperability
testing, gotchas discovered, etc..

-- David

---

From: Aydin Edguer <[email-masked]>
Date: Wed, 3 Mar 1999 10:37:34 -0500 (EST)

> I think that a hierarchical name space, where the realm part is akin to
> the FQDN part in an SMTP address is much more scalable.
...
> I suggest that this be the recommended practice for RADIUS proxy as well.

It already is - see RFC 2486 "The Network Access Identifier" and the
description of User-Name in draft-ietf-radius-radius-07.txt.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Nelson, David" <[email-masked]>
Date: Wed, 3 Mar 1999 11:09:48 -0500

Aydin Edguer writes...

> It already is - see RFC 2486 "The Network Access Identifier"
> and the description of User-Name in 
> draft-ietf-radius-radius-07.txt.

Yes, your point is well taken.  However the reference in 
draft-ietf-radius-radius-07.txt (on pp 25-26) indicates that
the User-Name attribute MAY be one of several formats,
including an RFC 2486 NAI.  I think that's not as strong as
indicating that an RFC 2486 NAI SHOULD be used for the
User-Name attribute in RADIUS proxy configurations.  It's this
somewhat stronger recommendation that I'm advocating.

Regards,

Dave

David B. Nelson                          Cabletron Systems, Inc.
Software Engineer V                      50 Minuteman Road
(978) 684-1330                           Andover, MA 01810
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Nelson, David" <[email-masked]>
Date: Wed, 3 Mar 1999 13:25:52 -0500

Carl,

Based on the recent discussions of NAI usage, I'll recommend that the
following changes to the RADIUS draft:

Original text:

> The NAS sends its RADIUS access-request to the "forwarding server"
> which forwards it to the "remote server."  The remote server sends a
> response (Access-Accept, Access-Reject, or Access-Challenge) back to
> the forwarding server, which sends it back to the NAS.  The choice of
> which server to forward the request to is based on the authentication
> "realm."  A realm can either be based on part of the User-Name, for
> example the part following an at ("@") sign (a "named realm"), or a
> Called-Station-Id (a "numbered realm"), or using whatever other
> criteria the forwarding server is configured to use.  Frequently, a
> fully qualified domain name is used as the named realm to provide
> uniqueness.

Proposed revised text:

The NAS sends its RADIUS access-request to the "forwarding server"
which forwards it to the "remote server."  The remote server sends a
response (Access-Accept, Access-Reject, or Access-Challenge) back to
the forwarding server, which sends it back to the NAS.  The User-Name
attribute SHOULD contain a Network Access Identifier [RFC 2486] for
RADIUS Proxy operations.  The choice of which server receives the
forwarded request SHOULD be based on the authentication "realm."  
The authentication realm SHOULD be the realm part of a Network Access
Identifier (a "named realm").  Alternatively, the choice of which
server receives the forwarded request MAY be based on a 
Called-Station-Id (a "numbered realm"), or MAY be based on whatever
other criteria the forwarding server is configured to use.

Regards,

Dave

-

---

From: [email-masked]
Date: Wed, 3 Mar 1999 11:14:24 -0800

I really like this suggestion.  Perhaps, though, changing the last line
from

>Alternatively, the choice of which

to

Alternatively, the choice of which
server receives the forwarded request MAY be based on whatever
other criteria the forwarding server is configured to use, such as
Called-Station-Id (a "numbered realm").

This seems to flow better if the intent is to say that you SHOULD use the
Realm but you MAY use something else. Otherwise, it sounds like you are
pushing Called-Station-Id.

-Clark

"Nelson, David" <[email-masked]> on 03/03/99 10:25:52 AM

Please respond to "Nelson, David" <[email-masked]>

To:   "'Carl Rigney'" <[email-masked]>, [email-masked]
cc:    (bcc: Clark Rudder/HQ/ISC)

Subject:  RE: (radius) More detail on Proxy

Carl,

Proposed revised text:

Regards,

Dave

-

-

---

From: Aydin Edguer <[email-masked]>
Date: Wed, 3 Mar 1999 14:48:11 -0500 (EST)

> pushing Called-Station-Id.

I actually prefer the previous wording.  This is because, in my opinion,
Network Access Identifier (NAI) and Called-Station-Id *are* preferred to
other methods for calculating the path used to forward the request.

For modem outsourcing (larger ISP or carrier, offering ports to a smaller
ISP) where there is a desire not want to require a full NAI, the phone
number that was dialed by the customer is easier and preferred to other
methods.

We do not want to encourage the use of other identifiers, although we
recognize that some operators may use them.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: [email-masked]
Date: Wed, 3 Mar 1999 11:56:32 -0800

>other methods for calculating the path used to forward the request.

In that case, the original might be a bit too ambiguous.  I'm not trying to
argue the point other than for clarity.  If the wording is to be such that
the reader knows that the "Network Access Identifier (NAI) and
Called-Station-Id *are* preferred to other methods for calculating the path
used to forward the request" then, perhaps, such should be stated more
clearly.

-Clark

-