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

From: William Marshall <[email-masked]>
Date: Wed, 17 Apr 2002 08:10:11 -0400 (EDT)

Mark Watson pointed out:
> 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

I would go even a few steps farther.

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

So my recommendations:
1) It is worthwhile recognizing these situations in draft-ietf-sip-rfc3261bis,
   and including text that limits the message transformations that such
   network elements can perform.  Essentially this means defining the
   previously coined term "transparent B2BUA".

2) New serivces MUST be designed with the assumption that such "transparent
   B2BUAs" will be in the path, minimize the ways they will fail with such
   message transformations, and discuss the recovery action that a UA may
   take in such failure cases. In the same way that new services MUST be
   designed knowing that forking may happen.  (draft-ietf-sip-guidelines?)

An example where (2) has already been followed is draft-ietf-sip-replaces;
it uses to-tag and from-tag, rather than full contents of From and To.

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: "Dean Willis" <[email-masked]>
Date: Wed, 17 Apr 2002 10:46:55 -0500

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

What you fail to distinguish is that like identity, there are two sorts
of privacy:

1) UA asserted
2) Network asserted

UA asserted privacy requires that the network NOT tamper with what the
UA has done, nor insert additional information that compromises the
privacy of the UA.

Network asserted privacy  requires a full, non-transparent B2BUA. I see
this as an OPTIONAL service, EXTERNAL to the proxy-like CSCF elements.
In other words, an anonymizer application.

--
Dean