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

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.

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

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

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.

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

Thanks for addressing some of my comments, especially the Discuss comments. I understand that the WG is using "Standards Action" as a placeholder for the moment until a different kind of registration mechanism is worked out. I think that's OK.

You did miss some of the earlier comments for which you agreed to make changes, and there are a couple of others that I think would clarify, but I'll leave these for the WG and Alissa to work out:

1: I'm not sure what the following sentence adds:

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

I'd delete it, but maybe I just don't understand why this is important to mention.
   
3: I think this section would work better as an appendix.

4: 

OLD
   If the "purpose" header field parameter is not present, interworking
   with the ISDN UUI Service MUST be assumed.
NEW
   The default value for the "purpose" header field is "isdn-uui" as
   defined in [I-D.ietf-cuss-sip-uui-isdn]. If the "purpose" header
   field parameter is not present, the ISDN UUI MUST be used.
END
   
- "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

8: This section should not be a numbered section. The RFC Editor will likely fix this, but if you do another edit, might as well fix it.

Thanks for handling my discuss points and comments.