Subject: [Sipping] Cookies vs. State

From: Rohan Mahy <[email-masked]>
Date: Wed, 17 Apr 2002 23:32:55 -0700 (Pacific Daylight Time)

two comments inline with ##

thanks,
-rohan

To: [email-masked], [email-masked]
Subject: Re: [Sip] Cookies or State
From: [email-masked]
Date: Wed, 17 Apr 2002 19:21:12 EDT
--------------------------------------------------------------------------------
[email-masked] writes:

There are two drafts that define how to save state in a UA for subsequent
use by a Proxy Server - State and Cookies.

State is part of the DCS work.  Cookies arose when IP assertions were
made against State.  Cookies attempted to get around the IP issues
by defining it as exactly like HTTP cookies.  To our consternation,
the same IP claims were then made against Cookies!

We need to get this capability.  The question is, should we
base it on State or Cookies?

In my personal (biased) opinion we are better off with Cookies.
If anyone did want to fight the IP claim, you would clearly
be better off with 75% same language as HTTP cookies.

## i vote for cookies because it is more generic than state.

I presume the reference for "Cookies" is still draft-willis-sip-cookies-00
of July 2001. I haven't seen any further discussion on this draft or
responses to the comments I submitted Nov 19. From that draft, it appears
there are significant security concerns with the use of "Cookies" in a
fashion similar to HTTP as proposed in this draft.

State would appear to have fewer security concerns if it is simply a value
stored in the UA for the beniefit of the proxy to fetch and use later. 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).

It continues to escape me why it would not be better for the proxy to
simply stored this "state" in its own storage, rather than using every UA
as a distributed storage device. This concept seems to go back to the days
when memory was limited (the first telephone switch I was involved in
designing had 64k bytes of memory!) When one can buy 512M bytes of memory
for less than $100, this should no longer be an issue. The "state" draft
seems to indicate that the only reason for doing this is so that "proxy
servers can remain stateless for the duration of the call", but I have
never heard a reason why this is desirable. (Note that bis-09 defines the
term "call-stateful proxy".) Why don't we just admit that it is required
in some cases to keep the call state in the proxy and stop trying to
invent ways around this, all of which have security and performance
problems?

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

Mike

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

---

From: Gordon Ledgard <[email-masked]>
Date: Thu, 18 Apr 2002 11:31:54 -0400

Inline....

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Thursday, April 18, 2002 10:59 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Sipping] Re: Cookies vs. State
> 
> 
> 
> 
> On Thu, 18 Apr 2002 [email-masked] wrote:
> > In a message dated 4/18/02 2:35:58 AM Eastern Daylight 
> Time, [email-masked]
> > writes:
> > In a message dated 4/17/02 9:06:48 PM Eastern Daylight Time,
> > [email-masked] 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
> >
> >
> >
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 18 Apr 2002 13:27:16 -0400

>----------------------------------------------------- 
functionality, >derived from RFC 2109. 
>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.
Agreed.  We do so primarily by limiting Cookies to the duration of a call 

>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. 
Of course we don't know exactly what cookies will be used for, but since
almost all of the "regular telephone-type services", including all forms
of Call Transfer, don't need cookies, I think we are pretty safe.

>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 
In HTTP, cookies are often "permanent".  Most of the abuse of cookies 
comes from this use.  Of course you can discard HTTP cookies at any time.
You may lose some "services" if you do.  Same with SIP cookies, but we
specify that cookies ARE NOT saved across sessions, primarily to avoid
the abuse that we have seen with HTTP cookies.

>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.
Woah, you don't send ALL stored cookies, you send those associated with
a particular call.  Message size can be a problem, in wireless networks,
and when message size exceeds MTU size with UDP.  That is a consideration
which the draft should note.

>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. 
Yes, but that would get us back to security issues wouldn't it.
I think we should not allow cookies to be held across calls until
we have better mechanisms to control abuse.

>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. 
Several others have noted that it is much easier to support high
availability
when state is stored in the endpoints rather than to have replication
mechanisms and all sorts of other gunk required when state is maintained
in the proxy server.  Some would say that while call-statefull proxies
may be needed for some services, they are mostly undesirable, and
SIP is designed for statefull UAs and stateless proxies.  Cookies
continues that design philosophy.

>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. 
State and Cookies predate SIP Change Process and have been grandfathered
in.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Apr 2002 09:05:10 -0400

>If the point is to store "state" in the UA by this method, then it's 
>obvious to me that the requirement is to store exactly one Cookie 
>per call. (One could argue whether a multipoint call like three way 
>calling is modeled as one call or two.) 
No, there could be multiple intermediaries in a call that need state
to be saved.  Each would add a cookie if it needed to.  Therefore
you could have multiple cookies per call.

>High availability with everything stored in one place is certainly 
>easier than storing the data in end devices and working out all 
>the protocol and security issues to fetch it whenever feature 
>processing needs to know it. Design technique for highly reliable 
>systems, often based on redundant pairs with sharing of state 
>information, has been around for decades. 
Yes, and the experience of building these systems is that it is
very hard to get them right.  It is possible, but hard.

>And I continue to puzzle over why a call stateful, highly reliable 
>proxy to control some service is considered to be "undesirable". 
>And it's not sufficient to say "because that's not the way http did it". 
Because many find that it's a whole lot easier to get stateless systems
reliable and scaleable then a stateful system.  If you want to build
systems that use replicated state by all means, do it.  To enable
people who want to build systems where state is kept in the UA, we
offer cookies.