[SIPForum-techwg] Interoperability Draft v3 - a few more comm ents

Tue Jan 17 16:39:35 EST 2006

Hi David,

Comments inline blow.

Thanks,

--Chris

> -----Original Message-----
> From: David R Oran [mailto:oran at cisco.com]
> Sent: Tuesday, January 17, 2006 3:12 PM
> To: Chris Sibley
> Cc: Elwell, John; Horvath Ernst; SIP Forum Tech WG
> Subject: Re: [SIPForum-techwg] Interoperability Draft v3 - a few more comm
> ents
> 
> 
> On Jan 17, 2006, at 2:39 PM, Chris Sibley wrote:
> 
> > Hi John,
> >
> > The SP will definitely want to validate *at least* the host/domain
> > portion of the URI, but I think the SP will also need to enforce some
> > form of "screening" on the user portion also.
> >
> > To illustrate my point, assume that the SP is providing PSTN
> > connectivity (inbound and outbound) for Enterprise A and Enterprise B.
> > Enterprise A (acmerockets.com) has the following telephone numbers:
> > 678-990-0000 through 0999. Enterprise B (joesexplosives.com) has the
> > following telephone numbers: 678-397-1000 through 1999.
> >
> > If the SP were only to validate the host portion of the URI,
> > Enterprise
> > A would be able to place calls to the PSTN using a FROM URI of, for
> > example, 678-397-1000 at acmerockets.com. If this call were allowed to
> > proceed to the PSTN, the callee would receive caller ID information
> > stating the call came from 678-397-1000 (Enterprise B's number).
> >
> Ouch. This is a slippery slope to mandating how enterprises allocate
> their user ids.
> It may be that the example is unrealistic and crafted in such a way
> as to make it seem there's a problem where there isn't.
> 
> Let's say we start from your premise that the SP has to ensure the
> enterprise does not issue "misleading" From URI's that will lead
> others to think that a SIP call from 678-397-1000 at acmerockets.com
> actually means that acmerockets.com has authority over
> +1-678-397-1000 as an E.164 number. Does that mean they'd better not
> allow George.W.Bush at acmerockets.com? Or a simple extension number
> like 1000 at acmerockets.com? What if the SP is acting as agent for
> allocating the block 678-397-2000 through 678-397-2999 and a call
> comes out as 3432 at acmerockets.com. Is that supposed to be policed?
> 

No, the Enterprise can use George.W.Bush at acmerockets or anything else in the
user portion that it desires. But remember, this interface specification is
all about interfacing with the PSTN so at some point that Enterprise's AOR
has to be converted into an E.164 address (by the SP). It is the E.164
address presented to the PSTN callee that I am concerned with.

I did neglect to include the 'user=phone' tag in my examples using telephone
numbers, so perhaps that is where the confusion comes in?

> > I don't think this behavior is desirable, so the SP should not only
> > validate the host portion of the URI but the user portion as well. My
> > reasoning is that while the Enterprise is authoritative for their DNS
> > domain in the SIP world, the SP is "authoritative" for the
> > Enterprise's
> > telephone numbers in the PSTN world (i.e. they are routed to
> > SP-controlled switches on the SS7 network).
> Right, but 678-397-1000 at acmerockets.com is *not* a PSTN number and
> should/can never be converted into one.
> 

True. Again, I should have included the 'user=phone' tag in my example, or
better yet used a tel: URI. I was *trying* to illustrate an example of
Enterprise A asserting that it was the owner of an E.164 address that
belonged to Enterprise B.

> > Accordingly, I think the SP
> > has at least some amount of responsibility for validating that the
> > identity asserted by an Enterprise is legitimate before it lets that
> > call go to the PSTN.
> It does, by validating the domain. NOTHING bad happens if somebody
> calls back to 678-397-1000 at acmerockets.com - the call will go to the
> right place, unless the service provider does something REALLY stupid
> like just extracting 678-3967-1000 from the SIP URI at their PSTN
> gateway and asserting that as the calling number.
> 

Again, the confusion must come into play due to the missing 'user=phone'
tag. Your example is exactly the scenario I was trying to describe. I'm
thinking about the call that goes from SIP --> PSTN (which doesn't
understand SIP URIs), not SIP --> SIP. 

Assuming for a moment that my example URI was formatted properly, in this
case I don't think it would be stupid for the SP to extract the E.164
address from the URI at the PSTN gateway (for use as the calling number).
This is what it SHOULD do, right?

> Now, of course I'm cognizant of the implications for potential
> phishing attacks when Viagra marketers make SIP URI's that look like
> phone numbers of PayPal or such. There's nothing new here and the
> analogy should serve as a caution that any attempt to mandate user
> assignment with the goal of preventing calls from being misrouted or
> return calls to be placed to the wrong place is likely doomed to
> failure.
> 

Exactly my point. If the SP doesn't police the user portion, and let's again
assume the URIs in my example contained the 'user=phone' tag, what's to stop
Enterprise A from sending a call to the SP (and ultimately the PSTN) with an
E.164 address in the user portion that belonged to Enterprise B? 

Should the SP just allow this call to proceed because the *domain* portion
of the URI is valid?

> > (This obviously requires the SP and Enterprise to
> > agree to the list of "valid" identities that can utilize the SIP
> > interface ahead of time.)
> >
> > Finally, please note that while I think the SP does need to
> > validate the
> > user portion of the URI, our interface specification as currently
> > written doesn't require it.
> >
> Right. An additional downside of this is that a new employee at
> acmerockets can't make outgoing phone calls until his AoR is
> registered with the service provider.
> 

Well, I would think this should only come into play if the Enterprise
obtained an additional block of numbers from the SP *and* wasn't using E.164
addresses and/or tel: URIs on the interface. (Hence, no other "mapping
table" would need to be managed.)

In this case of new number assignments, the SP has to configure their
switches to route the numbers to the Enterprise anyway, so is this really a
concern?

> > Per Section 10 (Enterprise PSTN Identities): "It therefore naturally
> > follows that validating the PBXs asserted PSTN identity against a list
> > of "legal" identities for the Enterprise is desirable before allowing
> > the call to proceed. While this interface specification does not
> > explicitly make this type of screening/validation required, it is
> > HIGHLY
> > RECOMMENDED."
> >
> I would actually take the opposite tack and recommend AGAINST doing
> this.
> 
> Sorry to rain on your parade here...
> 

No worries. That's why they call this a group discussion. :)

> Dave.
> 
> > Thanks,
> >
> > --Chris
> >
> >
> >> -----Original Message-----
> >> From: Elwell, John [mailto:john.elwell at siemens.com]
> >> Sent: Wednesday, January 11, 2006 3:23 AM
> >> To: Chris Sibley; David R Oran
> >> Cc: Horvath Ernst; SIP Forum Tech WG
> >> Subject: RE: [SIPForum-techwg] Interoperability Draft v3 - a few more
> > comm
> >> ents
> >>
> >> Chris,
> >>
> >> But it is likely to be only the domain part of the URI that the SP
> >> can
> >> check. Right?
> >>
> >> John
> >>
> >>> -----Original Message-----
> >>> From: Chris Sibley [mailto:Chris.Sibley at cbeyond.net]
> >>> Sent: 10 January 2006 19:01
> >>> To: David R Oran; Elwell, John
> >>> Cc: Horvath Ernst; SIP Forum Tech WG
> >>> Subject: RE: [SIPForum-techwg] Interoperability Draft v3 - a
> >>> few more comm ents
> >>>
> >>> I agree with David. The current draft of the specification describes
> >>> this concept in more detail in section 10, Enterprise PSTN
> > identities.
> >>> Since PSTN origination / termination (using SIP as the signaling
> >>> protocol between Enterprise and SP) is the main focus of the
> >>> specification, there is the fundamental problem of "policing" which
> >>> identities the Enterprise should be allowed to assert (when the call
> >>> terminates to the PSTN). To put it another way, it would be highly
> >>> unlikely that the Service Provider would want to allow the
> >>> Enterprise to
> >>> make calls to PSTN endpoints using any telephone number (identity,
> >>> caller ID information, or whatever you want to call it) they chose
> > to
> >>> put in the FROM field (or P-Preferred-ID). At a minimum, the SP
> > should
> >>> maintain a list of "Enterprise Identities" from the Enterprise realm
> >>> that are "authorized" to use the interface for purposes of
> >>> reaching the
> >>> PSTN.
> >>>
> >>> Thanks,
> >>>
> >>> --Chris
> >>>
> >>>>
> >>>
> >>>
> > **********************************************************************
> >>> This email may contain confidential information. If you are not
> >>> the intended recipient, please advise by return email and delete
> >>> immediately without reading or forwarding to others.
> >>>  - Cbeyond
> >>> **************************************************************
> >>> ********-----Original Message-----
> >>>> From: David R Oran [mailto:oran at cisco.com]
> >>>> Sent: Monday, January 09, 2006 4:34 PM
> >>>> To: Elwell, John
> >>>> Cc: Chris Sibley; Horvath Ernst; SIP Forum Tech WG
> >>>> Subject: Re: [SIPForum-techwg] Interoperability Draft v3 -
> >>> a few more
> >>> comm
> >>>> ents
> >>>>
> >>>>
> >>>> On Jan 9, 2006, at 4:22 PM, Elwell, John wrote:
> >>>>
> >>>>> Chris,
> >>>>>
> >>>>> <snip/>
> >>>>>> As I understand, P-Asserted-ID is only supposed to be
> >>> used between
> >>>>>> two
> >>>>>> proxies that are in the same trust domain AND in situations
> > where
> >>> the
> >>>>>> proxy adding the P-Asserted field has already authenticated the
> >>>>>> user's
> >>>>>> identity. In our case, I don't think the Service Provider can
> >>>>>> necessarily trust that the identity asserted by the
> >>>>>> Enterprise is valid,
> >>>>>> even if it has already been "screened" by the Enterprise.
> >>>>>>
> >>>>>> However, we can accept a "hint" from the Enterprise to
> > determine
> >>> the
> >>>>>> correct identity to use. Section 6 of RFC 3325 states: "If a
> >>>>>> P-Preferred-Identity header field is present in the message
> >>>>>> that a proxy
> >>>>>> receives from an entity that it does not trust, the proxy MAY
> > use
> >>>>>> this
> >>>>>> information as a hint suggesting which of multiple valid
> >>>>>> identities for
> >>>>>> the authenticated user should be asserted."
> >>>>> What is meant by "valid identities" here? How does the SP
> >>> know that
> >>>>> xxx at example.com, if received in a P-Preferred-Identity header
> >>>>> field, is a
> >>>>> valid identity? The PBX's domain, in this case example.com, is
> >>>>> responsible
> >>>>> for assigning URIs, so how does the SP know which values
> >>> are valid?
> >>>>>
> >>>> Well, it can't tell if xxx is valid (that's the job of
> > example.com),
> >>>> but if a enterprise domain has multiple identities it could
> >>> know that
> >>>> xxx at example.com and xxx at example-the-sequel.com were valid, but
> >>>> xxx at example-the-counterfeit-knockoff.com was not.
> >>>>
> >>>>> John
> >>>>> _______________________________________________
> >>>>> techwg mailing list
> >>>>> Send mail to: techwg at sipforum.org
> >>>>> Unsubscribe or edit options at:  http://sipforum.org/mailman/
> >>>>> listinfo/techwg
> >>>