Subject: [Sipping] Re: I-D ACTION:draft-shacham-sip-media-privacy-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jun 2005 18:11:08 -0400

Ron,

This is pretty interesting.

I see a few things that need a bit of work:

Did you intend this for the sip wg (based on title)? I think this would 
normally start in sipping. So I'm addressing comments there.

Your use of callerprefs isn't quite in line with the RFCs:

    ...  The caller may include this parameter in the
    "Reject-Contact" header to disallow the call being routed to any
    device with a privacy level lower than or equal to that specified.
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    For example, including the following header would keep the request
    from being routed to any device which would allow others to see or
    hear the output:

    Reject-Contact: *;privacy="organization"

What you have written would only reject based on an exact match with 
"organization". Range-based matches can only be done on numeric 
features. You can look at how priority was done.

Regarding use of offer/answer to "negotiate" privacy:

    We specify an extension to SDP to allow a session to be negotiated
    based on privacy requirements.  Two attributes are defined,
    "provided-privacy" and "required-privacy", each a value attribute
    which may take any of the values specified in Section 2.  An SDP
    description may include either or both of the attributes.
    ...
    Here, the sender notifies the other party that he is able to provide
    user-level privacy, and requires the same level from the other device
    in order to establish a session.  This attribute is treated as any
    other in the offer/answer exchange, in that the recipient must be
    able to provide privacy at least at the specified level in order to
    establish the session.
    ...
    Since caller preferences are only defined for
    the initiator of a session, the callee must use, in its response, the
    SDP extensions described in order to require that the caller use a
    device that is sufficiently private.

I think you at least need some additional specification. From the 
answerer's perspective this isn't much of a negotiation and seems to 
provide no promises of privacy. All the answerer can do is hope that the 
offerer will honor the request.

To be more certain, the answerer could simply refrain from transmitting 
media initially, while sending a reinvite to negotiate the privacy it 
requires. But this might not provide a very good user experience.

More likely is that the answerer be informed that the call is not 
private and simply refrain from sending *private* information until the 
desired level of privacy can be established.

	Paul

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Specifying Media Privacy Requirements in the 
>                           Session Initiation Protocol (SIP)
> 	Author(s)	: R. Shacham, et al.
> 	Filename	: draft-shacham-sip-media-privacy-00.txt
> 	Pages		: 9
> 	Date		: 2005-6-28
> 	
>    Participants in a normal phone conversation can assume that, given
>    the appropriate measures are taken against network eavesdropping,
>    what they say is only heard by the other participant.  The use of
>    speakerphones or visual output devices displaying video or messaging
>    removes this assumption.  In the Session Initiation Protocol (SIP), a
>    call may also be transfered to another device, suddenly compromising
>    the other participant's privacy.  Therefore, this document proposes
>    SDP and SIP protocol extensions that allow participants to specify
>    their privacy requirements for the other party's device, and
>    discusses how they may be used in different session scenarios.  It
>    also defines an SDP extension for allowing or disallowing the
>    recording of the session.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-shacham-sip-media-privacy-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-shacham-sip-media-privacy-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-shacham-sip-media-privacy-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> -------------------------------------------------------------------------
> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
> -------------------------------------------------------------------------
> In order to maintain computing infrastructure integrity, Cisco Systems
> Enterprise Messaging Services and InfoSec teams have set a mail policy
> disallowing executable attachments in email.
> 
> This message contained an executable attachment type that is prohibited 
> by this policy. The attachment has been removed from this message and 
> copied to quarantine by our systems. It will be held in quarantine for
> seven days in the event that the content needs to be retrieved.
> 
> Please be aware many viruses attempt to look like legitimate email or 
> notifications from anti-virus systems. We will clearly mark a seperation
> between our notifications and the original email as follows:
> 
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
> 
> For further reference information about viruses and email antivirus 
> efforts within Cisco, please visit:
> 
> http://wwwin.cisco.com/it/ems/services/antiviral
> 
> If your concern isn't addressed by the information in this notification 
> or the above web page, you may open a support request:
> 
> http://wwwin.cisco.com/support/
> 
> Select "Messaging", "Email-Related", "Mail Routing"
> 
> Please include in the text of your case the following information:
> 
> * Full headers of the message. Documentation on displaying the full 
> headers is available at this URL:
> 
> http://wwwin.cisco.com/support/library/faqs/solution002471.html 
> 
> * This unique quarantine identifier: j5SKXFCC001912
> 
> If the matter is urgent, you may follow up by calling one of the below 
> referenced numbers. Please make every effort to provide the above 
> requested information via the support web tool prior to calling as it 
> will greatly aid the resolution of your issue.
> 
> Americas:
> 1 408 526 8888
> 
> Asiapac
> +61 2 8446 8888
> 
> EMEA
> +31 20 485 4888
> 
> Japan
> +81 3 5549 6888
> 
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
> 
> Thank you for your cooperation,
> 
> Enterprise Messaging Services
> Cisco Systems, Inc
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Arjun Roychowdhury <[email-masked]>
Date: Tue, 28 Jun 2005 21:58:59 -0400

Does it also make sense to specify some guidelines for B2Bs that will
act as 'call servers' between two parties ?

for example a-->b2b-->c

a requires all the privacy extensions, b2b complies, but nothing
guides the b2b to request the same from c - so in effect, "a" believes
all his privacy is intact where as c is happily recording its
conversation, or  transferring itself out.

The same applies to conference servers - if a is dialing into a bridge
and requests privacy, for example, should the conference server allow
this only if it is sure all its participants can honour this request
of privacy ?

regds
arjun

-- 
Arjun Roychowdhury

---

From: Eunsoo Shim <[email-masked]>
Date: Wed, 29 Jun 2005 03:08:15 -0400

Currently there is no speficiation about the behavior of B2BUAs as far 
as I know.
Because of that, the B2BUA is an issue not only in this context.
Regards,

Eunsoo

---

From: Arjun Roychowdhury <[email-masked]>
Date: Wed, 29 Jun 2005 10:22:15 -0400

Yes, I know there is none -but you just need to be concerned with the
external appearance - a concatenation of of a UAC and UAS- and that is
defined in section 6 of RFC3261. Since these privacy requirements are
critical to the requestor (otherwise it is of no use to send it), it
might be useful to specify such a guideline, at the least (especially
since almost all of the 'call servers' in todays market are actually
b2bs)

regds
arjun

-- 
Arjun Roychowdhury

---

From: "Brijesh Kumar" <[email-masked]>
Date: Wed, 29 Jun 2005 11:18:37 -0400

Hi Ron:

It is an interesting draft, and I think specifying SDP parameters to
specify privacy requirements is technically fine.

However, I am curious as to how does specifying media privacy
during SIP session setup really get enforced. Even FCC has not been able
to control the use of broadcast media  since once you have
analog audio or video stream - you can do whatever you like with it
including recording, forwarding or playing back to your neighbors. The
only way FCC is able to do that is by forcing settop box and A/V
manufacturers
to totally eliminate analog outputs from the next gen A/V devices, and
getting all
other ports encrypted by the key supplied by the cable manufacturers.

So, it is not the mechanism of conveying privacy parameters to
other end, but whether it can be effectively enforced automatically is
what I am pointing to. You can as well say over the phone that please
don't record, or play my conversation on speakers.
If some one wants to do opposite of that, he/she can do it
any way.

cheers,

-brijesh

-- 
Arjun Roychowdhury