Re: [stir] RFC 8224

[Christer Holmberg <[e-mail]>]

Hi,

>1. Section 8.1:
>
>The origin is either in the From header or in the P-Asserted-Identity header, in the example below we have both, but which one to use is a matter of local policy, so we are going to process all 3 (one in the From, two in the PAI):
>
>orig1: sip:[e-mail];tag=p65539t1617206731m169121c110882s1_1220390100-1617434405
>orig2: sip:[e-mail]
>orig3: tel:xxxxxxxxx
>
>The destination is always in the To header:
>
>dest: sip:*99;phone-context=[e-mail];user=phone
>
>2. Section 8.1
>
>Per this section, SIP URIs containing a user=phone parameter or tel URI contain a phone numbers.  Everything else does not contain a phone number.
>
>Here only orig3 and dest contains a phone number, and need to be canonicalized using section 8.3.  The part subject to canonicalization is the user part of the URI:
>
>orig3: xxxxxxxxx
>dest: *99;phone-context=ims.mncxxx.mccxxx.3gppnetwork.org
>
>orig1 and orig2 are canonicalized using section 8.5.  The input is the whole URI:
>
>orig1: sip:[e-mail]
>orig2: ip:[e-mail]

Where in Section 8 is it defined that phone-context is removed?

Regards,

Christer






On 4/7/21 9:54 AM, Christer Holmberg wrote:
> 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.
>>
>> That is not my understanding of RFC 8224 section 8.1 and 8.3.
> 
> What is your understanding?
> 
> 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]
>> x.mcc3xxx.3gppnetwork.org;user=phone SIP/2.0
>> To: 
>> sip:*99;phone-context=[e-mail]
>> cxxx.3gppnetwork.org;user=phone
>> From: 
>> sip:[e-mail];tag=p65539t161720
>> 6731m169121c110882s1_1220390100-1617434405
>> Call-ID: p65539t1617206731m169121c110882s2
>> CSeq: 1 INVITE
>> Max-Forwards: 66
>> Content-Length: 896
>> Via: SIP/2.0/TCP 
>> xxxxxxxxxx:5060;branch=z9hG4bK1a5ca0b3c42536a59ddec4c723f8774fk555555
>> yaaaaacaaaaaaaaaaaaa3Zqkv7yujk3t0qbaaiaiaaaaabqaaaaaaaqaaaaaa
>> 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%2B
>> xxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%40
>> ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr
>> Record-Route: 
>> sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2EObabaeaaaaamsip%3A%2Bxxxxxxx%40ims.m
>> [e-mail].3gppnetwork.o
>> rg: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]
>> xx.mccxxx.3gppnetwork.org;user=phone,response="",nonce="",realm="",us
>> ername=[e-mail]<mailto:xxxxx
>> [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-ce
>> ll-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.m
>> ncxxx.mccxxxx.3gppnetwork.org
>> User-Agent: Ericsson MTAS - CXP2010134/1 R20F14
>> P-Charging-Function-Addresses: ccf="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
>> P-Served-User: 
>> sip:[e-mail];sescase=orig;regsta
>> te=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]
>> c312.3gppnetwork.org;user=phone
>>
>> …is ok, but;
>>
>> To: 
>> sip:#55;phone-context=[e-mail]
>> c312.3gppnetwork.org;user=phone<sip:*55;phone-context=ims.mnc420.mcc3
>> [e-mail];user=phone>
>>
>> …is NOT ok. Instead:
>>
>> To: 
>> sip:%2355;phone-context=[e-mail]420.
>> mcc312.3gppnetwork.org;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]
>> c312.3gppnetwork.org;user=phone
>>
>> To: 
>> sip:#55;phone-context=[e-mail]
>> c312.3gppnetwork.org;user=phone<sip:*55;phone-context=ims.mnc420.mcc3
>> [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]
>> c312.3gppnetwork.org;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]420.m
>>> cc312.3gppnetwork.org;user=phone
>>>
>>> It should be this
>>>
>>> To: 
>>> sip:%2A55;phone-context=[e-mail]420
>>> .mcc312.3gppnetwork.org;user=phone
>>>
>>>
>>>
>>
>>
> 


--
Marc Petit-Huguenin
Email: [e-mail]
Blog: https://protect2.fireeye.com/v1/url?k=96defbb0-c945c281-96debb2b-86e2237f51fb-55bc80b699dc4cf0&q=1&e=601eaa03-95ce-4b90-9575-83c0b1641010&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug