Subject: [Sip] FYI: IETF Liason Statement to 3GPP

From: Rohan Mahy <[email-masked]>
Date: Sun, 1 Sep 2002 12:18:33 -0700

Hi Folks,

Below is a copy of the liason statement that will be sent to 3GPP later 
today.

thanks,
-rohan

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

From: Chairs, SIP, SIPPING, and SIMPLE Working Groups of the Internet 
Engineering Task Force
Cc:   Area Directors, Transport Area, Internet Engineering Steering Group
To: CN and SA Working Groups of the Third-Generation Partnership Program
Subject: Liaison Statement on Interoperability Issues and SIP in IMS

I. Introduction

The IETF is made up of working groups, such as the Session Initiation
Protocol (SIP) Working Group, and these are supervised by the
Internet Engineering Steering Group, or IESG, whose goals
include maintaining technical quality and assuring that
its work is consistent with the "big picture" of Internet principles
and architecture.  The IETF also has the Internet Architecture
Board, or IAB, ensuring the big picture is clear.

The IESG's Area Director for SIP, and the IESG as a whole have given
repeated guidance to the SIP Working Group in the process of development 
and
approval of the consensus standards such as RFC 3261, during which
several points have been raised that we believe are related to the usage
of SIP in the Internet Multimedia Subsystem (IMS) specifications
being developed in 3GPP.  Our goal is to communicate these points at a
technical level, from the consensus of our approved standards, as
the Working Group chairs, to you as counterpart technical Working Group
chairs.  We wish to convey introductory points here, points about
interoperability in section 2, and specific issues about the IETF
SIP standards in section 3.

The key guidance is:

a) Internet standards are intended to have broad applicability for all
    aspects of the Internet, including private networks that use IP,
    whether or not connected to the public network. Developing
    "profiles"--subsets of or exceptions to these standards, whether
    for use on public or private networks, is dangerous because of
    the very high probability that such profiles will be incompatible
    with those deployed on the Internet as a whole, and we have
    learned that networks which are disconnected today somehow
    become connected tomorrow.  Thus inter-operability remains
    a critical issue, even for currently disconnected networks.

b) Any implementation of a protocol claimed or named to be an Internet
    protocol, such as SIP, should be greatly consistent with both the
    specification and the practice of that protocol on the Internet. If
    an implementation doesn't interoperate, and/or does not operate
    (if suitably configured) in general Internet environments, it
    is actually a separate protocol and should not be advertised or
    named the same as an implementation of an Internet protocol.

We believe that 3GPP chose to use SIP and other Internet protocols in
the IMS specification not only as a matter of expedient reuse, but
because of advantages such as interoperability, open
specification, and widespread deployment offered by these
protocols. Further, we believe that 3GPP's choice was influenced by
the expectation that these Internet advantages would lead to benefits
such as reduced systems cost, access to a wide variety of applications
being developed around the Internet, and the consequent ability to
develop and offer new value-added applications to wireless subscribers
and generate new revenue for wireless operators. We support this
choice and rationale, and welcome 3GPP as a collaborator in making the
best possible use of our protocols. To that end, we welcome 3GPP input
on requirements for the unique aspects of their environment, in the 
further
development of SIP and other Internet protocols, and look forward to
collaborating with 3GPP to facilitate developing the best understanding
for all about how best to configure SIP and other Internet protocols for
interoperability between the IM subsystem and the Internet.

II. Interoperability Issues

Careful review of published IMS specifications, by knowledgeable
individuals who participate in both 3GPP and IETF, has raised
certain concerns relating to interoperability (both in terms of a and b)
between IMS and the Internet.  The Chairs of the IETF SIP and
SIPPING Working Groups offer this liaison statement as guidance and
suggestions to 3GPP, in hopes of assuring effective interoperability.
We realize that some of these concerns stem from recent enhancements
to the SIP protocol, and cannot be immediately rectified in the IMS
specifications, whereas other concerns may be more readily
addressable. We encourage 3GPP to address these concerns to the
extent possible in IMS Release 5, and to address them and any
underlying issues before the finalization of IMS Release 6. We will
assist wherever reasonably possible, and welcome further
involvement with 3GPP to resolve these concerns.

In general, we would like 3GPP to consider two interopability goals:

1) While operator and business policy configurations (which are
    not matters of IETF concern) may prevent such behavior,
    the IMS specification itself should not prevent the possibility that
    an IMS user can access SIP services on the Internet, or establish
    SIP sessions with users on the Internet. This should be possible
    without requiring that some sort of application-level-gateway to
    modify the IMS protocols. In most cases, we expect that an IMS
    user should be able to access Internet applications even if there
    is no explicit support in IMS for that application.  This implies that
    IMS users have access to complete SIP implementations including
    security capabilities.

2) The SIP specification (RFC 3261) and the other related IETF
    standards allow for building strong and secure Internet applications.
    An IMS operator should be able to buy an off-the-shelf, IETF
    standard, commercial SIP system that implements the RFCs related
    to SIP, and which also has support for IMS-specific capabilites,
    plug it in, use configuration options to set up policies, and make
    it work in IMS systems.  Configuration and local policies would 
establish
    what local authentication, authorization, AAA, reporting, SIP
    P-headers, and other options are used that might not be widely
    implemented in the Internet--or indeed are not in the case of 
P-headers.
    Vendors building an IMS system should not need to build two
    completely separate products to address IMS and SIP in the Internet.
    The key point here is that there should be little or no difference
    other than the configuration choices conceptually in an
    implementation used in IMS and one used outside IMS.  This would
    be an ideal interoperability goal, and well suited to the IETF's
    orientation of standardizing what is implemented and available
    to the operator or user of the equipment (e.g. minimum
    mandatory to implement strong security), not what is used or how
    it is used.

III. Specific Concerns on SIP in IMS Release 5

The following discusses some of our technical concerns with IMS. It
should be noted that this is by no means an exhaustive list of
issues. It is intended primarily to introduce the types of
behaviors that concern us and the probable impact of these behaviors
on interoperability. However, where specific issues are illustrated,
we request specific consideration of these concerns by 3GPP.

There are three general classes of issues that we have identified:

1. IMS Call State Control Function (CSCF) nodes send messages that
    the SIP RFCs reserve to User Agents without implementing
    the functions required for User Agents. There is some 3GPP
    view that this is justified by viewing the CSCF as a "back to back
    user agent" with the User Agent, but it is not done correctly,
    because the CSCF must be implemented in all ways as User Agent
    in order to be serve as a B2BUA in this manner.

2. IMS CSCF nodes modify headers in ways explicitly prohibited to
    proxies by the SIP RFCs, again without implementing associated UA
    behavior.

3. IMS CSCF nodes modify bodies in messages which is not permitted to
    proxies by SIP RFCs, again without implementing the associated UA
    behavior.

A number of participants in the SIP working group, including the
chairs authoring this liaison statement, have identified specific
concerns with the IMS Release 5 specifications as we understand
them.  Some of these have been discussed in the context of
SIP or SIPPING chartered work.  We do not propose solutions here,
but we invite consideration of these concerns, with the goal of
3GPP achieving a better alignment to the IETF's SIP RFCs after
discussion in 3GPP and in the SIP and SIPPING mailing lists over some
period.  IETF will provide any support and assistance that will
help.

1) The P-CSCF may send a BYE on behalf of the UA, generally because
    the P-CSCF has been notified by the radio layer that the UA has
    lost contact.  Of course, the P-CSCF doesn't have the credentials
    to provide authentication of the BYE, so many UAs will consider this
    to be a forged message. This also renders 3GPP UAs vulnerable to
    denial of service attacks using forged BYEs.

2) The P-CSCF strips away Route, Record-Route, Via, Path, and
    Service-Route headers before passing messages on to the UA. It
    then reinserts them messages in the other direction,
    and may also strip out Route headers inserted by the UA. This
    breaks end-to-end protection using S/MIME and prevents the UA from
    accessing external services using loose routing. It also prevents
    the UA from knowing about any proxies that may have piggybacked on
    its registration using the Path mechanism, which is a serious
    violation of the openness principle and leaves 3GPP users
    registering with external servers subject to certain
    man-in-the-middle attacks affecting REGISTER messages without any
    way to detect those attacks.

3) The CSCF may edit SDP sent from or to the UA in order to force the
    selection of codecs considered favorable to the operator. This has
    the side effect of breaking end-to-end protection of the SDP using
    S/MIME. It also precludes interoperating with external elements
    when both the IMS UA and the external UA share only a common
    codec not supported by the P-CSCF.

4) The S-CSCF MAY (we believe this is still being discussed in 3GPP)
    obfuscate the To: and From: fields in messages. This appear to be
    based on a particular interpretation of privacy regulation in
    certain European domains.  It has the side effect of breaking
    end-to-end protection with S/MIME and breaking external services
    using the To: and From: fields, such as the most common forms of
    caller-ID used with SIP today.

5) The P-CSCF filters messages from the UA to assure that only an
    identity known to the P-CSCF is presented by the UA. This may
    interact with the preceding characteristic. This appears to be
    required to accommodate the authorization model of 3GPP, which
    authenticates only REGISTER transactions and uses them to establish
    a security association between a UA and the P-CSCF. The side effect is
    that a 3GPP user may use only the operator-provided identity and
    may not be able to effectively use third-party services that
    provide other identities unless those services provide identity
    transformation with a back-to-back user agent.

6) The I-CSCF (or THIG) may encrypt Via and Route information when
    acting in topology-hiding mode. This was allowed for in earlier SIP
    specifications, but the use has been deprecated for a variety of
    reasons. The exact impact on interoperability remains unknown.

7) Some CSCF elements and AS may manipulate message bodies.
    Manipulating message bodies in a proxy is forbidden in RFC 3261
    because it breaks end-to-end protection using S/MIME. These
    elements do not appear to implement all of the UA behavior that
    would enable them to preserve end-to-end protections.

As stated above, this statement does not recommend a timeframe for
aligning on the issues decribed above, but they are important.  One
way to ensure better aligment going forward is in a general 
recommendation.
The SIP Working Group chairs suggest that the implementers of
systems for IMS should consider doing interoperability testing of their
implementations against other SIP implementations. The SIPit
interoperability events are organized explicitly for this purpose,
and we intend to use these events to support the documentation of
interoperability of features required for advancing SIP and related
RFCs from "Proposed Standard" to "Draft Standard" status in the
IETF. Your participation in such testing would be helpful to the whole
SIP community.

IV.  Contacts:

Dean Willis, [email-masked], for SIP Working Group Chairs
Rohan Mahy,  [email-masked], for other SIP-related WGs' Chairs
Allison Mankin, [email-masked], for the IESG

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Mon, 2 Sep 2002 10:52:36 -0700

Hello again,

I just wanted to clarify something.  Despite the subject of *this* 
thread, this liason statement is from the chairs, not from "IETF" as a 
whole.  When I sent this to 3GPP the subject was "Liaison Statement on 
Interoperability Issues and SIP in IMS".

thanks,
-rohan

On Sunday, September 1, 2002, at 12:18 PM, Rohan Mahy wrote:

> repeated guidance to the SIP Working Group in the process of 
> development and