Subject: RE: [Sip] z9hG4bK forever ???

From: "Mark Watson"<[email-masked]>
Date: Wed, 17 Apr 2002 10:56:14 +0100

Bill,

Indeed, this approach seems good to me too. But expect people to argue the
following points:
1) Proxies as defined in RFC3261 cannot modify the From field. Sure, it is a
small extension, but strictly speaking it is more than a pure proxy does.
2) This modification does break some services. It would be best to avoid it
except when necessary e.g. if the *user* requires privacy, then still put
Anonymous in the From field.
3) verification of the From field is either 'required for consistent service
in a Service Provider environment' (myself, probably most of 3GPP, Juha,
others ? ...) OR 'contrary to the definition of the From field as an
end-to-end user asserted field' (Dean, Dave, others ? ...) - we have no
consensus on this.

The only compromise I can see on this is:
a) Those who want to verify the From: field do
b) Those who don't want to don't
c) In the absence of trust relationships the From: field is completely
untrusted (like everything else!). If you have a trust relationship, then as
part of this you will agree whether From: can be trusted or not.
d) The contents of the From field MAY be modified by devices in the network.
So we should design new services and features with this assumption where
possible

(d) is a logical consequence of (a) - don't try and argue out (d) unless you
think you can exclude (a) too.

...Mark

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: 17 April 2002 03:48
> To: [email-masked]
> Subject: [Sip] z9hG4bK forever ???
> 
> 
> Subject: was Re: Screened FromL and Privacy
> Subject: was Re: Summary of RE: [Sip] Comment, SIP Privacy draft
> Subject: was lots of others, too
> 
> All this discussion of proxy modification of the From and To headers,
> and the need for a B2BUA, seems to me to be a short-term problem only.
> 
> RFC3261 (2543bis-09) specifies matching of dialog-ids based only
> on Call-ID and tags, not on display-name or on addr-spec.  So
> when all endpoints are compliant with RFC3261, there will be no
> problem with a proxy modifying the display-name or addr-spec in
> the From header.
> 
> It is only during a transition period, when endpoints that conform
> to RFC2543 are supported as well as newer ones.  How long will
> this be?  How long will a proxy need to handle a UAC that doesn't
> supply a Contact header?  How long will a proxy need to handle
> a Record-Route header without the "lr" tag?  How long will a
> UAS need to handle a BYE received prior to sending 2xx?  How long 
> will the comparison be coded into the proxies and UAs looking 
> for "z9hG4bK"?
> 
> In all cases, my hope is not too long.  And, at the point when
> these "conversion aids" no longer need to be present in SIP
> implementations, it will be safe for proxies to modify the From
> header to provide anonymity, if the subscriber, or the user, or the
> regulator, (or others?), says that it should.
> 
> In cases like 3GPP, where (IIRC) release 5 does not include
> IMS connections outside of the wireless operator's network, the
> problem is even simpler.  Since 3GPP required RFC3261 everywhere,
> modification of the From header can be done immediately.  I would
> hope this transition period and the need for "conversion aids" would
> be over before 3GPP release 6 is deployed.
> 
> My conclusion from all of this is that 3GPP can require the UE to
> insert a valid user identifier in the From header, and the S-CSCF can
> change it if privacy is desired, on a session-by-session basis,
> based on whatever rules the S-CSCF wants to follow.
> 
> Comments?
> 
> Bill Marshall
> [email-masked]
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: [email-masked]
Date: Thu, 18 Apr 2002 09:32:48 +0300

> So we should design new services and features with this assumption where

the above is consistent with what i have tried to say about this topic
and contains nothing new.  this whole thread has thus been more or less
useless.

-- juha