Re: [stir] Comments on draft-stir-callback

I believe its basically a step towards deployment of the full STIR
solution. If you think about it, STIR requires support in the calling SIP
network, the terminating network, and requires a phone-number based
certificate system they can both connect to. WIth callback, it requires
support in the calling SIP network, the terminating network. But thats it -
no new certificate authorities required. Since it requires one less
dependency - and a significant one at that - it would allow quicker
deployment.

To your question on "why INVITE"? yes its a hack. Its based on the
hypothesis that - given the large number of proxies, SBCs and other gunk
that sit in the network, the odds that anything but an INVITE make it
through, seemed low. Architecturally i think OPTIONS is the best match but
does any SBC pass that?

To your specific questions:

1. most forking happens downstream from the proxy of record for the number;
since this request is handled by that proxy I dont think this is likely.
Can you think of a case were forking would happen upstream from the
proxy/agent which owns the number?

2. SDP is mandated because, per above, seems likely SBCs and other
middle-boxy SIP things will expect to see it in an INVITE.

3.good catch on receiver sending 200 OK. clearly in such cases a BYE would
be generated right away.

Thx,
Jonathan R.

On Wed, Mar 14, 2018 at 7:53 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
>
>
> On a high-level, for a “temporary solution”, I think this would take quite
> a bit of effort to deploy. Shouldn’t the focus be on getting the
> "certificate systems" up and running?
>
>
>
> Also, how does this relate to activities like SHAKEN?
>
>
>
>
> Anyway, assuming this would be needed, I have some comments on the
> protocol parts.
>
>
>
> First, even though I do consider myself more pragmatic than purist, I
> think usage of INVITE, and the usage of error response codes to return the
> verification result, is a really ugly hack.
>
>
>
> Second, there are also some operational issues with using INVITE:
>
>    1. Good old forking: The callback/verifying INVITE might get forked,
>    and the terminating agent may receive a non-471/472 response.
>    2. SDP: The draft requires SDP in the INVITE, but at the same time
>    says that it’s not used for anything. If so, why is it mandated? Because
>    offerless INVITEs might get rejected? SDP in INVITE might trigger media
>    resources etc to be reserved.
>    3. Section 7.3 talks about attacks by the agent receiving the
>    callback/verifying INVITE, but it does not cover the case where the agent
>    would send a 200 OK response – which would establish a session and could
>    trigger charging. Alternatively, the attacker could remove the option-tag
>    and forward the request somewhere. All this without the originally called
>    party knowing anything. The terminating agent can of course terminate such
>    “call" as soon as it gets the 200 OK, but it may already have triggered
>    some charging etc.
>
>
> Third, did the authors consider other mechanisms? For example, is there a
> reason e.g., SUB/NOT couldn’t be used for this? It would have none of the
> INVITE issues above (yes, a SUB can also get forked, but the client will
> receive NOT from each remote peer).
>
>
>
> Finally, it seems like the callback request (whatever SIP method is used)
> contains the called party in the From header field. Is there a technical
> reason why that is needed, or is it just for convenience?
>
>
>
> Thanks!
>
>
>
> Regards,
>
>
>
> Christer
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>
>

-- 
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net