Re: draft-kuthan-sip-derive

> Hendrik Scholz wrote:
> > Hi!
> > 
> > How would the TDM interworking work?
> 
> There are some limitations indeed -- if a gateway calls a SIP phone,
> and supports DERIVE, DERIVE actually asserts "can I reach *a gateway
> you are momentarily using*" (as opposed to say "I can reach you via
> your address"). Still I think that's meeting the "better-than-nothing"
> expectation offered by DERIVE. If we wanted to get closer to 
> the caller,
> we would have to dig in the PSTN protocols.
> 
> There is a practical and IMO worse concern: a telephone 
> number can resolve
> to way too many places: SIP routing is not symmetric in this case and
> pstn-2-sip request can take a different path than sip-2-pstn 
> request. Thus
> a verifier can very likely end up with a different GW than the one
> which initated the call in question. (If the phone number is offered
> in From as tel URI, one could for example try to perform an ENUM
> query with non-e164 result but I'm not sure it make sense -- 
> in the end,
> if there is such URI it could have been put in From straight).

This isn't a concern, though.  Even if the return routing worked
perfectly and you got back to the very same PSTN gateway, the
best you can achieve is trusting the caller-id asserted by the
PSTN.  Which can be spoofed, as we all know.  So, DERIVE to
an E.164 that terminates on a PSTN gateway can't tell you too
much; DERIVE to an E.164 that terminates on a SIP UA can be
pretty worthwhile.  I admit that a PSTN gateway could lie and
pretend to be a normal SIP UA; thus, a DERIVE validation of
an E.164 isn't as trustworthy as a DERIVE validation of an
email-style SIP URI because the PSTN gateway could lie.

If we had a way to determine who 'owns' an E.164, we could
make that owner prove they received the DERIVE query (by
asking them to encrypt something with their private key), 
which prevents a PSTN gateway from lying.  This is something 
that could be bolted on later, if/when we figure out how 
to map an E.164 to certificate that 'owns' it.

-d


> 
> 
> 
> > Look at 'Figure 1: Overview of Operation' and assume this:
> > 
> > - Call SIP->PSTN
> > 
> > The callee is in the PSTN/TDM world and proxy 2 acts as
> > a gateway.
> > In this case the callee would never send a SUBSCRIBE.
> > If there is no authentication/authorization for the call
> > the gateway may opt to subscribe to the user?
> 
> that's the best we can get, without PSTN interaction the
> gateway has to act on the party's behalf.
> 
> > 
> > - Call PSTN->SIP
> > 
> > The caller is on the TDM side and proxy 1 acts as a PSTN to SIP
> > gateway. The callee sends the SUBSCRIBE which ends up at
> > the edge on proxy 1.
> > What should the proxy do?
> > a) Respond on behalf of the caller
> > b) do not support the Dialog event package and respond
> >    with 489 to the SUBSCRIBE
> > c) do some magic based on information conveyed on the
> >    TDM side?
> 
> It does not have to be the proxy, it can be the gateway but the
> real problem is IMO if the SUBSCRIBE gets there at all. If it
> gets there, I think a) is the appropriate answer. (or b) if
> it does not support DERIVE). c) is apparently a difficult one.
> 
> -jiri
> 
> > 
> > Cheers,
> >  Hendrik
> > 
> _______________________________________________
> Sip mailing list  https://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  https://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