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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]