Subject: Re: [Sipping] new draft-ietf-sipping-isup-05 (Security)

From: [email-masked]
Date: Fri, 16 Aug 2002 11:23:46 EDT

In a message dated 8/15/02 6:54:46 PM Eastern Daylight Time, 
[email-masked] writes:

> Mike (Hammer),
> 
> >The problem is 
> > that the PSTN 
> > trust model relies on the trust of the ISUP or it fails 
> > completely.
> 
> This means we are trying to connect an open environment (IP) to a
> sensitive one (ISUP) and a general signaling gateway aproach is needed
> to absorb the trust model differences that you mention. This goes beyond
> the early media issue and may pop elsewhere as well. Yes, I know, this
> sounds like very high level, but maybe stepping back from just the early
> media issue would make sense. Does it?
> 

[MAP] Yes, I agree that this is the fundamental issue/problem behind a number 
of the discussions/disagreements on SIP/ISUP interworking. It seems that we 
need some good architectural understandings of how the two environments 
should work together. Unfortunately, it's hard to do that without exchanging 
some good diagrams.

In addtion, we need an understanding in the IETF that the trust model used in 
the PSTN was a perfectly good one for what it was doing, just as the model 
used in the IP world is good. They are just two different models which must 
work together.

Mike Pierce
Artel

---

From: [email-masked]
Date: Fri, 16 Aug 2002 17:28:37 EDT

In a message dated 8/16/02 12:27:35 PM Eastern Daylight Time, 
[email-masked] writes:

> >[MAP] Your concern about not being able to call someone who does not know 
> >you (making authentication hard) is exactly the problem I have with the
> SIP model. 
> 
> [HS] I don't think this has to do anything with technology or protocols.
> Party A should be able to call party B, even if they have no trust
> association previously established, subject to policy. Except for
> unlisted numbers. This goes for both PSTN and SIP.
> 
> If party B is behind a gateway, on the PSTN side, you are raising
> correctly the interesting issue who  should pay. I believe this is a
> policy issue depending on the service. If party B is a call center, then
> party B will pay. Other policies may just not accept SIP calls from
> unknown sources, as you mention, but this MUST NOT be a protocol design
> point, I believe.
> 

[MAP] Yes, we should be able to agree on technology and protocol independent 
requirements. Of course, any Party A needs to be able to call any Party B. 
But everytime a security risk is mentioned, it seems that the solution is 
simply that "the called party must authenticate the calling party". I've yet 
to see an explanation of how this can occur in a global network and still 
meet the requirements for call set-up time. (I'm afraid there are some who do 
not believe there is a requirement for call setup time.)

In the case of Party B behind a gateway, it is clear that the gateway needs 
to deal with the trust model on the IP side. I still don't see how, but I'll 
hope that someone has/will figure it out. But the trust model on the PSTN 
side is understood - it's the same as it is today. That means the gateway 
must be a (PSTN) network entity operated by an authorized Service Provider 
which can be trusted to operate correctly. Party B trusts the call when they 
get it because it came from a trusted entity (their service provider who 
trusted the previous service provider, etc all the way back to the gateway).

If I seem down on SIP, it's because I have seen an inability to deal with 
such issues.

Mike Pierce
Artel