I think it depends on what you think the future looks like. Yes a PBX PRI can spoof a CLID, though I would argue it's much harder to fake an ANI (because of who sets it). But anyway, I think such a thing is more limited in scope on the PSTN simply because there is less benefit to doing it. If you do it from a PRI, there is a physical link and switch records can be used to track back, and so your gain is limited - unless it's targeted at specific individuals (which makes that very insidious). Add to that that it still costs money to make the calls usually, and the benefit goes down further.
But if you think in the future (a) call cost approaches zero or becomes bulk in nature, at least for voip-voip calls, and (b) voip peering grows and/or open providers are included, then the benefit of CLID spoofing grows to potentially make SPIT profitable or Phishing attacks untraceable. It's not a near-term problem, and may never be a problem. It's just that email has such a problem and so there's concern that SIP could too someday. -hadriel > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Francois Audet > Sent: Wednesday, February 20, 2008 4:28 PM > To: Paul Kyzivat; Elwell, John > Cc: IETF SIP List; Henry Sinnreich; [EMAIL PROTECTED]; Richard Shockey > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > I think it's time for a reality check... > > In the PSTN, if you are an enterprise and have a trunk to a service > provider, > you can pretty much put whatever you want in the Calling Party Number (you > can't do that from home with an individual line as the CO puts the Calling > Party Number for you). The network will pass it for you to the other end. > > So, not only is the identity in PSTN "hop-by-hop" and not end-to-end, > anybody > with suitable trunk interface can spoof anybody else. > > So again, I don't see why WE need to worry about phone number identity. > > I agree with Jonathan that we should just document the limitations. > > And personally, I don't mind if we restrict the usefulness end-to-end > identity (4474) to addresses where the domain name actually matters and is > not ignored (as is the case with user=phone type numbers). > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Paul Kyzivat > > Sent: Wednesday, February 20, 2008 07:18 > > To: Elwell, John > > Cc: IETF SIP List; Henry Sinnreich; [EMAIL PROTECTED]; Richard Shockey > > Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > > > It seems that we have two parallel worlds: one using > > email-style addresses and another using phone numbers. While > > there are some devices that can play in both worlds, the > > majority of devices can only play in one of the worlds, or at > > least are strongly biased towards one so that usability with > > the other form is compromised. > > > > It seems essential that sip find a way to be successful in > > the phone number world - at least to the extent that a sip > > device in not perceived as being functionally worse than a > > comparable device using PSTN protocols. No amount of arguing > > that things would be better if you just used an email-style > > address will win the day there. > > > > The alternative is to accept that sip is worse than native > > PSTN equipment for phone numbers, and hope that the parallel > > communications world based on email-style addresses will > > eventually win out. But that is like waiting for IPv4 to be > > replaced by IPv6. > > > > Paul > > > > Elwell, John wrote: > > > Hannes, > > > > > > I know the questions were directed at Henry. However, if I may > > > intervene: > > > > > >> -----Original Message----- > > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > On Behalf Of > > >> Hannes Tschofenig > > >> Sent: 20 February 2008 08:00 > > >> To: Henry Sinnreich > > >> Cc: IETF SIP List; [EMAIL PROTECTED]; Richard Shockey > > >> Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > >> > > >> Hi Henry, > > >> > > >> there are two aspects to the story: > > >> > > >> * Do you believe there is a problem for security when interworking > > >> between the PSTN and SIP? > > >> (e.g., in the way how SIP Identity deals with E.164 numbers) > > > [JRE] There are actually two separate situations: use of > > E.164 numbers > > > for communication within the SIP world; and use of E.164 > > numbers when > > > interworking between SIP and PSTN. Did you intentionally limit your > > > question to the second of these? > > > Assuming that was the intention, I would point out that we > > can never > > > achieve end-to-end security when interworking with PSTN. > > The best we > > > can do is achieve security across the local SIP part as far as the > > > PSTN gateway. There are different opinions as to whether the PSTN > > > itself is secure - I won't express an opinion on that > > aspect. However, > > > what happens beyond the PSTN? Another SIP hop? An H.323 > > hop? There is > > > no way of knowing whether that is secured or not. Some guarantee of > > > security as far as the gateway is the best we can achieve, and, > > > importantly, the user should be made aware of this - do not > > raise his > > > expectations concerning the end-to-end security of the call. > > > > > > Let's concentrate on the end-to-end SIP case and provide a good > > > security solution for that. One possibility might be to use > > > email-style URIs for that. > > > > > > John > > > > > >> * If yes, do you think that someone should be > > investigating what todo > > >> about it? > > >> > > >> Don't get hung-up in the details of a specific strawman proposal > > >> that, I believe, shows quite well some of the challenges > > around the > > >> aspect of > > >> E.164 number ownership. > > >> > > >> Ciao > > >> Hannes > > >> > > >> > > >> Henry Sinnreich wrote: > > >>>> "Here is this problem, this is what we > > >>>> (IETF) think, the solution is in your court. Have a nice day." > > >>>> > > >>> I believe this puts it in nutshell. > > >>> > > >>> The telecom specific uses of ENUM technology are more > > appropriately > > >>> handled in the telecom standards organizations, such as the > > >> ITU-T, and > > >>> ETSI. > > >>> > > >>> Let's move on and work with Internet and web addressing > > >> that I believe > > >>> have the real potential for the Internet standards > > >> development and where > > >>> IETF resources are better placed. > > >>> > > >>> Thanks, Henry > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > >> Behalf Of > > >>> Richard Shockey > > >>> Sent: Tuesday, February 19, 2008 10:20 AM > > >>> To: [EMAIL PROTECTED] > > >>> Cc: 'IETF SIP List'; [EMAIL PROTECTED] > > >>> Subject: Re: [Sip] Infrastructure issues involving e164 numbers > > >>> > > >>> This is not to say that the IETF could play a useful and > > >> essential role. > > >>> We > > >>> can certainly develop and define the requirements, use cases etc. > > >>> > > >>> In addition the IETF can architect a solution but > > >> experience tells me > > >>> that > > >>> deployment and implementation issues surrounding e164 > > >> issues will need > > >>> the > > >>> cooperation of "other bodies" which is where the problem > > >> lies. It's not > > >>> really the ITU, in fact the ITU is a much easier place to > > get things > > >>> done these days. The complications arise with the ITU > > member states, > > >>> who jealously guard their diplomatic and political prerogatives. > > >>> > > >>> This was the conclusion that we drew when the > > >> Infrastructure ENUM issues > > >>> first arose. We essentially said ..."Here is this problem, > > >> this is what > > >>> we > > >>> (IETF) think, the solution is in your court. Have a nice day." > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] > > >>>> Sent: Tuesday, February 19, 2008 10:49 AM > > >>>> To: Richard Shockey > > >>>> Cc: 'IETF SIP List'; [EMAIL PROTECTED] > > >>>> Subject: Re: Infrastructure issues involving e164 numbers > > >>>> > > >>>> > > >>>> > If there is going to be a solution to the SIP > > identity problem > > >>>> involving > e164 numbers, it will not IMHO be solved in > > the IETF. > > >>>> > > > >>>> > > > >>>> Interesting view. I obviously does not appear to be an > > easy thing; > > >>>> in the draft I called this "There is non-neglectable deployment > > >>>> incentive challenge." > > >>>> > > >>> > > >>> _______________________________________________ > > >>> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > >>> This list is for NEW development of the core SIP Protocol Use > > >>> [EMAIL PROTECTED] for questions on current sip Use > > >>> [EMAIL PROTECTED] for new developments on the application of sip > > >>> > > >> _______________________________________________ > > >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol Use > > >> [EMAIL PROTECTED] for questions on current sip Use > > >> [EMAIL PROTECTED] for new developments on the application of sip > > >> > > > _______________________________________________ > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > [EMAIL PROTECTED] for questions on current sip Use > > > [EMAIL PROTECTED] for new developments on the application of sip > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] for new developments on the application of sip > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
