[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Clarification on RFC3576: Must Proxy-State be copied by the NAS? (fwd)



Hi,

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.

Cheers,


Emile.

On Mon, Sep 12, 2005 at 07:14:26PM -0700, Bernard Aboba wrote:

> 
> -----Original Message-----
> From: Jim Martin [mailto:jim@daedelus.com] 
> Sent: Monday, September 12, 2005 3:57 AM
> To: mchiba@cisco.com; gdommety@cisco.com; meklund@cisco.com;
> david@mitton.com; Bernard Aboba
> Subject: Clarification on RFC3576: Must Proxy-State be copied by the
> NAS?
> 
> Gentlepeople,
>      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.
> 
>      Thanks!
> 
>      - Jim
> 
> --
> 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/>
-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

--
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/>