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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf