Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call

From: [email-masked] (Patrice Calhoun)
Date: Tue, 7 Dec 1999 04:40:11 -0800

Matt,

Alhough the WG is nearly dead, there are many new companies actually
implementing RADIUS for use *other* than dial-in PPP (and some actually
do develop it for what it was intended for). Anyways, my point here is 
that there are many new implementations coming on board, and documenting
something half-ass (couldn't find any other language that really represented
my feeling about this issue), doesn't help anyone.

I would really be interested in finding out what an implementor does when
he reads these two paragraphs.

"Here is something you can do. We REALLY discourage you from doing it, and
if you do, please do it right".

What do you expect an implementor to do? How does he know whether he did
it right? There are no guidelines, no rules, nothing. A very vague statement.
Given the nature of the protocol, and the issues that I listed, this can
be VERY tricky to implement, and to get it right it's even harder.

Since people have done it, using their own imaginations, let's leave it out
and let the future implementors use their own imaginations as well.

PatC
>If RADIUS were a new protocol that we had just churned out of an active 
>working group, I would agree with you. But we are simply documenting 
>something from a nearly dead working group that very much needs documenting.
>
>So I would turn your argument around and say, "what harm is it to leave 
>those two paragraphs in?" We aren't trying to describe anything new. The 
>harm in trying to remove it is that we may have to go to WG last call again 
>and delay the whole process. I don't think there is enough harm here to do 
>that.
>
>
>At 09:21 AM 12/6/99 -0800, [email-masked] wrote:
>>Matt,
>>
>>I agree that we owe it to the community, but this *particular* change in the
>>new draft really concerns me. I would like to see it taken out of the draft,
>>before it is moved to last call. I really don't think that the new sentence
>>adds ANY benefit, in fact it simply casts a shadow of doubt on how proxies
>>really should work.
>>
>>As you say, servers do it today, and they follow RFC2138. So remove the two
>>paragraphs, and let servers do what they want. It really isn't as if the draft
>>proposes HOW a server can do it, so what *is* the benefit of having these two
>>paragraphs?
>>
>>PatC
>>
>> > Pat,
>> >
>> > You know as well (or better) as the rest of us about the limitations of
>> > RADIUS in a proxy environment. But nevertheless, a great many SP's are
>> > using it in a proxy environment and have been for some time. The protocol
>> > described in RFC 2138 has been applied to many scenarios that were never
>> > considered at the time it originally was approved by the WG and one of 
>> them
>> > is proxy.
>> >
>> > It does no good (IMHO) to worry about whether RFC 2138 allowed it or not,
>> > because RADIUS server vendors made it work anyway. Going to Draft Standard
>> > means that a lot of people are using the protocol and it is good to
>> > document the protocol as used. RADIUS is what it is.
>> >
>> > I think the current draft that is in last call now is fine and we have
>> > enough disclaimers in the text. We also have the ROAMOPS RFC's.
>> >
>> > Let's put RADIUS to bed. We owe it to the community.
>> >
>> >
>> >
>> > At 07:31 AM 12/6/99 -0800, [email-masked] wrote:
>> > > > Actually, the v2 draft doesn't include any Protocol changes; it just
>> > > > clarifies and explains proxy better, and adds a few values, and 
>> improves
>> > > > the examples.
>> > > >
>> > > > Its not really even v2; that's just the naming convention the Internet
>> > > > Drafts directory wanted to use for the advance from proposed to draft
>> > > > standard.
>> > > >
>> > > > Everything in the draft showed good interoperability at the Washington
>> > > > Bake-off two years ago.  Some people implemented Proxy incorrectly,
>> > > > but everyone who implemented it according to the spec interoperated.
>> > > >
>> > > > Note that the interoperability report includes some features added
>> > > > in the extensions draft, which is on an informational track, not
>> > > > standards, primarily for LAT and Appletalk support, which many NAS
>> > > > vendors aren't going to be doing.
>> > > >
>> > > > Are there any specific items that you're concerned about?
>> > >
>> > >actually, the following really scares me (I've sent an e-mail some 
>> time back
>> > >in regards to this particular item): >
>> > >"  A forwarding server may either perform its forwarding function in a
>> > >    pass through manner, where it sends retransmissions on as soon as it
>> > >    gets them, or it may take responsibility for retransmissions, for
>> > >    example in cases where the network link between forwarding and remote
>> > >    server has very different characteristics than the link between NAS
>> > >    and forwarding server.
>> > >
>> > >    Extreme care should be used when implementing a proxy server that
>> > >    takes responsibility for retransmissions so that its retransmission
>> > >    policy is robust and scalable."
>> > >
>> > >This defines a new type of proxy that wasn't supported (as far as I can
>> > tell) >in RFC2138. Here are my issues:
>> > >
>> > >1. How does the server *know* the network link characteristics. 
>> Furthermore,
>> > >The difference in link speed may be a few hops away, and the protocol
>> > doesn't >provide any round trip calculation which makes this *nearly*
>> > impossible. >Furthermore, given the nature of the RADIUS protocol, I really
>> > don't see how >one *could* really determine the round trip time in a proxy
>> > environment. >
>> > >2. The lack of retransmission logic in the protocol is just another 
>> way for
>> > >people to do Really Bad Implementations (TM), which will hamper the 
>> network.
>> > >The DHCP people had to remove their text from their I-D at the request of
>> > the >IESG, and theirs was much better defined than this draft.
>> > >
>> > >3. The fact that each RADIUS node in the chain MAY/WILL retransmit, 
>> how does
>> > >one syncronize the events? >
>> > >4. Certain attributes in the RADIUS protocol must be updated prior to
>> > >retransmissions (e.g. Acct-Session-Time). Furthermore, the identifier MUST
>> > be >updated each time something within the packet must be updated. So, who
>> > updates >these attributes, and how is the identifier field maintained.
>> > >
>> > >5. The warning above makes it clear that even the authors of the I-D think
>> > >this is a pretty dangerous area. So, why leave it in the draft?
>> > >
>> > >So, the above rambling are just some things that come to mind. I have a
>> > really >really hard time with leaving the text in the draft.
>> > >
>> > >PatC
>> > >
>> > >-
>> > >To unsubscribe, email [email-masked]' with
>> > >'unsubscribe ietf-radius' in the body of the message.
>> >
>

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

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 07 Dec 1999 07:52:13 -0800

Well, since my biggest fear is that this will yet again delay the
publishing of the very important Radius drafts the community is waiting 
for, let me ask the chair and/or the AD's if removing the sentence would 
require another WG last call?

-

---

From: Ran Atkinson <[email-masked]>
Date: Tue, 07 Dec 1999 10:57:06 -0500

Carl,

	My sense as a RADIUS operator/user is that its best to offer
whatever clues we can in the RFCs and try to reduce the need for
"implementor imagination".  My recent experience is that implementor clue
density is dropping just as fast as operator clue density.

	In the old Internet, the clue density was high enough that
reasonable things would happen.  In the new Internet, the sum(clue) has
remained a constant while the number of participants keeps growing rapidly.

	I find Pat's argument "Since people have done it using their
own imaginations, let's leave it out and let the future implementors
use their own imaginations as well" truly frightening as an operator.

	Proxy Servers are deployed and are useful in certain circumstances.
I would advocate keeping the proxy server documented in the RFC.  I
don't care whether that is packaged as at present or whether it gets moved
into a clearly non-normative appendix.

Ran
[email-masked]

-