Re: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

"DOLLY, MARTIN C" <md3135@att.com> Tue, 17 September 2019 16:35 UTC

Return-Path: <md3135@att.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48D91209EB for <dispatch@ietfa.amsl.com>; Tue, 17 Sep 2019 09:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Level:
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 x-nZnW5511n5 for <dispatch@ietfa.amsl.com>; Tue, 17 Sep 2019 09:35:40 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CCFA1209D3 for <dispatch@ietf.org>; Tue, 17 Sep 2019 09:35:40 -0700 (PDT)
Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x8HGRFHv008266; Tue, 17 Sep 2019 12:35:38 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 2v32mp9f74-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Sep 2019 12:35:35 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x8HGTjF0013298; Tue, 17 Sep 2019 12:29:45 -0400
Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x8HGTbGi013139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Sep 2019 12:29:37 -0400
Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id 41A1A16A3ED; Tue, 17 Sep 2019 16:29:37 +0000 (GMT)
Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (unknown [130.9.129.152]) by zlp27125.vci.att.com (Service) with ESMTPS id 292F616A3EB; Tue, 17 Sep 2019 16:29:37 +0000 (GMT)
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.197]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0468.000; Tue, 17 Sep 2019 12:29:36 -0400
From: "DOLLY, MARTIN C" <md3135@att.com>
To: Richard Barnes <rlb@ipv.sx>
CC: "Kaustubh Inamdar (kinamdar)" <kinamdar@cisco.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt
Thread-Index: AQHVbW3pd1QU+6QSIkSbaFE6OKqaVKcwD1M3
Date: Tue, 17 Sep 2019 16:29:35 +0000
Message-ID: <945E6F87-006C-4F4F-829A-C19E44DBEAE4@att.com>
References: <156825995534.13361.10232150689686123584.idtracker@ietfa.amsl.com> <DB05AE1C-7CD4-4BC6-BABB-2E8070CA29FB@cisco.com>, <CAL02cgR94hQOD-iiAdHe+Xr9+LZWcTDJv7RoxsjmNDZnwgbO-w@mail.gmail.com>
In-Reply-To: <CAL02cgR94hQOD-iiAdHe+Xr9+LZWcTDJv7RoxsjmNDZnwgbO-w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_945E6F87006C4F4F829AC19E44DBEAE4attcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-17_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909170155
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/H6efu1SV3ORVCryHHN2IlS5v6Jo>
Subject: Re: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Sep 2019 16:35:48 -0000

How does this fit with SIP CONNECT?

Martin C. Dolly
Lead Member of Technical Staff
Government & Services Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: md3135@att.com<mailto:md3135@att.com>

On Sep 17, 2019, at 11:38 AM, Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote:

I gave this draft a quick skim, and it seems sensible..  I'm not an expert in the configuration / setup of SIP trunks, but I do love automating manual processes (cf. ACME), and this draft seems like a plausible approach to automating things about SIP trunk configuration that are currently manual.

Couple of things that jumped out to me on a quick skim, in no particular order:

1. It would be good to have a tighter requirement for HTTPS in here..  For example, on the one hand, you have "it is required to secure HTTP using Transport Layer Security", but on the other hand, "MUST support the use of the https uri scheme" (not MUST use).  There is no reason to support unencrypted HTTP.  You can probably borrow some language from RFC 8555 https://tools.ietf.org/html/rfc8555#section-6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8555-23section-2D6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=XpLJRHudftgf9TYF395MAR923aZyfVyPb3j2gK8qDZ4&e=>

2. "Capability set documents MUST be formatted in XML or JSON" -- Why do you need both?

3. OAuth2 seems like overkill for this application.  OAuth2 is designed for a 3-party flow where authorization is being delegated; there are only two entities here.  It would be much simpler to just use some point-to-point authentication technique, such as TLS client certificates or even HTTP/SIP Digest authentication.

4. The WebFinger utilization here also seems like overkill.  Once you take out the OAuth2, you're just discovering a single URL -- at which point you might as well configure that directly!  In general, this document needs to specify (1) what configuration the client is presumed to start out with, and (2) how that information is used to auto-configure the trunk.  Cf. in ACME, "Each function is listed in a directory along with its corresponding URL, so clients only need to be configured with the directory URL."  It seems like all you really need here is a capability server URL and a certificate / password.

5. The relation types defined using "https://sipserviceprovider/<https://urldefense.proofpoint.com/v2/url?u=https-3A__sipserviceprovider_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=Nh0orXmFGB5EP87BbYzaB8LyrcQTu6_dDxUhpmpjSPA&e=>" need to be changed to something else.  While that's syntactically a URL, it isn't actually.  If you need a URI that isn't dereferenceable, please provide some URNs here.

--RLB







On Mon, Sep 16, 2019 at 9:31 PM Kaustubh Inamdar (kinamdar) <kinamdar@cisco.com<mailto:kinamdar@cisco.com>> wrote:
Hi All,
The following draft has been posted to dispatch. The draft aims to simplify peering between enterprise and service provider SIP networks. Discussions/comments are welcome.

-Kaustubh






    A new version of I-D, draft-kinamdar-dispatch-sip-auto-peer-00.txt
    has been successfully submitted by Cullen Jennings and posted to the
    IETF repository.

    Name:               draft-kinamdar-dispatch-sip-auto-peer
    Revision:   00
    Title:              Automatic Peering for SIP Trunks
    Document date:      2019-09-10
    Group:              Individual Submission
    Pages:              35
    URL:            https://www.ietf.org/internet-drafts/draft-kinamdar-dispatch-sip-auto-peer-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer-2D00.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=Q2zoz-rVzYoAPa1kAMOGqftJUWccXmkX8DAjNHO9MJQ&e=>
    Status:         https://datatracker.ietf.org/doc/draft-kinamdar-dispatch-sip-auto-peer/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=fcIx3co5agjP22REJR49X4c1pZoZgJEkbg3jjwt8eL0&e=>
    Htmlized:       https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=Tuzvwn9LD2APXpkJVHbzlTI7iXO3efPuikuGMp7Zabg&e=>
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-kinamdar-dispatch-sip-auto-peer<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=JGyQBNt1jPbfCcoLY9whz90UF1FEstsr-O3Cre3qCBQ&e=>



    Abstract:
       This draft specifies a configuration workflow to enable enterprise
       Session Initiation Protocol (SIP) networks to solicit the capability
       set of a SIP service provider network.  The capability set can
       subsequently be used to configure features and services on the
       enterprise edge element, such as a Session Border Controller (SBC),
       to ensure smooth peering between enterprise and service provider
       networks.




    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=hxxdnH1hOeFSij1s6a3ZjWpMO8A18PTrzUiyAbfVP0M&e=>.

    The IETF Secretariat



_______________________________________________
dispatch mailing list
dispatch@ietf.org<mailto:dispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/dispatch<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dispatch&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=zAFTXA1XJJYHFhi3WKkswkBsybSNo3bLJ3G0nP428FU&e=>
_______________________________________________
dispatch mailing list
dispatch@ietf.org<mailto:dispatch@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dispatch&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=zAFTXA1XJJYHFhi3WKkswkBsybSNo3bLJ3G0nP428FU&e=