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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 18 Apr 2002 07:13:29 +0100

Bill's argument breaks down in a few important points.

1)	Such a proxy" would not be RFC 3261 compliant.

2)	Release 5 does not preclude interworking with other SIP networks. It
merely does not specify how it occurs. It does not specify how interworking
with R2 might be performed, but I am sure that some wireless network at some
point in the future will specify it. The fact that Release 6 might get round
to a full specification will not invalidate any proprietary interworking
methods. Given the importance that some operators are placing on
interworking with enterprise networks, and the fact that most of the
enterprise SIP terminals out there are closer to RFC 2543 on this one than
to RFC 3261, I do not see it happening. Enterprise terminals also tend to
sit around longer than anyone thinks, and even if they are not attached to
the network, people still expect to pull them out of the cupboard after a
couple of years, plug them into the network, and see them work.

3)	In the longer term, with split mobiles, we cannot guarantee that the
UA part of the split is RFC 3261 conformant. Similar comments apply to the
lifetime of RFC2543 terminals as above.

"Short term" in Bill's argument can be 5 years or more.

Keith

> -----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
> 

_______________________________________________
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: "Mark Watson"<[email-masked]>
Date: Thu, 18 Apr 2002 12:00:16 +0100

I think we're about at the end of this one.

Two final points from me:
1) Dean's desire to avoid having the From: field mangled unless he has
specifically requested it is reasonable. I still think  that the
subscriber's wishes could overrule this though.

This is no different from the ISDN 'Special Arrangement' where the user
inserts any number they like in the Calling Party Number field. The network
passes it though with no checking, changing, nothing - I think this is
analogous to what Dean wants for the From field.

But the network still removes this information if the subscriber wants
anonymity. The stated purpose of the field is user identity, which implies
Personal Data of the subscriber. This is enough to argue that the network
must remove it if privacy is required, and this is certainly the application
of current legislation to ISDN.

What is the stated purpose of the From field - I do not think it is
sufficiently different for us to be _sure_ that we can avoid the
requirement.

So, the munging may still be required, but I certainly agree it should be
avoided wherever possible.

2) In formal terms, 'B2BUA == NOT Proxy'. We all know there will be/are
devices which behave very much like a proxy, but perform some additional
functions, such as these privacy services. This is fine. Everyone should be
aware that with only two terms defined 'B2BUA' and 'Proxy', such devices
fall into the B2BUA category.

...Mark

> From: Dean Willis [mailto:[email-masked]]
> Sent: 17 April 2002 17:36
> To: William Marshall; [email-masked]
> Subject: Re: [Sip] z9hG4bK forever ???
> 
> 
> Baill said:
> I disagree. I don't want the network mangling my user-to-user headers
> unless I've specifically requested it to do so. Specifically, the
> non-authenticated, non-mangled, non-protected From: field 
> offers utility
> which is DIFFERENT than that provided by network authenticated calling
> party ID, and I don't want to sacrifice that utility just because this
> is a capability the widely-deployed PSTN (as opposed to say Q.SIG)
> didn't have . . .
> 
> --
> Dean
> 
> 
> 
>

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Thu, 18 Apr 2002 09:57:35 -0600

> 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

I couldn't disagree more.

Our WG chairs have been enormously patient with the latest batch of rants and tirades on this subject. The quality of discussion has improved measurably since the one-hour RPID rathole in Minneapolis. Since the union of all proposed requirements is the null set, the most effective path forward will of necessity involve difficult compromise against less important requirements in order to satisfy those that will really matter over time. Frankly, Jon Peterson has done an excellent job of taking up this challenge and laying out some concrete proposals to address it.

While you are certainly entitled to your opinion, it should be abundantly clear by now that this set of issues is important to many in the sip community and isn't going away just because you would like to dismiss it. Based on list traffic, rough consensus *isn't* saying this is useless and it *isn't* saying we can ignore these issues and move on. 

--Andy

---

From: William Marshall <[email-masked]>
Date: Fri, 19 Apr 2002 15:50:10 -0400 (EDT)

Dean wrote:
> Bill said:
> > We have now identified TWO cases where un-proxy-like behavior will be
> > done in real networks.  The first, a few months ago, was where a
> > firewall control proxy modified the Contact header, and possibly
> > also modified the addresses and ports in the SDP.  The second is here,
> > where a privacy proxy modifies the From header (and quite probably,
> others).
> 
> Proxies in any form cannot modify bodies, and B2BUAs are likely to break
> things if they try to. SIP security relies greatly on smime-protected
> bodies.

The philosophy is nice, but not all that useful if it can't be put
into practice.  As was said previously on this subject:

Last February Jonathan Rosenberg said:
>Now, it is true that, ahem, certain prominent sip vendors have products
>called firewall control proxies which muck with the SDP. Whether these
>things are rightly proxies, based on the SIP spec, or a B2BUA, is more a
>matter of technical marketing than standards, so I would not lose too
>much sleep over it. Its far less a stretch than what people are calling
>softswitches these days ;). Our job here at IETF is to write standards
>that work and are good for the Internet.

And Rohan responded:
> I agree with Jonathan here.  We should leave the spec as is with the
> exception of *adding* Contact-Length.  Another prominent vendor that I
> know has an ALG that modifies the SDP, and I don't even want to
> *think* about what you would call it.  Both of these will break as soon as
> someone turns on the end-to-end SMIME integrity and encryption.  I would
> like to have that problem some day...

I still believe we should recognize that such things will exist, and that
services will need to cope with them, and that guidance to designers of
new services would benefit from knowing, in advance, what such elements
might do to cause them trouble.

Bill Marshall
[email-masked]

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 29 Apr 2002 10:26:14 +0100

The special arragement option depends on how the network operator deals with
providing it.
 
If the network operator gives it to all and everyone, then it is as you say.
Essentially as the From field. This requires no further consideration.
 
When it was specified however, one major use was identified as being from
enterprise networks, in fact they were the main proponents of such a usage.
If one follows the private network ISDN signalling specifications (ISO PSS1
and ECMA QSIG) then enterprise delivered values are screened in the
enterprise network, thus as far as the enterprise network is concerned, they
are regarded as network asserted rather than as user asserted. The only
reason for the special arrangement coding (user provided unscreened) in this
case is that the public network operators wanted a distinction between
public network asserted identities and private network asserted identities. 
 
So far the point is therefore that while enterprise networks can and do
assert identities, they may not be fully trusted. In the ISDN, it is trusted
sufficiently in order to deliver the CLIP service to the remote user, but is
not trusted sufficiently for malicious call identification. If we are to
achieve 100% mapping to the ISDN/PSTN, then we may need to reflect this
distinction.
 
I certainly do not believe that we should treat the unscreened coding in all
cases as mapping to the From header, as this will not give a 100% mapping in
the reverse direction. However, in the longer term, providing some values
indicating who provided the assertion may resolve this problem. In this case
dummy values such as "non-public network operator" could be used as the
asserting identity when such values are mapped.
 
In the short term, as a large number of public network operators do not
allow the special arrangement to exist, it may be best to ignore the special
arrangement, or at least the finer details of the mapping.
 
Keith

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: 18 April 2002 12:00
To: 'Dean Willis'; William Marshall; [email-masked]
Subject: RE: [Sip] z9hG4bK forever ???

...Mark 

> From: Dean Willis [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> is a capability the widely-deployed PSTN (as opposed to say Q.SIG) 
<https://www1.ietf.org/mailman/listinfo/sip>