Document: draft-ietf-speermint-voip-consolidated-usecases-13 (Note: The IETF Last Call was issued for version 12 - since version 13 was available, I reviewed it instead)  Reviewer: Spencer Dawkins IETF LC End Date: 2009-07-08 Review Date: 2009-07-23 (late!) IESG Telechat date: (not known)  Summary: This draft is almost ready for publication as an Informational RFC. I identified some minor questions (listed below). The ones I'd really like for Russ to think about are in Section 7 (Security Considerations).  I also made suggestions to improve clarity, but these should not slow the document approval process down, unless Russ thinks some o of them are important.  1.  Introduction     Only use cases related to VoIP are considered in this document.    Other real-time SIP communications use cases, like Instant Messaging    (IM) and presence are out of scope for this document.  In describing    use cases, the intent is descriptive, not prescriptive.  Spencer (clarity): I would suggest "These use cases are descriptive, not prescriptive" for the last sentence in this paragraph.     The use cases contained in this document attempts to be as    comprehensive as possible, but should not be considered the exclusive    set of use cases.  3.  Reference Architecture     Originating SSP (O-SSP) is the SSP originating a request.  Spencer (clarity): at this point in the document, it's not clear whether a "request" is a SIP request or a request to discover a peer, determine a next hop, etc. Could you add an adjective (probably either "SIP request" or something like "peering request")?     Terminating SSP (T-SSP) is the SSP terminating the request    originating from O-SSP.  Assisting LUF and LRF Provider offers LUF    and LRF services to O-SSP.  Indirect SSP (I-SSP) is the SSP providing    indirect peering service(s) to O-SSP to connect to T-SSP.     Note that in Figure 1 - some elements defined are optional in many    use cases.  Spencer (clarity): I would suggest "some elements included in Figure 1 are optional".  4.  Contexts of Use Cases     o  Next Hop Routing Determination - Resolving the SED information is       necessary to route the request to the T-SSP.  The LRF is used for       this determination.  The O-SSP may also use the standard procedure  Spencer (minor): is this "The O-SSP may also use" or "Alternatively, the O-SSP may use"? The text says "in addition to", but I'm thinking you mean "instead of".        defined in [RFC3263] to discover the next hop address.     o  Call setup - SSPs that are interconnecting to one another may also       define specifics on what SIP features need to be used when  Spencer (minor): are these SIP features? I'm thinking something more like "what unique interconnection parameters of this SIP peering arrangement must to be used", but you guys would be better at rephrasing, if you agree with the comment. For example, I'm not thinking port numbers are "SIP features"...        contacting the next hop in order to a) reach the next hop at all       and b) to prove that the sender is a legitimate peering partner.        Examples: hard-code transport (TCP/UDP/TLS), non-standard port       number, specific source IP address (e.g. in a private Layer-3       network), which TLS client certificate [RFC4366] to use, and other       authentication schemes.     o  Call reception - This step serves to ensure that the type of       relationship (static or on-demand, indirect or direct) is       understood and acceptable.  For example, the receiving SBE needs       to determine whether the INVITE it received really came from a       trusted member possibly via an access control list entry.  Spencer (clarity): I think the sentence would be clearer if it ended "came from a trusted member."  5.  Use Cases     Please note there are intra-domain message flows within the use cases    to serve as supporting background information.  Only inter-domain    communications are germane to Speermint.  Spencer (minor): I understand what you're saying, but as an RFC, this document will outlive the SPEERMINT working group. Perhaps "germane to this document"?  5.2.  Static Direct Peering Use Case     This is the simplest form of a peering use case.  Two SSPs negotiate    and agree to establish a SIP peering relationship.  The peer    connection is statically configured and is direct between the    connected SSPs.  The peers may exchange interconnection parameters  Spencer (clarity): I would suggest "and the peer SSPs are directly connected".     such as DSCP [RFC2474] policies, the maximum number of requests per    second and proxy location prior to establishing the interconnection.    Typically, the T-SSP only accepts traffic originating directly from    the trusted peer.          Note that UAC inserted its Fully Qualified Domain Name (FQDN) in         the VIA and CONTACT headers.  This example assumes that UAC has         its own FQDN.  In the deployment where UAC does not have its own         FQDN, UAC may insert an IP address into the headers.  Spencer (clarity): I would suggest c/its Fully/its own Fully/ in the first sentence, and dropping the second.     2.   UAC only knows UAS's TN but not UAS's domain.  It appends its  Spencer (clarity): I would suggest "UAC knows UAS's TN, but does not know UAS's domain". Similar text appears in other use cases below.          own domain to generate the SIP URI in Request-URI and TO header.         O-Proxy checks the Request-URI and discovers that the Request-         URI contains user parameter "user=phone".  This parameter         signifies that the Request-URI is a phone number.  So O-Proxy         will extract the TN from the Request-URI and query LUF for SED         information from a routing database.  In this example, the LUF         is an ENUM [RFC3761] database.  The ENUM entry looks similar to         this:     7.   O-SBE sends the INVITE to T-SBE.  O-SBE is the egress point to         the O-SSP domain, so it should ensure subsequent mid-dialog         requests traverse via itself.  If O-SBE chooses to act as a         Back-to-Back User Agent (B2BUA) [RFC3261], it will terminate the  Spencer (clarity): Your terminology is correct, but this sentence uses "terminate" to mean something different from what "terminate" means in the rest of the document. You just say "generate a new INVITE request in step 10 below - perhaps s/terminate the call and//? This sentence also appears in other use cases later in the document.          call and generate a new INVITE request.  If O-SBE chooses to act         as a proxy, it should record-route to stay in the call path.  In         this example, O-SBE is a B2BUA.     12.  RTP is established between the UAC and UAS.  Note that the media         passes through O-DBE and T-DBE.  Spencer (clarity): Is this "In this example, the media passes through O-DBE and T-DBE"? The text sounds like this always happens. The text in 5.3 is clearer that this is optional.  5.2.2.  Options and Nuances     In Figure 2 O-SSP and T-SSP peer via SBEs.  Normally, the operator    will deploy the SBE at the edge of its administrative domain.  The    signaling traffic will pass between two networks through the SBEs.    The operator has many reasons to deploy a SBE.  For example, either    proxy and UA may use [RFC1918] addresses that are not routable in the  Spencer (clarity): is this "either operator's proxies and/or UAs may use [RFC1918] addresses that are not routable in the other operator's network"? I'm confused by "either proxy and UA", at any rate.     target network.  The SBE can perform a NAT function.  Also, the SBE    eases the operation cost for deploying or removing Layer-5 network    elements.  Consider the deployment architecture where multiple    proxies connect to a single SBE.  An operator can add or remove a    proxy without coordinating with the peer operator.  The peer operator    "sees" only the SBE.  As long as the SBE is maintained in the path,    the peer operator does not need to be notified.     SBE deployment is a decision within an administrative domain.  Either    one or both administrative domains can decide to deploy SBE(s).  To    the peer network, most important is to identify the next-hop address.  Spencer (clarity): suggest for this sentence "This decision does not affect the peer network's ability ability to identify the next-hop address"     Whether the next-hop is a proxy or SBE, the peer network will not see    any difference.  5.3.  Static Direct Peering Use Case - Assisting LUF and LRF     The call flow looks almost identical to Static Direct Peering Use    Case except Step 2,4,5 and 6 which happen in LUF/LRF provider  Spencer (clarity): suggest "except that Steps 2, 4, 5 and 6 involve the LUF/LRF provider" - and I'm not sure "remotely" is needed with this change.     remotely instead of happening in O-SSP domain.  5.3.1.  Administrative Characteristics     The LUF/LRF provider provides the LUF and LRF services for the O-SSP.    As such, LUF/LRF provider, O-SSP and T-SSP form a trusted  Spencer (clarity): I'd suggest s/As such/Taken together/     administrative domain.  To reach T-SSP, O-SSP must still require pre-    arranged agreements for the peer relationship with T-SSP.  The    Layer-5 policy is maintained in the O-SSP and T-SSP domains, and the    LUF/LRF provider may not be aware of any Layer-5 policy between the    O-SSP and T-SSP.     A LUF/LRF provider can serve multiple administrative domains.  The    LUF/LRF provider typically does not share SED from one administrative    domain to another administrative domain without appropriate    permission granted.  Spencer (clarity): I'd suggest s/ granted//  5.3.2.  Options and Nuances     The LRF/LRF provider can use multiple methods to provide SED to    O-SSP.  The most commonly used are an ENUM and a SIP Redirect.  The  Spencer (clarity): is this "an ENUM lookup and a SIP Redirect"?     O-SSP should negotiate with the LUF/LRF provider which query method    it will use prior to sending request to LUF/LRF provider.     The T-SSP needs to populate its users' AORs and SED to the LUF/LRF    provider.  Currently, this procedure is non-standardized and labor  Spencer (clarity): is this "The LUF/LRF provider must be populated with the T-SSP's users' AORs and SED"?     intensive.  A more detailed description of this problem has been    documented in the work in progress [I-D.ietf-drinks-cons-rqts].  5.4.  Static Indirect Peering Use Case - Assisting LUF and LRF     The difference between a Static Direct Use Case and a Static Indirect    Use Case lies within the Layer-5 relationship of which O-SSP and    T-SSP maintain.  In the Indirect use case, the O-SSP and T-SSP do not  Spencer (clarity): I'd suggest s/of which O-SSP and T-SSP maintain/maintained by the O-SSP and T-SSP/     have direct Layer-5 connectivity.  They require one or multiple    Indirect Domains to assist routing the SIP messages and possibly the    associated media.     In this use case, the O-SSP and T-SSP want to form a peer    relationship.  For some reason, the O-SSP and T-SSP do not have    direct Layer-5 connectivity.  The reasons may vary, for example    business demands and/or domain policy controls.  Due to this indirect    relationship the signaling will traverse from O-SSP to one or  Spencer (clarity): I'd suggest s/to/through/ (to reflect "traverse")     multiple I-SSP(s) to reach T-SSP.     In addition, O-SSP decides to use a LUF/LRF provider.  This LUF/LRF  Spencer (clarity): I'd suggest s/decides to use/is using/     provider stores the T-SSP's SED pre-populated by T-SSP.  One    important motivation to use the LUF/LRF provider is that T-SSP only    needs to populate its SED once to the provider.  Any O-SSP who wants  Spencer (clarity): I'd suggest "Using a LUF/LRF provider allows the T-SSP to populate its SED once, while any O-SSP who wants ..."     to query T-SSP's SED can use this LUF/LRF provider.  Current practice    has shown that it is rather difficult for the T-SSP to populate its    SED to every O-SSP who likes to reach the T-SSP's subscribers.  This  Spencer (clarity): I'd suggest s/likes to/must/     is especially true in the Enterprise environment.          Note that the response shows the next-hop is the SBE in Indirect         SSP.  Spencer (nit): I'd suggest s/Indirect SSP/I-SSP/  5.4.1.  Administrative characteristics     In this use case. there are two levels of trust relationship.  First    trust relationship is between the O-SSP and LUF/LRF provider.  The    O-SSP trusts the LUF/LRF to provide the T-SSP's SED.  Second trust    relationship is between O-SSP and I-SSP.  The O-SSP trusts the I-SSP    to provide Layer-5 connectivity to assist the O-SSP to reach T-SSP.    The O-SSP and I-SSP have a pre-arranged agreement for policy.  Note    that Figure 4 shows a single provider to provide both LUF/LRF and    I-SSP, O-SSP can choose two different providers.  Spencer (clarity): suggest s/I-SSP, O-SSP/I-SSP, but O-SSP/  5.5.  Static Indirect Peering Use Case     This use case O-SSP uses its internal LUF/LRF.  One of the reasons of  Spencer (clarity): suggest "In this use case, O-SSP uses its internal LUF/LRF".     using internal LUF/LRF is to control the routing database.  By    controlling the database, O-SSP can apply different routing rules and    policies to different T-SSPs.  For example, O-SSP can use I-SSP1 and    Policy-1 to reach T-SSP1, and use I-SSP2 and Policy-2 to reach    T-SSP2.  Note that there could be multiple I-SSPs and multiple SIP    routes to reach the same T-SSP; this is out of scope of Speermint and    has become a focus in the IETF DRINKS working group.  Spencer (minor): again, this document as an RFC will outlive both working groups...  5.5.1.  Administrative characteristics     T-SSP <---> I-SSP = Relationship T-I     In the T-I relationship, typical policies, features or functions    observed consist of codec "scrubbing", anonymizing, and transcoding.    I-SSP must record-route and stay in the signaling path.  T-SSP will    not accept message directly sent from O-SSP.  Spencer (nit): suggest s/message directly sent/messages sent directly/  5.5.2.  Options and Nuances     In Figure 5, we show I-DBE.  Using I-DBE is optional.  One scenario    the I-DBE can be used is when the O-SSP and T-SSP do not have a  Spencer (clarity): Suggest s/One scenario the I-DBE can be used/For example, the I-DBE might be used/     common codec.  To involve I-DBE, I-SSP should know the list of codec  Spencer (nit): s/codec/codecs/     supported by O-SSP and T-SSP.  When I-SBE receives the INVITE    request, it will make a decision to invoke the I-DBE.  Another    scenario an I-DBE can be used is if O-SSP uses SRTP [RFC3711] for  Spencer (clarity): suggest "An I-DBE might also be used if"     media and T-SSP does not support SRTP.  5.6.  On-demand Peering Use Cases     On-demand Peering [RFC5486] describes two SSPs form the peering  Spencer (clarity): suggest a/describes two/describes how two/     relationship without a pre-arranged agreement.     The basis of this use case is built on the fact that there is no pre-    established relationship between the O-SSP and T-SSP.  The O-SSP and    T-SSP does not share any information prior to the dialog initiation    request.  When the O-Proxy invokes the LUF and LRF on the Request-    URI, the terminating user information must be publicly available.    Besides, when the O-Proxy routes the request to the T-Proxy, the  Spencer (clarity): suggest s/Besides, when/When/     T-Proxy must accept the request without any pre-arranged agreement    with O-SSP.  5.6.1.  Administrative characteristics     The On-demand Direct Peering Use Case is typically implemented in a    scenario where the T-SSP allows any O-SSP to reach its serving    subscribers.  T-SSP administrative domain does not require any pre-    arranged agreement to accept the call.  The T-SSP makes its    subscribers information available in public.  This model mimics the  Spencer (clarity): is this "publicly available"?     Internet email model.  Sender does not need an pre-arranged agreement    to send email to the receiver.  5.6.2.  Options and Nuances     Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP    can decide to deploy SBE.  Since T-SSP is open to the public, T-SSP    is considered to be in higher security risk than static model because    there is no trusted relationship between O-SSP and T-SSP.  T-SSP    should protect itself from any attack launch by untrusted O-SSP.  Spencer (clarity): suggest s/launch/launched/  7.  Security Considerations     This document introduces no new security consideration.  However, it  Spencer (minor): I'm not sure what "new" refers to here - is this "beyond RFC 3263", or "beyond ENUM", or ... ?     is important to note that session interconnect, as described in this    document, has a wide variety of security issues that should be    considered in documents addressing both protocol and use case    analyzes.  [I-D.niccolini-speermint-voipthreats] discuss the  Spencer (minor): couldn't parse "use case analyzes" in this sentence.  Spencer (minor): I'm wondering if the last sentence in this paragraph is enough ("look at the other draft")?     different security threats related to VoIP peering.  8.  IANA Considerations     This document creates no new requirements on IANA namespaces    [RFC5226].  Spencer (clarity): we often include "Note to RFC Editor: please delete this section before publication" for null IANA sections, as Russ commented on one of MY recent drafts :-)