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

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Mar 2018 07:53:18 +0000

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Mar 2018 19:43:10 +0000

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 <
[email-masked]> 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?
>
>
>
> 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.
>
>
>
>    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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>
>

-- 
Jonathan Rosenberg, Ph.D.
[email-masked]
http://www.jdrosen.net