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

From: Alan Johnston <[email-masked]>
Date: Fri, 9 Sep 2011 10:39:25 -0500

Dale,

Thanks for your comments.  See mine below.  I have updated the draft
based on your comments.

- Alan -

On Wed, Aug 24, 2011 at 1:17 PM, Worley, Dale R (Dale)
<[email-masked]> wrote:
> 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.

You are correct.

  (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.

I have used your description.

>
> 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".

I have changed all the references to originating 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.
>

I have used this language.

> 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.

I have rewritten it to remove the second include:

"SIP messages covered by this include INVITE requests and end-to-end
responses to the INVITE, i.e. 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.

Done.

>
> 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.  [...]

Added the and.

>
> 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.

Done.

>
> 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.
>

Done.

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

I have used your text.

>
> 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.

The answer depends on the mechanism.  I think the discussion of to
what extend these security requirements can be met in a realistic SIP
deployment should be in the requirements document.

>
> Dale
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>