Subject: [Sipping] Re: Cookies vs. State

From: [email-masked]
Date: Thu, 18 Apr 2002 15:39:40 EDT

In a message dated 4/18/02 11:02:35 AM Eastern Daylight Time, [email-masked] 
writes:

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

Yes, I've been involved in the design and implementation of 3 telephony 
switching systems, where the presumed requirement was for high 
reliability/almost no down time. They operated on the principle of 
active/standby processors and critical peripherals and performed "state" 
sharing between the two sides in order to support switch-over when the active 
side failed. I guess coming from this design background, I continue to wonder 
why so much effort is being put into complex protocols and procedures between 
devices which have a high failure rate and down time rather than tackling the 
real problem. Telephone and data switching equipment in the past was designed 
for low failure and down time and I continue to wonder why I keep getting 
e-mails from our system administrator that "The LAN or e-mail server will be 
down for several hours for maintenance".

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

> 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..." ?
> 
> 
That was my comment. Any device which does not guarantee that the Cookie is 
thrown away when I "hang up" is non-compliant.

Mike

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 18 Apr 2002 13:03:25 -0700 (Pacific Daylight Time)

> down for several hours for maintenance".

Based on your description, you did not implement such a system in software
(as I queried), but in hardware instead.  It is fundamental to the
Internet model to use lots of cheap distributed components.  Despite the
phone systems better reliability during oridinary usage, the Internet
continues to adapt better to unforseen massive failures.  Your Mileage May
Vary.

> thrown away when I "hang up" is non-compliant.

Agreed.

thanks,
-rohan

> 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: Henry Sinnreich <[email-masked]>
Date: Thu, 18 Apr 2002 16:00:25 -0500

>"The LAN or e-mail server will be down for several hours for
maintenance". 

Sorry, but this does not happen in environments that have a distributed
server architecture, with DNS based or other load sharing approach. I
don't like to say it, but I am just fortunate to live in such a
resilient network, so I know it can be done with non-telephony, non-
"carrier strength" approach. The "carrier strength" boxes were and still
are designed for the single mode of failure architecture in the ITU-T
central control models. Or in the softswitch and many IP PBX models.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, April 18, 2002 2:40 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Sipping] Re: Cookies vs. State

In a message dated 4/18/02 11:02:35 AM Eastern Daylight Time,
[email-masked] writes: 

> Further, as Dean wrote: 'Both approaches leave the format of the
"hunk" open 
> table stored on the proxy, or almost anything else.' It seems to me
that any 
> understand the State or Cookie anyway, unless they share keys.
Wouldn't that 

no.  have you ever implemented a robust, real-time, high-availability 
state sharing mechanism in software?

Yes, I've been involved in the design and implementation of 3 telephony
switching systems, where the presumed requirement was for high
reliability/almost no down time. They operated on the principle of
active/standby processors and critical peripherals and performed "state"
sharing between the two sides in order to support switch-over when the
active side failed. I guess coming from this design background, I
continue to wonder why so much effort is being put into complex
protocols and procedures between devices which have a high failure rate
and down time rather than tackling the real problem. Telephone and data
switching equipment in the past was designed for low failure and down
time and I continue to wonder why I keep getting e-mails from our system
administrator that "The LAN or e-mail server will be down for several
hours for maintenance". 

urgent 
it's 
> the current dialog plus any dialog resulting from redirection or
referral of 
> 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 
other 
> than the one setting up the call (or by a limited set which may take
over for 

  Cookies are discarded when the call instantiating the cookie and all 
  calls derived from that call have terminated.

That was my comment. Any device which does not guarantee that the Cookie
is thrown away when I "hang up" is non-compliant. 

Mike