[Sipping] SIPPING review of draft-vanelburg-sipping-served-user-02.txt

[Spencer Dawkins <[e-mail]>]

I was asked to provide an expert review for this draft. My review follows.

The ADs should pay particular attention to notes 3 and 7 below - they are 
the requirements I'm still not sure are satisfied.

I also included additional comments for the authors, but these comments 
should not be considered part of the expert review.

Thanks,

Spencer

Summary...

1.  A designated expert (as defined in RFC 2434 [4]) MUST review the
       proposal for applicability to SIP and conformance to these
       guidelines.  The Expert Reviewer will send email to the Transport
       Area Directors on this determination.  The expert reviewer can
       cite one or more of the guidelines that haven't been followed in
       his/her opinion.

* Spencer Dawkins is the designated expert. This e-mail is sent to the
SIPPING mailing list. The RAI ADs are copied in this email.

   2.  The proposed extension MUST NOT define SIP option tags, response
       codes, or methods.

* The draft satisfies this requirement: The draft defines a new P-Header
called "P-Served-User" that identifies an IMS Public User Identity.

I should mention that I didn't see any explanation of usage for this
P-Header - is it applicable for all SIP methods? response codes? etc.

   3.  The function of the proposed header MUST NOT overlap with current
       or planned chartered extensions.

* The draft satisfies this requirement to the best of my ability to tell
(although this isn't easy to know for sure because "served user" is only
defined as "IMS Public User Identity of the user" in this specification -
I'm fairly sure that we don't have current or planned chartered extensions
for exactly this, but can't be sure that we don't have current or planned
chartered extensions for anything analogous to this, and that's the critical
question).

I wish this draft did not define Yet Another Identity (as Jeroen pointed
out), but I don't think this concern belongs in my expert review.

   4.  The proposed header MUST be of a purely informational nature, and
       MUST NOT significantly change the behavior of SIP entities which
       support it.  Headers which merely provide additional information
       pertinent to a request or a response are acceptable.  If the
       headers redefine or contradict normative behavior defined in
       standards track SIP specifications, that is what is meant by
       significantly different behavior.

* The draft satisfies this requirement: the P-Served-User header contains an
IMS Public User Identity. This header does not redefine or contradict
normative behavior defined in standards track SIP specifications.

A proxy or AS might change its behavior based on a difference between
P-Served-User and some other identity, but since conveying the difference
between this the P-Served-User identity and other SIP identities is the goal
for this P-header, this effect seems reasonable.

   5.  The proposed header MUST NOT undermine SIP security in any sense.
       The Internet Draft proposing the new header MUST address security
       issues in detail as if it were a Standards Track document.  Note
       that, if the intended application scenario makes certain
       assumptions regarding security, the security considerations only
       need to meet the intended application scenario rather than the
       general Internet case.  In any case, security issues need to be
       discussed for arbitrary usage scenarios (including the general
       Internet case).

* The draft satisfies this requirement:  The security section describes the
security considerations that apply to insecure network paths and allows for
two methods of securing those paths (physical security and IPsec). The draft
also points out the need to remove these headers at domain trust boundaries.

   6.  The proposed header MUST be clearly documented in an (Individual
       or Working Group) Informational RFC, and registered with IANA.

* The draft satisfies this requirement:  It is intended to become an
Informational RFC, and lists the header in its IANA section. The IANA
section includes all the information that
http://www.iana.org/assignments/sip-parameters contains for entries in the
header field subregistry.

   7.  An applicability statement in the Informational RFC MUST clearly
       document the useful scope of the proposal, and explain its
       limitations and why it is not suitable for the general use of SIP
       in the Internet.

* The draft may very well satisfy this requirement:  Two points here.

First, I'm reading "in the Internet" as "in non-IMS environments", so the
text that says

   When SIP is used on the Internet, there are typically no proxies
   involving an application server over an ISC interface.  Consequently,
   the P-Served-User header field does not seem useful in a general
   Internet environment.

does make me wonder if similar functionality is useful in non-IMS
environments (for example, MEDIACTRL use of ASs might also find a similar
capability useful).

Second, sections 3.1-3.4 are very dense (a lot of 3GPP-specific call flows
that are mostly the same from scenario to scenario), and I'm not sure how
"clear" this text is to the non-3GPP SIP community that needs to reach 
consensus that this P-Header would not be useful in a non-3GPP environment.

--------------------------------------------------------------

The following notes are included for the draft authors, but aren't part of
the expert review.

1.  Introduction

   The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia
   Subsystem) uses SIP (RFC3261 [2]) as its main signalling protocol.
   (For more information on the IMS, a detailed description can be found
   in 3GPP TS 23.228 [8] and 3GPP TS 24.229 [10].) 3GPP has identified a
   set of requirements that can be met, according to the procedures in
   RFC 3427 [5], by defining a new SIP P-header.

Spencer: I am hoping that you're saying "that are most appropriately met",
but (nit) this should probably be "met by defining a new SIP P-header,
according to the procedures in RFC 3427 [5]".

Spencer: I note that neither the abstract nor the introduction actually
summarize what that requirement is. Could a one-sentence description be
added?

   The remainder of this document is organized as follows.  Section 3
   outlines the problem using particular service scenarios and Section 4
   discusses the requirements derived from these scenarios.  Section 5
   defines the P-Served-User header field, which meets those
   requirements, and Section 6 discusses the applicability and scope of
   this new header field.  Section 7 registers the P-Served-User header
   field with the IANA and Section 8 discusses the security properties
   of the environment where this header field is intended to be used.

3.1.  General

   In the 3GPP IMS the S-CSCF (Serving CSCF) is a SIP proxy that serves
   as a registrar and handles originating and terminating session states
   for users allocated to it.  This means that any call that is
   originated by a specific user or any call that is terminated to that
   specific user will pass through an S-CSCF that is allocated to that
   user.

Spencer: If this draft can be slightly de-3GPPed, it would be much easier
for the IETF community to understand (and to agree with). Simply referring 
to the CSCF as a SIP proxy in many places would be a simple change, and text 
like "over the Cx interface" is true but not necessary for an understanding 
of this proposed P-header within the IETF. Some uses of 3GPP terminology in 
the Abstract and Introduction are useful, because they provide context for 
the request.

   At the moment that an S-CSCF is allocated for a specific user, a user
   profile is downloaded to the S-CSCF from the HSS (Home Subscriber
   Server) over the Cx interface.  This user profile tells the S-CSCF
   whether the user is allowed to originate or terminate calls or

Spencer: either this is garbled or my English skills have evaporated.
Perhaps "important for this particular document" was cut-and-pasted in
error?

   important for this particular document whether an AS needs to be
   linked in over the ISC interface.  The user profile information that
   determines whether particular initial request need to be sent to a
   particular AS is called initial Filter Criteria (iFC), see for
   example 3GPP TS 23.218 [7].

Spencer: the previous paragraph has a lot more detail than necessary. Is
this saying more than "When a S-CSCF is allocated for a specific user, the
S-CSCF receives a profile that tells the S-CSCF whether the user is allowed
to originate or terminate calls, or whether an application server is
required"?

   To be able for an S-CSCF to perform its responsibilities it needs to
   determine on which users behalf it is performing its tasks and which
   session case is applicable for the particular request.  (For session
   case see 3GPP TS 29.228 [11]) The session case distinguishes the
   originating and terminating call cases and whether the particular
   user is registered or not.

   When the S-CSCF determines that for an incoming initial request the
   originating call case applies, it determines the served user by
   looking at the P-Asserted-Identity header field ( RFC 3325 [4]) which
   carries the network asserted identity of the originating user.  When
   after processing the iFC for this initial request the S-CSCF decides
   to forward the request to an AS, the AS has to go through a similar
   process of determining the session case and the served user.  Since
   it should come to the same conclusion that this is an originating
   session case it has to look at the P-Asserted-Identy header field as
   well to determine the served user.

   When the S-CSCF determines that for an incoming initial request the
   terminating call case applies, it determines the served user by
   looking at the Request-URI ( RFC 3261 [2]) which carries the identity
   of the intended terminating user.  When after processing the iFC for
   this initial request the S-CSCF decides to forward the request to an
   AS, the AS has to go through a similar process of determining the
   session case and the served user.  Since it should come to the same
   conclusion that this is a terminating session case it has to look at
   the Request-URI as well to determine the served user.

   In the originating case it can be observed that while the P-Asserted-
   Identity header field just represents the originating user when it
   enters the S-CSCF, it is overloaded with another meaning when it is
   sent to an AS over the ISC interface.  This other meaning is that it
   serves as a representation of the served user.

   In the terminating case a similar overloading happens to the Request-
   URI, while it first only represented the identity of the intended
   terminating user, it is overloaded with another meaning when it is
   sent to an AS over the ISC interface.  This other meaning is that it
   serves as a representation of the served user.

   In basic call scenarios this does not show up as a problem, but once
   more complicated service scenarios (notably forwarding services)
   needs to be realised it poses severe limitations.  Such scenarios are
   brought forward in the following sub sections.

3.2.  Diversion; continue on terminating leg, but finish subsequent
      terminating iFC first

Spencer: given that sections 3.1-3.4 are very dense and repetitive, and you
think 3.2 justifies this header, you might either delete the others or 
simply list additional scenarios in one paragraph. 




_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP