[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt
Responses below [MB].
-----Original Message-----
From: Hans Erik van Elburg [mailto:ietf.hanserik at gmail.com]
Sent: Wednesday, March 11, 2009 6:56 PM
To: Barnes, Mary (RICH2:AR00)
Cc: sip at ietf.org; Ian Elz; Audet, Francois (SC100:3055)
Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt
But you do not have control over a previously visited proxy using the
header. Why should that one dictate the privacy needs of the next hop
proxy in the same domain?
[MB] If the Privacy header is for the request as a whole (i.e., it's not
tagged against a specific hi-entry), then by the definition of the
header in RFC 3323 (with the addition of the priv-value="history"), it
does apply to how the handled is request at every node. And, again, it
is a SHOULD NOT, so it is possible that there might be conditions under
which you don't want to "dictate the privacy needs..." - you just need
to specify the conditions. Also, within the same domain, the hi-entries
are NOT removed even if the Privacy header is used. If Proxy 1 and Proxy
2 are responsible for the same domain, then you don't remove the
hi-entries until you leave that domain. [/MB]
I dont think there is a conflict it is just adding some higher level of
granularity in controlling the privacy of specific entries.
[MB] I had interpreted the "none" to be used with the Privacy header
(for the whole request, not just specific hi-entries), so that the
specific entry can be forwarded outside a domain. [/MB]
/Hans Erik
Mary Barnes wrote:
> And, if you have a network whereby you believe that none of the
> information that Proxy 2 will put in hi-entries reveals any
> information that is considered private, then you can set your flag, or
> whatever and not drop the hi-entries when they leave that domain -
> that's why it's a SHOULD NOT - i.e., don't do it unless you've
> evaluated why it's okay to do it in that case. It is clearly
> documented in 4244 that there is indeed a loss of information when you
> use the Privacy header versus tagging individual hi-entries with the
> privacy header. Now, we could add a Recommendation that the Privacy
> header be used only to tag individual entries.
>
> Yes, I agree the "none" is not a good idea (and conflicts with the
> Privacy header) as it kindof overrides it, so to speak.
>
> Mary.
>
>
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
> Hans Erik van Elburg
> Sent: Wednesday, March 11, 2009 6:02 PM
> To: Barnes, Mary (RICH2:AR00)
> Cc: sip at ietf.org; Ian Elz; Audet, Francois (SC100:3055)
> Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt
>
> When a proxy1 adds a Privacy header with the value history, then why
> should a proxy 2 not be able to say: fine but I override the general
> privacy rule for the specific hi-entry that I add or am responsible
for?
>
> I was reacting to "I don't like the "none" idea as it really must be
> up to the entity that added the Privacy header to the request, as to
> whether it wants the HI entries that it adds to go outside a domain."
>
> /Hans Erik
>
> Mary Barnes wrote:
>
>> I'm not sure if I'm clear on your concern here - what is the
>>
> "something"
>
>> in the "Why should History-Info enforce..."?
>>
>> If by the "something" you mean removing the history-info header (if
>> it's session or header level privacy), we have to go back to the
>> fundamental History-Info solution requirements and consider the
>> functionality provided by the Privacy header in RFC 3324. This isn't
>> about application-agnostic or not. The information in the hi-entries
>> can be considered of the same ilk as the other information that is
>> intended to be kept private by the use of the Privacy header, thus if
>> the request indicates session or header levels of privacy, the proxy
>> SHOULD NOT forward the hi-entries. Note, it's a SHOULD NOT. If your
>> network configuration is such that there is no privacy issue with
>> sharing that information, then you can document as such and explain
>> why it's perfectly okay to forward the hi-entries.
>>
>> However, per my note below, even if the prior hop strips out
>> information that is appropriate to the next domain, the last hi-entry
>> can be added by that next hop proxy to preserve the information
>> before
>>
>
>
>> that proxy might change the request-uri.
>>
>> Mary.
>>
>> -----Original Message-----
>> From: Hans Erik van Elburg [mailto:ietf.hanserik at gmail.com]
>> Sent: Wednesday, March 11, 2009 5:05 PM
>> To: Barnes, Mary (RICH2:AR00)
>> Cc: Ian Elz; Audet, Francois (SC100:3055); sip at ietf.org
>> Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt
>>
>> I believe in this case the History-Info application-agnosticness
>> principle applies.
>>
>> Why should History-Info enforce something, that goes against the
>> whishes of a domain that is adding a hi-entry and should be
>> considered
>>
>
>
>> best equiped in judging what privacy rules apply for this specific
>>
> entry.
>
>> /Hans Erik
>>
>> Mary Barnes wrote:
>>
>>
>>> Ian,
>>>
>>> This is an interesting question. I need to think about it some more,
>>> but I don't like the "none" idea as it really must be up to the
>>> entity
>>>
>>>
>>
>>
>>> that added the Privacy header to the request, as to whether it wants
>>> the HI entries that it adds to go outside a domain. My initial
>>> thought
>>>
>>>
>>
>>
>>> is that we can't overrule the overall Privacy header. The thing is
>>> that the Privacy header doesn't preclude gathering the information
>>> and
>>>
>>>
>>
>>
>>> using within a domain AND if it were to not include an hi-entry when
>>> the request leaves the domain for which the proxy is responsible,
>>> the
>>>
>
>
>>> recipient can add the hi-entry for the current request-uri before it
>>> adds the new hi-entry.
>>>
>>> Your PSTN example doesn't strictly map obviously to a SIP model and
>>> I
>>>
>
>
>>> would think you might consider the PSTN hop to be within the same
>>> domain for which the proxy (or gw, I guess) is responsible OR
>>> consider
>>>
>>>
>>
>>
>>> this a walled garden whereby the Privacy header doesn't apply. Which
>>> brings me to a more general question as to how you all deal with
>>> other
>>>
>>>
>>
>>
>>> headers when you do your mapping to the PSTN when there is a Privacy
>>> header? It would seem this problem isn't unique to History-Info,
>>> although I know little about the details of PSTN I/W.
>>>
>>> Regards,
>>> Mary.
>>>
>>> -----Original Message-----
>>> From: Ian Elz [mailto:ian.elz at ericsson.com]
>>> Sent: Wednesday, March 11, 2009 4:54 AM
>>> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055)
>>> Cc: sip at ietf.org
>>> Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt
>>>
>>> Mary, Francois,
>>>
>>> Section 4.1 of the draft allows for the addition of the Privacy
>>> header
>>>
>>>
>>
>>
>>> parameter with a value of "history" to be included with the
>>> hi-targeted-to-uri.
>>>
>>> Can this be extended to also allow the value "none".
>>>
>>> A node adding a H-I entry is allowed to specify the privacy value
>>> "history" either in the Privacy header or as a header parameter
>>> associated with the hi-targeted-to-uri. If the former action is
>>> taken
>>>
>
>
>>> by one node this results in privacy for all history info header
>>> entries even if this is not required. There is no way for privacy of
>>> an individual H-I entry to be set to none if no Privacy is required
>>> for the uri.
>>>
>>> This creates a specific problem when interworking with the PSTN
>>> where
>>>
>
>
>>> the privacy is associated with each E.164 number included in the
>>> protocol. If an INVITE is being mapped to ISUP and the H-I entries
>>> are
>>>
>>>
>>
>>
>>> being used to map to redirection numbers then a single Privacy
>>> header
>>>
>
>
>>> with the value "history" will result in all numbers being
restricted.
>>>
>>> If the Privacy header parameter could include the value "none" then
>>> this would explicitly indicate that the associated uri was allowed
>>> to
>>>
>
>
>>> be presented.
>>>
>>> The ability to explicitly allow presentation of specific H-I entries
>>> may also be useful in pure sip implementations.
>>>
>>> I don't believe that this change would create any backward
>>> compatibility issues. The existing implementations will continue as
>>> deployed but new implementations could explicitly set no privacy for
>>> a
>>>
>>>
>> specific uri.
>>
>>
>>> There are no security issues other than those already defined in the
>>> draft that an intervening node could modify an existing H-I entry.
>>> The
>>>
>>>
>>
>>
>>> Privacy header value of "none" should only be included by the node
>>> in
>>>
>
>
>>> the same manner as the existing inclusion of the "history" value.
>>>
>>> Ian Elz
>>>
>>>
>>> -----Original Message-----
>>> From: i-d-announce-bounces at ietf.org
>>> [mailto:i-d-announce-bounces at ietf.org] On Behalf Of
>>> Internet-Drafts at ietf.org
>>> Sent: 04 March 2009 15:15
>>> To: i-d-announce at ietf.org
>>> Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>> Title : An Extension to the Session Initiation
>>> Protocol (SIP) for Request History Information
>>> Author(s) : M. Barnes, F. Audet
>>> Filename : draft-barnes-sip-rfc4244bis-00.txt
>>> Pages : 49
>>> Date : 2009-03-04
>>>
>>> This document defines a standard mechanism for capturing the history
>>> information associated with a Session Initiation Protocol (SIP)
>>>
>>>
>> request.
>>
>>
>>> This capability enables many enhanced services by providing the
>>> information as to how and why a call arrives at a specific
>>> application
>>>
>>>
>>
>>
>>> or user. This document defines a new optional SIP header,
>>> History-Info, for capturing the history information in requests.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.t
>>> x
>>> t
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>> _______________________________________________
>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol Use
>>> sip-implementors at cs.columbia.edu for questions on current sip Use
>>> sipping at ietf.org for new developments on the application of sip
>>>
>>>
>>>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> sip-implementors at cs.columbia.edu for questions on current sip Use
> sipping at ietf.org for new developments on the application of sip
>