WELCOME & CALL TO ORDER - Alliance for …



TITLE:ATIS/SIP Forum IP-NNI TF Meeting Notes, April 28-29, 2020SOURCE:Anna Karditzas, Committee Coordinator, akarditzas@LEADER(S):IP-NNI TF Co-Chair: Martin Dolly, AT&T (md3135@)IP-NNI TF Co-Chair: Chris Wendt, Comcast (chris_wendt@)NOTICEOnly documents that are final/approved by an ATIS Committee represent the consensus of that Committee. Draft documents, on the other hand, are dynamic in nature and subject to change. Draft documents therefore may not accurately reflect the consensus of the ATIS Committee. Neither ATIS nor the Committee makes any representation or warranty, express or implied, with respect to the sufficiency, accuracy or utility of the information or opinion contained or reflected in the material utilized. ATIS further expressly advises that any use of or reliance upon the material in question is at your risk and neither ATIS nor the Committee shall be liable for any damage or injury, of whatever nature, incurred by any person arising out of any utilization of the material. It is possible that this material will at some future date be included in a copyrighted work by ATIS. ATIS/SIP Forum IP-NNI TFVirtual Meeting – April 28-29, 2020Tuesday, April 28: 1-5pm ETWednesday, April 29: 9am-5pm ETMeeting NotesWELCOME & CALL TO ORDERChris Wendt (Comcast), IP-NNI TF Co-Chair, called the meeting to order and welcomed participants at 1:06pm ET on April 28, 2020. The meeting reconvened at 9:03am ET on April 29, 2020. INTRODUCTIONS & SIGN INMr. Wendt welcomed the attendees. The meeting participants are listed below: 4/284/29NameCompanyEmailXXMartin Dolly (IP-NNI TF Co-Chair)AT&Tmd3135@XXChris Wendt (IP-NNI TF Co-Chair)Comcastchris_wendt@XXKirk BurroughsApplekburroughs@XXGaurav LambaAppleglamba@XXAndy JurczakAT&Tajurczak@XXHoward LangAT&Thl1539@XXDavid PreoBandwidthdpreo@XXPhilip LinseCenturyLinkphilip.linse@XXRobert DiandaCharter Communicationsrobert.dianda@XXCarol-lyn TaylorCISA ECDcarol-lyn.taylor@XXArye EphrathCISA ECD Supportarye@XPark YangCiscoparyang@XMohamed BaracheComcastMcarac7997k@XXDavid HancockComcastdavid_hancock@XXChia-Chang LiComcastchia-chang_li@XAndre SavageCox Communicationsandre.savage@XScott UptonCox Communicationsscott.upton@XXClark WhittenCox Communicationsclark.whitten@XXMarian HearnCST GA (Canada)marian.hearn@cstga.caXXBen CampbellCTIAben@XXHarold SaltersCTIAhms5516@XXArleen ElliottEricssonarleen.elliott@XXGeorge FotiEricssongeorge.foti@XXHala MowafyEricssonhala.mowafy@XXTerry ReeseEricssontheresa.reese@XXTracey CashFirst Oriontcash@XXJulie Sara FowlerFirst Orionjfowler@XMichael PowersGBSD Technologiesmike.powers@XXJeffrey RossGBSD Technologiesjeffrey.ross@XXDavid KayHiyadkay@XJohn Haraburdaiconectivjharaburda@XXGary Richenakericonectivgrichenaker@XXAndrew GallantInCharge Systemsabgallant@XXMike HamiltonInCharge Systemsmikehamilton@XJames LutzInfocomguyinfocomguy@XXDoug BellowsInteliquentdoug.bellows@XTimothy MoranLeidosmorantl@XXPeter BrownMetaswitchpeter.brown@XAustin SpreadburyMetaswitchaustin.spreadbury@XRuss PenarMicrosoftrussp@XXDoug LawsNECAdlaws@XXDouglas RanalliNetNumberdranalli@XXAnthony CrestiNeustaranthony.cresti@team.neustarXMick MossNeustarMick.Moss@team.neustarXXKen Politz Neustarkpolitz@cis.XXShreyas SaitawdekarNeustarshreyas.saitawdekar@team.neustarXJason TorreyNeustarjason.torrey@team.neustarXXMohammad KhaledNokiamohammad.khaled@XXChris CurrieNumber Accesschris.currie@XXAnis JafferNumeracleanis@XXRebekah JohnsonNumeraclerebekah@XTyler HawbakerOTD (Tridea Works)tyler.hawbaker@XXTom MorescoPerspecta Labstmoresco@XXRay Singh Perspecta Labsrsingh@XXJohn WullertPerspecta Labsjwullert@XXJames HamlinPurple & ZVRSjames.hamlin@purple.usXXMary BarnesRealtime Communications, LLCMLB@XXTolga AsverenRibbon Communicationstasveren@XXJamie GibsonRibbon Communicationsjgibson@XGraham LeGeyt (guest)Shaw Communicationsgraham.legeyt@sjrb.caXXRichard ShockeySIP Forumrichard@shockey.usXXJusten DavisSomosjdavis@XXMary RetkaSomosmretka@XXShaunna ForsheeT-Mobileshaunna.l.foreshee@t-XXPierce GormanT-Mobilepierce.gorman@t-XXDavid HolmesT-Mobiledavid.holmes@t-XXKaren RiepenkrogerT-Mobilekaren.s.riepenkroger@t-XXGreg SchumacherT-Mobilegregory.schumacher@t-XXDon BeelerTDR Technologydon.beeler@XSarah HalkoTelnyxsarah@XRamon TorresTelnyxramon@XXGerry ChristensenTNSgchristensen@XLavinia KennedyTNSlkennedy@XXJose Mario Miranda MartinezTNSmmiranda@XXJim DaltonTransNexusjim.dalton@XXAlec FenichelTransNexusalec.fenichel@XXChrister FahlgrenTwiliochrister@XXMark DesterdickVerizondesterdick@XXAnna KarditzasATISakarditzas@XXSteve BarclayATISsbarclay@XIan DeakinATISideakin@XCarroll Gray-PrestonATIScg-preston@XXJim McEachernATISjmceachern@XXBrent StruthersATISbstruthers@XJackie WohlgemuthATISjwohlgemuth@REVIEW & APPROVAL OF AGENDAThe agenda was made available to participants via ATIS Workspace (AWS) as IPNNI-2020-00077R003. Modifications were proposed and the agenda was approved as revised throughout the meeting in IPNNI-2020-00077R007. ATIS OP, IPR, ANTITRUST AND CONTRIBUTIONS NOTICESATIS Procedures: ATIS Forum and Committee activities must adhere to the ATIS Operating Procedures (OP) for ATIS Forums and Committees.Intellectual Property Rights (IPR): In connection with the development of an ATIS deliverable that requires use of patented inventions, the ANSI Patent Policy as adopted by ATIS and as set forth in Section 10.4 of the OP shall apply. Under this policy:Disclosure of relevant patented inventions at the earliest possible time is encouraged. Neither the Forum or Committee nor its leaders can ensure the accuracy or completeness of any disclosure, investigate the validity or existence of a patent, or determine whether a patent is essential to the use of an ATIS deliverable. The discussion of licensing terms is prohibited in ATIS Forums and Committees.Patent disclosure and assurance statements consistent with the ATIS OP must be submitted in writing to the ATIS General Counsel.Antitrust: Attendees are reminded that participation in industry fora involves the potential for antitrust concerns or risks. To avoid such concerns/risks, participants should carefully observe the OP. Sensitive discussion topics such as price, costs, specific contractual terms, etc., should be avoided. Contributions: In order for ATIS to facilitate, promote, and disseminate its work, each contributor must grant ATIS the rights necessary to adapt, copy, and publicly distribute any contribution or submittal. Each contribution or document therefore is subject to unlimited perpetual, non-exclusive, royalty-free, world-wide rights, and license to ATIS of any copyrights in such a contribution. As a general rule, ATIS will not consider any contribution, presentation, or other input that is subject to any requirement of confidentiality or any restriction on its dissemination. Questions: If there are any questions, comments, or concerns, participants should contact their company's legal counsel, the Committee leadership, ATIS staff, or ATIS legal counsel.It was asked if there were any patents to identify or disclose at this time. There were no patent disclosures made by the attendees.REVIEW OF ACTION ITEMS FROM PREVIOUS MEETINGSAction Item: Mary Barnes (Realtime Communications) will update the SHAKEN Roadmap baseline, IPNNI-2019-00038R003, incorporating the updates contained in IPNNI-2019-00140R000. This Action Item was closed with the posting of IPNNI-2020-00084R001. Action Item: Mary Barnes (Realtime Communications) will update the references to the IP-NNI overview documents in Sections 5.5 and 5.6 of IPNNI-2019-00140R001. This Action Item was closed with the posting of IPNNI-2020-00084R001. Action Item: Participants should consider whether any changes are necessary for IPNNI-2019-00152R001, SHAKEN Support of “div” PASSporT, before it can go to letter ballot at the February 19, 2020 virtual meeting.Participants were encouraged to review this baseline in advance of the next meeting so that it can be approved for letter ballot at the next meeting on May 18, 2020. This Action Item was closed. Action Item: Participants should review IPNNI-2020-00021R003, Updated Baseline Text for Draft ATIS Standard on SIP RPH Signing using PASSporT Tokens, in detail and prepare any comments for the next iteration of this document. Participants were encouraged to review this baseline in advance of the next meeting so that it can be approved for letter ballot at the next meeting on May 18, 2020. This Action Item was closed. IP-NNI TOPIC DISCUSSIONATIS-1000074.v002, Signature-based Handling of Asserted information toKENs (SHAKEN)IPNNI-2020-00008R006, Signature-based Handing of Asserted information using toKENs (SHAKEN) (revmarked)This revmarked baseline was not discussed. IPNNI-2020-00008R007, Signature-based Handing of Asserted information using toKENs (SHAKEN) (clean)This contribution contains the clean version of the baseline with the changes accepted during the April 13, 2020, virtual meeting.Agreement Reached: This contribution was accepted as the approved baseline. IPNNI-2020-00083R000, Proposed updates to SHAKEN (clean)Mark Desterdick (Verizon) presented this contribution, which proposes updates to ATIS-1000074.v002 to state that a verstat value should only be set for A-level attestation. A comment was made that this statement may conflict with RFC 24-229; a consistency check should be made. A suggestion was made to codify this in the API document. However, the API document is informative, not normative; also, no display framework standard exists yet. Verstat is not passed between networks, so carriers can do whatever they want with it locally. However, if verstat is specified then other values may need to be specified. It was noted that enterprises do not have access to the CA list and cannot see that information regardless of whether a call has A-, B-, or C-level attestation. While some carriers can handle receiving all the information received by the service provider, not all can; some carriers only have a PBX and a gateway, which cannot handle the load. TN validation passed means that the call is verified, but does not necessarily indicate which attestation level was assigned. A suggestion was made to make these proposed changes in RFC 24-229, rather than in this document. Initially, the work on attestation levels was coupled with display; there would have been a linkage of attestation levels and attestation display indicators. However, this fell through when the work on display ceased, and was not realized. Agreement Reached: This contribution was accepted as modified in IPNNI-2020-00084R001 for incorporation into the baseline. Participants were encouraged to review the anticipated clean version of the baseline in advance of the next meeting so that it can be approved for letter ballot at the next meeting on May 18, 2020. A couple participants noted that they anticipate having edits ready for the next meeting. Verification Token Use Cases IPNNI-2017-00020R000, Verification Token Use Cases BaselineThere were no contributions submitted for this Issue. ATIS-1000080.v003, SHAKEN Governance Model and Certificate ManagementIPNNI-2020-00015R005, ATIS-1000080.v003, SHAKEN Governance Model and Certificate Management (revmarked)This revmarked baseline was not discussed. IPNNI-2020-00015R006, ATIS-1000080.v003, SHAKEN Governance Model and Certificate Management (clean)David Hancock (Comcast) presented this clean baseline, which incorporates the changes agreed upon during the March 30, 2020, virtual meeting. APIs have been implemented but are not consistent with the standard in some places. A question was raised on whether to alter implementation to align with the standard, or to update the standard to reflect implementation. Participants were encouraged to review the anticipated clean version so that it can be approved for letter ballot at the next meeting on May 18, 2020.Agreement Reached: This contribution was accepted as the approved baseline. Action Item: Mary Barnes (Realtime Communications) will provide an updated baseline for ATIS-1000080.v003 to align with implemented APIs. ATIS-1000084.v002, Technical Report on Operational and Management Considerations for SHAKEN STI Certification Authorities and Policy AdministratorsIPNNI-2020-00017R001, Proposed updates to ATIS-1000084.v002Participants were encouraged to review this baseline in advance of the next meeting so that it can be approved for letter ballot at the next meeting on May 18, 2020.Robo-MetricsIPNNI-2018-00083R001, Robo-Metrics BaselineThere were no contributions submitted for this Issue. SHAKEN Roadmap IPNNI-2018-00038R003, SHAKEN Roadmap [Baseline]This contribution is the accepted baseline. IPNNI-2020-00084R001, SHAKEN Roadmap [clean]Mary Barnes (Realtime Communications) presented this clean baseline for the SHAKEN Roadmap, which includes the updates contained in IPNNI-2019-00140R000. Agreement Reached: This contribution was accepted as the updated baseline roadmap. IPNNI-2020-00085R003, Proposed updates to SHAKEN Roadmap Mary Barnes (Realtime Communications) presented this contribution, which contains proposed updates for the SHAKEN Roadmap that include the updates contained in IPNNI-2019-00140R000 as well as updates for SHAKEN OOB. Agreement Reached: This contribution was accepted as modified for incorporation into the updated baseline. IPNNI-2020-00084R002, SHAKEN Roadmap [revmarked]Mary Barnes (Realtime Communications) presented this revmarked baseline for the SHAKEN Roadmap, which incorporates the changes proposed in IPNNI-2020-00085R003. ATIS-1000085.v002, SHAKEN Support of “div” PASSporT TokenIPNNI-2020-00045R000, SHAKEN Support of “div” PASSporT (Baseline)This is the SHAKEN Support of “div” PASSporT baseline, which was previously approved. Participants were encouraged to review this baseline in advance of the next meeting so that it can be approved for letter ballot at the next meeting on May 18, 2020.IPNNI-2020-00079R000, Proposed baseline for SHAKEN Support of “div” PASSporTDavid Hancock (Comcast) presented this contribution, which proposes updates to the baseline to add support for div authentication using delegate certificates. The changes proposed in this contribution were not accepted and this contribution was noted. SHAKEN Delegate Certificates IPNNI-2020-00022R004, Document describing delegate certificate framework for SHAKEN (revmarked)This revmarked baseline was not discussed. IPNNI-2020-00022R005, Document describing delegate certificate framework for SHAKEN (clean)This contribution is the clean version of IPNNI-2020-00022R004, and incorporates the changes proposed in IPNNI-2020-00053R000 excluding section 5.3.5, as agreed upon during the March 10, 2020, virtual meeting. Agreement Reached: This contribution was accepted as the clean baseline. IPNNI-2020-00065R002, Proposed baseline for SHAKEN Delegate CertificatesDavid Hancock (Comcast) presented this contribution, which removes the editor’s note since the RespOrg can be a legitimate SHAKEN SP. Regarding the editor’s note in Section 3.1, RespOrgs can assign toll-free numbers. Mr. Dolly noted a preference for more documentation on this issue; for example, a document or technical report on RespOrgs explaining what would be expected of them. If a RespOrg does not support this mechanism, they cannot receive a certificate. In the event that a carrier does not support delegate certificates, can an organization that got an 8YY number from a carrier that does not support delegate certificates use that 8YY number on another carrier? The use of 8YY numbers is high in call centers. 8YY is a special case as it is governed separately. A proposal was made to create a new baseline for a technical report that specifically addresses RespOrgs. A proposal was made to either push base PASSporT as an option for informing the OSP, or detail multiple mechanisms to inform the OSP. RCD mandates a name at a minimum in the base PASSporT. If the number is ported, the SP is obligated to revoke the certificate. This document narrows the PA’s role to an absolute minimum. Agreement Reached: The proposed changes in section 6.1 were rejected; David Hancock (Comcast) will bring a revised baseline to the next session on Wednesday, April 29, 2020. IPNNI-2020-00065R004, Proposed updates to SHAKEN Delegate CertificatesDavid Hancock (Comcast) presented this contribution, which reflects comments made on the April 28, 2020, session of the IP-NNI TF meeting. This revision removes the RespOrg material, assuming the creation of a new Technical Report addressing RespOrgs; adds a note that support for TN AuthList pass-by-reference can be added to a subsequent version of the document; and removes support for signing base RFC 8225 PASSporTs. Three possible scenarios were discussed: Enterprise provides everythingThe SP is authoritative over only the TN and uses base PASSporT OSP handles everything and inserts RCD for base STIR/SHAKENThis contribution was accepted for incorporation into the baseline. SHAKEN Calling Name and Rich Call Data Handling Procedures IPNNI-2020-00025R002, SHAKEN Calling Name and Rich Call Data Handling Procedures (revmarked)This is a revmarked baseline which incorporates the changes proposed in IPNNI-2020-00052R000 as agreed upon during the March 10, 2020, virtual meeting. This contribution was noted for information. IPNNI-2020-00025R003, SHAKEN Calling Name and Rich Call Data Handling Procedures (clean)David Hancock (Comcast) presented this contribution, which is the clean version of IPNNI-2020-00025R002. Agreement Reached: This contribution was accepted as the clean baseline. IPNNI-2020-00080R000, Proposed updates to SHAKEN Calling Name and Rich Call Data Handling Procedures David Hancock (Comcast) presented this contribution, which proposes updates to Sections 5 and 6 to maintain alignment with the latest IETF drafts, as well as to reduce the number of options in order to simplify implementations. Comments were made on the necessity of the “rcdi” claim, noting that making it mandatory seems unnecessary. The “rcdi” claim should be mandatory if the claims include a link; it should not mandatory if there is a reference. An observation was made that this solution was intentionally designed to not be compatible with non-delegated certificates. A note was made that Section 5.2.1 covers RCD authentication specifically, not RCD claims – a suggestion was made to expand it to include RCD claim in a SHAKEN PASSporT. If the majority opinion is to use RCD as the main mechanism for this case, then inclusion of “nam” field can be revisited (as initially established in IETF). This contribution was noted. IPNNI-2020-00080R002, Proposed updates to SHAKEN Calling Name and Rich Call Data Handling Procedures David Hancock (Comcast) presented this contribution, which reflects comments made during the April 28, 2020, session of the IP-NNI TF meeting. This revision adds requirements regarding referenced rcd resource updates and updates the auth/verify procedures to differentiate between RCD authentications. Agreement Reached: This contribution was accepted for incorporation into the baseline. Best Current Practices on the protection of STIR/SHAKEN data between service providers and from service providers to enterprisesIPNNI-2019-00055R000, Best Current Practices on the protection of STIR/SHAKEN data between service providers and from service providers to enterprises (Baseline)There were no contributions submitted for this Issue. Methods to Determine SHAKEN Attestation Levels Using Enterprise-Level Credentials and Telephone Number Letter of Authorization ExchangeIPNNI-2020-00035R000, Methods to Determine SHAKEN Attestation Levels Using Enterprise-Level Credentials and Telephone Number Letter of Authorization Exchange (Baseline)This is the current approved baseline. Signature-based Handling of SIP RPH Assertion Verification Token Use Cases IPNNI-2020-00021R002, Updated Baseline Text for Draft ATIS Standard on SIP RPH Signing using PASSporT Tokens (revmarked)This contribution was not discussed. IPNNI-2020-00021R003, Updated Baseline Text for Draft ATIS Standard on SIP RPH Signing using PASSporT Tokens (clean)This contribution was not discussed. SIP RPH Signing in Support of Emergency CallingIPNNI-2020-00010R002, Session Initiation Protocol (SIP) Resource-Priority Header (RPH) Signing in Support of Emergency Calling (revmarked)This contribution contains the revmarked baseline, which incorporates changes accepted at the February 19, 2020, virtual meeting. IPNNI-2020-00010R003, Session Initiation Protocol (SIP) Resource-Priority Header (RPH) Signing in Support of Emergency Calling (clean)Terry Reese (Ericsson) presented this contribution, which is the clean version of IPNNI-2020-00010R002. Agreement Reached: This contribution was accepted as the approved baseline. IPNNI-2020-00069R001, Proposed edits to SIP RPH Signing in Support of Emergency CallingTerry Reese (Ericsson) presented this contribution, which is proposes edits to the baseline, IPNNI-2020-00010R003. It was noted that 3GPP will likely only document one mechanism for IMS networks, and any additional documentation on IMS Emergency Services Networks will need to be created in the IP-NNI TF. An addition in this revision states that the IBCF needs to remove the verstat parameter before sending the Call to the Emergency Services Network. Agreement Reached: This contribution was approved for incorporation into the baseline. Central TN Database Approach to Full Attestation for Enterprises with Multi-Homing and/or Multi-TenancyIPNNI-2020-00023R000, Central TN Database Approach to Full Attestation for Enterprises with Multi-Homing and/or Multi-TenancyThere were no contributions submitted for this Issue. Leveraging Model for Originating eNtity authentication – full aTtestation With an entity Identity in a Secure Token (LEMON-TWIST)IPNNI-2020-00026R001, LEveraging Model for Originating eNtity Authentication – full aTtestation With an entity Identity in a Secure Token (LEMON TWIST)This contribution contains the revmarked baseline, which incorporates the changes accepted during the March 30, 2020, IP-NNI virtual meeting. This contribution was noted.IPNNI-2020-00026R002, LEveraging Model for Originating eNtity Authentication – full aTtestation With an entity Identity in a Secure Token (LEMON TWIST)Mary Barnes (Realtime Communications) presented this contribution, which is the clean baseline of -00026R001. Agreement Reached: This contribution was accepted as the approved baseline. SHAKEN: Out-of-Band Token TransmissionIPNNI-2020-00058R002, Signature-based Handling of Asserted information using toKENs (SHAKEN): Out-of-Band Token Transmission (baseline)This is the clean baseline, which was accepted at the IP-NNI TF meeting on April 13, 2020. IPNNI-2020-00074R000, Extending STIR/SHAKEN over TDM InterconnectsTolga Asveren (Ericsson) presented this contribution, which defines a mechanism to extend STIR/SHAKEN attestations over TDM interconnects. This contribution expands on the content contained in a previous presentation, IPNNI-2020-00067R000.Agreement Reached: This new topic was accepted for discussion in the IP-NNI TF. Agreement Reached: This contribution was accepted as the baseline for the newly accepted topic “Extending STIR/SHAKEN over TDM Interconnects”. IPNNI-2020-00076R000, Proposed updates to SHAKEN OOB Token TransmissionAlec Fenichel (TransNexus) presented these proposed updates to the clean baseline contained in IPNNI-2020-00058R002. It was noted that the CPS situation would not work for every scenario; however, it should work for the large majority of TDM calls. If the token is not received, it works just like in-band; the call will not be dropped. Retargeting and diversion cases were discussed. A suggestion was made to include the most generic use case (re: Figure 2) and extrapolate based off of that use case. Since for in-band, div is handled in a separate guideline document, a proposal was made to address OOB similarly: to address base case in-document, and address div in a separate document. Participants discussed the benefits of documenting div and RCD exceptions in the diversion document or in a separate document. A suggestion was made to pull out OOB exceptions and include them in a separate subsection of this contribution. Another suggestion was made to handle div in the baseline, IPNNI-2020-00058R002. Contributions are welcome to advance discussion on this topic. Some of these higher-level issues may be incorporated into IPNNI-2020-00082R000. Agreement Reached: This contribution was accepted for incorporation into the baseline, IPNNI-2020-00058R002. IPNNI-2020-00081R000, Issues for SHAKEN OOB Robert Dianda (Charter) presented this contribution, which identifies issues for SHAKEN OOB. A comment was made that IPNNI-2020-00076R000 contains a note that STI-AS is number portability-aware. In-band does not require LNP authentication. For the STI-VS HTTP interface, this information is built into HTTP specs. This contribution was noted. Other Contributions IPNNI-2020-00082R000, Technical Report on Alternatives for Caller Authentication for Non-IP TrafficJim McEachern (ATIS) presented this proposed baseline, which proposes an outline for a technical report that would consider the broad problem of authentication for non-IP traffic and provide a framework for consideration of proposed mechanisms. A proposal was made to establish a small group that would meet separate to discuss this topic and advance work on this subject. Further information will be sent to the mailing list. Agreement Reached: This contribution was accepted as modified in IPNNI-2020-00082R001 as a new baseline for this newly accepted topic. REVIEW OF ISSUE STATUS/TARGET RESOLUTION DATESIPNNI-2020-00030R004, IP-NNI Document TrackerThis contribution was not discussed. IPNNI-2020-00003R001, SHAKEN Progress TrackerThis contribution was not discussed. FUTURE WORK/ASSIGNMENTS/MEETINGSThe following virtual meetings were noted:IPNNI: Monday, May 18, 10am-1pm ETPTSC: Wednesday, May 6, 10am-2pm ETThe following F2F meetings were noted:Q3: Week of August 10 – Denver, CO (preferred)/ Philadelphia, PA / Seattle, WA Q4: Reston, VA [TNS] ANY OTHER BUSINESSIPNNI-2020-00078R000, 911/SHAKENMs. Reese reviewed the open issues contained in this presentation, which was previously reviewed on the joint IP-NNI TF/ESIF/WTSC meeting on 911/SHAKEN. Impact of RPH signing/authentication on HTTP signingRequest/Response and verificationRequest/Response messagesA participant posted the following question: considering most implementations have to do with large SIP messages/headers (at least NSEP RPH), what if a call with RPH, SHAKEN, and div gets a failed verification on the SHAKEN side, but the RPH is validated? If so, the call goes through as a priority call, since it is NSEP; RPH takes precedence. NSEP initially did not include SHAKEN signing, but was added due to the possibility of terminating to a carrier that does not understand RPH signing. Since this is a high-probability service with the combination of STIR/SHAKEN signing, RPH, and A attestation, even if RPH got dropped the probability of those calls going through would be high. For 911, being able to pass information about that telephone number is useful for analytics, which can use that information to counter TDoS attacks on emergency networks. A question was raised about what the anticipated behavior is if a call fails terminating into a network that does not support RPH or STIR/SHAKEN. Even if the network does not support RPH, they still receive the STIR/SHAKEN information. If that fails, then it falls to local policy. If the number changes, the original signing TN gets dropped and the server with whatever calling number it gets changed to re-signs and also adds a STIR/SHAKEN signing with an updated “from” – like back-to-back relay, not a divert; a new call comes out. Action Item: Martin Dolly (AT&T) will set up a meeting with interested parties to generate a proposal for the next meeting. Action Item: Mary Retka (Somos) will bring in a contribution on toll-free calls in the SHAKEN framework. Handling of 911 originations with non-dialable callback numbers911 calls can be identified by RPH, as well as a unique, SHAKEN-compatible 10-digit TN composed of a 911 prefix and seven digits. The number populated in the callback field is non-dialable. Non-dialable numbers are different than unregistered phones; with non-dialable numbers there is some information available, whereas unregistered numbers have no information available. If it is a 10-digit number that can be canonicalized, then it technically could pass STIR/SHAKEN specifications. A TDoS attack is an issue with radio access, not the emergency public network. A proposal was made to create a new attestation level for 911 calls, separate from the existing levels A, B, and C – perhaps “unknown”. These calls only go to an emergency network. This would not change implementations except for emergency networks, where changes would be necessary for emergency calls using the CSCF function. A comment was made that there is already a 911-related specification; why not use that and sign the unique numbers on the origid of the RPH passport and treat it like it is always validated? Why use two identity headers when RPH is already present, which is specific to 911? 911 is passed to CVT in order to protect against TDoS attacks. If calls originate from a TN repeatedly over a period of time, a protection buffer into the PSAP can be created before having to hit a human resource, which would create a bottleneck. The RPH contains a 911 area code telephone number, which effectively constitutes a unique identifier for that device. A question was raised on whether calls from an unregistered device would receive B or C attestations. Unregistered numbers can be either roamers or phones without SIM cards. If someone has a SIP trunk with an enterprise and calls 911 without a calling number, how would that call be signed, from a SHAKEN perspective? If the PBX is your customer, then that call would receive a B attestation. Attestation levels cannot be assigned without a TN. A note was made that emergency networks already have TDoS mitigation built into the network. A suggestion was made to eliminate STIR/SHAKEN on calls to emergency networks, to avoid uncertainty. Action Item: Martin Dolly (AT&T), Terry Reese (Ericsson), Chris Wendt (Comcast), Robert Dianda (Charter), Greg Schumacher (T-Mobile), and Jim McEachern (ATIS) will work on a proposal on STIR/SHAKEN for emergency networks to bring to the IP-NNI TF. Handling of 911 originations from roamersThe basis of Know Your Customer is that carriers need to have a business relationship to allow anyone to roam on each other’s networks. Based on the roaming agreement, there is a contract: when that UE attaches, there will be a query from the home network’s MME to the guest network’s HHS. The guest HHS downloads the subscriber’s info, so calls placed from the roamer receive A attestation. If there is no roaming agreement in place, the roamer is treated as an unregistered device. Handling of callback calls with private calling (PSAP) TNs3GPP still needs to make updates to 24.229, including on SIP URI. Verstat values are accepted in 3GPP 24.229; header parameters are registered by 3GPP. Verstat is already registered as a tel URI parameter. Participants noted that IETF likely will not consider making these changes. Conveyance of RPH assertion valuesLeave as is: populate appropriate assertion value before it sends signingRequest associated with RPH to STI-AS. Ms. Reese will incorporate these conclusions into the RPH baseline (IPNNI-2020-000010R003) and update the presentation (IPNNI-2020-00078R000) that was reviewed during the joint IP-NNI TF/ESIF/WTSC meeting on April 28, 2020.Non-IP scenariosParticipants were informed that any inquiries or interest in non-IP scenarios should be directed to Jim McEachern (ATIS). ADJOURNMENTMr. Dolly thanked participants for attending and adjourned the meeting at 3:35 PM ET on April 29, 2020. ___________________________________________________________Notes submitted by:Anna Karditzas, ATIS Committee Coordinator ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download