Re: [stir] New draft draft-rosenberg-stir-callback-00

["Cullen Jennings (fluffy)" <[e-mail]>]

On Mar 4, 2018, at 12:50 AM, David Frankel <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jonathan and Cullen –

I read the draft with interest and wonder if you can clarify a few things for me. My understanding of SIP nuances is limited, so I may be overlooking some obvious things here. At the same time, I’m trying to be pragmatic about how things work in the “real world” vs. the world as defined by the specs.

So my questions / comments are:

A) I see in section 3 references to SUPPORTED and REQUIRE header fields that include “stir-callback”. Then in sub-part 1 of section 3, in the call diagram I see references to SUPPORTED and REQUIRE headers that say “stir-verify”.  (Note, btw, that there are two sub-parts 1 in section 3; I think they are supposed to be numbered 1, 2, 3 instead of 1, 1, 2.) There are further references in the document to “stir-verify”. Then in section 8.1, there are references to a “sip-verify” Option Tag.

So my question is: are “stir-callback”, “stir-verify” and “sip-verify” all meant to be the same string, and perhaps the exact value evolved during development of the document? Or are there really two or three different option-tags involved here? Or am I missing how these three different values are actually applied?


We probably just messed up some cut and paste as we changed names.

B) In the “real world”, a PSTN call from Bob (tel:1, served by Provider B), to Alice (tel:2<tel:1>, served by Provider A) is often completed by B sending the call to transit provider X, which, even in an end-to-end SIP connection, will re-initiate the call and send it to provider Y, which then re-initiates it and sends it to terminating Provider A. (Note that the call path from B to A typically does not necessarily follow the reverse path of a call from A to B.)

So in order to propagate properly from origination to termination, the “verifying INVITE” proposed in section 3, containing the REQUIRE: stir-callback header, will need to first be processed by Provider X. As I understand it, X will need to be capable of recognizing the new REQUIRE header and knowing that it needs to propagate the call onward (NOT reject it due to lack of support for stir-callback), and will need to send the call to Y with the new REQUIRE header included. AND it will also need to know that it needs to propagate the VERIFY-CALL header as well.

Y will receive this INVITE, and it too will need to know that it needs to accept this invite and propagate it onward with the REQUIRE and VERIFY-CALL headers.

Since stir-callback is not today a defined option, if X and Y were conforming to the SIP RFC, they would today reject this INVITE. So does this mean that your STIR-Callback approach will necessitate updates of currently-conforming UA’s acting in the transit role to now provide support for this new type of INVITE?

Finally, if and when the verification INVITE gets to A, and as your document explains, A will have to be smart enough to process the verify request and send the appropriate response. That support is noted in your document; I’m wondering if you also need to document the kind of support that will be required from intermediate providers, and note the importance of A being RFC-compliant with respect to REQUIRE headers it does not understand.

Yes, you are right the intermediate providers SBCs would need to be configured to support that require header. This is certainly a deployment issue but I’m not sure I see it as much different from the same SBCs needing to be configured to 8224 Identity header. Thoughts ?


C) At the end of section 3 you note: “The presence of the Require header field in the verifying INVITE is critical to the operation of the solution.  It prevents the verifying INVITE from actually ringing a real phone, which would be quite annoying.” This is my biggest concern.

If the new REQUIRE header gets dropped somewhere along the way, the INVITE will look “normal”, so won’t Provider A ring Alice’s phone? Or, if A is not RFC-compliant and ignores the REQUIRE header, Alice’s phone will ring. (And of course if the call originator was spoofing the number, and in fact Bob’s verification INVITE went to the real owner of the number, served by provider C, C would have to be RFC-compliant in this regard or the real number owner’s phone would ring.)

I am nervous that in today’s real world deployments, your approach is fragile because it is dependent on the various UA’s in the call path diligently following the SIP RFC.

I made a few test calls acting like I was Bob’s UA, having received an INVITE from A that I want to verify. So I sent an INVITE back towards A, inserting the REQUIRE: stir-callback header in my mock “verification” INVITE; I sent these calls through various real-world termination providers.

In a couple of cases, I got back 420 Bad Extension responses. That’s good and bad; the good news is that it tells me that those particular UA’s ARE RFC compliant in this respect. They don’t understand a REQUIREd option so they are necessarily rejecting the call. On the other hand, it points out that if these UA’s are acting as intermediate providers (which, in these cases, they are), they will need to be updated to accept and pass the stir-callback related headers even though they are just providing a transit function and even though they are not assuming any responsibility for verification.

In my other test cases, the destination phone rang even though this was supposed to be a “verification” INVITE. This tells me, I think, that at least the first UA (X, in my explanation above) in the verification call path is non-RFC-complaint, and that downstream UA’s are either also non-compliant, or that the REQUIRE header got dropped along the way.

I am nervous about the extent to which deployed UA’s are non-RFC-compliant with respect to the REQUIRE header, and how that could undermine deployability of this solution. Maybe you intended that the solution only apply when A and B are directly connected and there are no intermediate providers. But I’m concerned that’s only a small fraction of “real world” calls today.


First let me say that is awesome you just went and tried this. I love real world data. Some of the version of Asterisk I have seen configured that way but sort of surprised if people are using ACME or Cisco SBCs that way. I certainly don’t have any desire to embarrass any particular SP about their SIP deployment but would you be willing to share what providers did this such that we might try and track down why they did it - that might help decide how much of an issue it is?


I am interested in your thoughts on these items, and on getting me back on track if I’ve misunderstood aspects of the proposal.


I think you have understood the gist of the proposal and perhaps we have some tweaks to make. I agree with your high level points of there are intermediaries in the call we care about and that if any server along the chain is non compliant with require, it does not work well. Perhaps we can think of ways to mitigate that but not obvious how.

Now that we have 8824 out the door, I’m more trying out ideas to see what might work to help reduce SPAM and I share some of your concerns about this but not sure what’s better for deployment.

However, any in band STIR solution is going to require the service providers to test and support it. I would not be surprised to find that any SBC configured to ignore the Require header is also pretty unlike to pass the Identity header.  For a long time, I have seen many things blocked at IETF from by the “SBC won’t support that” argument but in this particular case it is a bit different. If some carrier has all of it customers getting an irritating call back call ever time they dial a new number, I’m sure the economics of customer satisfaction and retention will cause that carrier to change the configuration of their SBC to not ignore the Require header.

I am worried about this and the rest of STIR when the interconnect between the carriers is SS7.



David

David Frankel
ZipDX® LLC
Monte Sereno, CA USA
Tel: 1-800-FRANKEL (1-800-372-6535)

From: stir <[e-mail]<mailto:[e-mail]>> On Behalf Of Jonathan Rosenberg
Sent: Thursday, March 1, 2018 6:15 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [stir] New draft draft-rosenberg-stir-callback-00

Hey all - been a while :)
Cullen and I wrote up a concept for using STIR with self-signed or domain based certs, and then handling number validation with an in-band callback. We think its a promising approach to accelerate STIR deployments, since it allows them to happen without the cert infrastructure being in place.

https://www.ietf.org/id/draft-rosenberg-stir-callback-00.txt
Comments welcome.
-Jonathan R.

--
Jonathan Rosenberg, Ph.D.
[e-mail]<mailto:[e-mail]>
http://www.jdrosen.net<http://www.jdrosen.net/>
_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir