Re: [stir] RFC 8224

[Chris Wendt <[e-mail]>]

We’ve definitely had various discussions about relevant To and From and PAID in context of orig and dest in the past, not with total agreement, although i've advocated that perhaps STI-AS should normalize as best practice to make rules of 8224 verification work correctly on terminating side in these cases.  *55 is not something that seems relevant to escape an originating SIP network in any case.  But interesting to see if i start a war here :)

> On Apr 7, 2021, at 11:26 AM, Zerr, Brad <[e-mail]> wrote:
> 
> Hi Chris,
>  
> Here is a little background that got this conversation going. 
>  
> One of our customers sent us a SIP INVITE so we could perform the Stir-Shaken Signing for them.  The customer performed the translations on their MMTEL TAS to translate *55 to a 10 digit number.  When we receive the SIP INVITE for signing, it had the REQ-URI with the 10 digit number and the TO header with *55, see below.  Our applications rejected this because of the TO header (whether it is right or wrong is to be determined).  So we start questioning how * and # short codes should be handled.
>  
> FYI, I “x” out information to keep anonymous
>  
> INVITE sip:+xxxxxxxxxx;phone-context=[e-mail];user=phone <sip:+xxxxxxxxxx;phone-context=[e-mail];user=phone>SIP/2.0
> To: sip:*99;phone-context=[e-mail];user=phone <sip:*99;phone-context=[e-mail];user=phone>
> From: sip:[e-mail];tag=p65539t1617206731m169121c110882s1_1220390100-1617434405 <sip:[e-mail];tag=p65539t1617206731m169121c110882s1_1220390100-1617434405>
> Call-ID: p65539t1617206731m169121c110882s2
> CSeq: 1 INVITE
> Max-Forwards: 66
> Content-Length: 896
> Via: SIP/2.0/TCP xxxxxxxxxx:5060;branch=z9hG4bK1a5ca0b3c42536a59ddec4c723f8774fk555555yaaaaacaaaaaaaaaaaaa3Zqkv7yujk3t0qbaaiaiaaaaabqaaaaaaaqaaaaaa
> Via: SIP/2.0/TCP xxxxxxx:5082;branch=z9hG4bK1220390081-337970536
> Route: sip:xxxx.cgah.ims.mncxxx.mccxxx.3gppnetwork.org;callhalf=orig;lr <sip:xxxx.cgah.ims.mncxxx.mccxxx.3gppnetwork.org;callhalf=orig;lr>
> Route: sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A%2Bxxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%40ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr <sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A%2Bxxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%40ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr>
> Record-Route: sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2E[e-mail]:5060;maddr=xxxxxxxxx;lr <sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2E[e-mail]:5060;maddr=xxxxxxxxx;lr>
> Contact: sip:p65539t1617206731m169121c110882s1@xxxxxxxx:5082;+g.3gpp.accesstype="cellular";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel <sip:p65539t1617206731m169121c110882s1@xxxxxxxx:5082;+g.3gpp.accesstype=%22cellular%22;+g.3gpp.icsi-ref=%22urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel>"
> Content-Type: application/sdp
> Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
> Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
> Supported: timer, 100rel, path, precondition, replaces
> P-Asserted-Identity: sip:[e-mail] <sip:[e-mail]>
> P-Asserted-Identity: tel:xxxxxxxxx <tel:xxxxxxxxx>
> Proxy-Authorization: Digest uri=sip:*99;phone-context=[e-mail];user=phone <sip:*99;phone-context=[e-mail];user=phone>,response="",nonce="",realm="",username=[e-mail] <mailto:[e-mail]>
> P-Visited-Network-ID: ims.mnc420.mcc312.3gppnetwork.org <http://ims.mnc420.mcc312.3gppnetwork.org/>
> P-Access-Network-Info: 3GPP-E-UTRAN-FDD;local-time-zone="2021-03-31T11:05:31-05:00";utran-cell-id-3gpp=xxxxxxxxxxxxxxxxxxxxxxxx
> Min-SE: 900
> Session-Expires: 1800
> P-Charging-Vector: icid-value=pcscf2.ims.mncxxx.mcc3xxx.3gppnetw-1617-206731-149675;icid-generated-at=pcscf2.ims.mncxxx.mccxxx.3gppnetwork.org <http://ims.mncxxx.mccxxx.3gppnetwork.org/>;orig-ioi=ims.mncxxx.mccxxxx.3gppnetwork.org <http://ims.mncxxx.mccxxxx.3gppnetwork.org/>
> User-Agent: Ericsson MTAS - CXP2010134/1 R20F14
> P-Charging-Function-Addresses: ccf="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
> P-Served-User: sip:[e-mail] <sip:[e-mail]>;sescase=orig;regstate=reg
> Feature-Caps: *;+g.3gpp.registration-token="<63b9cf28>"
> P-Early-Media: supported
> Session-ID: 7c386176b888d13d404845e189d6885b
>  
> From: Chris Wendt <[e-mail]> 
> Sent: Wednesday, April 7, 2021 10:10 AM
> To: Christer Holmberg <[e-mail]>
> Cc: Zerr, Brad <[e-mail]>; Marc Petit-Huguenin <[e-mail]>; Cullen Jennings <[e-mail]>; IETF STIR Mail List <[e-mail]>; Eric Rescorla <[e-mail]>; Jon Peterson <[e-mail]>; Toy, Arthur <[e-mail]>
> Subject: Re: [stir] RFC 8224
>  
> This is a legit question for RFC8224 and agree with the answers, but just in case it’s relevant you would not send these types of SIP URIs as dest in context of STIR/SHAKEN (over NNI/peering relationship) which only supports tel URIs currently.  That may not be your use-case but just wanted to clarify in case it was relevant.  I would be curious to know the context if you are willing to share though, i am guessing intra network use case between device and app server?  Definitely interested in those cases, for me in context of delegate certs.
>  
> -Chris
> 
> 
> On Apr 7, 2021, at 9:52 AM, Christer Holmberg <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi,
>  
> ´*´ can be used as such in a SIP-URI, but ‘#’ would have to be escaped.
>  
> So:
>  
> To: sip:*55;phone-context=[e-mail];user=phone <sip:*55;phone-context=[e-mail];user=phone>
>  
> …is ok, but;
>  
> To: sip:#55;phone-context=[e-mail];user=phone <sip:*55;phone-context=[e-mail];user=phone>
>  
> …is NOT ok. Instead:
>  
> To: sip:%2355;phone-context=[e-mail];user=phone <sip:%2355;phone-context=[e-mail];user=phone>
>  
> …will have to be used.
>  
> Regards,
>  
> Christer
>  
>  
>  
> From: Zerr, Brad <[e-mail] <mailto:[e-mail]>> 
> Sent: keskiviikko 7. huhtikuuta 2021 14.27
> To: Christer Holmberg <[e-mail] <mailto:[e-mail]>>; Marc Petit-Huguenin <[e-mail] <mailto:[e-mail]>>; Cullen Jennings <[e-mail] <mailto:[e-mail]>>; IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; Eric Rescorla <[e-mail] <mailto:[e-mail]>>; Jon Peterson <[e-mail] <mailto:[e-mail]>>; Toy, Arthur <[e-mail] <mailto:[e-mail]>>
> Subject: RE: [stir] RFC 8224
>  
> Good Morning.
>  
> Would you mind providing an example of what the TO header should look like for both a * and # dial to help clear up?  Assume they are leading characters in the TO header.
>  
> Example of what is being sent today:
>  
> To: sip:*55;phone-context=[e-mail];user=phone <sip:*55;phone-context=[e-mail];user=phone>
>  
> To: sip:#55;phone-context=[e-mail];user=phone <sip:*55;phone-context=[e-mail];user=phone>
>  
> From: Christer Holmberg <[e-mail] <mailto:[e-mail]>> 
> Sent: Wednesday, April 7, 2021 3:14 AM
> To: Marc Petit-Huguenin <[e-mail] <mailto:[e-mail]>>; Cullen Jennings <[e-mail] <mailto:[e-mail]>>; Zerr, Brad <[e-mail] <mailto:[e-mail]>>; IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; Eric Rescorla <[e-mail] <mailto:[e-mail]>>; Jon Peterson <[e-mail] <mailto:[e-mail]>>; Toy, Arthur <[e-mail] <mailto:[e-mail]>>
> Subject: RE: [stir] RFC 8224
>  
> Hi,
> 
> >I think the question was about the format to use before canonicalization.
> >
> >My understanding of RFC 3986 is that `#` should be escaped because it is the delimiter for an URI fragment. Fragments are not defined in SIP URIs, but a generic URI parser may still remove everything after and including '#'.
> 
> "#" will have to be escaped in a SIP-URI, e.g., in a To header field.
> 
> But, Section 8.3 of RFC 8224 has nothing to do with a SIP-URI or the To header field.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> OTOH there is no need to escape '*' as it is part of the `sub-delims` rule.
> 
> so
> 
> ....
> To: sip:*55;phone-context=[e-mail];user=phone <sip:*55;phone-context=[e-mail];user=phone>
> ....
> 
> is fine, but dialing directly an extension would be:
> 
> ....
> To: sip:[e-mail];user=phone <sip:[e-mail];user=phone>
> ....
> 
> On 4/6/21 5:43 AM, Christer Holmberg wrote:
> > Hi,
> > 
> > %2A is not the ASCII format of *, it is the escaped (see RFC 3261).
> > 
> > And, the syntax allows both * and #, so no need to escape (in fact, it is not even possible to escape in this case):
> > 
> > tn-spec = 1*tn-char
> > tn-char = "#" / "*" / DIGIT
> > 
> > Also, note that RFC 8224 does not define the syntax of the To header field - that is done in RFC 3261. The telephone number described in Section 8.3 of RFC 8224 will be included in the PASSPort (RFC 8225).
> > 
> > Regards,
> > 
> > Christer
> > 
> > From: stir <[e-mail] <mailto:[e-mail]>> On Behalf Of Cullen Jennings
> > Sent: tiistai 6. huhtikuuta 2021 15.30
> > To: Zerr, Brad <[e-mail] <mailto:[e-mail]>>; IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>
> > Cc: [e-mail] <mailto:[e-mail]>; Eric Rescorla <[e-mail] <mailto:[e-mail]>>; Jon Peterson <[e-mail] <mailto:[e-mail]>>; Toy, Arthur <[e-mail] <mailto:[e-mail]>>
> > Subject: Re: [stir] RFC 8224
> > 
> > 
> > Adding to STIR mailing list …
> > 
> > 
> > On Apr 5, 2021, at 9:19 AM, Zerr, Brad <[e-mail]<mailto:[e-mail] <mailto:[e-mail]%3cmailto:[e-mail]>>> wrote:
> > 
> > Good Morning.
> > 
> > This may not be the correct process, so let me know if I should ask this in a different forum.
> > 
> > I had a question regarding section 8.3 when it comes to * and # handling. Is this stating that when a * or # proceeds a digit string (i.e. *55), it should be in ASCI Format for the * (i.e. %2A)
> > 
> > <image001.png>
> > 
> > So Instead of this:
> > 
> > To: sip:*55;phone-context=[e-mail];user=phone <sip:*55;phone-context=[e-mail];user=phone>
> > 
> > It should be this
> > 
> > To: sip:%2A55;phone-context=[e-mail];user=phone <sip:%2A55;phone-context=[e-mail];user=phone>
> > 
> > 
> > 
> 
> 
> -- 
> Marc Petit-Huguenin
> Email: [e-mail] <mailto:[e-mail]>
> Blog: https://protect2.fireeye.com/v1/url?k=980fc57b-c794fc4a-980f85e0-86e2237f51fb-d778e82319b4f5fa&q=1&e=032f1e9f-0aed-459c-b48f-5a5bb8a74467&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F <https://protect2.fireeye.com/v1/url?k=980fc57b-c794fc4a-980f85e0-86e2237f51fb-d778e82319b4f5fa&q=1&e=032f1e9f-0aed-459c-b48f-5a5bb8a74467&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F>
> Profile: https://www.linkedin.com/in/petithug <https://www.linkedin.com/in/petithug>
>  
> 
> This e-mail message is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information of Transaction Network Services.
> Any unauthorized reviews, use, disclosure or distribution is prohibited. If you are not
> the intended recipient, please contact the sender by reply e-mail and destroy all copies
> of the original message.
> 
> 
> 
> This email has been scanned for email related threats and delivered safely by Mimecast.
> For more information please visit http://www.mimecast.com <https://protect2.fireeye.com/v1/url?k=637df9a8-3ce6c0ad-637db933-86959e472243-f3817145c048b8e8&q=1&e=c8cf1527-7ed0-445d-a2d9-6e029fd3a549&u=http%3A%2F%2Fwww.mimecast.com%2F>
>  
> 
> 
> This e-mail message is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information of Transaction Network Services.
> Any unauthorized reviews, use, disclosure or distribution is prohibited. If you are not
> the intended recipient, please contact the sender by reply e-mail and destroy all copies
> of the original message.
> 
> 
> This email has been scanned for email related threats and delivered safely by Mimecast.
> For more information please visit http://www.mimecast.com <http://www.mimecast.com/>