Subject: [SIP] Hide header

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 8 Nov 2000 11:27:28 -0000

I noted in Henning's list of headers for IANA that the Hide header is
deprecated.

In the bis-02 draft, there appears to be no text that indicates this, or
gives any details on what the term means as regards sending and receiving,
apart from some discussion in annex I. Is there some proposed text somewhere
that states SHOULD NOT for sending, and changes the "m" status in table 6
for proxies.

Keith
Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 08 Nov 2000 08:43:47 -0600

"Drage, Keith (Keith)" wrote:
> In the bis-02 draft, there appears to be no text that indicates this, 
> or gives any details on what the term means as regards sending and 
> receiving, apart from some discussion in annex I. Is there some 
> proposed text somewhere that states SHOULD NOT for sending, and 
> changes the "m" status in table 6 for proxies.

Keith:

Digging into some of the (pertinent) emails I have saved, I found this
from Henning that may help:

> Date: Sat, 02 Sep 2000 22:21:39 -0400
> From: Henning Schulzrinne <[email-masked]>
> X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL  (WinNT; U)
> X-Accept-Language: en
> MIME-Version: 1.0
> To: Jonathan Rosenberg <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [SIP] transaction identification
> References: <[email-masked]> <39AC83A0.68A61CA@dy
> namicsoft.com> <[email-masked]> <[email-masked]
> et> <[email-masked]> <[email-masked]> <39AF563
> [email-masked]> <[email-masked]> <39B06683.FE987438@d
> ynamicsoft.com>
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Sender: [email-masked]
> Errors-To: [email-masked]
> X-Mailman-Version: 1.1
> Precedence: bulk
> List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
> X-BeenThere: [email-masked]
> Content-Length: 2102
> Status: RO
> X-Status: $$$$
> X-UID: 0000000040
>  
>  
> > It might be worthwhile to take a step back and examine whether or not
> > this kind of fix (just needed for via hiding) can rather be addressed by
> > ditching via hiding and doing something else entirely. I don't think its
> > widely implemented, and there are definintely issues with the security
> > model (the next hop provides the feature for you).
> >
>  
> This is only one of the problems. With hindsight, my other concerns
> about Via hiding:
>  
> - complexity, particularly hidden "gotchas" that surface at various
> points (as in this instance);
>  
> - interference with loop detection and debugging;
>  
> - over-promise: unlike HTTP, where via-hiding makes some sense since all
> data is in one place, Via-hiding in SIP by itself does nothing to hide
> the caller. (I'm having a hard time thinking of applications where
> hiding the caller doesn't matter, but where hiding a proxy does.)
> There's all kind of other information leakage:
>  
>   - Contact
>   - Route/Record-Route
>   - SDP (various places, including o=, c=)
>   - possibly accidental leakage in User-Agent header and Call-ID,
> depending on how they're generated
>  
> Also, unless this is implemented everywhere, the feature is not likely
> to be very useful, without the sender having any recourse such as "don't
> route this request unless you can hide". I would guess that almost all
> existing proxies simply ignore the Hide header.
>  
> Thus, there is a danger of asking for via-hiding and then deluding
> oneself
> hat this indeed provides anonymity.
>  
> I think we should welcome opportunities to simplify the spec by removing
> marginally useful features.
>  
> For real anonymity, a back-to-back UA (that creates a "fresh" SDP entry
> and otherwise scrubs the request of identifying information) seems about
> the only viable approach.
>  
> Email has existed for many years without this feature, with "mixers" for
> anonymity.
>  
> If this is truly needed, I would argue that this should be an extension
> specified separately, with a Proxy-Require header.
>  
> Henning
>  
>  

- vijay
-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
Internet Software & eServices Group
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184