RE: [Sipping] Re: Cookies vs. State

["Rosen, Brian" <[e-mail]>]

>----------------------------------------------------- 
>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.
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 
>SIP-cookies at the conclusion of a telephone call either. 
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.


_______________________________________________
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