Subject: [cuss] Second round of WGLC for draft-ietf-cuss-sip-uui-reqs

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 16 Aug 2011 17:19:13 -0500

Folks: Enrico and I will like to issue a second round of
WGLC for the CUSS Problem Statement and Requirements draft
as follows:

   Draft: draft-ietf-cuss-sip-uui-reqs-04.txt
   WGLC period: August 16, 2011 - August 30, 2011

The authors believe that they have addressed the open
issues discussed at IETF-81 (Quebec City).

Please go through the latest version of the draft [1] and
indicate any comments on the list by Aug-30-2011.

[1] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-04.txt

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 24 Aug 2011 14:17:49 -0400

Here are my comments on draft-ietf-cuss-sip-uui-reqs-04.

2.2.  Proxy Retargeting

I am not sure I can tell what the point of this use case is.  I
*think* that the idea is that in this case the proxy is changing the
request-URI, whereas in 2.1, it is silently assumed that the proxy is
not changing the request-URI.  (My practical experience is that
proxies change request-URIs almost all the time, so the default case
of a proxy simply forwarding based on the existing request-URI doesn't
come naturally to mind.)  But there are also unclarities in the
wording.  E.g,., "the terminating UA" vs. "a different termination
UA", but only one terminating UA is shown.

*If* I am right, this would be clearer as:

   In this scenario, the originator UA includes UUI in the INVITE sent
   through a proxy to the terminating UA.  The proxy retargets the
   INVITE, changing its request-URI to a URI that addresses the
   termination UA.  The UUI information is then received and processed
   by the terminating UA.  This call flow is identical to Figure 1
   except that the proxy retargets the request, i.e., changes the
   request-URI as directed by some unspecified process.  The UUI in
   the INVITE needs to be passed unchanged through this proxy
   retargeting operation.

Also, the use of "originator" vs. "originating" and "terminator"
vs. "terminating" is not clear.  My impression is that in telecomm
usage, the latter terms are favored over the former terms; this
document prefers "originator" and "terminator", but also uses
"termination" and "terminating".

2.4.  Referral

I would be a bit clearer to say:

   [...]  In some cases, this call flow is used in place of the
   redirection call flow:  the Referrer immediately answers the call
   and then sends the REFER.  This scenario is shown in Figure 3.

REQ-1

Change "includes" to "include", since the subject of "include" is
"responses":

   SIP messages covered by this include INVITE requests and end-to-
   end responses to the INVITE, which >>>include<<< 18x, 200, and 3xx
   responses.

REQ-6

It reads better changing the "or"s to "and"s:

   REQ-6: The mechanism will support interworking with call control
   related DSS1 information elements, QSIG information elements, and
   ISUP parameters.

REQ-8

The grammar of REQ-8 is not quite correct.  Perhaps this is better:

   REQ-8: The mechanism will allow a UAC to require that a UAS
   understands the call control UUI mechanism in order to have a
   request routed to IT.  [...]

or perhaps the word "and" is omitted here:

   REQ-8: The mechanism will allow a UAC to require that a UAS
   understands the call control UUI mechanism >>>and<<< have a request
   routed based on this information.  [...]

REQ-11

   REQ-11: The solution will provide a mechanism of transporting at
   least 128 octets of user data and a one octet protocol discriminator,
   i.e. 129 octets in total.

I would make explicit that the UUI is a sequence of octets, because
there is no other place where we state the data model we envision for
UUI.  Viz.:

   REQ-11: The UUI is a sequence of octets.  The solution will provide
   a mechanism for transporting at least 128 octets of user data and a
   separate one-octet protocol discriminator, i.e. 129 octets in total.

4.  Security Considerations

The last sentence of the 1st paragraph does not (IMHO) clearly state
what everyone knows that it means.  Perhaps:

   [...]  As such, is important for application users of SIP UUI to
   know the level of security used and deployed in their particular
   SIP environments, and not to assume that a standardized (but
   perhaps rarely deployed) security mechanism is in place.

The following two paragraphs document 3 security approaches, despite
stating that they contain two.  Some revisions:

   There are >>>three<<< main security models that need to be
   addressed by the SIP UUI mechanism.  One model treats the SIP layer
   as untrusted and requires end-to-end integrity protection and/or
   encryption.  This model can be achieved by providing these security
   services at a layer above SIP.  In this case, the application
   integrity protects and/or encrypts the UUI information before
   passing it to the SIP layer.  This method has two advantages: it
   does not assume or rely on end-to-end security mechanisms in SIP
   (which have virtually no deployment), and allows the application
   which understands the contents of the UUI to apply a proper level
   of security.

   >>>A second approach<<< is for the application to pass the UUI without
   any protection to the SIP layer and require the SIP layer to
   provide this security, >>>e.g., through routing requests using sips:
   URIs<<<.  This approach is possible in theory, although its practical
   use would be extremely limited.

    >>>The third model<<< utilizes a trust domain and relies on perimeter
   security at the SIP layer.  This is the security model of the PSTN
   and ISDN where UUI is commonly used today.  This approach uses hop-
   by-hop security mechanisms and relies on border elements for
   filtering and application of policy.  This approach is used today in
   SIP UUI deployments.  >>>Within this approach, there is a
   requirement that intermediary elements can detect and remove a UUI
   element based on policy, but there is no requirement that an
   intermediary element be able to read or interpret the UUI (as the UUI
   contents only have end-to-end significance).<<<

Within these three models, it's not clear to me exactly what the
security requirements (REQ-13, REQ-14, and REQ-15) mean.  Does each
requirement apply within the environment of each model?  And seemingly
the threat model changes between models:  in model 1, the SIP
intermediaries are untrusted; in model 2, the SIP intermediaries seem
to be trusted, but the networks are not trusted; and in model 3, the
"walled garden" network is entirely trusted.

Dale