Re: [stir] RFC 8224

[Marc Petit-Huguenin <[e-mail]>]

On 4/7/21 10:45 AM, Christer Holmberg wrote:
> 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?

It is removed by not being part of the username (or user part) portion of a SIP URI:

8.1:

"First, implementations will ascertain if the user portion of the URI
  constitutes a telephone number.  Telephone numbers most commonly
  appear in SIP header field values in the username portion of a SIP
  URI"

8.3:

"Once an implementation has identified a telephone number, it must
  construct a number string."

"o  Implementations MUST drop any "+"s, internal dashes, parentheses,
     or other non-numeric characters, except for the "#" or "*" keys
     used in some special service numbers"

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


-- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug