[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 227: Proxy State
Alan DeKok said:
"> [BA] This suggests that paragraphs 3 and 4 in the text below are not
> correct. Any suggestions on how we can fix it?
Before I do that, it would appear that my recommendation here is
opposite to what RFC 3576 says. Are we OK with changing the
recommendation in -bis?
That is, do current implementations behave as per RFC 3576? If so, I
would prefer to maintain inter-operability. The text can then be left
as-is.
If not, then the implementations do not use Proxy-State, and I would
prefer to replace the paragraphs with other text explaining why
Proxy-State is not used. The text in RFC 3576 permits implementations
to receive Proxy-State, but to not forward it. Maybe the
implementations have chosen that method.
My preference is to have one recommended method of operation, rather
than 2-3.
I'd like to get clarity on those questions before submitting suggested
text."
Some responses from RFC 3576 implementers are enclosed below Any thoughts on how we should proceed?
As an aside, I've pulled all the text relating to Proxy State into a single Section 3.1, so it will be easier to modify:
3.1. Proxy State
If there are any Proxy-State attributes in a Disconnect-Request or
CoA-Request received from the server, the forwarding proxy or NAS
MUST include those Proxy-State attributes in its response to the
server.
A forwarding proxy or NAS MUST NOT modify existing Proxy-State,
State, or Class attributes present in the packet. The forwarding
proxy or NAS MUST treat any Proxy-State attributes already in the
packet as opaque data. Its operation MUST NOT depend on the content
of Proxy-State attributes added by previous proxies. The forwarding
proxy MUST NOT modify any other Proxy-State attributes that were in
the packet; it may choose not to forward them, but it MUST NOT change
their contents. If the forwarding proxy omits the Proxy-State
attributes in the request, it MUST attach them to the response before
sending it.
When the proxy forwards a Disconnect or CoA-Request, it MAY add a
Proxy-State Attribute, but it MUST NOT add more than one. If a
Proxy-State Attribute is added to a packet when forwarding the
packet, the Proxy-State Attribute MUST be added after any existing
Proxy-State attributes. The forwarding proxy MUST NOT change the
order of any attributes of the same type, including Proxy-State.
Other attributes can be placed before, after or even between the
Proxy-State attributes.
When the proxy receives a response to a CoA-Request or Disconnect-
Request, it MUST remove its own Proxy-State (the last Proxy- State in
the packet) Attribute before forwarding the response. Since
Disconnect and CoA responses are authenticated on the entire packet
contents, the stripping of the Proxy-State Attribute invalidates the
integrity check - so the proxy needs to recompute it.
=========================================================
Date: Wed, 16 May 2007 13:37:41 -0700
From: James Blaisdell <james@mocana.com>
To: Bernard Aboba <aboba@internaut.com>
Subject: Re: RFC 3576bis Open Issues
Hello Bernard,
I don't believe either of these items are an issue for us. It's been a while, since we implemented RFC-3576 CoA support. Issue #227 does not affect us, as we provide a RADIUS client. As for issue #226, we're operating at a lower level; we handle the processing of requests, failover, CoA notifications, building varbinds, other sundry tasks --- the actual message processing is left up to the application.
fyi - RFC-3576 for some reason doesn't seem to have caught on as quickly as I would have expected. We had a very difficult time finding a RADIUS server that supported this capability when we released this feature last year.
At 12:42 PM -0700 5/16/07, Bernard Aboba wrote:
>In the IETF RADEXT WG, we have two open issues on RFC 3576bis:
>
>Issue 226: RFC 3576bis and Renumbering
>Issue 227: Proxy State
>
>Details on the open issues are
>available at:
>http://www.drizzle.com/~aboba/RADEXT/
>
>In order to resolve these issues, we are seeking answers to the following
>questions from implementers of RFC 3576:
>
>a. Have you implemented Framed-IP-Address or
>Framed-IPv6-Prefix/Framed-Interface-Id as a Session Identification
>attribute (as opposed to a parameter that can be changed in a
>CoA-Request)?
>b. Have you implemented the proxy state algorithm described below (as
>opposed to an alternative approach)?
>
>Any information you can provide on these issues would be helpful in
>enabling the timely completion of the RFC 3576bis effort.
>
>Current Proxy State text in RFC 3576bis
>
> If there are any Proxy-State Attributes in a Disconnect-Request or
> CoA-Request received from the server, the forwarding proxy or NAS
> MUST include those Proxy-State Attributes in its response to the
> server.
>
> A forwarding proxy or NAS MUST NOT modify existing Proxy-State,
> State, or Class Attributes present in the packet. The forwarding
> proxy or NAS MUST treat any Proxy-State attributes already in the
> packet as opaque data. Its operation MUST NOT depend on the
> content of Proxy-State attributes added by previous proxies. The
> forwarding proxy MUST NOT modify any other Proxy-State Attributes
> that were in the packet; it may choose not to forward them, but it
> MUST NOT change their contents. If the forwarding proxy omits the
> Proxy-State Attributes in the request, it MUST attach them to the
> response before sending it.
>
> When the proxy forwards a Disconnect or CoA-Request, it MAY add a
> Proxy-State Attribute, but it MUST NOT add more than one. If a
> Proxy-State Attribute is added to a packet when forwarding the
> packet, the Proxy-State Attribute MUST be added after any existing
> Proxy-State attributes. The forwarding proxy MUST NOT change the
> order of any attributes of the same type, including Proxy-State.
> Other Attributes can be placed before, after or even between the
> Proxy-State Attributes.
>
> When the proxy receives a response to a CoA-Request or Disconnect-
> Request, it MUST remove its own Proxy-State (the last Proxy- State
> in the packet) before forwarding the response. Since Disconnect
> and CoA responses are authenticated on the entire packet contents,
> the stripping of the Proxy-State Attribute invalidates the
> integrity check - so the proxy needs to recompute it.
=========================================================
Date: Thu, 17 May 2007 12:54:29 -0400
From: Michael Lecuyer <mjl@theorem.com>
To: Bernard Aboba <aboba@internaut.com>
Subject: Re: RFC 3576bis Open Issues
The Proxy-State attribute behaves correctly through the AXL RADIUS Server API. The authenticators are re-calculated correctly.
The AXL RADIUS Server tracks upstream routing tables based on the source IP address of the Access-Request packet and routed back on any of the following attributes: NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address. Downstream proxy servers may send DM/COA packets if permitted by the AXL server's configuration.
So if an Access-Request comes from 192.168.1.1 the routing tables are loaded with any existing routing attributes (e.g. NAS-IP-Address). When a DMCOA packet is sent either by the AXL server or by a proxy server the AXL routing will send them to the example 192.168.1.1. The upstream routing tables are many-to-one allowing for different NAS-IP-Address's to be routed back to a single origin.
Proxy-State attributes are used in the normal way for reverse/forward DMCOA requests. One is added if there is a request or response for a proxy server. None are added if the AXL server is the source of the DM/COA request.
The Server uses the originally defined session identifier attributes found in RFC 3576:
User-Name
NAS-Port
Framed-IP-Address
Called-Station-Id
Calling-Station-Id
Acct-Session-Id
Acct-Multi-Session-Id
NAS-Port-Type
NAS-Port-Id
Originating-Line-Info
Framed-Interface-Id
Framed-IPv6-Prefix
There seems to be a fair bit of controversy in the 'Issue 200: RADIUS Response and Retransmissions' over these identifiers. It's certainly a good article on the vague nature of the original RFC.
=========================================================
Date: Wed, 23 May 2007 13:02:14 -0700
From: "Murtaza Chiba (mchiba)" <mchiba@cisco.com>
To: Bernard Aboba <aboba@internaut.com>
Subject: RE: RFC 3576bis Open Issues
Hi Bernard,
The answers are the question a) is configurable and b) is not implemented.
Regards,
Murtaza