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

[Ranjit Avasarala <[e-mail]>]

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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7C8f7f691977104a02c56e08da1cc1a356%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637853915250872762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7vp%2Fn9jfcrDCenYXJ6w9ePzAHCGBriNtxv4MqYlrAAM%3D&reserved=0>
>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>