[Sipping] Re: Cookies vs. State

[[e-mail]]

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.

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?

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. 

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".

------------------------------------------------------------------------------

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