Proposed Resolution to RFC 3576bis Issue 132: Must Proxy-State be Copied by NAS?

["Bernard Aboba" <bernard_aboba@hotmail.com>]

The text of issue 132 is enclosed below.  The proposed resolution is to add 
the following text to Section 3.2:

"      If there are any Proxy-State Attributes in a Disconnect-Request or
     CoA-Request received from the server, the forwarding proxy MUST
     include those Proxy-State Attributes in its response to the
     server.

     A forwarding proxy MUST NOT modify existing Proxy-State, State, or
     Class Attributes present in the packet.  The forwarding proxy 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."

------------------------------------------------------------------------------------------------------------------------
Issue 132: Must Proxy-State be Copied by the NAS?
Submitter name: Jim Martin
Submitter email address: jim@daedelus.com
Date first submitted: September 12, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00841.html
Document: RFC3576bis
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

I have a question regarding RFC3576, specifically the behavior
of the Proxy-State attribute when contained in a Disconnect Message.
Fundamentally, the question is, if a Disconnect-Request is received
by a NAS which contains a Proxy-State, MUST the NAS copy this Proxy-
State into the associated Disconnect-Response?

While there is no /explicit/ statement that says "Proxy-state
must be preserved by the client receiving the Disconnect-Request",
there are a couple of places where it is clearly implied.

First in section 2.3, in discussing the behavior of forwarding
proxies with respect to these messages, it says:
When using a forwarding proxy, the proxy must be able to alter the
packet as it passes through in each direction. When the proxy
forwards a Disconnect or CoA-Request, it MAY add a Proxy-State
Attribute, and when the proxy forwards a response, it MUST remove
its Proxy-State Attribute if it added one. Proxy-State is always
added or removed after any other Proxy-States, but no other
assumptions regarding its location within the list of Attributes
can be made. 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. A forwarding proxy MUST NOT modify existing Proxy-
State, State, or Class Attributes present in the packet.

To me, this seems a clear implication that the NAS would include the
proxy-state in the response, and hence the need for text to specify
that it must be removed by the proxy. This is further supported by
the following excerpt from the table in Section 3.2:

Disconnect Messages

Request      ACK      NAK      #      Attribute
[text deleted]
0+           0+       0+       33     Proxy-State

Do you (jointly or severally) agree with my assessment?
Clarification would be very helpful.

[Emile Bergen]
I completely agree -- the NAS has server role in this exchange, and just
like Proxy-State MUST be echoed by the server for Access-Request and
Accounting-Request packets, it MUST be echoed by the NAS for
Disconnect-Request (and other RFC3576 messages where the NAS functions
as the server), for exactly the same reasons.

The situation seems quite symmetrical to me.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>