RE: [Sipping] Re: Cookies vs. State

[Gordon Ledgard <[e-mail]>]

Inline....


> -----Original Message-----
> From: Rohan Mahy [mailto:[e-mail]]
> Sent: Thursday, April 18, 2002 10:59 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: [Sipping] Re: Cookies vs. State
> 
> 
> 
> 
> On Thu, 18 Apr 2002 [e-mail] wrote:
> > In a message dated 4/18/02 2:35:58 AM Eastern Daylight 
> Time, [e-mail]
> > writes:
> > > ## the reason to allow a server to remain stateless 
> allows servers to fail
> > > ## in the middle of a call without interruption of 
> service.  this is
> > > ## arguably much easier/better/faster than requiring SIP 
> servers to fully
> > > ## mirror call state across a cluster of servers.
> > > ## thx, -r
> >
> > In a message dated 4/17/02 9:06:48 PM Eastern Daylight Time,
> > [e-mail] writes:
> > > The concern for being stateless is not memory but HA. 
> What happens when a
> > > Call statefull proxy dies? How do you reconstruct states 
> after recovery?
> > > Distributing state to edge lowers the risk in failure 
> conditions. If a US
> > > fails, it only affect that very UA none else [when UA is 
> dead - the call is
> > > anyway lost]. Providing HA a statefull proxy is not easy 
> job either.
> >
> > Yes, I presumed that someone would use the above as the 
> reason for storing
> > state (whether as "Cookie" or "State") in the UA. That's 
> why my original
> > e-mail stated that "It is presumed that the lack of a 
> standard definition of
> > this state value would preclude its use by a different 
> proxy than the one
> > which stored it (at least by a proxy of a different 
> design)." Another proxy
> > could take over for a failed one only if they had a common 
> understanding of
> > the contents of the "State" or "Cookie". I don't see this 
> ever happening
> > between proxies of a different design, therefore, I think 
> it is wrong to use
> > it. If you can standardize the contents of either, that is 
> a different story.
> 
> typically only one or two enitities in the path of the call are
> likely to set/check cookies.  the cookies set by one server 
> just need to
> be understood by other members of the same high-availability cluster.
> this is really MUCH less of a big deal than you are making it 
> out to be.
> 
> > Further, as Dean wrote: 'Both approaches leave the format 
> of the "hunk" open
> > -- it could be cryptographically protected, just a hash 
> value matching a
> > table stored on the proxy, or almost anything else.' It 
> seems to me that any
> > of these security measures would prevent another proxy from 
> being able to
> > understand the State or Cookie anyway, unless they share 
> keys. Wouldn't that
> > be as hard as sharing states?
> 
> no.  have you ever implemented a robust, real-time, high-availability
> state sharing mechanism in software?
> 

To expand on "NO" for a moment, all the members of the cluster have to
do is exchange keys or markers when they boot up or come into the cluster.
Easy as cake. If they share the actual state, they need to constantly
update each other or some other repository each time the state changes.



> > State is clearly less of a security problem than Cookie. As 
> noted in the
> > "State" draft, 'Cookies typically persist across sessions'. 
> "State", on the
> > other hand, clearly only exists until the next state 
> change, i.e., when a
> > call ends, the state disappears (or goes to idle). Cookies, 
> on the other hand
> > may persist longer and the indication in previous 
> discussions was that they
> > may contain more than just "state" information and may do 
> other things like
> > cause new calls to be initiated.
> 
> The state draft was written before the SIP cookies draft, and 
> so refers to
> an assumed use of HTTP cookies.  This last sentence clearly does not
> apply SIP cookies.
> 
> > As Dean noted: "I also believe the security concern is 
> SLIGHTLY less urgent
> > than in HTTP. As I understand it, both state and cookie 
> drafts indicate a
> > substantially shorter lifetime for the token. In the case 
> of state, the
> > lifetime is the duration of the current dialog. In the case 
> of cookie, it's
> > the current dialog plus any dialog resulting from 
> redirection or referral of
> > the original dialog.
> > HTTP cookies, on the other hand, persist relatively 
> indefiitely and may be
> > extracted by any server in the domain of the cookie during any HTTP
> > interaction with said server for the duraction of the cookie."
> >
> > I addressed this issue of Cookie persistance in my November 
> 19 comments which
> > I will repeat below. The only way that "Cookie" can be 
> allowed is if it must
> > be erased at the end of a call and if it can not be read by 
> any proxy other
> > than the one setting up the call (or by a limited set which 
> may take over for
> > another proxy in the case of proxy failure and which the UA 
> can verify is
> > allowed to handle the call further). Any other use would be 
> a serious
> > security problem and probably illegal in some places. A 
> device must be
> > considered non-compliant if it does not erase the "Cookie".
> 
> Perhaps this should be more obvious, but Section 5.1 of the 
> SIP cookies
> draft states:
> 
>    Cookies are discarded when the call instantiating the 
> cookie and all
>    calls derived from that call have terminated.
> 
> The purpose of this sentence was clearly to prevent the kind of abuses
> permitted by the current HTTP mechanism.  Would you be 
> satisfied if this
> sentence said "Cookies MUST be discarded..." ?
> 
> thanks,
> -rohan
> 
> > 
> --------------------------------------------------------------
> ----------------
> >
> > -----------------------------------------------------------
> > Comments on draft-willis-sip-cookies-00:
> >
> > This draft provides a good base-line for definition of a SIP-cookie
> > functionality, derived from RFC 2109.
> >
> > Some comments/observations:
> >
> > 1. The proposed SIP-cookie borrows heavily from the 
> definition/procedures of
> > cookies for HTTP (RFC 2109). Given the known possibility of 
> abuse of cookies
> > in HTTP, it is very important that the avoidance of such 
> abuse be considered
> > for SIP.
> >
> > 2. Currently, if one disables all cookies in their browser, 
> certain web-based
> > applications such as on-line shopping are not usable, but 
> this does not
> > affect access to most web-browsing. If the support of SIP cookies is
> > essential to the provision of regular telephone type 
> service (e.g., Call
> > Transfer), a user would not be able to disable cookies, 
> thereby exposing
> > themselves to possible abuse. The draft is written as if a 
> User Agent is
> > required to store cookies, that is, can not disable them as 
> a web-browser can
> > today.
> >
> > 3. Section 8, Security Considerations states: "Cookies in 
> SIP, unlike cookies
> > in HTTP, are discarded at the conclusion of a session." It 
> is not clear why
> > this is stated, since RFC 2109 allows the User Agent to 
> discard cookies. It
> > states that "When a user agent terminates execution, it 
> should let the user
> > discard all state information." It seems that the common 
> browsers do not
> > choose to provide the user with this option to discard 
> cookies upon exit,
> > probably since the companies that produce them want to use 
> these persistent
> > cookies as much as any other companies. If these same 
> companies implement SIP
> > functionality, it can be expected that they will choose to 
> not discard
> > SIP-cookies at the conclusion of a telephone call either.
> >
> > 4. As I understand the draft, it requires a user agent to 
> store cookies, and
> > seems to make a strong objective that it must store at 
> least 10 cookies of at
> > least 4096 bytes each, and that it must include all stored 
> cookies in every
> > subsequent message it sends associated with a call. Since 
> other draft
> > proposals result in sending a very large number of messages for some
> > capabilities, especially those associated with providing 
> security, it would
> > appear that this results in huge amounts of data being 
> sent. It is obvious
> > this can not lead to an efficient telephone service.
> >
> > 5. One could easily envision services that would benefit 
> from retaining
> > SIP-cookies after completion of a call in order to support 
> a new call.
> >
> > 6. This draft appears to be one more admission that 
> processing of many (maybe
> > all) telephone type applications requires that the entity 
> controlling the
> > service have knowledge of the "state" of the call. In an 
> increasing number of
> > defined applications, it is a proxy that controls the 
> service (not the user
> > agent as perhaps originally envisioned) and that proxy 
> needs to "remember"
> > the state of the call and service. RFC 2543 included the 
> concept of a
> > "stateful proxy", which maintains the state of a 
> transaction (until a
> > definitive response is received). The proposed revision of 
> SIP further
> > refines this definition of "stateful proxy" and then 
> introduces the notion of
> > a "call stateful (proxy)" which maintains the state "from 
> the initiating
> > INVITE to the terminating BYE", but it does not describe in 
> detail the
> > operation of a "call stateful proxy".
> >
> > For the control of telephone services using SIP beyond the 
> simple, basic
> > call, it appears that the time has come to admit that these 
> services require
> > a "call stateful proxy" and not to depend on storing of 
> "cookies" in user
> > agents as a substitute.
> >
> > 7. For some yet to be defined SIP-provided services, this 
> cookie mechanism
> > will probably be essential. In line with the recent draft 
> for "SIP Change
> > Process", draft-tsvarea-sipchange-00.txt, a definition of 
> the requirements
> > needs to be submitted to SIPPING. This would identify the 
> specific class of
> > services/capabilities that require the addition of a 
> SIP-cookie. It should be
> > intended for special cases (equivalent to the shopping cart 
> example in RFC
> > 2109), not support for everyday telephone services.
> >
> > Mike Pierce
> > Artel
> >
> >
> >
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP