The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem
draft-vanelburg-sipping-served-user-08

[Ballot discuss]
Ok - I see what you are saying in your reply to this. The line

  Proxies MUST
  remove the header when forwarding requests to untrusted nodes or when
  the proxy does not have knowledge of any other proxy in the route set
  that is able to understand the header.

This still seems to leave open some pretty wide doors. For example, say that B was in the route set, but not in the Trust Domain, yet B was known to support this. Clearly it should not be forwarded to B but this text seems to allow it. I suggested one way to fix this in the comment.

[Ballot comment]
Change "trust domain" to "Trust Domain"

OLD
When forwarding the request to a trust node
NEW
When forwarding the request to a node in the Trust Domain

OLD
  Proxies MUST
  remove the header when forwarding requests to untrusted nodes or when
  the proxy does not have knowledge of any other proxy in the route set
  that is able to understand the header.
NEW
  Proxies MUST
  remove the header when forwarding requests to nodes that are not in the Trust Domain or when
  the proxy does not have knowledge of any other proxy in the route set includes a proxy that will remove it before it is routed to any node that is not in the Trust Domain.

[Ballot discuss]
Cullen's note about Proxy-Require seems important.

Since this document specifies a feature specific to 3GPP IMS, it's
title should say "3GPP IMS", or something similar.

Section 6 should use "example.com".

[Ballot discuss]
In the absence of a discovery mechanism, the security of the P-Served-User
header field seems to rely on manual configuration of a database of
P-Served-User aware proxies within the given trust domain.  It might be
a good idea to describe the contents of this database, and note that the
protecting the integrity of this database is critical.

[Ballot discuss]
There was a Gen-ART Review of draft-vanelburg-sipping-served-user-04.txt
  by Francis Dupont.  A new version of the document has been posted, but
  there was not a reply to the review.  The suggestions in the review were
  clearly not accepted, so a reply is needed.

  There was a SecDir Review of draft-vanelburg-sipping-served-user-05.txt
  by Sandy Murphy.  There has not been a reply to this review either.

[Ballot discuss]
The security section is not adequate to meet the security needs this draft describes. When it says that a proxy "MUST not insert the header unless ..." it really means "the PROXY MUST remove the header unless ....". To ensure that proxy does this, you need to ensure that proxy actually supports this specification since ones that did not would not remove the header and thus not meet the security requirements. To ensure this, I suspect you need a Proxy-Require option tag.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following assignments in the "Session Initiation Protocol (SIP) Parameters " registry located at
http://www.iana.org/assignments/sip-parameters
sub-registry "Header Fields"

Header Name compact Reference
----------------- ------- ---------
P-Served-User [RFC-vanelburg-sipping-served-user-04]

We understand the above to be the only IANA Action for this document.