Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02

From: James Rafferty <[email-masked]>
Date: Fri, 10 Jun 2011 17:24:43 -0400

Hi, 

I've reviewed the document and think it's in good shape for publication.  

I have one small editorial comment on the last sentence of section 3.3

The sentence currently reads:  

" The ability to maintain UUI in these scenarios is critical."

I'd suggest --  "The ability to pass along UUI in these call redirection scenarios is critical." -- since the meaning of "maintain" in this context isn't totally clear.   

James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
Sent: Tuesday, May 31, 2011 10:15 AM
To: [email-masked]
Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02

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

   Draft: draft-ietf-cuss-sip-uui-reqs-02.txt
   WGLC period: May 31, 2011 - June 17, 2011

The authors believe that they have addressed all open issues.
Please go through the latest version of the draft [1] and make sure that there aren't any other outstanding issues.

[1] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.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/
_______________________________________________
cuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cuss

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Jun 2011 16:03:11 +0200

I don't think this is quite ready to go yet, mainly because I don't think the security story stands scrutiny. See comments 13 and 14 below. In particular, knowing that we are choosing a mechanism based on a header field, end-to-end privacy and integrity protection does not seem to be feasible. Given that we probably need to accept hop-by-hop security, this will probably be OK within a trusted domain (where intermediaries are trusted), but falls apart when leaving that domain. For example, in the redirect case, if the 3xx sends UUI all the way back to the originating UA in another domain, it could disclose sensitive information, or the UUI could be subject to modification by that other domain before including in the new INVITE request. In practice, of course, this would all be taken care of by an SBC, which would perform the redirection without the UUI leaving the domain. Similarly for REFER. I think we need proper discussion of these aspects and a reformulation of the relevant requirements.

Specific comments:

1. The Abstract is too long. Some of the stuff about examples could be left for the main document.

2. Also in Abstract:
"A common example in another protocol is the ISDN User to User
   Information Service."
Since the previous sentences are talking about applications, it seems to imply ISDN U-U is an application, which isn't correct, so shouldn't portray this as an example application, but as a corresponding mechanism in another protocol.

3. Section 1:
"It is
   assumed that the application is running in both the originator of the
   session and the terminator of the session.  That is, the application
   interacts with the User Agent Client (UAC) and User Agent Server
   (UAS)."
This seems to imply a fixed relationship between session originator and UAC and between session terminator and UAS, which is not correct - UAC and UAS relate to transactions, not sessions. Note that we are not concerned only with the initial INVITE transaction.

4. Section 2:
I don't think the document uses RFC 2119 terms.

5. Section 3.2:
Figure 2 looks identical to figure 1 - could just reference figure 1 instead or enhance figure 2 to show what is different.

6. Section 3.3:
"Instead, these slight
   differences between the SIP UUI service and the ISDN service need to
   be carefully noted and discussed in an interworking specification."
This implies somebody will write an interworking specification. I think it would suffice to say:
"Instead, these slight
   differences between the SIP UUI service and the ISDN service need to
   be carefully noted and taken into account when considering interworking."

7. Section 3.3:
"If the Redirect Server is not in the same administrative domain as
   the Terminator, the Redirect Server must not remove or replace any
   UUI in the initial INVITE.  In Figure 3, this means that if F1
   included UUI, the Redirect Server could not modify or replace the UUI
   in F2.  However, if the Redirect Server and the Terminator are part
   of the same administrative domain, they may have a policy allowing
   the Redirect Server to modify or rewrite UUI information.  In fact,
   many UUI uses within an Enterprise rely on this feature to work today
   in ISDN."
This sounds more like something for the mechanism document - is it really needed in this document?

8. Section 3.4:
"such as out-of-dialog REFER
   call control"
What is "REFER call control"?

9. Section 4:
"This section discusses the requirements for the transport of call
   control related user to user information (UUI)."
I think it "states" the requirements. Similar at the end of section 1.

10. Section 4:
" REQ-8: The mechanism will allow a UAC to learn or request that a UAS
   understands the call control UUI mechanism and permit routing of
   requests based on this."
Should these be two separate requirements? Or are we happy for the mechanism just to satisfy either one of these (as implied by "learn or request"?

11. Section 4:
" REQ-10: The mechanism will provide the ability for a UA to discover
   which types or application usages of UUI another UA understands or
   supports."
This sounds like it is asking for a sort of OPTIONS request to see whether application foo is supported, prior to sending UUI for foo in the INVITE request. If that is not the intention, I think it needs some rewording. The ISDN protocol discriminator indicates that a particular piece of UUI being transmitted is for application foo - I don't recall that it does more than that.

12. Section 4:
"REQ-13: The mechanism will allow integrity protection of the UUI.
This allows the UAS to be able to know that the UUI has not been
      modified or tampered with by intermediaries."
This seems to suggest S/MIME? But I am not even sure that S/MIME would cover the redirect or refer cases. Note that TLS and SIPS do not satisfy this requirement as stated.

13. Section 4:
"REQ-14: The mechanism will allow end-to-end privacy of the UUI."
Again it seems to imply S/MIME. Yes, it could be achieved by some sort of encryption mechanism used by the application, but that is always possible. We don't need a requirement on the mechanism to achieve that, unless the mechanism is to specify such an encryption mechanism for applications. As for an RFC 3323-like privacy mechanism, this would not provide end-to-end privacy, because intermediaries have access to the information.

14. QSIG is mentioned, so there should be a reference to ECMA-143 (the basic QSIG standard). However, note that QSIG does not have a UUI standard, so any QSIG interworking will be with a proprietary extension.

Nits:
- "a new SIP extensions"
- Could do with a terminology consistency check, e.g., I think "terminator" and "terminating UA" refer to the same thing.
- Use "INVITE request" rather than "INVITE", in cases where INVITE request (as opposed to INVITE transaction, INVITE method or INVITE response) is intended.
- "The UUI could be used to
   lookup information rendered to the agent at the time of call
   answering." Change "rendered to" to "for rendering to". Also I would delete "at the time of call answer", since it could be rendered prior to answer.
- "SIP messages covered by this include 3xx responses to INVITE and
      REFER requests." This is ambiguous - it could be interpreted as covering 3xx responses to REFER requests. I think it should say:
"SIP messages covered by this include REFER requests and 3xx responses to INVITE requests."

John

> Sent: 31 May 2011 15:15
> Folks: Enrico and I will like to issue a WGLC for the CUSS
> Problem Statement and Requirements draft as follows:
> 
> 
> Please go through the latest version of the draft [1] and
> make sure that there aren't any other outstanding issues.
>

---

From: Alan Johnston <[email-masked]>
Date: Tue, 21 Jun 2011 10:51:15 -0500

John,

Thanks for your comments.  We should have some more discussion about
security now as it may save us time when working on the mechanism.
See my comments below marked AJ>

- Alan -

On Fri, Jun 17, 2011 at 9:03 AM, Elwell, John
<[email-masked]> wrote:
> I don't think this is quite ready to go yet, mainly because I don't think the security story stands scrutiny. See comments 13 and 14 below. In particular, knowing that we are choosing a mechanism based on a header field, end-to-end privacy and integrity protection does not seem to be feasible.

AJ> Well, it depends if you think S/MIME is feasible.  As described in
RFC 3261, it is possible, using S/MIME to get end-to-end privacy and
integrity protection even for a header field.  Of course, in the
process, the header is transported as a body.  This is far from ideal,
and the lack of S/MIME deployment with SIP in any case makes this more
theoretical than not.  However, it is an option that could be used in
certain deployments where this made sense.

 Given that we probably need to accept hop-by-hop security, this will
probably be OK within a trusted domain (where intermediaries are
trusted), but falls apart when leaving that domain.

AJ>  I agree that the real usage of this mechanism will use (and need)
hop-by-hop security within a trust domain.

For example, in the redirect case, if the 3xx sends UUI all the way
back to the originating UA in another domain, it could disclose
sensitive information, or the UUI could be subject to modification by
that other domain before including in the new INVITE request. In
practice, of course, this would all be taken care of by an SBC, which
would perform the redirection without the UUI leaving the domain.
Similarly for REFER. I think we need proper discussion of these
aspects and a reformulation of the relevan
>  t requirements.

AJ> So you would like a discussion of this most likely deployed
security model in this draft?  I think that might be a good idea.

> 1. The Abstract is too long. Some of the stuff about examples could be left for the main document.

AJ> OK.

> Since the previous sentences are talking about applications, it seems to imply ISDN U-U is an application, which isn't correct, so shouldn't portray this as an example application, but as a corresp…

AJ> Agreed.

> This seems to imply a fixed relationship between session originator and UAC and between session terminator and UAS, which is not correct - UAC and UAS relate to transactions, not sessions. Note tha…

AJ> Right - I'll fix this.

> I don't think the document uses RFC 2119 terms.

AJ> You are correct.  I can remove this section.

> Figure 2 looks identical to figure 1 - could just reference figure 1 instead or enhance figure 2 to show what is different.

AJ> Yes, we can do that.

>   be carefully noted and taken into account when considering interworking."

AJ> Well, an interworking specification is a milestone on our charter
and we  have an individual draft written, so I think it is pretty safe
that we will have this specification.

> This sounds more like something for the mechanism document - is it really needed in this document?

AJ> It is not needed here, so I can move it to the mechanism draft.

> What is "REFER call control"?

AJ>  Call control using REFER - I'll clarify the sentence.

> I think it "states" the requirements. Similar at the end of section 1.

AJ> OK

> Should these be two separate requirements? Or are we happy for the mechanism just to satisfy either one of these (as implied by "learn or request"?

AJ> I think they are separate requirements.

> This sounds like it is asking for a sort of OPTIONS request to see whether application foo is supported, prior to sending UUI for foo in the INVITE request. If that is not the intention, I think it needs some rewording.

AJ> Yes, this is the intention.

The ISDN protocol discriminator indicates that a particular piece of
UUI being transmitted is for application foo - I don't recall that it
does more than that.

AJ> Right - in some cases, we may do better than the ISDN.

> This seems to suggest S/MIME? But I am not even sure that S/MIME would cover the redirect or refer cases. Note that TLS and SIPS do not satisfy this requirement as stated.

AJ> In the case of redirect or refer, the UUI would be signed by the
redirector or referer.  Again, real world usages would not use S/MIME.

> Again it seems to imply S/MIME. Yes, it could be achieved by some sort of encryption mechanism used by the application, but that is always possible. We don't need a requirement on the mechanism to…

AJ> Yes, S/MIME would be required.  I do expect applications that
transport sensitive information in UUI to do their own encryption.

> 14. QSIG is mentioned, so there should be a reference to ECMA-143 (the basic QSIG standard). However, note that QSIG does not have a UUI standard, so any QSIG interworking will be with a proprietar…

AJ> I'll add it.

---

From: Alan Johnston <[email-masked]>
Date: Tue, 21 Jun 2011 11:59:26 -0500

James,

Thanks for the review.  We'll fix it.

- Alan -

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 21 Jun 2011 20:44:54 +0200

Alan,

I pretty much agree with your responses and will wait to see how the next version looks, particularly the security discussion.

John

> From: Alan Johnston [mailto:[email-masked]] 
> Sent: 21 June 2011 16:51
> To: Elwell, John
> Cc: Vijay K. Gurbani; [email-masked]
> Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02
> 
> John,
> 
> > I don't think this is quite ready to go yet, mainly because 
> I don't think the security story stands scrutiny. See 
> comments 13 and 14 below. In particular, knowing that we are 
> choosing a mechanism based on a header field, end-to-end 
> privacy and integrity protection does not seem to be feasible.
> 
> > 1. The Abstract is too long. Some of the stuff about 
> examples could be left for the main document.
> 
> AJ> OK.
> 
> >
> > 2. Also in Abstract:
> > Since the previous sentences are talking about 
> applications, it seems to imply ISDN U-U is an application, 
> which isn't correct, so shouldn't portray this as an example 
> application, but as a corresponding mechanism in another protocol.
> 
> AJ> Agreed.
> 
> >
> > 3. Section 1:
> > "It is
> > This seems to imply a fixed relationship between session 
> originator and UAC and between session terminator and UAS, 
> which is not correct - UAC and UAS relate to transactions, 
> not sessions. Note that we are not concerned only with the 
> initial INVITE transaction.
> 
> > Figure 2 looks identical to figure 1 - could just reference 
> figure 1 instead or enhance figure 2 to show what is different.
> >
> 
> AJ> Yes, we can do that.
> 
> > 6. Section 3.3:
> > "Instead, these slight
> > This implies somebody will write an interworking 
> specification. I think it would suffice to say:
> > "Instead, these slight
> > Should these be two separate requirements? Or are we happy 
> for the mechanism just to satisfy either one of these (as 
> implied by "learn or request"?
> 
> > This sounds like it is asking for a sort of OPTIONS request 
> to see whether application foo is supported, prior to sending 
> UUI for foo in the INVITE request. If that is not the 
> intention, I think it needs some rewording.
> 
> > This seems to suggest S/MIME? But I am not even sure that 
> S/MIME would cover the redirect or refer cases. Note that TLS 
> and SIPS do not satisfy this requirement as stated.
> 
> > Again it seems to imply S/MIME. Yes, it could be achieved 
> by some sort of encryption mechanism used by the application, 
> but that is always possible. We don't need a requirement on 
> the mechanism to achieve that, unless the mechanism is to 
> specify such an encryption mechanism for applications. As for 
> an RFC 3323-like privacy mechanism, this would not provide 
> end-to-end privacy, because intermediaries have access to the 
> information.
> 
> > 14. QSIG is mentioned, so there should be a reference to 
> ECMA-143 (the basic QSIG standard). However, note that QSIG 
> does not have a UUI standard, so any QSIG interworking will 
> be with a proprietary extension.
> >
> 
> AJ> I'll add it.
> 
> 
> >
> > Nits:
> > - "a new SIP extensions"
> > - Could do with a terminology consistency check, e.g., I 
> think "terminator" and "terminating UA" refer to the same thing.
> > - Use "INVITE request" rather than "INVITE", in cases where 
> INVITE request (as opposed to INVITE transaction, INVITE 
> method or INVITE response) is intended.
> >   answering." Change "rendered to" to "for rendering to". 
> Also I would delete "at the time of call answer", since it 
> could be rendered prior to answer.
> >      REFER requests." This is ambiguous - it could be 
> interpreted as covering 3xx responses to REFER requests. I 
> think it should say: