Subject: [Sipping] Protocol Action: ISUP to SIP Mapping to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 03 Sep 2002 10:32:04 -0400

The IESG has approved publication of the following Internet-Draft as
a Proposed Standard:

  o ISUP to SIP Mapping <draft-ietf-sipping-isup-06.txt>

  This document is the product of the Session Initiation Proposal
  Investigation Working Group. The IESG contact persons are Allison
  Mankin and Scott Bradner.

  Technical Summary

  The "ISUP to SIP Mapping" document describes a way to perform the
  mapping between two signaling protocols: the Session Initiation
  Protocol (SIP) described in RFC 3261 and the ISDN User Part (ISUP) of
  the Signaling System 7 (SS7) protocol used in telephone networks. This
  mechanism could be used when phone calls use both SIP in an IP network
  and the Public Switched Telephone Network (PSTN). ISUP is used in
  telephone networks for controlling telephone calls and for maintenance
  of the network (blocking circuits, resetting circuits etc.).

  The scope of this mapping document is limited to allowing SIP elements
  such as proxy servers (which do not typically understand ISUP) to make
  routing decisions based on ISUP criteria such as the called party
  number. This document consequently provides a SIP mapping only for
  those ISUP parameters which might be used by intermediaries in the
  routing of SIP requests. As a side effect of this approach,
  translation also increases the overall interoperability by providing
  critical information about the call to SIP endpoints that cannot
  understand encapsulated ISUP, or perhaps which merely cannot
  understand the particular ISUP variant encapsulated in a message.

  This document also is limited only to the call functionality of ISUP.
  Maintenance messages dealing with PSTN trunks are treated only as far
  as they affect the control of an ongoing call; otherwise these message
  neither have nor require any analog in SIP.

  Working Group Summary

  The current version of the document reflect the issues raised during
  the IETF Last Call. There was considerable discussion during and
  for a short time after the IETF Last Call period, within the working
  group mailing list, related to conflicting interpretations of some of
  the mapped ISUP parameters. A summary of the results of discussion
  was prepared for the list by the document editor and consensus was
  agreed upon.
 
  Protocol Quality

  These documents were reviewed for the IESG by Allison Mankin and
  Steve Bellovin.

Notes to RFC Editor:

Please replace the first paragraph of Section 15, Security Considerations,
with the following two paragraphs, in order to satisfy concerns
raised in the IESG Security Area Director review, beyond those met
by the -06 draft itself.

15. Security Considerations

   The translation of ISUP parameters into SIP headers may introduce
   some privacy and security concerns above and beyond those that have
   been identified for other functions of SIP-T [9A].  Merely securing
   encapsulated ISUP, for example, would not provide adequate privacy
   for a user requesting presentation restriction if the Calling Party
   Number parameter is openly mapped to the From header. Section 12.2
   shows how SIP Privacy [9B] should be used for this function.  Since
   the scope of SIP-ISUP mapping has been restricted to only those
   parameters that will be translated into the headers and fields used
   to route SIP requests, gateways consequently reveal through
   translation the minimum possible amount of information.

   A security analysis of ISUP is beyond the scope of this
   document.  ISUP bridging across SIP is discussed more fully in
   [9A], but Section 7.2.1.1 discusses processing the translated
   ISUP values in relation to any embedded ISUP in a request 
   arriving at PSTN gateway.  Lack of ISUP security analysis may pose
   some risks if embedded ISUP is blindly interpreted.  Accordingly,
   gateways SHOULD NOT blindly trust embedded ISUP unless the
   request was strongly authenticated [9A], and the sender
   is trusted, e.g., is another MGC that is authorized
   to use ISUP over SIP in bridge mode.  When requests are received
   from arbitrary end points, gateways SHOULD filter any
   received ISUP.  In particular, only known-safe commands
   and parameters should be accepted or passed through.  Filtering
   by deleting believed-to-be-dangerous entries does not work well.
 
--------
Please replace the text as follows:

Section 7.2.1.1

Old:

      When a SIP INVITE arrives at a PSTN gateway, the gateway SHOULD
      attempt to make use of encapsulated ISUP (see [3]), if any, within
      the INVITE to assist in the formulation of outbound PSTN signaling.

New:

      When a SIP INVITE arrives at a PSTN gateway, the gateway SHOULD
      attempt to make use of encapsulated ISUP (see [3]), if any, within
      the INVITE to assist in the formulation of outbound PSTN signaling,
      but SHOULD also heed the security considerations in Section 15.
--------

Old:

      One mechanism that provides a
      way of supporting fully-featured privacy negotiation (which interacts
      well with identity management systems) is described in [20].

New:

      One mechanism that provides a
      way of supporting fully-featured privacy negotiation (which interacts
      well with identity management systems) is described in [9A].
                                                                                                                  
--------

Please add to the Normative References:

[9A] Vemuri, A., Peterson, J., "SIP for Telephones (SIP-T):
          Context and Architectures," draft-ietf-sipping-sipt, Approved
          July 2002.

[9B] Peterson, J., "A Privacy Mechanism for the Session Initiation
          Protocol (SIP)", draft-ietf-sip-general", Approved June 2002.

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