Subject: RE: [Sip] A sips: trial balloon for you to shoot down

From: "Elwell, John" <[email-masked]>
Date: Thu, 02 Nov 2006 21:23:49 +0000

Francois,

If I understand you correctly, I would favour 3. In other words, if a PSTN
gateway receives a SIPS request it should be able to accept it. Any concerns
about security within or beyond the PSTN should be dealt with by some other
(to be investigated) mechanism.

John 

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 02 November 2006 19:19
> To: Dean Willis; Attila Sipos
> Cc: IETF SIP List
> Subject: RE: [Sip] A sips: trial balloon for you to shoot down
> 
>  
> 
> > -----Original Message-----
> > From: Dean Willis [mailto:[email-masked]] 
> > Sent: Thursday, November 02, 2006 9:44 AM
> > To: Attila Sipos
> > Cc: IETF SIP List
> > Subject: Re: [Sip] A sips: trial balloon for you to shoot down
> > 
> > 
> > Attila aksed:
> > > So, what you're saying that PSTN gateways should use a
> > > sip: URI with transport=tls?
> > >
> > 
> > I think so.
> 
> That would require a normative change to RFC 3261 which has 
> deprecated transport=tls.
> 
> Furthermore, I think this is a bad idea to be honest. I'd rather
> have the suggestion that someone made that requests with SIPoverTLS
> be forwarded to SIPoverTLS by proxies.
> 
> I think we have 4 choices for PSTN Gateways:
> 
> 1 - SIPS is only valid if all hops are withing a SIP network. PSTN
>     gateways would therefore not use SIPS. Gateways to H.323 wouldn't
>     either, even if H.323 is secured (same thing for other protocols).
> 
> 2 - SIPS is valid withing an IP network. H.323 gateways could 
>     use SIPS, provided they are using an equivalent security level on
>     the H.323 side. PSTN gateways gateways would therefore 
> not use SIPS.
> 
> 3 - SIPS is significant only withing a SIP network, and 
> hop-off to PSTN
>     or other networks such as H.323 ARE allowed (in the case of H.323,
> it would
>     require security). 
> 
> 4 - SIPS is significant only withing a SIP network, and 
> hop-off to PSTN
>     or other networks such as H.323 ARE allowed and in both cases, you
>     would require the gateway network to use security. 
> 
> I think Brian Rosen favored 4. Personally, I prefer either 1 or 2.
> 
> There are quite different however. 
> 
> 1 is my farorite choice if we think that sips has a limitted life-span
> and
> will have limited deployment, and will eventually be replaced by
> something better.
> 
> 2 is my favorite if we believe sips has a more long-term future.
> 
> > > Can we, possibly with Requires, enforce that all hops use the TLS?
> > 
> > We possibly could, but that would be a new SIP extension, not 
> > part of the current sips: specification, and outside of the 
> > scope of what could be done with an informational or BCP document.
> 
> Right.
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Nov 2006 17:04:41 -0500

John beat me to it. I also favor 3 (without the special case for H.323) 
because it is the only one that is really well defined. Once you get 
beyond this you are talking about the semantics of what is being 
carried, and we are going need something else to deal with that.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 2 Nov 2006 17:38:58 -0500

I guess the problem here is whether you consider the PSTN to be secure, in
the sense of TLS, expressed in Dean's proposed wording.  If you do, then
what you propose is consistent.

Can you give me a use case where sips does something useful when one end is
on the PSTN?

I don't think anyone believes the PSTN is secure in anything close to TLS
level security.  I sort of understand the issue of the IETF can only control
the sip path, and what happens beyond is not in its purview.  Using that to
create meaningless mechanisms isn't helpful IMO.

Let's use the example cited a little while ago: a MESSAGE.  You clearly
could, at a gateway, convert that to SMS.  Does it make ANY sense to call
that secure if it was TLS from UAC to a gateway, and then over a GSM network
to a handset?  Isn't there a substantive difference between that and TLS
protected MESSAGE all the way to the handset?  What earthly good does it do
to get sips to succeed if the last hop is not secure?  I think if the
gateway knows its not the end of the signaling, then it has to fail sips if
it can't maintain TLS.

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, November 02, 2006 5:05 PM
> To: Elwell, John
> Cc: IETF SIP List; Francois Audet; Dean Willis

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Nov 2006 18:52:19 -0600

> gateway knows its not the end of the signaling, then it has to fail  

Ouch. Good example. I was about to endorse #3, but I think you're  
onto something here.

--
Dean

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 2 Nov 2006 23:17:47 -0500

So far the explanation/argument of sips has been that sips is not a synonym
for human-to-human security.  It does not provide a lock icon.  It is
nothing more than a mandate that each sip hop use TLS.  It is just a uri
scheme, which behaves like a require/proxy-require for transport=tls.  It is
nothing more than that.

Your proposal is that it become more than a uri scheme for sip; that it
become a human-level request for TLS or TLS-level of "secure" (whatever that
is defined as), regardless of the protocol.  That it reaches something past
the UAS, in some higher plane.  Almost like a require that the message
headers (and really the body) not leave a cpu.  Or maybe a new scheme called
tls. :)

Don't get me wrong - I understand what you mean and why, but SIPS isn't it.
It would be a significant divergence from 3261 to define a sips uri scheme
as having such a property, to reach beyond the SIPS UAS, IMO.  The uri in
the sips request is not even the identifier of the SMS receiver.  It is the
identifier of the gateway.  If you reached that gateway using TLS, then you
succeeded.  

Does any URI or scheme mean more?  Http, https, email, ftp, etc. all
identify the server/end of the protocol, not something beyond. (an
interesting one would be tel - if there was a tels, that is) 

I think what you're really looking for is a new thing.

-hadriel

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, November 02, 2006 5:39 PM
> To: 'Paul Kyzivat'; 'Elwell, John'
> Cc: 'IETF SIP List'; 'Francois Audet'; 'Dean Willis'

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 2 Nov 2006 23:50:32 -0500

>  What earthly good does it do
> gateway knows its not the end of the signaling, then it has to fail sips
> if it can't maintain TLS.

But that sip-sms gateway is the end of the signaling.  The end of SIP
signaling altogether.  The body contents happened to get transferred in
another protocol though.

But ok, so let's say the MESSAGE gateway sends it over email (not unlikely).
It happens to be able to get an SMTP over TLS connection to your email
server.  So it can do it, right?  Little did it know the end user uses pop3
in the clear to pull down email from that server, or that server then
forwarded it to an SMS gateway.  Or your sips-based Invite audio session was
to a sips voicemail server, but the user used sip to hear your voicemail.
What earthly good was done?  ;)

-hadriel

---

From: Aki Niemi <[email-masked]>
Date: Fri, 03 Nov 2006 11:01:17 +0200

> create meaningless mechanisms isn't helpful IMO.

What do you mean by "TLS level security"? AFAICS, sips is still meant to
work as a hop-by-hop security mechanism, much like how the PSTN works.

> gateway knows its not the end of the signaling, then it has to fail sips if

Can you explain how this would be any different for a web form, used via
 an https URL, that feeds a message as an SMS into the GSM cloud? i
don't see the HTTP community spending effort in figuring out how to deal
with that type of corner cases.

I think this particular monkey-wrench is not particularly interesting,
and the only thing the IETF *can* do is something along the lines of #3
in Francois' note.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Nov 2006 09:04:20 -0500

This time Hadriel gave the answer I would have given.

To answer Brian directly, no I don't think the PSTN is secure in the 
sense of TLS. But it does have some security properties that, at least 
on average, are better than what one gets with unsecured sip over the 
internet. Using SIPS sips to reach a GW may provide a useful tool for 
creating an end to end session that is no worse than a pure PSTN 
session. That in itself is worth something. The same is true if it is a 
MESSAGE gateway to SMS.

The SIPS itself doesn't guarantee this. It is only SIPS in combination 
with the UAs and what they do that guarantees that. But everything that 
extends beyond the UAs (including a UA that drives a UI) has such a 
dependency.

(I find the positions in this discussion to be very interesting. I find 
I am aligned with those I have often have had differences with in the 
past, and arguing with those I typically more often agree with. I have 
no idea what that means.)

	Paul

Hadriel Kaplan wrote:
>> if

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 3 Nov 2006 11:33:14 -0500

The proposal Dean made included this text:
>Where TLS is not used, the implementor MUST exercise a high level of
>caution to provide adequate security and MUST preserve operationally
>equivalent protection of message integrity, privacy, and participant
>identity (authentication).

A PSTN gateway does not do that. 

Again, as has been said, we'll all agree that sips is not sufficient to
solve all of our security problems, and I readily see that there are
circumstances where the security in the PSTN is considered sufficient.  I
claim that's not sips.

Brian

> Sent: Friday, November 03, 2006 9:04 AM
> To: Hadriel Kaplan
> Cc: 'Brian Rosen'; 'IETF SIP List'
> >> Can you give me a use case where sips does something useful when one
> end
> >> is
> >> on the PSTN?
> >>
> >> the sip path, and what happens beyond is not in its purview.  Using
> that
> >> to
> >> protected MESSAGE all the way to the handset?  What earthly good does
> it
> >> do

---

From: Michael Thomas <[email-masked]>
Date: Fri, 03 Nov 2006 08:43:10 -0800

> Ouch. Good example. I was about to endorse #3, but I think you're  

I find all of this slippery slopery rather fascinating. On the one hand, 
I'm being
told that SIPS is a crappy stopgap and that I shouldn't be too worried 
about the
trust implications of evil middle proxies, and other hand I see this 
amazing amount
of hand-wringing about what happens when it's outside of the realm of SIP.

Riddle me this: I assume you have no problem with a SIPS session 
terminating
on my host and that I blat out the payload to a terminal window? What 
happens
if the terminal window is, oh say, at Times Square via a handy VNC 
connection?

       Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Nov 2006 11:43:26 -0500

> A PSTN gateway does not do that. 

And I'm not agreeing with that. I think the UA in this case does what it 
does. It may do something special if sips was used, and it may not. 
While what it does may be important to the sender at the other end, it 
just doesn't have anything to do with SIPS.

As others have pointed out, this is just like HTTPS. There is nothing in 
the specification of HTPPS that requires the HTTPS server to treat the 
information it receives securely.

Based on your criteria, if a server receives a MESSAGE over SIPS, what 
may it do with it, and what may it not do with it? Can it store the 
message on a file server? Does it matter what the security of the file 
server is? How is storing it on an insecure file server any better than 
sending it via SMS?

	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 3 Nov 2006 10:55:52 -0600

On Nov 3, 2006, at 10:43 AM, Michael Thomas wrote:

> on my host and that I blat out the payload to a terminal window?  
> What happens

Well, that's your problem. We probably wouldn't document it as a Best  
Current Practice, however.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Fri, 03 Nov 2006 09:03:03 -0800

> Current Practice, however.

So the fact that I turned it into a bunch of rectangles and sent it 
somewhere
is enough disqualify it from getting the GoodSIPSkeeping Seal of Approval?
What if I mangle it a bit first and make some SIP Haiku before I render 
it into
rectangles? Still not SIPSworthy?

Not that we're not talking about a BCP per se: we're talking about 
whether my
host should reject the SIPS message or not.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 03 Nov 2006 09:06:54 -0800

> Current Practice, however.

Also: from a Dev standpoint, you're presupposing that the SIP input side 
of the
call leg has any clue whatsoever as to what the output side of the call 
or whatever
else it might be will do with the message. That is think is completely 
untenable in
all but the most fixed function of devices, and even then may be 
ridiculously
difficult. Which is to say: you can specify it in some net.schoolmarm 
fashion, but
that doesn't mean anybody will obey it.

       Mike

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Nov 2006 11:25:37 -0600

Brian, I'm a bit confused now...

Do you think that sips is usable to a PSTN gateway, or not?

Or are you saying that it depends what the gateways does with it? 

> Sent: Friday, November 03, 2006 8:33 AM
> To: 'Paul Kyzivat'; 'Hadriel Kaplan'
> Cc: 'IETF SIP List'
> Again, as has been said, we'll all agree that sips is not 
> sufficient to solve all of our security problems, and I 
> readily see that there are circumstances where the security 
> in the PSTN is considered sufficient.  I claim that's not sips.
> 
> Brian
> 
> > session. That in itself is worth something. The same is 
> true if it is 
> > a MESSAGE gateway to SMS.
> > 
> > with the UAs and what they do that guarantees that. But everything 
> > that extends beyond the UAs (including a UA that drives a 
> UI) has such 
> > a dependency.
> > 
> > (I find the positions in this discussion to be very interesting. I 
> > find I am aligned with those I have often have had 
> differences with in 
> > the past, and arguing with those I typically more often 
> agree with. I 
> > have no idea what that means.)
> > 
> > 	Paul
> > 
> > Hadriel Kaplan wrote:
> > > So far the explanation/argument of sips has been that 
> sips is not a
> > synonym
> > > for human-to-human security.  It does not provide a lock 
> icon.  It 
> > > is nothing more than a mandate that each sip hop use TLS.  It is 
> > > just a uri scheme, which behaves like a 
> require/proxy-require for transport=tls.
> > It is
> > > nothing more than that.
> > >
> > > Your proposal is that it become more than a uri scheme 
> for sip; that 
> > > it become a human-level request for TLS or TLS-level of "secure" 
> > > (whatever
> > that
> > > is defined as), regardless of the protocol.  That it reaches 
> > > something
> > past
> > > the UAS, in some higher plane.  Almost like a require that the 
> > > message headers (and really the body) not leave a cpu.  
> Or maybe a 
> > > new scheme
> > called
> > > tls. :)
> > >
> > > Don't get me wrong - I understand what you mean and why, but SIPS 
> > > isn't
> > it.
> > > It would be a significant divergence from 3261 to define 
> a sips uri
> > scheme
> > > as having such a property, to reach beyond the SIPS UAS, 
> IMO.  The 
> > > uri
> > in
> > > the sips request is not even the identifier of the SMS 
> receiver.  It 
> > > is
> > the
> > > identifier of the gateway.  If you reached that gateway 
> using TLS, 
> > > then
> > you
> > > succeeded.
> > >
> > >> I guess the problem here is whether you consider the PSTN to be 
> > >> secure,
> > in
> > >> the sense of TLS, expressed in Dean's proposed wording.  
> If you do,
> > then
> > >> I don't think anyone believes the PSTN is secure in 
> anything close 
> > >> to
> > TLS
> > >> level security.  I sort of understand the issue of the IETF can 
> > >> only control the sip path, and what happens beyond is not in its 
> > >> purview.  Using
> > that
> > >> to
> > >> Let's use the example cited a little while ago: a MESSAGE.  You 
> > >> clearly could, at a gateway, convert that to SMS.  Does 
> it make ANY 
> > >> sense to
> > call
> > >> that secure if it was TLS from UAC to a gateway, and then over a 
> > >> GSM network to a handset?  Isn't there a substantive difference 
> > >> between that and
> > TLS
> > >> to get sips to succeed if the last hop is not secure?  I 
> think if 
> > >> the gateway knows its not the end of the signaling, then 
> it has to 
> > >> fail
> > sips
> > >> if
> > >> it can't maintain TLS.
> > >>
> > >> Brian
> > >
> > >
> > > This list is for NEW development of the core SIP Protocol Use 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments on the application of sip
> > >
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Nov 2006 13:06:33 -0500

Just to be clear, what I am proposing is that SIPS mean that there is a 
hop-by-hop TLS connection from UAC to UAS. Period. Nothing more, nothing 
less.

If one of the UAs happens to be a B2BUA, this says nothing about what 
happens on the other side. If one of the UAs happens to be a PSTN 
gateway, it says nothing about that either.

While this is pretty weak, it has the benefit of being well defined. I 
don't think we will be getting into disagreements about whether a 
particular use case complies or not.

Will it, by itself, solve any real world security problem? Probably not. 
But IMO no other plausible definition of sips will do that either.

Then we can move on and work on other kinds of security that promise 
more, possibly using SIPS as a component of the solution.

	Paul

Paul Kyzivat wrote:
>>>>> clearly

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 3 Nov 2006 13:20:20 -0500

What if we turn this around?

The PSTN circuit switched world has physical security. Its users have some 
assurance that the "bits" of their phone call are delivered intact and only 
those with access to and control of the switching equipment could see or 
muck with those bits. In the packet world, we must use TLS to provide the 
same assurance because things in the clear can be seen and mucked by anybody 
with a computer. With TLS, only those with access to or control of the 
intermediaries (proxies, B2BUA, SBCs, etc) can see or muck with the 
signaling "bits". We have the a similar sort of transitive trust, although 
in the wide open Internet we may have not have the pre-established 
relationships between providers as exists in the PSTN.

The requirement for sips is at a minimum is to provide that level of 
security. Its not to equal a military secure phone. That's the next level of 
security that needs to be worked on.

Therefore, I would say, that a PSTN gateway injecting a call into the sip 
network MUST use sips to at least equal the level of security provided by 
the PSTN.

If we want a level of security that would require the PSTN to provide the 
military secure phone, that's something more than sips.

I guess that would make sips equivalent to Dean's idea of BCP SIPoverTLS. 
But I think that is what sips is today.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

----- Original Message ----- 
From: "Michael Thomas" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: "'IETF SIP List'" <[email-masked]>; "'Paul Kyzivat'" <[email-masked]>; 
"'Elwell, John'" <[email-masked]>; "'Francois Audet'" 
<[email-masked]>
Sent: Friday, November 03, 2006 12:06 PM
Subject: Re: [Sip] A sips: trial balloon for you to shoot down

> call leg has any clue whatsoever as to what the output side of the call or 
> whatever

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Nov 2006 12:39:27 -0600

So, if I understand you correctly, you favor allowing SIPS to PSTN 
gateway, regardless of what it does after, right?

> Sent: Friday, November 03, 2006 10:07 AM
> To: Paul Kyzivat
> Cc: 'IETF SIP List'
> Just to be clear, what I am proposing is that SIPS mean that 
> there is a hop-by-hop TLS connection from UAC to UAS. Period. 
> Nothing more, nothing less.
> 
> If one of the UAs happens to be a B2BUA, this says nothing 
> about what happens on the other side. If one of the UAs 
> happens to be a PSTN gateway, it says nothing about that either.
> 
> While this is pretty weak, it has the benefit of being well 
> defined. I don't think we will be getting into disagreements 
> about whether a particular use case complies or not.
> 
> Then we can move on and work on other kinds of security that 
> promise more, possibly using SIPS as a component of the solution.
> 
> 	Paul
> 
> Paul Kyzivat wrote:
> > 
> > 
> > Brian Rosen wrote:
> > And I'm not agreeing with that. I think the UA in this case 
> does what 
> > it does. It may do something special if sips was used, and 
> it may not.
> > As others have pointed out, this is just like HTTPS. There 
> is nothing 
> > in the specification of HTPPS that requires the HTTPS 
> server to treat 
> > the information it receives securely.
> > 
> > server is? How is storing it on an insecure file server any better 
> > than sending it via SMS?
> > 
> >     Paul
> > 
> sufficient 
> >> to solve all of our security problems, and I readily see 
> that there 
> >> are circumstances where the security in the PSTN is considered 
> >> sufficient.  I claim that's not sips.
> >>
> >> Brian
> >>
> >>> sense of TLS. But it does have some security properties that, at 
> >>> least on average, are better than what one gets with 
> unsecured sip 
> >>> over the internet. Using SIPS sips to reach a GW may provide a 
> >>> useful tool for creating an end to end session that is no 
> worse than 
> >>> a pure PSTN session. That in itself is worth something. 
> The same is 
> >>> true if it is a MESSAGE gateway to SMS.
> >>>
> >>> The SIPS itself doesn't guarantee this. It is only SIPS in 
> >>> combination with the UAs and what they do that guarantees 
> that. But 
> >>> everything that extends beyond the UAs (including a UA 
> that drives a 
> >>> UI) has such a dependency.
> >>>
> differences with 
> >>> in the past, and arguing with those I typically more often agree 
> >>> with. I have no idea what that means.)
> >>>
> >>>     Paul
> >>>
> >>> Hadriel Kaplan wrote:
> >>>> Your proposal is that it become more than a uri scheme for sip; 
> >>>> that it become a human-level request for TLS or TLS-level of 
> >>>> "secure" (whatever
> >>> that
> receiver.  
> >>>> Does any URI or scheme mean more?  Http, https, email, ftp, etc. 
> >>>> all identify the server/end of the protocol, not 
> something beyond. 
> >>>> (an interesting one would be tel - if there was a tels, that is)
> >>>>
> >>>>> the sense of TLS, expressed in Dean's proposed wording.  If you 
> >>>>> do,
> >>> then
> >>>>> Can you give me a use case where sips does something 
> useful when 
> >>>>> one
> >>> end
> >>>>> is
> >>>>> on the PSTN?
> >>>>>
> >>>>> clearly could, at a gateway, convert that to SMS.  Does it make 
> >>>>> ANY sense to
> >>> call
> >>>>> protected MESSAGE all the way to the handset?  What 
> earthly good 
> >>>>> does
> >>> it
> >>>>> do
> >>>>> to get sips to succeed if the last hop is not secure?  
> I think if 
> >>>>> the gateway knows its not the end of the signaling, 
> then it has to 
> >>>>> fail
> >>> sips
> >>>>> if
> >>>>> it can't maintain TLS.
> >>>>>
> >>>>> Brian
> >>>>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Nov 2006 12:40:56 -0600

I don't think this is doable.

It just means all existing SIP implementations in the world would
be uncompliant.

It could be a RECOMMENDED strenght however. But even that I think
is controversial. 

> From: Bob Penfield [mailto:[email-masked]] 
> Sent: Friday, November 03, 2006 10:20 AM
> To: Michael Thomas; Dean Willis
> Cc: 'IETF SIP List'; 'Paul Kyzivat'; 'Elwell, John'; Audet, 
> Francois (SC100:3055)
> The PSTN circuit switched world has physical security. Its 
> users have some assurance that the "bits" of their phone call 
> are delivered intact and only those with access to and 
> control of the switching equipment could see or muck with 
> those bits. In the packet world, we must use TLS to provide 
> the same assurance because things in the clear can be seen 
> and mucked by anybody with a computer. With TLS, only those 
> with access to or control of the intermediaries (proxies, 
> B2BUA, SBCs, etc) can see or muck with the signaling "bits". 
> We have the a similar sort of transitive trust, although in 
> the wide open Internet we may have not have the 
> pre-established relationships between providers as exists in the PSTN.
> 
> The requirement for sips is at a minimum is to provide that 
> level of security. Its not to equal a military secure phone. 
> That's the next level of security that needs to be worked on.
> 
> Therefore, I would say, that a PSTN gateway injecting a call 
> into the sip network MUST use sips to at least equal the 
> level of security provided by the PSTN.
> 
> If we want a level of security that would require the PSTN to 
> provide the military secure phone, that's something more than sips.
> 
> Cc: "'IETF SIP List'" <[email-masked]>; "'Paul Kyzivat'" 
> <[email-masked]>; "'Elwell, John'" 
> <[email-masked]>; "'Francois Audet'" 
> <[email-masked]>
> >>> terminating on my host and that I blat out the payload to 
> a terminal 
> >>> window?  What happens if the terminal window is, oh say, at Times 
> >>> Square via a handy VNC connection?
> >>>
> >>>
> >>
> > Also: from a Dev standpoint, you're presupposing that the SIP input 
> > side of the call leg has any clue whatsoever as to what the output 
> > side of the call or whatever else it might be will do with the 
> > message. That is think is completely untenable in all but the most 
> > fixed function of devices, and even then may be ridiculously 
> > fashion, but that doesn't mean anybody will obey it.
> >
> >       Mike
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Nov 2006 14:24:00 -0500

> gateway, regardless of what it does after, right?

Yup.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 3 Nov 2006 14:46:20 -0500

> But IMO no other plausible definition of sips will do that either.
Okay, so what you are REALLY saying is deprecate sips.  You admit that what
you want to do is not useful.
 
> more, possibly using SIPS as a component of the solution.
Right.  Come back in a year or so, and we'll have some drafts to look at.
Same old, same old.

We've been saying that for 4 or 5 YEARS.  So far, nothing which we think is
useful has been proposed.  Everything gets shut down, mostly because it
doesn't solve someone's problem they think HAS to be solved by the proposed
mechanism.

I think we can get something useful out of sips.  I think Dean did a decent
job of defining what that is.  I think it's not perfect.  It doesn't meet
everyone's needs.  It will have judgment calls to be made.

But I think it will be quite useful.

Brian

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 3 Nov 2006 16:38:01 -0600

In-line.

Thx
Samir
 
> But IMO no other plausible definition of sips will do that either.

  Looks like you are agreeing to _deprecate_ sips. Thx.
> more, possibly using SIPS as a component of the solution.

  This is what I want to avoid, which I said earlier too. The strength
of the chain is the strength of the weakest link. We will have one more
beast within SIP itself to inter-work.

---

From: Dean Willis <[email-masked]>
Date: Sun, 5 Nov 2006 10:14:05 -0600

On Nov 3, 2006, at 12:20 PM, Bob Penfield wrote:

>
> The PSTN circuit switched world has physical security. Its users  
> have some assurance that the "bits" of their phone call are  
> delivered intact and only those with access to and control of the  
> switching equipment could see or muck with those bits. In the  
> packet world, we must use TLS to provide the same assurance because  
> things in the clear can be seen and mucked by anybody with a  
> computer. With TLS, only those with access to or control of the  
> signaling "bits". We have the a similar sort of transitive trust,  
> although in the wide open Internet we may have not have the pre- 
> established relationships between providers as exists in the PSTN.
>

Ah, speaking as a former recreational (okay, SOMETIMES I got paid for  
it. That make me a pro?) hacker of the phone system, I have to say  
"Nope. It's just that the PSTN has a better press bureau".

For example, the way ISDN is generally deployed in the US, anybody  
can present any caller-ID number that they ant to deploy.

And anybody who can drop an inductive pickup (or even a couple of  
alligator clips) on your line gets your signaling AND your media in  
the clear.

And bored technicians sitting in LD-carrier switching junctions  
listen in on 1-900-calls (US sexy-chat services) with amazing  
frequency. Actually, they frequently step through entire banks of  
circuits sampling calls just to make sure things are working ok.  
Maybe they don't listen much, but they could if they wanted to.

> The requirement for sips is at a minimum is to provide that level  
> of security. Its not to equal a military secure phone. That's the  
> next level of security that needs to be worked on.

You mean, "none, why bother?"

--
Dean