Subject: Gen-ART Review of draft-ietf-speermint-voip-consolidated-usecases-13

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 24 Jul 2009 20:51:25 +0200

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 :-)

---

From: "Yiu L. Lee" <[email-masked]>
Date: Sun, 26 Jul 2009 07:00:32 -0400

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