Hi Spencer, Thanks very much for the detailed comments, we will address them after IETF-75. We will also wait for the AD¹s direction before posting a new version.
Thanks, Yiu On 7/24/09 2:51 PM, "Spencer Dawkins" <spen...@wonderhamster.org> wrote: > I have been selected as the General Area Review Team (Gen-ART) reviewer for > this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd or AD before posting a > new version of the draft. > > 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 :-) > >
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
