Subject: Re: (radius) More detail on Proxy

From: David Bolen <[email-masked]>
Date: Mon, 1 Mar 99 14:10:56 EST

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

> Some implementations require Proxy-State to be before the reply 
> attributes, which is causing problems with us because we attach
> Proxy-State at the end.

We had a recent thread on that right?  I think the general agreement
was that those implementations were broken.  Clearly that sort of
behavior has never been required by the RFC nor could be assumed by an
implementation.

I do agree that if such implementations do exist, having a comment
specifically highlighting such an assumption as incorrect could be a
good thing, although it's unfortunate since it's already existing
attribute behavior in general, so an implementation writer that made
that mistake might already not be paying close attention to the RFC :-)

I don't think I'd want to require any sort of support for
interoperability with such an implementation, however, in general.  If
you're stuck with an unchangeable peer that you must work with, then
some sort of configurable option or behavior change in your
implementation is probably the only way out.

I'd see changes such as this as specific workarounds for
interoperability with broken implementations, of which there might be
any number of similar problems depending on the implementation in
question.  For example, I had to implement a configurable option to
avoid NULs in my Proxy-State attributes in order to interoperate with
older Livingston/Merit code (not sure about the latest stuff) since
they NUL-terminated all string attributes internally.  Clearly that
wasn't implied by the RFC, nor would I make having such an option a
requirement for any implementation, but I needed it in the real world.

-- 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: "Dale E. Reed Jr." <[email-masked]>
Date: Mon, 01 Mar 1999 12:20:50 -0800

> behavior has never been required by the RFC nor could be assumed by an

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 just thought a quick one liner who save us from 
this in the future.
 
> that mistake might already not be paying close attention to the RFC :-)

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

Thats what we are working on right now.
 
> requirement for any implementation, but I needed it in the real world.

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.

-- 

Dale E. Reed Jr.      Emerald and RadiusNT
__________________________________________
IEA Software, Inc.    www.iea-software.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.