datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

A Mechanism for Transporting User to User Call Control Information in SIP
draft-ietf-cuss-sip-uui-15

Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.

Adrian Farrel

Comment (2014-03-13)

The only solution in Section 7 that makes just the UUI opaque to
inspection by transit nodes seems to be the first option...

   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, applications are encouraged to use their own integrity and/or
   encryption mechanisms before passing it to the SIP layer.

This mechanism appears to require that the source and destination
applications have a security association of some sort. The reality of
this is that every pair of applications in the SIPiverse have to
maintain SAs of their own construction.

There would appear to be two options not covered here:
1. The local SIP speaker is responsible for maintaining an SA with the
   remote speaker and for encrypting just the UUI (maybe this is what
   the second option is saying, but it also says "this will not work in
   practice").
2. SIP is enhanced to provide key exchange for the applications.

I don't for a moment propose that this document should be blocked on
this issue, but I would like to hear that some mechanism is being
developed to provide protection for this data.

Barry Leiba

Comment (2014-04-03)

-- Section 4.1 --

   UAs SHOULD ignore UUI data from packages or encoding that they do not
   understand.

That SHOULD seems odd.  What else could they possibly do with things they don't
understand?  It would seem that trying to make sense of something I
fundamentally don't understand could open me up to all sorts of problems,
including security or privacy exposures, no?  If it's a SHOULD, then under what
conditions might one not ignore them, and what would one then do?

UPDATE: Version -15 changes "SHOULD" to "SHALL", addressing this issue.  Thanks
very much for considering my comment.

Benoit Claise

Comment (2014-03-25)

As mentioned by Jouni in his OPS DIR review:

More on the document nits..

** Generic:

o The document assumes that the reader knows a bunch of related acronyms
  (like ISDN, PSTN, UA, SIP, URL, URI, MIME, S/MIME, ISUP, IPsec etc). I
  urge them to be expanded on the first occurrence.

o Mixed use of references. Pick one style. Currently there are:
  - bla bla in RFC 1234 bla bla
  - bla bla in RFC 1234 [RFC1234] bla bla
  - bla bla in [RFC1234] bla bla.

  Be consistent with the referencing style.

o Use of RFC 2119 language. One should check when use "must" or "MUST"
  etc, since currently use of those keywords are mixed even in the
  same sentence.

  Also, in places "shall" is used where I think "SHALL" would be more
  appropriate. Anyway, do the authors try to indicate a difference
  between "shall" and a "must"? In places a sentence using "shall" is
  immediately followed by other sentence using "MUST". Be consistent
  with the requirements language use.

o One thing confuses me slightly though. In Section 3 it is stated that
  proxies and other intermediates are not expected to understand UUI
  data etc. However, later in Sections 4.3 the text about border elements
  (regarding proxies and B2BUAs) indicate that User-to-User and UUI data
  should be understood under a specific context. Maybe this could be
  clarified in Section 3..?

** Section 1:

   "This mechanism was designed to meet the use cases, requirements, and.."
    ^^^^^

It is unclear to what "this" refers to, specifically since the "this" word
begins a new paragraph.

  "The mechanism is a new SIP header field, along with a new SIP option
   tag.  The header field carries the UUI data, along with parameters.."

Which header and which option?

** Section 4.1:

  "The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC 5234 and extends RFC 3261 (where token

o RFC 5234 defines an ABNF not BNF.
o Should it be "updated RFC 3261" and should that also be reflected
  in the document boiler plate?

  "[RFC3515] or the 3xx to the INVITE SHOULD support the UUI mechanism.
                   ^^^^^
o Should it be "3xx response" ?

  "Here is an example of an included User-to-User header field from the
   redirection response F2 of Figure 2:"

o Figure 2 in where? This document does not have any caption with "Figure".

** Section 5:

     "3.  User Agents (UAs) are the generators and consumers of the UUI
      data.  Proxies and other intermediaries may route based on the.."
                                               ^^^^^^^^^^^
o May route what? Requests? Responses?

     "into a request or response.  (The default is one per encoding.)"
                                  ^^^                              ^^^
o Why parenthesis? Consider restructuring the sentence.

** Section 6:

o To my understanding RFC2119 language is not appropriate for IANA
  considerations.

** Section 7:

  "User to user information can potentially carry sensitive information.."
   ^^^^^^^^^^^^

o "User-to-User" since the rest of the document uses that convention.

  "using S/MIME or IPSec can be used, as discussed in the review of.."
         ^^^^^^    ^^^^^
o References missing.

** Section 8:

  "described: MIME body and URI parameter transport."
              ^^^^^
o References missing.

** Section 8.2:

  "However, the CUSS working group believes, consistent with its
   charter, that SIP needs to have its own native UUI data transport
   mechanism.  It is not reasonable for a SIP UA to have to implement.."

o Do not refer to a WG and a charter.. both of these are moving targets
  and will change or vanish during time.

** Section 8.3:

  "not clear how this mechanism could meet REQ-9."

  and

  "As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5,
   REQ-7, REQ-11, REQ-13, and REQ-14.  Meeting REQ-12 seems possible,
   although the authors do not have a specific mechanism to propose.
   Meeting REQ-3 is problematic, but not impossible for this mechanism.
   However, this mechanism does not seem to be able to meet REQ-9."

o It is not clear which requirement defined or discussed where this
  references.. Add references in which document I can find these
  requirements.

** Section 8.4:

  "The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and
   REQ-11.  It is possible the approach could meet REQ-12 and REQ-13.
   The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and
   REQ-14."

o Same comment as for Section 8.3.

** Section 10:

o I do not recall ever seen references starting with Informative instead
  of Normative. I guess this is ok though

Joel Jaeggli

Comment (2014-03-24)

This is not a discuss but I'd observe that I'm a little dissatisfied with the
security considerations section. Of the options enumerated there, option three
is clearly the one frequently employed. It seems like the least adequate, and I
 don't know how sip moves out of that space into actually protecting data
etierh inband or by wrapping the whole thing in a consistent fashion.

Kathleen Moriarty

Comment (2014-03-21)

I support Stephen Farrell's position and have the following additional comments:

In the Security Considerations Section:
On privacy - suggest the following words, change from:
User to user information can potentially carry sensitive information
   that might require privacy or integrity protection from third parties
   that may wish to read or modify the UUI data.
To:
User to user information can potentially carry sensitive information
   that might require confidentiality protection for privacy or integrity
   protection from third parties that may wish to read or modify the UUI data.

Third paragraph:
IPSec should be IPsec

Pete Resnick

Discuss (2014-03-24)

4:

   The "purpose" header field parameter identifies the package
   which defines the generation and usage of the UUI data for a
   particular application.

I think you need to add something like: "The value of the 'purpose' parameter
is the package name, as registered in the uui-packages sub-registry defined in
section 6.3." It took me a while to figure out that that's what you intended.
(I *think* that's what you intended.)

   For the case of interworking with the ISDN
   UUI Service, the ISDN UUI Service interworking package is used.  If
   the "purpose" header field parameter is not present, interworking
   with the ISDN UUI Service MUST be assumed.

This creates a hard dependency on draft-ietf-cuss-sip-uui-isdn, since you are
making ISDN the default. You'll need to move that document to Normative
References if you do that. I think it's best not to do that and instead strike
the sentence and instead say that 'purpose' is REQUIRED.

5:

   UUI packages defined using this SIP UUI mechanism MUST follow the
   "Standards Action" guideline as defined in [RFC5226] and publish a
   standards track RFC which describes the usage.

This seems bogus. First of all, "Standards Action" is a registration guideline,
not a use guideline, so this MUST seems completely wrong. If I want to use a
private-use package I see absolutely no interoperability reason I should be
disallowed from doing so. See comments on section 6 below for more on the
choice of the guideline.

6.3:

"Standards Action" seems like complete overkill. I would like to hear an
explanation of why First Come First Served (FCFS) is not appropriate for these
packages. If I get a package I don't understand, I'm going to ignore it, so if
you want to send (and register) one that is not already defined, I don't see
why you can't just register it. We know that anything more than FCFS does
actual interoperability damage by encouraging the community to do all sorts of
unregistered extensions. What is the problem with doing these things as FCFS,
or maybe "Expert Review"?

6.4:

I don't understand why this needs an IANA registry at all. As far as I can
tell, content is entirely dependent on the package definition. That means that
if I define "foo" content for my package, you could define "foo" content for
your package and there will be no problem with the two names colliding. Why do
you need a registry for these? Is there going to be content that is
package-independent? If so, you may want to explain what those would be like in
section 4.

Comment (2014-03-24)

Abstract: s/The rules which apply for a specific application/The syntax and
semantics for the UUI data used by a specific application/

1:

-  s/A mechanism is defined/It defines a mechanism/

- I don't understand what the following means:

   Note that in most cases, there
   is an a priori understanding between the UAs in regard to what to do
   with received UUI data.

Please explain.

3: This section should be an appendix.

4:

- "MUST be assumed" does not help an implementer. Which end is doing the
assuming? What is the implementation supposed to do once it makes this
"assumption".

Here are my attempts to fix. Feel free to edit:

OLD
   If the "purpose" header field parameter is not present, interworking
   with the ISDN UUI Service MUST be assumed.
NEW
   If the "purpose" header field parameter is not present, the sending
   implementation is indicating that it interworks with the ISDN UUI
   Service and the receiving implementation MUST use the ISDN UUI
   Service.
END

OLD
   If not present, the content MUST be assumed to be the default defined
   for the package.
NEW
        If not present, the default content defined for the package MUST
        be used.
END

OLD
   If the "encoding" header
   field parameter is not present, the encoding MUST be assumed to be
   the default defined for the package.
NEW
   If the "encoding" header field parameter is not present, the default
   encoding defined for the package MUST be used.
END

However, see DISCUSS points.

- "This mechanism SHOULD NOT be used to convey a URL or URI"

Why not? And (assuming there's a good reason), why doesn't this say MUST NOT?
What are the exceptions? It would be nice to state them here.

4.1:

OLD
   RFC 3261 (where token and quoted-string are defined).
NEW
   RFC 3261 (where token, quoted-string, and generic-param are defined).
END

OLD
   The rules for how many User-to-User header fields of each package may
   be present in a request or a response are defined for each package.
NEW
   Each package defines how many User-to-User header fields of each
   package may be present in a request or a response.
END

4.2: Can we strike most of this section and simply refer to RFC 4648?
Essentially, say "This document defines the hex encoding of UUI data. When the
value of 'hex' is used in the 'encoding' paramater of a header field, the data
is encoded using Base16 encoding according to section 8 of RFC 4648.   The
hex-encoded value is normally represented using the 'token' construction from
RFC 3261, although the 'quoted-string' construction is permitted, in which case
the quotes MUST be ignored." Then in section 6.5, set the description to "Base
16 encoding" and make the reference RFC 4648, section 8.

8: This section should not be a numbered section.

Stephen Farrell

Comment (2014-04-08)

Thanks for handling my discuss points and comments.