[sipcore] #16: Privacy behavior is confusing

"sipcore issue tracker" <trac@tools.ietf.org> Mon, 30 August 2010 20:14 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: sipcore issue tracker <trac@tools.ietf.org>
Precedence: bulk
Auto-Submitted: auto-generated
To: hkaplan@acmepacket.com
Date: Mon, 30 Aug 2010 20:15:07 -0000
Message-ID: <064.c332b45494f9c1c0917449f41a07017b@tools.ietf.org>
Cc: sipcore@ietf.org
Subject: [sipcore] #16: Privacy behavior is confusing

#16: Privacy behavior is confusing
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:            
     Type:  enhancement             |      Status:  new       
 Priority:  minor                   |   Milestone:  milestone1
Component:  rfc4244bis              |     Version:  2.0       
 Severity:  In WG Last Call         |    Keywords:            
------------------------------------+---------------------------------------
 [I'm submitting this ticket because when I read the draft the first few
 times, it kept annoying me.  But it could easily just be me and no one
 else.]

 Maybe it's just me, but I've read the draft multiple times and I find the
 Privacy header stuff for anonymizing H-I headers to be really confusing.
 In RFC 3323, the idea was for providing privacy of the *originator*
 information.  New headers could stipulate they also reveal such
 information and thus should be anonymized, but it's really debatable if
 H-I entries reveal information about the *originator*, vs. the target.

 The only way I can see they reveal originator info is because they can
 reveal the IP Address of the originator's proxy, or originator's domain,
 because Alice may send the request to sip:Bob@aliceproxy.com.  But in that
 context, it's true the aliceproxy.com H-I has to be anonymized, but
 clearly not sip:Bob@bobsproxy.com once aliceproxy retargets to that.
 Furthermore, by forcing all H-I entries to be anonymized, it breaks the
 use of H-I for some pretty important uses.  You could say "well that's
 what anonymization means", but that's not true - it is NOT the case that a
 caller-id anonymized call does not get the right voicemail or ACD service.
 Because "anonymized" calls are about originator information, not
 destination information.  After all, the destination *knows* who you're
 calling... it's not a secret to Bob that you called Bob!

 What the draft needs to do is explain there are multiple "types" of
 Privacy: privacy to anonymize the originator, privacy to anonymize
 diverting targets from subsequent targets and the originator, and privacy
 to anonymize the final reached target from the originator.  The last two
 happen to work the same way: through the Privacy header being embedded in
 the H-I entries of responses.  The draft then needs to explain *why* the
 first case of originator information could be revealed by H-I, and why
 there needs to be support for anonymizing all the H-I's using the Privacy
 header for that first case.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/16>
sipcore <http://tools.ietf.org/sipcore/>

[sipcore] #16: Privacy behavior is confusing sipcore issue tracker
Re: [sipcore] #16: Privacy behavior is confusing Paul Kyzivat
Re: [sipcore] #16: Privacy behavior is confusing Mary Barnes