Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 28 Nov 2018 21:17:01 +0000

Greetings,

We had an ATIS- SIP Forum IPNNI meeting today. 
Several operators performed lab testing with large SIP headers. It was found that some deployed vendor equipment will drop the SIP INVITE if a single header exceeds a certain length.

The IPNNI requests that the option for support of individual Identity headers be added back into draft-ietf-stir-passport-divert, as nesting may result in failures.

Thank you for your consideration.

Regards,

Martin C. Dolly
Lead Member of Technical Staff
Government & Services Standards
AT&T
Cell: +1.609.903.3360
Email: [email-masked]

-----Original Message-----
From: stir <[email-masked]> On Behalf Of Robert Sparks
Sent: Tuesday, October 23, 2018 2:58 PM
To: [email-masked]
Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt

We plan to WGLC this document shortly after the Bangkok meeting, but if anyone has any major issues with it, please bring them up now so we can work them out during that meeting.

RjS

On 10/22/18 7:08 PM, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF.
>
>          Title           : PASSporT Extension for Diverted Calls
>          Author          : Jon Peterson
> 	Filename        : draft-ietf-stir-passport-divert-04.txt
> 	Pages           : 12
> 	Date            : 2018-10-22
>
> Abstract:
>     This document extends PASSporT, which conveys cryptographically-
>     signed information about the people involved in personal
>     communications, to include an indication that a call has been
>     diverted from its original destination to a new one.  This
>     information can greatly improve the decisions made by verification
>     services in call forwarding scenarios.  Also specified here is an
>     encapsulation mechanism for nesting a PASSporT within another
>     PASSporT that assists relying parties in some diversion scenarios.
>
>
> The IETF datatracker status page for this draft is:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> org_doc_draft-2Dietf-2Dstir-2Dpassport-2Ddivert_&d=DwICAg&c=LFYZ-o9_HU
> MeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rPMGq7kv2BGudfdZh7O0Klj1GlIEi4
> S4U6ZcvMDUXd0&s=kd2Yz4GCgDKOSymv2aLYUADzjR6AWffmnPSXjuYSGZ0&e=
>
> There are also htmlized versions available at:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
> ml_draft-2Dietf-2Dstir-2Dpassport-2Ddivert-2D04&d=DwICAg&c=LFYZ-o9_HUM
> eMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rPMGq7kv2BGudfdZh7O0Klj1GlIEi4S
> 4U6ZcvMDUXd0&s=BToPQIIkMCUzUrB8XhiVCMFNj7SJIh49AImdMcCRp9c&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> org_doc_html_draft-2Dietf-2Dstir-2Dpassport-2Ddivert-2D04&d=DwICAg&c=L
> FYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rPMGq7kv2BGudfdZh7O0K
> lj1GlIEi4S4U6ZcvMDUXd0&s=QgOSunMIP4lN49FN75w2hLI2QZMil7jaW-Q4irYBXVA&e
> =
>
> A diff from the previous version is available at:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcd
> iff-3Furl2-3Ddraft-2Dietf-2Dstir-2Dpassport-2Ddivert-2D04&d=DwICAg&c=L
> FYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rPMGq7kv2BGudfdZh7O0K
> lj1GlIEi4S4U6ZcvMDUXd0&s=57v9jHegC0yKQjthkptLgxxjK2OgKFmPXEhJFU5Dfpo&e
> =
>
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_intern
> et-2Ddrafts_&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2
> g&m=rPMGq7kv2BGudfdZh7O0Klj1GlIEi4S4U6ZcvMDUXd0&s=ZOq0I6yZGiy_RDG_MUp-
> vzuBiBQrTPd5q48MABiOxBY&e=
>
> _______________________________________________
> stir mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_stir&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7I
> tG0r2g&m=rPMGq7kv2BGudfdZh7O0Klj1GlIEi4S4U6ZcvMDUXd0&s=Zen9oBkuiFcBcM1
> Mms4FKeVZxxohlxvrDzJ4Dz0HCxw&e=

_______________________________________________
stir mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rPMGq7kv2BGudfdZh7O0Klj1GlIEi4S4U6ZcvMDUXd0&s=Zen9oBkuiFcBcM1Mms4FKeVZxxohlxvrDzJ4Dz0HCxw&e=

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 29 Nov 2018 00:10:49 +0000

Personally, I'm fine with putting the option for individual Identity headers back in. I've been trying to do some rewrites for clarity about authentication service and verification service behavior for "div" based on some early comments, and I'm sure the original text about nesting and non-nesting would have needed a similar patching anyway.

Ideally, if there's any firmer data from operator networks about what the scale of the problem is - like what size headers are really a problem - that would be nice to know.

Jon Peterson
Neustar, Inc.

On 11/28/18, 1:17 PM, "stir on behalf of DOLLY, MARTIN C" <[email-masked] on behalf of [email-masked]> wrote:

    Greetings,

    
    
    Regards,
    
    Martin C. Dolly

    -----Original Message-----
    From: stir <[email-masked]> On Behalf Of Robert Sparks
    Sent: Tuesday, October 23, 2018 2:58 PM
    To: [email-masked]
    Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt

    RjS

    
    _______________________________________________
    stir mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwICAg&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=FvQYCnbfElq6VfDsf3xVLotfF0L2gOarO0sdc1yJTrg&s=5mzFytkW9fVT82kLOUsOxdwMvqQEiTpBYJTlVFVd6nI&e=

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 29 Nov 2018 00:18:59 +0000

Jon

First, thanks for understanding 

To your question, as low as 800, with the major issue at 1000 octets

Break NDA saying more

Regards

Martin C Dolly
AT&T
+1 609 903 3360

> On Nov 28, 2018, at 7:10 PM, Peterson, Jon <[email-masked]> wrote:
> 
>

---

From: Chris Wendt <[email-masked]>
Date: Wed, 28 Nov 2018 19:45:13 -0500

We also have equipment in the network that also has same behavior. If the equipment just truncated or just passed the INVITE through, it would be fine, but given there is equipment that basically just drops calls, and wrong or right, it does seem to be a prevalent behavior, keeping the multiple identity header option for div would be the only pragmatic option. 

-Chris

> On Nov 28, 2018, at 7:18 PM, DOLLY, MARTIN C <[email-masked]> wrote:
> 
> Jon
> 
> https://www.ietf.org/mailman/listinfo/stir

---

From: Richard Shockey <[email-masked]>
Date: Wed, 28 Nov 2018 21:27:13 -0500

+1   I totally support the position that Martin and Chris are advocating.  

I might add that some of us are looking at formal legal protection for methods for Call Authentication aka STIR/SHAKEN headers to prevent either inadvertent or malicious alteration.  Some of you vendors should take note. 

We are looking at extending sections of US 47 CFR 64.1601.  CFR is the Code of Federal Regulations.  

Other national jurisdictions may want to take a look at this.  Film at 11.  

§64.1601   Delivery requirements and privacy restrictions.
(a) Delivery. Except as provided in paragraphs (d) and (e) of this section:
 
(1) Telecommunications carriers and providers of interconnected Voice over Internet Protocol (VoIP) services, in originating interstate or intrastate traffic on the public switched telephone network (PSTN) or originating interstate or intrastate traffic that is destined for the PSTN (collectively “PSTN Traffic”), are required to transmit for all PSTN Traffic the telephone number received from or assigned to or otherwise associated with the calling party to the next provider in the path from the originating provider to the terminating provider. This provision applies regardless of the voice call signaling and transmission technology used by the carrier or VoIP provider. Entities subject to this provision that use Signaling System 7 (SS7) are required to transmit the calling party number (CPN) associated with all PSTN Traffic in the SS7 ISUP (ISDN User Part) CPN field to interconnecting providers, and are required to transmit the calling party's charge number (CN) in the SS7 ISUP CN field to interconnecting providers for any PSTN Traffic where CN differs from CPN. Entities subject to this provision who use multi-frequency (MF) signaling are required to transmit CPN, or CN if it differs from CPN, associated with all PSTN Traffic in the MF signaling automatic numbering information (ANI) field.
 
(2) Intermediate providers within an interstate or intrastate call path that originates and/or terminates on the PSTN must pass unaltered to subsequent providers in the call path signaling information identifying the telephone number, or billing number, if different, of the calling party that is received with a call. This requirement applies to SS7 information including but not limited to CPN and CN, and also applies to MF signaling information or other signaling information intermediate providers receive with a call. This requirement also applies to VoIP signaling messages, such as calling party and charge information identifiers contained in Session Initiation Protocol (SIP) header fields, and to equivalent identifying information as used in other VoIP signaling technologies, regardless of the voice call signaling and transmission technology used by the carrier or VoIP provider.
 
(b) Privacy. Except as provided in paragraph (d) of this section, originating carriers using Signaling System 7 and offering or subscribing to any service based on Signaling System 7 functionality will recognize *67 dialed as the first three digits of a call (or 1167 for rotary or pulse dialing phones) as a caller's request that the CPN not be passed on an interstate call. Such carriers providing line blocking services will recognize *82 as a caller's request that the CPN be passed on an interstate call. No common carrier subscribing to or offering any service that delivers CPN may override the privacy indicator associated with an interstate call. Carriers must arrange their CPN-based services, and billing practices, in such a manner that when a caller requests that the CPN not be passed, a carrier may not reveal that caller's number or name, nor may the carrier use the number or name to allow the called party to contact the calling party. The terminating carrier must act in accordance with the privacy indicator unless the call is made to a called party that subscribes to an ANI or charge number based service and the call is paid for by the called party.
 
(c) Charges. No common carrier subscribing to or offering any service that delivers calling party number may
 
(1) Impose on the calling party charges associated with per call blocking of the calling party's telephone number, or
 
(2) Impose charges upon connecting carriers for the delivery of the calling party number parameter or its associated privacy indicator.
 
(d) Exemptions. Section 64.1601(a) and (b) shall not apply when:
 
(1) A call originates from a payphone.
 
(2) A local exchange carrier with Signaling System 7 capability does not have the software to provide *67 or *82 functionalities. Such carriers are prohibited from passing CPN.
 
(3) A Private Branch Exchange or Centrex system does not pass end user CPN. Centrex systems that rely on *6 or *8 for a function other than CPN blocking or unblocking, respectively, are also exempt if they employ alternative means of blocking or unblocking.
 
(4) CPN delivery—
 
(i) Is used solely in connection with calls within the same limited system, including (but not limited to) a Centrex system, virtual private network, or Private Branch Exchange;
 
(ii) Is used on a public agency's emergency telephone line or in conjunction with 911 emergency services, on a telephone line to contact non-public emergency services licensed by the state or municipality, or on any entity's emergency assistance poison control telephone line; or
 
(iii) Is provided in connection with legally authorized call tracing or trapping procedures specifically requested by a law enforcement agency.
 
(e) Any person or entity that engages in telemarketing, as defined in section 64.1200(f)(10) must transmit caller identification information.
 
(1) For purposes of this paragraph, caller identification information must include either CPN or ANI, and, when available by the telemarketer's carrier, the name of the telemarketer. It shall not be a violation of this paragraph to substitute (for the name and phone number used in, or billed for, making the call) the name of the seller on behalf of which the telemarketing call is placed and the seller's customer service telephone number. The telephone number so provided must permit any individual to make a do-not-call request during regular business hours.
 
(2) Any person or entity that engages in telemarketing is prohibited from blocking the transmission of caller identification information.
 
(3) Tax-exempt nonprofit organizations are not required to comply with this paragraph.
 
(f) Paragraph (b) of this section shall not apply when CPN delivery is made in connection with a threatening call. Upon report of such a threatening call by law enforcement on behalf of the threatened party, the carrier will provide any CPN of the calling party to law enforcement and, as directed by law enforcement, to security personnel for the called party for the purpose of identifying the party responsible for the threatening call.
 
(g) For law enforcement or security personnel of the called party investigating the threat:
 
(1) The CPN on incoming restricted calls may not be passed on to the line called;
 
(2) Any system used to record CPN must be operated in a secure way, limiting access to designated telecommunications and security personnel, as directed by law enforcement;
 
(3) Telecommunications and security personnel, as directed by law enforcement, may access restricted CPN data only when investigating phone calls of a threatening and serious nature, and shall document that access as part of the investigative report;
 
(4) Carriers transmitting restricted CPN information must take reasonable measures to ensure security of such communications;
 
(5) CPN information must be destroyed in a secure manner after a reasonable retention period; and
 
(6) Any violation of these conditions must be reported promptly to the Commission.
 
[60 FR 29490, June 5, 1995; 60 FR 54449, Oct. 24, 1995, as amended at 62 FR 34015, June 24, 1997; 68 FR 44179, July 25, 2003; 71 FR 75122, Dec. 14, 2006; 76 FR 73882, Nov. 29, 2011; 82 FR 56917, Dec. 1, 2017]
 
Effective Date Note: At 82 FR 56917, Dec. 1, 2017, §64.1601 was amended by revising paragraphs (d)(4)(ii) and adding paragraph (f). These paragraphs contain information collection and recordkeeping requirements and will not become effective until approval has been given by the Office of Management and Budget.

— 
Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

On 11/28/18, 7:45 PM, "stir on behalf of Chris Wendt" <[email-masked] on behalf of [email-masked]> wrote:

    -Chris

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 29 Nov 2018 20:01:36 +0000

+1 on not requiring nesting.

Not sure what to think about legislation that "prevents" "inadvertent" alterations.  Is that possible?  

FWIW, given the extended discussion on the IP-NNI call yesterday about known and anticipated SHAKEN verification failure scenarios for "corner case" call flows with no proposed or standard solution other than a best practice of treating the call as "not verified", perhaps it might be prudent to get some real-world operational experience to help craft details of supporting legislation.

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Wednesday, November 28, 2018 8:27 PM
To: Chris Wendt <[email-masked]>; Martin C Dolly <[email-masked]>
Cc: Peterson, Jon <[email-masked]>; Robert Sparks <[email-masked]>; [email-masked]
Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt

 

 

 

 
 
(4) CPN delivery—

 

 

 

 

 

— 
Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

On 11/28/18, 7:45 PM, "stir on behalf of Chris Wendt" <stir-bounces@ietf..org on behalf of [email-masked]> wrote:

    -Chris
    
    >>   Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04..txt
    >> 
    >>>   PASSporT that assists relying parties in some diversion scenarios..
    >>> 
    >>>