Re: [stir] RFC 8224

Marc Petit-Huguenin <marc@petit-huguenin.org> Wed, 21 April 2021 15:10 UTC

Return-Path: <marc@petit-huguenin.org>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CAC3A2B76 for <stir@ietfa.amsl.com>; Wed, 21 Apr 2021 08:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5, WEIRD_QUOTING=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ht1856lVVEWC for <stir@ietfa.amsl.com>; Wed, 21 Apr 2021 08:10:07 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844893A2B74 for <stir@ietf.org>; Wed, 21 Apr 2021 08:10:07 -0700 (PDT)
Received: from [IPv6:2601:648:8400:8e7d:d250:99ff:fedf:93cd] (unknown [IPv6:2601:648:8400:8e7d:d250:99ff:fedf:93cd]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 68D65AE21E; Wed, 21 Apr 2021 17:10:02 +0200 (CEST)
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
To: Roman Shpount <roman@telurix.com>, "Peterson, Jon" <jon.peterson=40team.neustar@dmarc.ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>, "Toy, Arthur" <atoy@tnsi.com>, IETF STIR Mail List <stir@ietf.org>, Cullen Jennings <fluffy@iii.ca>, Christer Holmberg <christer.holmberg@ericsson.com>, Chris Wendt <chris-ietf@chriswendt.net>, "Zerr, Brad" <BZerr@tnsi.com>
References: <DM6PR15MB4108EDAC1D320CA0132CFFE3C8779@DM6PR15MB4108.namprd15.prod.outlook.com> <AM0PR07MB38605E6633E95419244D696193759@AM0PR07MB3860.eurprd07.prod.outlook.com> <DM6PR15MB4108B0D599C3319A140113B3C8749@DM6PR15MB4108.namprd15.prod.outlook.com> <AM0PR07MB3860CD5984E899362BE7833493749@AM0PR07MB3860.eurprd07.prod.outlook.com> <DM6PR15MB410820BCCADE717BE76BF53FC8749@DM6PR15MB4108.namprd15.prod.outlook.com> <AM0PR07MB3860BB92288C2BCF00B7633E93749@AM0PR07MB3860.eurprd07.prod.outlook.com> <DM6PR15MB41089C5F2D124EDE43252E2DC8749@DM6PR15MB4108.namprd15.prod.outlook.com> <AM0PR07MB38604B120B9D1264EA9468D693749@AM0PR07MB3860.eurprd07.prod.outlook.com> <F53A0233-30E4-4CB1-B176-676443C96237@chriswendt.net> <DM6PR15MB4108B0A2531BD2AEBE838867C8499@DM6PR15MB4108.namprd15.prod.outlook.com> <82A3D2D6-F066-4C1F-9CAC-6314D6232805@chriswendt.net> <710508DF-BE69-44E7-8704-CDC8B98E3259@team.neustar> <CAD5OKxt9UfMr4oSt7PUcJ9Bx+MTEM8NTyQnLmGw4Omn_9yTa1g@mail.gmail.com>
Message-ID: <a869cc7e-2197-a29a-a940-e1b497b84396@petit-huguenin.org>
Date: Wed, 21 Apr 2021 08:10:00 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CAD5OKxt9UfMr4oSt7PUcJ9Bx+MTEM8NTyQnLmGw4Omn_9yTa1g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/XfyxP3P6ynltRz8youki-Qo2UbM>
Subject: Re: [stir] RFC 8224
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2021 15:10:13 -0000

I think that the issue is not how to canonicalize these dialstrings -- RFC 8224 is already telling us what to do, and that's also the case for numbers like "*55".  The problem is that these dialstring should not even be signed in the first place, and that's what is missing in RFC 8224.

Basically there should be an additional step that says phone numbers that are not already E.164 numbers (in a SIP URI with a user=phone extension, or in a TEL URI), they should be rejected by the authentication service.  As it is written, RFC 8224 accepts everything and try to canonicalize, which is IMO the issue.

In concrete terms:

- Bullet points 2 and 3 of section 8.3 should be removed.
- Section 8.3 should add a paragraph that says that there is a 3rd category beyond Telephone Numbers and URIS: Non-routeable Telephone Numbers (NTN), and that if an INVITE contains an NTN then the INVITE should be rejected.
- Bullet points 2 and 3 of section 8.3 should be reworked as informative text that explains what a service *before* the authentication service could do with such rejection -- which can be 1) bypassing the authentication service, 2) convert the NTN into a routable number and resubmit it to the authentication service or 3) propagate the rejection back to the caller.


On 4/20/21 8:10 AM, Roman Shpount wrote:
> I have a border question: What if the destination is phone number +
> extension as in sip:+11231231212%231212@provider.com? The portion after the
> # has no meaning for transit providers but can be interpreted by the
> destination PBX.
> 
> Best regards.
> _____________
> Roman Shpount
> 
> 
> On Tue, Apr 20, 2021 at 10:50 AM Peterson, Jon <jon.peterson=
> 40team.neustar@dmarc.ietf.org> wrote:
> 
>>
>>
>> I certainly think it was the intention of the canonicalization procedures
>> to resolve dial strings into globally routable numbers. While there are
>> always going to be some exceptions to this (service codes is an example, or
>> certain non-geographic freephone numbers, say), I think Chris is hitting on
>> the right point here. We sign calls so that a relying party on the
>> terminating side can validate them. If what the relying party receives is a
>> dial string that has no meaning in their network, what are we accomplishing?
>>
>>
>>
>> Jon Peterson
>>
>> Neustar, Inc.
>>
>>
>>
>> *From: *Chris Wendt <chris-ietf@chriswendt.net>
>> *Date: *Tuesday, April 20, 2021 at 7:22 AM
>> *To: *"Zerr, Brad" <BZerr@tnsi.com>
>> *Cc: *Christer Holmberg <christer.holmberg@ericsson.com>om>, Marc
>> Petit-Huguenin <marc@petit-huguenin.org>rg>, Cullen Jennings <fluffy@iii.ca>ca>,
>> IETF STIR Mail List <stir@ietf.org>rg>, Eric Rescorla <ekr@rtfm.com>om>,
>> "Peterson, Jon" <jon.peterson@team.neustar>ar>, "Toy, Arthur" <atoy@tnsi.com>
>> *Subject: *Re: [stir] RFC 8224
>>
>>
>>
>> Hi Brad,
>>
>>
>>
>> I think maybe you are addressing the local mechanics since you are likely
>> focused on getting implementation correct, but i’m asking more high level
>> about why we are signing dialing codes as a dest, when this is application
>> specific and there is no chance this will mean anything to a terminating
>> provider or customer across NNI interface.  In fact, seems like a real
>> potential security threat, which is why i’d like to get some feedback on
>> whether i’m not seeing why this would be potentially useful in the case of
>> STIR generically let alone STIR/SHAKEN specifically.
>>
>>
>>
>> -Chris
>>
>>
>>
>> On Apr 19, 2021, at 4:33 PM, Zerr, Brad <BZerr@tnsi.com> wrote:
>>
>>
>>
>> Good afternoon, Chris.
>>
>>
>>
>> I am a visual person, so thought it would be nice to lead off with the
>> call flow scenario to put this into context.  This is a pretty typical call
>> flow scenario for ADC (abbreviated dialing codes / short codes).  I fit
>> into the green box below.  As you can see, there is a lot of escaping and
>> putting # back into the correct fields.
>>
>>
>>
>> <image001.png>
>>
>>
>>
>> *From:* Chris Wendt <chris-ietf@chriswendt.net>
>> *Sent:* Monday, April 19, 2021 2:48 PM
>> *To:* Christer Holmberg <christer.holmberg@ericsson.com>
>> *Cc:* Zerr, Brad <BZerr@tnsi.com>om>; Marc Petit-Huguenin <
>> marc@petit-huguenin.org>gt;; Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail
>> List <stir@ietf.org>rg>; Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <
>> jon.peterson@neustar.biz>gt;; Toy, Arthur <atoy@tnsi.com>
>> *Subject:* Re: [stir] RFC 8224
>>
>>
>>
>> Hi Brad, All,
>>
>>
>>
>> 1000082 is a technical report and not a normative document, however
>> doesn’t mean that fixes can’t or shouldn’t happen, but you or the folks
>> that participate should bring this back to IPNNI group.
>>
>>
>>
>> But maybe to take it up a level, I’m still struggling why you are sending
>> this dial string, signed back to a peering point.  I’m just wondering do we
>> have something broken here and is this an IETF stir issue or IPNNI issue.
>>
>>
>>
>> Since this is IETF list, can anyone justify why we want to sign sip:*99 as
>> dest for any general SIP scenario?
>>
>>
>>
>> I really think part of STIR/SHAKEN initiative should be thinking about
>> what telephone identity is being used in To/From/PAID, and it think this is
>> something that needs cleaning up, especially across NNI, but i would argue
>> even intra network too, but I realize that is harder argument.
>>
>>
>>
>> So, not sure i’m missing something, but i’m a little puzzled why others
>> are not questioning this as well, thus i’m asking the question.
>>
>>
>>
>> -Chris
>>
>>
>>
>>
>> On Apr 8, 2021, at 4:25 PM, Christer Holmberg <
>> christer.holmberg@ericsson.com> wrote:
>>
>>
>>
>> Hi,
>>
>>
>>
>> I am not making ATIS contributions, but I am sure there is someone else
>> who can help you with that :)
>>
>>
>>
>> I still think the processing of the phone-context parameter is a question
>> mark, though. Maybe we need to add some text somewhere (unless I’ve missed
>> it).
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>>
>> *From:* Zerr, Brad <BZerr@tnsi.com>
>> *Sent:* torstai 8. huhtikuuta 2021 22.56
>> *To:* Christer Holmberg <christer.holmberg@ericsson.com>om>; Marc
>> Petit-Huguenin <marc@petit-huguenin.org>rg>; Chris Wendt <
>> chris-ietf@chriswendt.net>
>> *Cc:* Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>;
>> Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>;
>> Toy, Arthur <atoy@tnsi.com>
>> *Subject:* RE: [stir] RFC 8224
>>
>>
>>
>> Fyi.  Something like this in the document (ATIS-1000074 or 1000082) may go
>> a long way:
>>
>>
>>
>> <image001.png>
>>
>>
>>
>> *From:* Christer Holmberg <christer.holmberg@ericsson.com>
>> *Sent:* Thursday, April 8, 2021 2:34 PM
>> *To:* Zerr, Brad <BZerr@tnsi.com>om>; Marc Petit-Huguenin <
>> marc@petit-huguenin.org>gt;; Chris Wendt <chris-ietf@chriswendt.net>
>> *Cc:* Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>;
>> Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>;
>> Toy, Arthur <atoy@tnsi.com>
>> *Subject:* RE: [stir] RFC 8224
>>
>>
>>
>> Hi Brad,
>>
>>
>>
>> You take the telephone number from the To header, and place it into the
>> “dest”/”tn” claim of the PASSport.
>>
>>
>>
>> But, unfortunately # has to be escaped in the To header, and un-escaped in
>> the “dest”/”tn” claim, so you need to do a escaped-to-un-escaped conversion
>> when placing the phone number in the PASSport.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>>
>>
>>
>>
>>
>> *From:* Zerr, Brad <BZerr@tnsi.com>
>> *Sent:* torstai 8. huhtikuuta 2021 22.27
>> *To:* Christer Holmberg <christer.holmberg@ericsson.com>om>; Marc
>> Petit-Huguenin <marc@petit-huguenin.org>rg>; Chris Wendt <
>> chris-ietf@chriswendt.net>
>> *Cc:* Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>;
>> Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>;
>> Toy, Arthur <atoy@tnsi.com>
>> *Subject:* RE: [stir] RFC 8224
>>
>>
>>
>> Hi Christer,
>>
>>
>>
>> Can you describe how you determine that.  According to ATIS-1000074-E, the
>> destination claim “tn” states to use the To header.
>>
>>
>>
>> <image002.png>
>>
>>
>>
>> *From:* Christer Holmberg <christer.holmberg@ericsson.com>
>> *Sent:* Thursday, April 8, 2021 2:21 PM
>> *To:* Zerr, Brad <BZerr@tnsi.com>om>; Marc Petit-Huguenin <
>> marc@petit-huguenin.org>gt;; Chris Wendt <chris-ietf@chriswendt.net>
>> *Cc:* Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>;
>> Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>;
>> Toy, Arthur <atoy@tnsi.com>
>> *Subject:* Re: [stir] RFC 8224
>>
>>
>>
>> Hi Brad,
>>
>>
>>
>> The ATIS text you reference is not for the To header.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>>
>> Get Outlook for iOS
>> <https://urldefense.com/v3/__https://aka.ms/o0ukef__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm4_Mp3zA$>
>> ------------------------------
>>
>> *From:* Zerr, Brad <BZerr@tnsi.com>
>> *Sent:* Thursday, April 8, 2021 10:16:44 PM
>> *To:* Christer Holmberg <christer.holmberg@ericsson.com>om>; Marc
>> Petit-Huguenin <marc@petit-huguenin.org>rg>; Chris Wendt <
>> chris-ietf@chriswendt.net>
>> *Cc:* Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>;
>> Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>;
>> Toy, Arthur <atoy@tnsi.com>
>> *Subject:* RE: [stir] RFC 8224
>>
>>
>>
>> Hi all,
>>
>>
>>
>>  From previous conversations, it was recommended that the # character in
>> the TO header needed to be escaped with %23
>>
>>
>>
>> To: sip:%2355;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
>> mcc312.3gppnetwork.org
>> <https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$>
>> ;user=phone
>>
>>
>>
>> This seems to be at odds with ATIS 1000082 stating what the allowed
>> characters are.  As you can see below from 1000082, the % is not as part of
>> this list.
>>
>>
>>
>> Recommendations?
>>
>>
>>
>> <image003.png>
>>
>>
>>
>> *From:* Christer Holmberg <christer.holmberg@ericsson.com>
>> *Sent:* Wednesday, April 7, 2021 4:00 PM
>> *To:* Marc Petit-Huguenin <marc@petit-huguenin.org>rg>; Zerr, Brad <
>> BZerr@tnsi.com>gt;; Chris Wendt <chris-ietf@chriswendt.net>
>> *Cc:* Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>;
>> Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>;
>> Toy, Arthur <atoy@tnsi.com>
>> *Subject:* RE: [stir] RFC 8224
>>
>>
>>
>> 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:+1xxxxxxxxxx@ims.mncxxxx.mccxxx.3gppnetwork.org;tag=p65539t1617
>>>>>>> 20
>>>>>>> 6731m169121c110882s1_1220390100-1617434405
>>>>>>> orig2: sip:xxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org
>>>>>>> orig3: tel:xxxxxxxxx <xxxxxxxxx>
>>>>>>>
>>>>>>> The destination is always in the To header:
>>>>>>>
>>>>>>> dest:
>>>>>>> sip:*99;phone-context=ims.mncxxx.mccxxx.3gppnetwork.org@ims.mncxxx.
>>>>>>> mc
>>>>>>> cxxx.3gppnetwork.org
>> <https://urldefense.com/v3/__http://cxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmPaMNhOA$>
>> ;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
>> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=7c40792e-23db4012-7c4039b5-86b1886cfa64-568f8cb842251179&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fims.mncxxx.mccxxx.3gppnetwork.org*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm9qz1or8$>
>>>>>>>
>>>>>>> orig1 and orig2 are canonicalized using section 8.5. The input is
>> the whole URI:
>>>>>>>
>>>>>>> orig1: sip:+1xxxxxxxxxx@ims.mncxxxx.mccxxx.3gppnetwork.org
>>>>>>> orig2: ip:xxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org
>>>>>>
>>>>>> 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:
>>>>
>>>> It is part of the user part.
>>>>
>>>> When user=phone is present, the user part is encoded as a
>> telephone-subscriber (RFC 2806), which may contain a phone-context.
>>>
>>> Right, I was thinking of user=phone.
>>>
>>> phone-context and the other parameters are removed when applying the
>> first bullet point in 8.3.
>>
>> well, the bullet only talks about specific characters, which means numeric
>> characters of the phone-context would remain...
>>
>> I think there should be explicit text about tel-URL parameters (in
>> addition to phone-context there are also others).
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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 <BZerr@tnsi.com>
>>>>>> Sent: keskiviikko 7. huhtikuuta 2021 18.26
>>>>>> To: Chris Wendt <chris-ietf@chriswendt.net>et>; Christer Holmberg
>>>>>> <christer.holmberg@ericsson.com>
>>>>>> Cc: Marc Petit-Huguenin <marc@petit-huguenin.org>rg>; Cullen Jennings
>>>>>> <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>; Eric Rescorla
>>>>>> <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>; Toy,
>>>>>> Arthur <atoy@tnsi.com>
>>>>>> 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=imsmncXXXmccXXXXgppnetworkorg@ims.mnc
>>>>>> x x x.mcc3xxx.3gppnetwork.org
>> <https://urldefense.com/v3/__http://x.mcc3xxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm2TTnri4$>;user=phone
>> SIP/2.0
>>>>>> To:
>>>>>> sip:*99;phone-context=ims.mncxxx.mccxxx.3gppnetwork.org@ims.mncxxx.
>>>>>> m
>>>>>> c
>>>>>> cxxx.3gppnetwork.org
>> <https://urldefense.com/v3/__http://cxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmPaMNhOA$>
>> ;user=phone
>>>>>> From:
>>>>>> sip:+1xxxxxxxxxx@ims.mncxxxx.mccxxx.3gppnetwork.org;tag=p65539t1617
>>>>>> 2
>>>>>> 0
>>>>>> 6731m169121c110882s1_1220390100-1617434405
>>>>>> Call-ID: p65539t1617206731m169121c110882s2
>>>>>> CSeq: 1 INVITE
>>>>>> Max-Forwards: 66
>>>>>> Content-Length: 896
>>>>>> Via: SIP/2.0/TCP
>>>>>> xxxxxxxxxx:5060;branch=z9hG4bK1a5ca0b3c42536a59ddec4c723f8774fk5555
>>>>>> 5
>>>>>> 5 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%
>>>>>> 2
>>>>>> B
>>>>>> xxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%
>>>>>> 4
>>>>>> 0 ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr
>>>>>> Record-Route:
>>>>>> sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2EObabaeaaaaamsip%3A%2Bxxxxxxx%40ims.
>>>>>> m
>>>>>> ncxxx.mccxxx.3gppnetwork.org@scscf2.ims.mncxxxx.mccxxxx.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:xxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org
>>>>>> P-Asserted-Identity: tel:xxxxxxxxx <xxxxxxxxx>
>>>>>> Proxy-Authorization: Digest
>>>>>> uri=sip:*99;phone-context=ims.mnc4xxx.mccxxx.3gppnetwork.org@ims.mn
>>>>>> c
>>>>>> x
>>>>>> xx.mccxxx.3gppnetwork.org
>> <https://urldefense.com/v3/__http://xx.mccxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmrKVq_1I$>
>> ;user=phone,response="",nonce="",realm="",
>>>>>> u
>>>>>> s
>>>>>> ername=xxxxxxxxxxxxxx@ims.mncxxx.mcc3xxx.3gppnetwork.org<mailto:xxx
>>>>>> x x xxxxxxxxx@ims.mncxxx.mcc3xxx.3gppnetwork.org>
>>>>>> P-Visited-Network-ID: ims.mnc420.mcc312.3gppnetwork.org
>> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=34ec8226-6b77bb1a-34ecc2bd-86b1886cfa64-e171fd55781981c8&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fims.mnc420.mcc312.3gppnetwork.org*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm_E69mA8$>
>>>>>> P-Access-Network-Info:
>>>>>> 3GPP-E-UTRAN-FDD;local-time-zone="2021-03-31T11:05:31-05:00";utran-
>>>>>> c
>>>>>> e
>>>>>> ll-id-3gpp=xxxxxxxxxxxxxxxxxxxxxxxx
>>>>>> Min-SE: 900
>>>>>> Session-Expires: 1800
>>>>>> P-Charging-Vector:
>>>>>> icid-value=pcscf2.ims.mncxxx.mcc3xxx.3gppnetw-1617-206731-149675;ic
>>>>>> i
>>>>>> d
>>>>>> -generated-at=pcscf2.ims.mncxxx.mccxxx.3gppnetwork.org
>> <https://urldefense.com/v3/__http://ims.mncxxx.mccxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmzkbVY5k$>
>> ;orig-ioi=ims.
>>>>>> m
>>>>>> ncxxx.mccxxxx.3gppnetwork.org
>> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=eeef46a8-b1747f94-eeef0633-86b1886cfa64-e50d414254cbb27d&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fncxxx.mccxxxx.3gppnetwork.org*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmmgQ1NYU$>
>>>>>> User-Agent: Ericsson MTAS - CXP2010134/1 R20F14
>>>>>> P-Charging-Function-Addresses: ccf="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
>>>>>> P-Served-User:
>>>>>> sip:xxxxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org;sescase=orig;regs
>>>>>> t
>>>>>> a
>>>>>> te=reg
>>>>>> Feature-Caps: *;+g.3gpp.registration-token="<63b9cf28>"
>>>>>> P-Early-Media: supported
>>>>>> Session-ID: 7c386176b888d13d404845e189d6885b
>>>>>>
>>>>>> From: Chris Wendt
>>>>>> <chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>>
>>>>>> Sent: Wednesday, April 7, 2021 10:10 AM
>>>>>> To: Christer Holmberg
>>>>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.c
>> <christer.holmberg@ericsson.com%3cmailto:christer.holmberg@ericsson.c%0b>>>>>
>> o
>>>>>> m
>>>>>>>>
>>>>>> Cc: Zerr, Brad <BZerr@tnsi.com<mailto:BZerr@tnsi.com>>; Marc
>>>>>> Petit-Huguenin
>>>>>> <marc@petit-huguenin.org<mailto:marc@petit-huguenin.org>>; Cullen
>>>>>> Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>>; IETF STIR Mail List
>>>>>> <stir@ietf.org<mailto:stir@ietf.org>>; Eric Rescorla
>>>>>> <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Jon Peterson
>>>>>> <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>; Toy,
>>>>>> Arthur <atoy@tnsi.com<mailto:atoy@tnsi.com>>
>>>>>> 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 <
>> christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> ´*´ can be used as such in a SIP-URI, but ‘#’ would have to be
>> escaped.
>>>>>>
>>>>>> So:
>>>>>>
>>>>>> To:
>>>>>> sip:*55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
>>>>>> m
>>>>>> c
>>>>>> c312.3gppnetwork.org
>> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
>> ;user=phone
>>>>>>
>>>>>> …is ok, but;
>>>>>>
>>>>>> To:
>>>>>> sip:#55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
>>>>>> m
>>>>>> c
>>>>>> c312.3gppnetwork.org
>> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
>> ;user=phone<sip:*55;phone-context=ims.mnc420.mc
>> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=de790f19-81e23625-de794f82-86b1886cfa64-8040fe565ed6c82c&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fims.mnc420.mc*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmXz7Bjus$>
>>>>>> c
>>>>>> 3 12.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone>
>>>>>>
>>>>>> …is NOT ok. Instead:
>>>>>>
>>>>>> To:
>>>>>> sip:%2355;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
>>>>>> mcc312.3gppnetwork.org
>> <https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$>
>> ;user=phone
>>>>>>
>>>>>> …will have to be used.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Zerr, Brad <BZerr@tnsi.com<mailto:BZerr@tnsi.com>>
>>>>>> Sent: keskiviikko 7. huhtikuuta 2021 14.27
>>>>>> To: Christer Holmberg
>>>>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.c
>> <christer.holmberg@ericsson.com%3cmailto:christer.holmberg@ericsson.c%0b>>>>>
>> o
>>>>>> m
>>>>>>>> ; Marc Petit-Huguenin
>>>>>> <marc@petit-huguenin.org<mailto:marc@petit-huguenin.org>>; Cullen
>>>>>> Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>>; IETF STIR Mail List
>>>>>> <stir@ietf.org<mailto:stir@ietf.org>>
>>>>>> Cc: chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>;
>>>>>> Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Jon Peterson
>>>>>> <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>; Toy,
>>>>>> Arthur <atoy@tnsi.com<mailto:atoy@tnsi.com>>
>>>>>> 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=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
>>>>>> m
>>>>>> c
>>>>>> c312.3gppnetwork.org
>> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
>> ;user=phone
>>>>>>
>>>>>> To:
>>>>>> sip:#55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
>>>>>> m
>>>>>> c
>>>>>> c312.3gppnetwork.org
>> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
>> ;user=phone<sip:*55;phone-context=ims.mnc420.mc
>> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=8b69ba29-d4f28315-8b69fab2-86b1886cfa64-770258b0ccf0eabc&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fims.mnc420.mc*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmuZBnGaY$>
>>>>>> c
>>>>>> 3 12.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone>
>>>>>>
>>>>>> From: Christer Holmberg
>>>>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.c
>> <christer.holmberg@ericsson.com%3cmailto:christer.holmberg@ericsson.c%0b>>>>>
>> o
>>>>>> m
>>>>>>>>
>>>>>> Sent: Wednesday, April 7, 2021 3:14 AM
>>>>>> To: Marc Petit-Huguenin
>>>>>> <marc@petit-huguenin.org<mailto:marc@petit-huguenin.org>>; Cullen
>>>>>> Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>>; Zerr, Brad
>>>>>> <BZerr@tnsi.com<mailto:BZerr@tnsi.com>>; IETF STIR Mail List
>>>>>> <stir@ietf.org<mailto:stir@ietf.org>>
>>>>>> Cc: chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>;
>>>>>> Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Jon Peterson
>>>>>> <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>; Toy,
>>>>>> Arthur <atoy@tnsi.com<mailto:atoy@tnsi.com>>
>>>>>> 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=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
>>>>>> m
>>>>>> c
>>>>>> c312.3gppnetwork.org
>> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
>> ;user=phone
>>>>>> ....
>>>>>>
>>>>>> is fine, but dialing directly an extension would be:
>>>>>>
>>>>>> ....
>>>>>> To: sip:+14085550460%2377@example.org;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 <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>>
>>>>>>> On Behalf Of Cullen Jennings
>>>>>>> Sent: tiistai 6. huhtikuuta 2021 15.30
>>>>>>> To: Zerr, Brad <BZerr@tnsi.com<mailto:BZerr@tnsi.com>>; IETF STIR
>>>>>>> Mail List <stir@ietf.org<mailto:stir@ietf.org>>
>>>>>>> Cc: chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>;
>>>>>>> Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Jon Peterson
>>>>>>> <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>; Toy,
>>>>>>> Arthur <atoy@tnsi.com<mailto:atoy@tnsi.com>>
>>>>>>> Subject: Re: [stir] RFC 8224
>>>>>>>
>>>>>>>
>>>>>>> Adding to STIR mailing list …
>>>>>>>
>>>>>>>
>>>>>>> On Apr 5, 2021, at 9:19 AM, Zerr, Brad <
>> BZerr@tnsi.com<mailto:BZerr@tnsi.com<mailto:BZerr@tnsi.com%3cmailto:BZerr@tnsi.com
>> <BZerr@tnsi.com%3cmailto:BZerr@tnsi.com%3cmailto:BZerr@tnsi.com%3cmailto:BZerr@tnsi.com>>>>
>> 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=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
>>>>>>> m
>>>>>>> cc312.3gppnetwork.org
>> <https://urldefense.com/v3/__http://cc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmfRONVeE$>
>> ;user=phone
>>>>>>>
>>>>>>> It should be this
>>>>>>>
>>>>>>> To:
>>>>>>> sip:%2A55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc4
>>>>>>> 2
>>>>>>> 0
>>>>>>> .mcc312.3gppnetwork.org
>> <https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$>
>> ;user=phone
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>
>>
>>
>>


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