[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed Resolution to RFC 3576bis Issue 132: Must Proxy-State be Copied by NAS?
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
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
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: email@example.com
Date first submitted: September 12, 2005
Comment type: T
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
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:
Request ACK NAK # Attribute
0+ 0+ 0+ 33 Proxy-State
Do you (jointly or severally) agree with my assessment?
Clarification would be very helpful.
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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.