Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-reason)

[Ranjit Avasarala <[e-mail]>]

Hi Tolga

yes currently there is no need to match any claim with any SIP header, but
my proposal was - if a need arises in future to match and if SBC internal
policies prevent custom headers from being passed across, then the SBC
could map those values to SIP Private headers and pass them across.

Regards
Ranjit



On Mon, Apr 18, 2022 at 10:47 AM Asveren, Tolga <[e-mail]> wrote:

> A few thoughts about various topics in this thread/related threads:
>
>
>
>    - Technically, there is no need to match any claim with a
>    corresponding SIP header
>       - Claim value can be used directly
>       - The only exception is orig/dest matching to From/PAI and
>       Request-URI
>          - As these are needed to link the PASSporT with a particular
>          call -at least as good as it gets together with freshness check-
>       - With Identity header, we have the luxury of e2e delivery
>       - Expecting this for other SIP headers is not realistic/a very
>       risky assumption -at least not in the short-term-
>    - Keeping “crn” in “rcd” is practically the right decision IMHO
>    - Having a standard set of “crn” values could be useful
>       - It is probably a good idea to allow non-standard values as well
>       - It is true that there won’t be any guarantees on the honest use
>       of the value except the implicit trust/business relationship/assumed
>       reputation of the signer
>       - I think there would be deployment scenarios where such implicit
>       trust can be assumed on a per signer basis and this would  allow downstream
>       elements/entities to apply certain policies based on “crn” content
>
>
>
> Thanks,
>
> Tolga
>
> *From:* stir <[e-mail]> *On Behalf Of * DOLLY, MARTIN C
> *Sent:* Wednesday, April 13, 2022 5:44 PM
> *To:* Gorman, Pierce <[e-mail]>; Ranjit Avasarala <
> [e-mail]>
> *Cc:* Chris Wendt <[e-mail]>; Ben Campbell <
> [e-mail]>; SIPCORE <[e-mail]>; IETF STIR Mail List <
> [e-mail]>
> *Subject:* [EXTERNAL] Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04
> (call-reason)
>
>
>
> At the NNI, stripping is based on interconnection
>
> Agreements
> ------------------------------
>
> *From:* stir <[e-mail]> on behalf of Gorman, Pierce <
> [e-mail]>
> *Sent:* Wednesday, April 13, 2022 5:27:00 PM
> *To:* Ranjit Avasarala <[e-mail]>
> *Cc:* Ben Campbell <[e-mail]>; SIPCORE <[e-mail]>; IETF
> STIR Mail List <[e-mail]>; Chris Wendt <[e-mail]>
> *Subject:* Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04
> (call-reason)
>
>
>
> Hi Ranjit
>
>
>
> I didn’t say a service provider SBC *could* strip the Subject and
> Call-info headers.  I implied the SBC was likely to be configured to strip
> those headers.  i.e., not possible, probable.
>
>
>
> All sorts of foo gets sent in SIP to service providers whether
> accidentally or intentionally.  Either way, SIP INVITEs routinely get
> stripped of extraneous non-essential headers to reduce interworking
> problems and potential attacks.
>
>
>
> I do agree the contents could be mapped to get across the SBC boundary and
> where I would map them to is the RCD PASSporT in a SIP Identity header.
>
>
>
> BR, Pierce
>
>
>
> *From:* Ranjit Avasarala <[e-mail]>
> *Sent:* Wednesday, April 13, 2022 4:00 PM
> *To:* Gorman, Pierce <[e-mail]>
> *Cc:* Ben Campbell <[e-mail]>; Chris Wendt <
> [e-mail]>; IETF STIR Mail List <[e-mail]>; SIPCORE <
> [e-mail]>
> *Subject:* Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04
> (call-reason)
>
>
>
> *[External]*
>
>
>
> Hi Pierce
>
>
>
> Yes I do agree that SBC could strip the call-info header and not pass it
> through. But in case the information contained in that header is needed
> downstream like by CSCF, then SBC could map the contents of the Call-Info
> header to a new Private header and send it across.
>
>
>
> Regards
>
> Ranjit
>
>
>
> On Tue, Apr 12, 2022 at 3:59 PM Gorman, Pierce <[e-mail]>
> wrote:
>
> Could be passed through, yes, but you’ll need to define “if needed”.
>
>
>
> The general policy for inbound SIP traffic of the service provider I was
> employed by for more than 30 years, including in my role as lead SBC design
> engineer, was to strip proprietary and non-essential SIP headers at the
> untrusted interface of the SBC.  Call-Info in particular would be in that
> category since it can include URLs which refer to goodness knows what.
>
>
>
> Ben said, “there is the question of whether SBCs will mess with either”
> (header), and my opinion is he is right, there is a question, and my
> opinion is folks should assume, yes, those headers are at risk of being
> stripped (as they most likely are today).
>
>
>
>
>
> *From:* Ranjit Avasarala <[e-mail]>
> *Sent:* Tuesday, April 12, 2022 3:47 PM
> *To:* Gorman, Pierce <[e-mail]>
> *Cc:* Ben Campbell <[e-mail]>; Chris Wendt <
> [e-mail]>; IETF STIR Mail List <[e-mail]>; SIPCORE <
> [e-mail]>
> *Subject:* Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04
> (call-reason)
>
>
>
> *[External]*
>
>
>
> Depends on policy, but they could be passed thru to if needed
>
>
>
> Regards
>
> Ranjit
>
>
>
> On Tue, Apr 12, 2022 at 3:23 PM Gorman, Pierce <[e-mail]>
> wrote:
>
> I assume Call-Info or Subject are likely to be stripped by SBCs.
>
>
>
>
>
> *From:* stir <[e-mail]> *On Behalf Of *Ben Campbell
> *Sent:* Tuesday, April 12, 2022 3:18 PM
> *To:* Chris Wendt <[e-mail]>
> *Cc:* IETF STIR Mail List <[e-mail]>; SIPCORE <[e-mail]>;
> Henning Schulzrinne <[e-mail]>
> *Subject:* Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04
> (call-reason)
>
>
>
> *[External]*
>
>
>
> (as individual)
>
>
>
> (as individual)
>
>
>
> Apologies for coming to this thread late.
>
>
>
> I agree we should keep the crn claim for “rcd” passports at this point. I
> also understand there to be some implementations that either use it or plan
> to use it..
>
>
>
> I don’t have a strong opinion on the Callinfo param vs Subject question,
> as long as we have a consistent mapping. I guess there is the question of
> whether SBCs will mess with either, but I don’t know if that is more likely
> for one or the other.
>
>
>
> Thanks!
>
>
>
> Ben.
>
>
>
> On Mar 20, 2022, at 10:47 AM, Chris Wendt <[e-mail]>
> wrote:
>
>
>
> Hi Henning,
>
>
>
> Just to focus on call-reason for passport-rcd at the moment, we do have
> that, it is an independent claim “crn” explicitly separate from the “rcd”
> claim. It is defined in same passport-rcd document, but that doesn’t change
> how it’s defined or used. I think one hopefully simple fix is to maybe
> reference Subject as a mapping for this claim and maybe point to
> callinfo-rcd in a more generic way that we can further discuss subject vs
> callinfo in the sipcore draft as we move that forward.  As i understand it,
> most implementations are focused on passport-rcd at the moment, so i don’t
> want to hold that up if possible.
>
>
>
> To everyone,
>
>
>
> It would be great to get further input on this whether anyone has strong
> feelings about using Subject vs callinfo parameter call-reason.  I have the
> sense that there isn’t yet much implementation if any at all (of
> callinfo/call-reason, i believe there is implementation of passport-rcd
> “crn”), and there won't strong feeling one way or the other, but if anyone
> does have strong feelings please speak up.
>
>
>
> -Chris
>
>
>
> On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne <[e-mail]>
> wrote:
>
>
>
> Hi Chris,
>
>
>
> tl;dr: My suggestions are: (1) leave call purpose out
> of draft-ietf-stir-passport-rcd; (2) drop call-purpose
> from draft-ietf-sipcore-call-info-rcd; (3) consider a new JWT claim
> "subject" [or whatever] that encapsulates the signed call purpose in the
> future.
>
>
>
> More details inline below.
>
>
>
> On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt <[e-mail]>
> wrote:
>
> Hi Henning,
>
>
>
> I understand what you are saying.  I do however think there is reasons to
> protect call-reason/Subject of call.  I think these situations are mostly
> in the context of delegation to perhaps a call center, where you have
> authorized them to represent your company in particular ways, including not
> only your identity, but for different context of calls that you have
> authorized them to represent you.  We all know there is some call centers
> that use call identities with good reputation for customers that may
> exploit that reputation for other customers.  I would look at this as
> similar situation.
>
>
>
> I think we generally agree - your example of a call center is probably, in
> my view, the most likely case where some indication of call purpose will be
> used, probably with explicit arrangement with the carrier. This may well
> turn out to be similar to the current model for SMS, where (in the US and
> some other countries) you'll have to register your "campaign" with the
> carrier or designated third party. This may even take the notion of a
> template ("This call is about your recent order from {date}") that can be
> auto-enforced. It's clear that carriers seem quite concerned about their
> individual customers messaging, in volume, to their subscribers, given the
> abuse.
>
>
>
>
>
> There is also potential for future of Subject/call-reason to be more than
> just a text string.
>
>
>
> I suspect that's best handled separately, once we have a clearer use case.
> I don't think we can just stick this into call-reason without all kinds of
> backwards-compatibility issues.
>
>
>
>
>
> I’m struggling a bit on your point that we should sign some data but not
> other data because it is less likely to be manipulated.  Is that the bar we
> should be striving for here? Seems to conflict with my understanding of
> some of the goals.
>
>
>
> Maybe this indicates that we should be clearer on the goals. My take on
> the value of STIR "classic" (for TNs) is that the main purpose of signing
> is to make it clear who is responsible for the information provided - thus,
> the whole discussion of A/B/C attestation. Indeed, the experience seems to
> indicate that C-level attestation is actually a signal for a robocall,
> i.e,. C-level calls are *more* likely to be robocalls than unsigned calls.
> A/B/C obviously have the same cryptographic strength and all prevent
> modification by third parties.
>
>
>
> I don't think that carrier manipulation of the caller information (except
> in various normalization ways) has ever been a major problem - it's
> originator (OSP or end user) spoofing. This is rather different than the
> typical threat model where the originator worries about evil Mallory
> changing their data, e.g., by redirecting a money transfer to them.
>
>
>
> But for call-purpose, this is less relevant - this is clearly (mostly)
> useful if inserted by the originating caller, and unlike for A-level
> attestation, the carrier can't really validate that the message is
> truthful. How would it know that "You have won a cruise!" in the
> call-purpose/Subject was correct or a scam? Indeed, as mentioned, if I were
> a carrier, I'd never want to attest to that purpose, as somebody could
> reasonably claim that the carrier should have known that the recipients
> hadn't won anything.
>
>
>
> This is the main reason that I think this should be a separate claim - if
> anybody should sign/attest this, it's the enterprise call center and only
> that call center.
>
>
>
>
>
> Why not have the framework that we can do that.  You are free to protect
> or not protect data depending on your own policy.
>
>
>
> Nothing wrong as such. My argument is that RCD and call-purpose/Subject
> are very different, so they shouldn't be in the *same* framework. If we
> need Subject/call-purpose, they should be in separate claims, for the
> operational reasons mentioned.
>
>
>
>
>
> I guess i want to be sure whether you are reacting to us not using Subject
> vs call-info as a common container for “rich call data” related info or
> that we have both call-info and ‘rcd’ as a container for Rich Call Data
> more generally?  I think there is many reasons why we landed there, we can
> re-hash that in the context of call-info vs subject.  I would be less
> excited about re-hashing it for passport/rcd.
>
>
>
> For the reasons above, I think this is a bad idea for both cases, in
> my view. It's worse for Call-Info, because of the duplication of existing
> functionality.
>
>
>
> To use an analogy: The RCD is mostly like a business card. We don't
> typically write our contracts and messages on business cards - we might
> staple our business card to a note.
>
>
>
> My constructive suggestion is to create a separate claim if needed. (My
> understanding is that rcd-14 does not contain the call purpose, so this is
> the current state.)
>
>
>
>
>
> I do believe both of these frameworks need to be extensible, i don’t think
> we are finished.  We can define more passport extensions, but at the same
> time, do we want to redefine “rcd” and “rcdi” for new passport extensions?
>
>
>
> No, we should create, in my view, a separate document that focuses on
> signing the call purpose, expressed either as Subject (as the compact form)
> or an explicit JWT claim, such as "subject".
>
>
>
>
>
> -Chris
>
>
>
>
>
>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
> <https://clicktime.symantec.com/3Rdm4a4kEdNdgP4kcfQmXHr7GS?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fsipcore%26data%3D04%2A7C01%2A7Cpierce.gorman%2A40t-mobile.com%2A7C8f7f691977104a02c56e08da1cc1a356%2A7Cbe0f980bdd994b19bd7bbc71a09b026c%2A7C0%2A7C0%2A7C637853915250872762%2A7CUnknown%2A7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%2A3D%2A7C3000%26sdata%3D7vp%2A2Fn9jfcrDCenYXJ6w9ePzAHCGBriNtxv4MqYlrAAM%2A3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU%21%21BhdT%21lVhTBoiSdTpfns3f5q-tn_IpActJ0lJodzxhFCqIiwqryyv3-kiFsq3uPygOt5tNhA6w5Iw3BcNkYDawgm1zu-QG%24>
>
>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
> <https://clicktime.symantec.com/3XSrFHfUS2q5UfN8JrjXJFh7GS?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fsipcore%26data%3D04%2A7C01%2A7CPierce.Gorman%2A40t-mobile.com%2A7Cf6f90a7ae5cf40b886df08da1cc59210%2A7Cbe0f980bdd994b19bd7bbc71a09b026c%2A7C0%2A7C0%2A7C637853932135869825%2A7CUnknown%2A7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%2A3D%2A7C3000%26sdata%3DTXa6a%2A2B%2A2BD0iXGv281xu72j%2A2FTblVpnsqKG0oxMY24s030%2A3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ%21%21BhdT%21lVhTBoiSdTpfns3f5q-tn_IpActJ0lJodzxhFCqIiwqryyv3-kiFsq3uPygOt5tNhA6w5Iw3BcNkYDawgjI_Wb4K%24>
>
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential
> and/or proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
>