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

["Kaustubh Inamdar (kinamdar)" <[e-mail]>]

Hi Richard,

Thanks for going over the draft, please find my responses inline:


From: Richard Barnes <[e-mail]>
Date: Tuesday, 17 September 2019 at 9:08 PM
To: Kaustubh Inamdar <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

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

Kaustubh: Noted, will go over that section and make the appropriate changes.

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


Kaustubh:  JSON and XML were included to provide flexibility. If however, the larger group favours the use of a single format, we are okay to make the appropriate changes.

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.


Kaustubh: Digest authentication is certainly the easiest client authentication technique. There is/has been little evidence of SIP service providers using client certificates for authentication. The main reason OAuth was chosen was to allow client authentication to be in line with what modern cloud based platforms use.


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.


Kaustubh: Each enterprise network or site within an enterprise is assumed to start off with one of two possible scenarios -



1. The enterprise is provided with the URL of the capability server hosted in the service provider network - this information could be provided by the service provider along with other relevant trunking information such as the username and password combination to use be used while constructing SIP digest responses for 401/407 responses.



2. The enterprise is required to discover the URL of the capability server hosted in the service provider domain. In terms of discovery, the options considered were U-NAPTR and WebFinger. Given the significant deployment trail of WebFinger, it seems to be the best option. Not sure, if there is discovery mechanism embedded in RFC 8555.



In essence, the draft also requires the enterprise to have two fundamental information units to set this framework into motion:



 1. The URL of the capability server

 2. A mechanism for the ITSP to authenticate the enterprise (if at all).


5. The relation types defined using "https://sipserviceprovider/" 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.


Kaustubh: Will look into this one…

--RLB







On Mon, Sep 16, 2019 at 9:31 PM Kaustubh Inamdar (kinamdar) <[e-mail]<mailto:[e-mail]>> 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
    Status:         https://datatracker.ietf.org/doc/draft-kinamdar-dispatch-sip-auto-peer/
    Htmlized:       https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-kinamdar-dispatch-sip-auto-peer



    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<http://tools.ietf.org>.

    The IETF Secretariat



_______________________________________________
dispatch mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dispatch