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

From: Carl Rigney <[email-masked]>
Date: Fri, 3 Dec 1999 09:23:18 -0800 (PST)

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?

--
Carl

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

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 6 Dec 1999 07:31:01 -0800 (PST)

> 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

-

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 6 Dec 1999 09:21:05 -0800 (PST)

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:
> >in regards to this particular item): >
> >This defines a new type of proxy that wasn't supported (as far as I can
> tell) >in RFC2138. Here are my issues:
> >
> >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. >
> >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.
> >
> >one syncronize the events? >
> >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.
> >
> >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
> >
> >-

-

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 06 Dec 1999 09:16:04 -0800

Pat,

-

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 06 Dec 1999 17:41:01 -0800

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.

-

---

From: John Vollbrecht <[email-masked]>
Date: Tue, 07 Dec 1999 13:12:00 -0500

I agree with Pat that this wording about proxy is not good.  RFC 2607 "procy
Chaining and Policy Implementation in Roaming" discusses the whole proxy with
radius issue, and there was significant discussion of this in the Roamops WG.  The
conclusion was different that what is described here.  In RFC 2607 the forwarding
behaviour for an Authorization request is described as

   Proxy2 in the diagram above SHOULD NOT send a Reply packet to Proxy1
   without first having received a Reply packet initiated by the Home
   Server.  The two exceptions are when the proxy is enforcing policy as
   described in section 5.1 and when the proxy is acting as an
   accounting store (as in store and forward), as described in section
   5.2

Section 5.1 describes the store and forward case for ACCOUNTING (not Access)
Requests.  Section 5.2 describes the case where the proxy is rejecting the request
and doesn't need to forward it.

I think this wording in the RADIUS draft will give implementers the wrong idea
about what is a good implementation. I would also like to see it removed.

-- John

"[email-masked]" wrote:

> > Its not really even v2; that's just the naming convention the InternetExcept
> for the two cases described below, a proxy server such as
>

-