[Sip] comments on privacy-04

["Peterson, Jon" <jon.peterson@neustar.biz>]

Since we now have a WGLC on sip-privacy-04, I have a couple of comments that
I apologize in advance for not presenting earlier.

I think that SIP needs a network-provided privacy mechanism, and I think the
system described by this draft is a reasonable solution to that problem.
However, the sip-privacy-04 system is more complicated than it needs to be
in order to solve this problem, and these complexities give rise to
confusions about the implementation and applicability of the mechanism.
Today, the SIP charter speaks to a need for privacy mechanisms but not, for
example, for new identity-assertion mechanisms.

Jon Peterson
NeuStar, Inc.

-----

- rpi-screen: As the recent thread in the SIP ML suggested, the behavior in
sip-privacy-04 for handling RPIDs received from an untrusted source might be
confusing. If untrusted entities shouldn't add the RPID header (which I
gather from the applicability), then why not say that a proxy MUST remove
any RPID headers it receives from an untrusted source? Today, it sets the
'screen=no' parameter instead. However, no behavior in the document is
defined for using an RPID header with 'screen=no' - it merely says that a UA
that receives it in a message shouldn't trust it (although what exact
behavior this entails is unclear). If this is totally deadweight in
signaling, it should just be removed - SIP messages don't need any help
getting larger. If you receive a RPID from a trusted entity, 'screen=yes'
could just be assumed; a parameter that says "trust me" may very well be
redundant in a trusted network. If it turns out that an RPID that the proxy
will add itself is identical to an RPID that has been supplied by an
untrusted source, then while this may be just lip service I think the least
ambiguous and most secure language is still to say that the proxy removes
the untrusted header and adds a trusted header. If for whatever reason it
turns out we do need this parameter, the idea that both 'screen=yes' and
'screen=no' can appear in the same RPID header (this is permitted in 6.1)
must be unnecessary. Finally, if you are going to have this parameter,
calling it "screen" is a little misleading; screening in the PSTN can refer
to selectively blocking calls based on the original calling/called number
(to me it implies that some feature has been invoked that inspects the ANI
and the dialed number and determines that this is a legitimate target for
the caller's class of service). Maybe "verify" would make more sense.

- rpi-pty-type: This parameter allows you to specify which party's identity
is contained in the RPID header ("calling" or "called" are currently
allowed). However, no motivation for this capability is presented in the
draft - it defines the conditions under which these parameters are inserted,
but there is no recipient behavior that justifies their insertion. Moreover,
the behavior for adding the parameter holds only that a request contains a
'calling' id, and the response contains a 'called' id. This sounds right -
I'd imagine that a privacy mechanism would use the RPID header to express
the private identity of the sender of a message; and in fact, if the
rpi-id-type header is not present, that's exactly what the recipient
assumes. So in short the motivation for this parameter isn't clear. If there
is a need for it then the draft should describe it, otherwise, I think this
parameter should be removed, since the default behavior seems appropriate.
This draft allows network-asserted identity as a means to end-user privacy;
the identity that is private is the identity of the originator of the
message. Finally, if you are going to have this parameter anyway, "calling"
and "called" are a little too telephony-specific, and those telephony roles
don't map cleanly onto the mechanism. This is already causing problems in
the draft: in 7.5, it suggests that you proxies should use the "calling"
rpi-id-type to identify the originator of any INVITE request - but what
about a re-INVITE in the reverse direction in the middle of a dialog?

- rpi-id-type: I find this the most problematic of the existing parameters.
I believe that the sip-privacy mechanism (at least, this chartered work)
exists to make an identity private, not to invent new forms of identity. I
believe that the kinds of entities in a SIP network that have privacy
concerns are users - not client devices, or intermediary devices, or what
have you. Now, that isn't to say that keeping a user's identity private
might not require hiding information about the device from which a user is
calling, and so on. This does not, however, motivate a need for a
network-asserted device URI like the "term" value of the rpi-id-type. No
proxy or UAS behavior is suggested in the document for use of the "term"
rpi-id-type, nor is it made clear how a proxy inserting this RPID would know
to assert an "identity" for a terminal (possibly from some out-of-band
authentication mechanism? but does the terminal authenticate itself as well
as the user?). Also, the distinction between "user" and "subscriber" in
privacy-04 is a little confusing. They represent a new distinction between
identities in SIP, and it isn't particularly clear why they are required as
part of a privacy mechanism; the difference between a "subscriber" (the
default, and traditionally the user of the SIP session), and a "user" seems
to be somehow related to settlement, or the administrative grouping of user
accounts. It isn't clear how a proxy would ascertain that it needs to apply
these parameters to an RPID, or how they'd be used  So, I'd also like to
suggest that if there is a need for a parameter or header that can assert
arbitrary new types of identity (distinguishing between subscribers or
users, URIs for devices, secret superhero identities, etc), then I for one
would like to see this proposed in a separate document. New types of
identity introduced to SIP may in turn have some privacy requirements, but
it does not follow from this that a privacy document is the right place to
propose all kinds of new identities. If these identities are useful outside
the context of privacy, that might have suggested that this is a separable
issue. The privacy considerations for these new identities can be explored
subsequent to their acceptance by the SIP community. For the time being, I
think this parameter is superfluous and confusing, and it should be removed.

- rpi-privacy: To me this parameter is really the crux of the draft - that
and the fact that the RPID header can be added, deleted or modified only by
proxy servers. However, it hasn't been clear to me why the privacy parameter
is defined only within the scope of the RPID header. If we would like this
draft to have general applicability to the privacy problem, perhaps it would
be better if "privacy" were defined as a general URI header. The RPID header
should usually, but perhaps not always, contain a URI that has a "privacy"
parameter. I'd be interested to hear if there are scenarios within the
applicability of the draft in which the RPID header should be used without a
"privacy" parameter - perhaps the presence of "privacy" in RPID could be a
MUST. However, I see no reason why it might not make sense for other URIs
than those in an RPID to contain the "privacy" parameter.

- Extensibility: While it's generally desirable for a mechanism to be
extensible (you should reuse existing mechanisms to solve new problems if
you can), sometimes extensibility can be confusing. Given the strict
applicability that precedes sip-privacy-04, it isn't really clear how much
extensibility is desirable - and at what point extensibility would invite
the use of RPID to architectures outside of that applicability. While I
applaud the move in sip-privacy-04 to require that extensions to the RPID be
published in an RFC, I'm not sure that this alone is sufficient. The middle
two parameters I've discussed above (rpi-ip-type and rpi-pty-type) are
extensible in privacy-04. Given that I'm a little queasy on their current
values (not to mention their overall relevance), it would probably go
without saying that I'm unsure about extending them further. These
reservations do not however carry over to the 'rpi-privacy' parameter - I
believe that should be extensible.

- RPID-Privacy: The need to assert any of the above parameters in the
RPID-Privacy should probably also be revisited in the light of the
considerations above. I think it's pretty clear that an RPID-Privacy header
should express the wishes of the originating user to keep their identity
private in this message, and it isn't clear why a user would want to tell
the network to, say, keep some other user's identity private. If this is
needed, the draft should explain when it would be useful.

- Gobbledygook in From: The motivation for cryptographically random garbage
in the From header may have gone away in light of the mandate for the 'tag'
parameter in the From field of requests in rfc2543bis, which guarantees that
dialog identification will be globally unique. I would suggest instead that
the From header for an anonymous request should be completely homogenous, so
all private From headers look alike. rfc2543bis09 actually contains examples
of both - in some places, anonymous requests use an apparently random user
and/or host, in other places something standard like 'anonymous@localhost'.
I would recommend the latter, if only because you already have to build
something globally unique for the tag - or at the very least, that this
point be revisited in light of bis. 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip