Subject: Re: [Sipping] New draft to clarify the privacy mechanism

From: Mayumi Munakata <[email-masked]>
Date: Thu, 19 Oct 2006 17:12:01 +0900

Hi Paul and Shida,

Thank you for your comments, Paul.

>> - Warning: what kind of modification did you have in mind? Why?
>>
> I don't quite recall why we added this. I need to see what Mayumi
> has to say on this > Mayumi?

Warning header is mentioned in RFC 3323 as one of the headers that can reveal identity information.

In RFC 3323, Section 4.1 says:
   The following SIP headers, when generated by a user agent, can
   directly or indirectly reveal identity information about the
   originator of a message: From, Contact, Reply-To, Via, Call-Info,
   User-Agent, Organization, Server, Subject, Call-ID, In-Reply-To and
   Warning.

That was why I considered Warning header as a target of Privacy:user.  However, how to obscure it is not clear while all other headers in the above sentence were mentioned in Section 5 (Privacy Service Behavior) in RFC 3323.

According to Section 20.43 in RFC 3261, "Warning header field values are sent with responses and contain a three-digit warning code, host name, and warning text."  The privacy service may have to modify the host name in Warning header, I guess.

Thanks,
Mayumi

> ------------------------------
> Date: Wed, 18 Oct 2006 09:55:07 -0700
> From: Shida Schubert <[email-masked]>
> Subject: Re: [Sipping] New draft to clarify the privacy mechanism
> To: Paul Kyzivat <[email-masked]>
> Cc: Mayumi Munakata <[email-masked]>, [email-masked]
> 
> 
> Hi Paul;
> 
> Thanks for your comments.
> 
> my comments inline..
> 
> Paul Kyzivat wrote:
>> Interesting draft.
>>
>> I'm mostly in agreement with your Table 1. I'm glad to see that you
>> structured this so that the actions taken by each option are disjoint.
>> If they were overlapping it would present difficulties in
>> implementation. Specifically, the appropriate implementation point in
>> the route of a request varies from option to option. (User is best
>> done near the origination point, session can be done almost anywhere,
>> but the others need to be done near to the exit point of the trust
>> domain.)
>>
>> You included several entries with question marks, but you didn't
>> include any discussion of the considerations leading to the question
>> marks. Clearly those need to be sorted out.
>>
> I agree that they needed to be sorted out and that is exactly why
> we added the question mark. We wanted other's opinions.
>> Also, you describe "strip", which is consistent with current practice
>> up to a point. What you don't do is mention that the server doing the
>> stripping must restore the stripped value in responses.
> We will add a text explaining each of the action listed/used in
> the table.
>> Regarding the question marks:
>>
>> - Warning: what kind of modification did you have in mind? Why?
>>
> I don't quite recall why we added this. I need to see what Mayumi
> has to say on this > Mayumi?
>> - Referred-By: modifying this is likely to break the REFER. I think
>> this might depend on whether it appears in REFER or INVITE.
>> If in a REFER, it reflects the user doing the REFER and so may
>> be considered an appropriate subject of Privacy:user.
>> If it is in an INVITE, it doesn't identify the sender of the
>> request and so may not be an appropriate subject of Privacy:user.
> I think we are talking about what to do in REFER here.
> Whatever "Referred-by" value referee sends in INVITE is what it
> obtained through a REFER request from referrer, so I think we only need
> to worry about Referred-by value sent in REFER. Should this be
> clarified in the text?
>> - Replaces: this references specific state held by the target of the
>> request. It is obviously already known to the target, and the request
>> can't function without it. I don't see what can/should be modified.
>>
>> - Target-Dialog: same as Replaces.
> Considering Target-Dialog contains call-id, which is to be obfuscated
> when "user" is set as a priv-value, I believe same must go for
> target-dialog.
>> - Path: This can be stripped from a request, as long as restored
>> in the response.
> Agree.
> Shida
>> - Service-Route: This only appears in responses. For it to be
>> stripped without breaking things, it must be replaced with something
>> that will be restored later whenever that value appears in a Route
>> header.
>> Paul
>>
>> Mayumi Munakata wrote:
>>> Hi all,
>>>
>>> We have submitted a new draft clarifying the privacy mechanism.
>>> The draft tries to clarify the semantics of each privacy header value
>>> (priv-value) and the handling of the target SIP headers to be
>>> obscured for each of the pre-existing priv-value. It also
>>> provides some guidelines on providing privacy considerations for
>>> future extensions of SIP headers which may be influenced by the
>>> privacy mechanism. This draft is not trying to change any existing
>>> definitions (RFCs 3323, 3325 and 4244).
>>>
>>> During WGLC of acr-code draft, the definitions of priv-values in
>>> Privacy header were discussed in SIP ML. It seems like some people
>>> have different interpretations of Privacy mechanism.
>>> We are afraid that such discrepancy of interpretations will cause a
>>> lack of interoperability. This draft is trying to clarify the privacy
>>> mechanism in order to solve the problem.
>>>
>>> Any suggestions and comments would be appreciated.
>>>
>>> Clarification of Privacy Mechanism for SIP
>>> draft-munakata-sipping-privacy-clarified-00
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-munakata-sipping-privacy-clarified-00.txt
>>>
>>>
>>> Thanks,
>>> Mayumi Munakata

_______________________________________________
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: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Sat, 21 Oct 2006 15:03:58 +0200

The draft containing the Diversion header was not presented to the WG,
the internet-draft is dead, and has never followed the rules according
to RFC 3427.

IETF deals only with the headers and extensions created according to RFC
3427. 

If you want to work out the implications and consequences of
implementing something that IETF did not discuss, I suggest you consult
the author's directly - they will not be covered in IETF documents.

Regards

Keith

> -----Original Message-----
> From: Hendrik Scholz [mailto:[email-masked]] 
> Sent: 19 October 2006 14:25
> To: Mayumi Munakata
> Cc: [email-masked]
> Hi!
> I didn't follow the prior discussions but how about the 
> Diversion header?
> Diversion as of draft-levy-sip-diversion-08.txt supports a 
> diversion-privacy tag to protect the original destination.
> In contrast to Referred-By it contains the destination not the source.
> 
> The issue I currently see is that removing additional 
> information might break call log or billing applications.
> 
> Cheers,
>   Hendrik
> 
> --
> Hendrik Scholz - <[email-masked]> - 
> http://www.wormulon.net/ drag me, drop me - treat me like an object
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>