Re: [stir] RFC 8224

[Christer Holmberg <[e-mail]>]

Hi,

Maybe the problem with the To header is the phone-context parameter. The RFC 8224 procedures do not cover the presence of the parameter: the parameter is not removed, nor is it added to the tn. And, the generic SIP canonicalization procedures does not remove the parameter either.

Regards,

Christer

From: Zerr, Brad <[e-mail]>
Sent: keskiviikko 7. huhtikuuta 2021 18.26
To: Chris Wendt <[e-mail]>; Christer Holmberg <[e-mail]>
Cc: 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

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/2.0
To: sip:*99;phone-context=[e-mail];user=phone
From: 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
Route: 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
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]
P-Asserted-Identity: tel:xxxxxxxxx
Proxy-Authorization: Digest uri=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
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;orig-ioi=ims.mncxxx.mccxxxx.3gppnetwork.org
User-Agent: Ericsson MTAS - CXP2010134/1 R20F14
P-Charging-Function-Addresses: ccf="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
P-Served-User: 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]<mailto:[e-mail]>>
Sent: Wednesday, April 7, 2021 10:10 AM
To: Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Cc: Zerr, Brad <[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]>>; 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

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

…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

…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

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
....

is fine, but dialing directly an extension would be:

....
To: 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
>
> It should be this
>
> To: 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
Profile: 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<https://protect2.fireeye.com/v1/url?k=f73bbf9b-a8a08749-f73bff00-866132fe445e-a64fcf54962ba2b5&q=1&e=84936e3c-4199-4e8a-8f63-382196b5c5e3&u=http%3A%2F%2Fwww.mimecast.com%2F>
________________________________