Subject: Re: (radius) RADIUS proxy

From: David Bolen <[email-masked]>
Date: Mon, 15 Mar 99 19:50:04 EST

> No, I am not assuming anything.  I was answering a specific question.

Sorry, I chose to reply to the most recent message (your second
response) in the thread that was about loop detection... your first of
your pair of responses did specifically say to use Proxy-State for
loop detection:

   > How can I find out whether the packet was already forwarded by my server?

   You check for a Proxy-State attribute with a value you recognize.

   > so I can use for example a vendor specific attribute, but can I add my
   > VSA to the Access-Request that is being forwarded?

   No, you should not add a Vendor-Specific attribute - you should use the
   Proxy-State attribute.

and I sort of just referenced both in my reply at once.  Sorry for not
being clearer.

> The question was "Is the anything that prohibits to add a Proxy-State
> with the same value to the request?".  The answer is yes.

Why?  If two servers use the same mechanism for Proxy-State, there's
nothing formally stopping them from both inserting an identically
encoded Proxy-State object, and if the second server preserves the
first in the forwarded request, they will both be present.  And if two
servers use different mechanisms, there's no guarantee they can't
produce the same result.

> Correct according to RFC 2138 but possibly not correct (depending upon
> interpretation) according to the new draft document that will become
> the new Draft Standard for RADIUS:

Which was what the recent discussion on this list was about that I
alluded to.  Discussion at that time included several mentions of
earlier Proxy-State's not necessarily remaining in the forwarded copy
(and the issue of whether that conflicted with "modify" in the text).
Not sure what if any change to the text is forthcoming, if any.

> But the specific question I was answering was not about loop detection,
> it was whether you could have a packet with the same Proxy-State in it
> twice.  My answer remains "no", since the server *should* not allow that
> to happen, because it is a definite symptom of a loop, even if loops cannot
> always be detected.

I'm not sure I agree.  If you have two different implementations,
there is no guarantee that they might not produce the same Proxy-State.

> Excuse me, but how is that guaranteed?  A proxy server can filter out
> Vendor-Specific attributes just as easily as it can filter out the
> Proxy-State.

Not if it wants to forward on an identical request that it received.
The Proxy-State attribute is by definition an inserted attribute that
is an artifact of the proxy process, and has no bearing on anything
but the specific hop over which it is received (e.g., it's not part of
the original request).  But a VSA is not so limited, and it would not
be smart of a server to purge a VSA in general.

I'll agree however that "guarantee" is perhaps a bit strong.
Certainly, there may exist administrative controls that filter a
request across an administrative proxy boundary (our own server does
this), but I definitely think a VSA has a much better chance of
remaining unchanged through the forwarding process than Proxy-State
with respect to loop detection - again if you want to do so based on
attributes.

> Proxy-State.  In fact, some RADIUS servers, for better or for worse,
> will filter out any unknown Vendor-Specific attribute automatically.

If they're doing that during a proxy stage, then I'd consider them
very poor implementations - unless such filtering is part of a larger
administrative restriction model and not just because they didn't
recognize the attribute.  They can't know whether or not a final
RADIUS server will be able to make use of that information.  After
all, that's the whole point of VSAs - they may not be globally
understood, but can still be processed (or transparently forwarded) as
part of a request.

But I agree with your point in general - while I still consider them
more likely to survive than Proxy-State, they probably aren't all that
much more guaranteed.

-- 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: MARC DE VRIES WE41/KT <[email-masked]>
Date: Tue, 16 Mar 1999 10:40:03 +0200 (MET-DST)

>   No, you should not add a Vendor-Specific attribute - you should use the

Our proxy implementation uses following attribute combos to detect loops:

NAS-Id (attr 4 or 32)
Acct-Session-Id (if available in Access-Request)

OR

NAS-Id
NAS-Port
User-Name

This of course assuming these attributes are not altered along the proxy path.

>Not sure what if any change to the text is forthcoming, if any.

I do not believe preservation of Proxy-States through proxy hops is required,
but it may be desirable in some roaming environments.

IMO, the draft/RFC can list this preservation as an example or even recommended
practice, but not as a requirement the way it is formulated today.

Kind regards,

 Marc.

-