--- 1/draft-ietf-speermint-architecture-09.txt 2010-03-09 02:11:13.000000000 +0100 +++ 2/draft-ietf-speermint-architecture-10.txt 2010-03-09 02:11:13.000000000 +0100 @@ -1,18 +1,53 @@ -Speermint Working Group A.Uzelac(Ed.) -Internet Draft Global Crossing -Intended status: Informational -Expires: May 2010 - November 10, 2009 + +SPEERMINT A. Uzelac, Ed. +Internet-Draft Global Crossing +Intended status: Informational R. Penno +Expires: September 10, 2010 Juniper Networks + M. Hammer + Cisco Systems + D. Malas + CableLabs + S. Khan + Comcast + H. Kaplan + Acme Packet + J. Livingood + Comcast + D. Schwartz + XConnect Global Networks + R. Shockey + Shockey Consulting + March 9, 2010 SPEERMINT Peering Architecture - draft-ietf-speermint-architecture-09 + draft-ietf-speermint-architecture-10 + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Abstract + + This document defines a peering architecture for the Session + Initation Protocol (SIP) [RFC3261], it's functional components and + interfaces. It also describes the steps necessary to establish a + session between two peering domains in the context of the functions + defined. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -21,504 +56,503 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 26, 2010. + This Internet-Draft will expire on September 10, 2010. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. - This document is subject to BCP 78 and the IETF Trust's Legal Provisions - Relating to IETF Documents (http://trustee.ietf.org/license-info) - in effect on the date of publication of this document. Please - review these documents carefully, as they describe your rights and - restrictions with respect to this document. Code Components - extracted from this document must include Simplified BSD License - text as described in Section 4.e of the Trust Legal Provisions and - are provided without warranty as described in the BSD License." - -Abstract - - This document defines the SPEERMINT peering architecture, its functional - components and peering interface functions. It also describes the steps taken - to establish a session between two peering domains in the context of the - functions defined. + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. Table of Contents - 1. Introduction...................................................2 - 2. Reference SPEERMINT Architecture...............................4 - 3. Procedures of Inter-domain SSP Session Establishment...........4 - 3.1. Relationships between functions/elements..................5 - 4. Recommended SSP Procedures.....................................5 - 4.1. Originating SSP Procedures................................5 - 4.1.1. The Look-Up Function (LUF)...........................5 - 4.1.1.1. Target Address Analysis.........................6 - 4.1.1.2. ENUM Lookup.....................................6 - 4.1.2. Location Routing Function (LRF)......................6 - 4.1.2.1. DNS Resolution..................................7 - 4.1.2.2. Routing Table...................................7 - 4.1.2.3. LRF to LRF Routing..............................7 - 4.1.3. The Signaling Path Border Element (SBE)..............7 - 4.1.3.1. Establishing a Trusted Relationship.............8 - 4.1.3.2. Sending the SIP request.........................8 - 4.2. Target SSP Procedures.....................................8 - 4.2.1. The Ingress Signaling Path Border Element (SBE)......8 - 4.2.1.1. TLS.............................................8 - 4.2.1.2. Receive SIP requests............................9 - 4.3. Data Path Border Element (DBE)............................9 - 5. Address space considerations...................................9 - 6. Security Considerations........................................9 - 7. IANA Considerations...........................................10 - 8. Acknowledgments...............................................10 - 9. References....................................................11 - 9.1. Normative References.....................................11 - 9.2. Informative References...................................12 - Author's Addresses...............................................13 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Reference Architecture . . . . . . . . . . . . . . . . . . . . 4 + 3. Procedures of Inter-domain SSP Session Establishment . . . . . 5 + 4. Relationships between functions/elements . . . . . . . . . . . 6 + 5. Recommended SSP Procedures . . . . . . . . . . . . . . . . . . 6 + 5.1. Originating SSP Procedures . . . . . . . . . . . . . . . . 7 + 5.1.1. The Look-Up Function (LUF) . . . . . . . . . . . . . . 7 + 5.1.1.1. Target Address Analysis . . . . . . . . . . . . . 7 + 5.1.1.2. ENUM Lookup . . . . . . . . . . . . . . . . . . . 7 + 5.1.2. Location Routing Function (LRF) . . . . . . . . . . . 8 + 5.1.2.1. DNS resolution . . . . . . . . . . . . . . . . . . 8 + 5.1.2.2. Routing Table . . . . . . . . . . . . . . . . . . 8 + 5.1.2.3. LRF to LRF Routing . . . . . . . . . . . . . . . . 8 + 5.1.3. Signaling Path Border Element (SBE) . . . . . . . . . 8 + 5.1.4. Establishing a Trusted Relationship . . . . . . . . . 9 + 5.1.4.1. IPSec . . . . . . . . . . . . . . . . . . . . . . 9 + 5.1.4.2. Co-Location . . . . . . . . . . . . . . . . . . . 9 + 5.1.4.3. Sending the SIP Request . . . . . . . . . . . . . 9 + 5.2. Target SSP Procedures . . . . . . . . . . . . . . . . . . 9 + 5.2.1. The Ingress SBE . . . . . . . . . . . . . . . . . . . 10 + 5.2.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.2.1.2. Receive SIP Requests . . . . . . . . . . . . . . . 10 + 5.3. Data Path Border Element (DBE) . . . . . . . . . . . . . . 10 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction - The objective of this document is to define a reference peering architecture in - the context of Session PEERing for Multimedia INTerconnect (SPEERMINT). In this - process, we define the peering reference architecture, its functional - components, and peering interface functions from the perspective of a SIP - Service provider's (SSP) network. - - This architecture allows the interconnection of two SSPs in layer 5 peering as - defined in the SPEERMINT Requirements [14] and Terminology [13] documents. - - Layer 3 peering is outside the scope of this document. Hence, the figures in - this document do not show routers so that the focus is on Layer 5 protocol - aspects. - - This document uses terminology defined in the SPEERMINT Terminology document - [13], so the reader should be familiar with all the terms defined there. + The objective of this document is to define a reference peering + architecture in the context of session peering for multimedia + interconnects. In this process, we define the peering reference + architecture, its functional components, and peering interface + functions from the perspective of a SIP Service provider's (SSP) + [RFC5486] network. - In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", - "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are - to be interpreted as described in [RFC2119]. + This architecture allows the interconnection of two SSPs in layer 5 + peering as defined in the SIP-based session peering requirements + [I-D.ietf-speermint-requirements]. -2. Reference SPEERMINT Architecture + Layer 3 peering is outside the scope of this document. Hence, the + figures in this document focus on Layer 5 protocol functions and + elements. - Figure 2 depicts the SPEERMINT architecture and logical functions that form the - peering between two SSPs. + This document uses terminology defined in the Session Peering for + Multimedia Interconnect Terminology document [RFC5486]. - --------------- --------------- - / \ / \ - | +--LUF-+ | +------+ | +--LUF-+ | - | |->| | | | ENUM | | | |<-| | - | | | +------------>| TN DB|<------------+ | | | - | | | | | +------+ | | | | | - | | +------+ | | +------+ | | - | | | | | | - | | +--LRF-+ | +--------+ | +--LRF-+ | | - | |->| | | | DNS | | | |<-| | - | | | +----------->|IP Addrs|<-----------+ | | | - | | | | | +--------+ | | | | | - | | +------+ | | +------+ | | - | | | | | | - | | | | | | - | | +-------+ +-------+ | | - | ----------->| | | |<----------- | - | | SBE |<------------>| SBE | | - | | | | | | - | +-------+ +-------+ | - | SSP1 | | SSP2 | - | +-------+ +-------+ | - | | | | | | - | | DBE |<------------>| DBE | | - | | | | | | - | +-------+ +-------+ | - \ / \ / - --------------- --------------- - Figure 1: Reference SPEERMINT Architecture +2. Reference Architecture - For further details on the elements and functions described in this figure, - please refer to [RFC 5486]. + Figure 1 depicts the architecture and logical functions that form + peering between two SSPs. The terms used in the diagram are expanded + here for reference: -3. Procedures of Inter-domain SSP Session Establishment + o SBE - Signaling Path Border Element is described in Section 5.1.3 - This document assumes that in order for a session to be established from a UA - in the Originating SSP's network to an UA in the Target SSP's network the - following steps are taken: + o LUF - Look-up Function is described in Section 5.1.1 - 1. Determine the target SSP via the LUF. + o LRF - Location Routing Function is described in Section 5.1.2 - a. If the target address represents an intra-SSP resource, the - behavior is out-of-scope with respect to this draft. + o SF - Signaling Function is defined in [RFC5486] - 2. Determine the address of the SF of the target SSP via the LRF. + o SIP - Session Initiation Protocol is defined in [RFC3261] - 3. Establish the session + o DBE - Data Path Border Element is described in Section 5.3 - 4. Exchange the media, which could include voice, video, tec, etc. + o DNS - Domain Name Service is described in Section 5.1.2.1 - 5. End the session (BYE) + o ENUM - E.164 Number Mapping is described in Section 5.1.1.2 - The originating SSP would likely perform steps 1-4, and the target SSP would - likely perform steps 4-5. + o FQDN - Fully Qualified Domain Name - In the case the target SSP changes, then steps 1-4 would be repeated. This is - reflected in Figure 2 that shows the target SSP with its own peering functions. + o TN DB - Telephone Number Database + o IP - IPv4/v6 Address - 3.1. Relationships between functions/elements + o RTP - Real-time Transport Protocol is defined in [RFC3550] - - An SBE can contain a SF function. - - An SF can perform LUF and LRF functions. - - As an additional consideration, a Session Border Controller [SBC RFC], can - contain an SF, SBE and DBE, and may perform the LUF and LRF functions. - - The following functions can communicate as follows, depending upon various - real-world implementations: - o SF can communicate with LUF, LRF, SBE and SF - o LUF can communicator with SF and SBE - o LRF can communicate with SF and SBE + +=============++ ++==============+ + || || + +-----------+ +-----------+ + | SBE | | SBE | + | +-----+ | SIP +-----+ | +-----+ | + | | LUF |<-|------>|ENUM | | | LUF | | + | +-----+ | ENUM |TN DB| | +-----+ | + SIP | | +-----+ | | + ------>| +-----+ | DNS +-----+ | +-----+ | + | | LRF |<-|------>|FQDN | | | LRF | | + | +-----+ | |IP | | +-----+ | + | +-----+ | SIP +-----+ | +-----+ | + | | SF |<-|----------------|->| SF | | + | +-----+ | | +-----+ | + +-----------+ +-----------+ + || || + +-----------+ +-----------+ + RTP | DBE | RTP | DBE | + ------>| |--------------->| | + +-----------+ +-----------+ + || || + SSP1 Network || || SSP2 Network + +=============++ ++=============+ -4. Recommended SSP Procedures + Figure 1 - This section describes the functions in more detail and provides some - recommendations on the role they would play in a SIP call in a Layer 5 peering - scenario. + For further details on the elements and functions described in this + figure, please refer to [RFC5486]. - Some of the information in the section is taken from [14] and is put here for - continuity purposes. +3. Procedures of Inter-domain SSP Session Establishment - 4.1. Originating SSP Procedures + This document assumes that in order for a session to be established + from a User Agent (UA) in the Originating SSP's network to a UA in + the Target SSP's network the following steps are taken: -4.1.1. The Look-Up Function (LUF) + 1. Determine the target SSP via the LUF. (Note: If the target + address represents a resource within the originating SSP, the + behavior is out-of-scope with respect to this draft.) - Purpose is to determine the SF of the target domain of a given request and - optionally develop Session Establishment Data. + 2. Determine the address of the SF of the target SSP via the LRF. - 4.1.1.1. Target Address Analysis + 3. Establish the session - When the originating SSP receives a request to communicate, it analyzes the - target URI to determine whether the call needs to be routed internal or - external to its network. The analysis method is internal to the SSP; thus, - outside the scope of SPEERMINT. + 4. Exchange the media, which could include voice, video, text, etc. - If the target address does not represent a resource inside the originating - SSP's administrative domain or federation of domains, then the originating SSP - performs a Lookup Function (LUF) to determine a target address, and then is - resolves the call routing data by using the Location routing Function (LRF). + 5. End the session - For example, if the request to communicate is for an im: or pres: URI type, the - originating SSP follows the procedures in [8]. If the highest priority - supported URI scheme is sip: or sips: the originating SSP skips to SIP DNS - resolution in Section 5.1.3. Likewise, if the target address is already a sip: - or sips: URI in an external domain, the originating SSP skips to SIP DNS - resolution in Section 4.1.2.1. + The originating SSP would likely perform steps 1-4, and the target + SSP would likely perform steps 4-5. - If the target address corresponds to a specific E.164 address, the SSP may need - to perform some form of number plan mapping according to local policy. For - example, in the United States, a dial string beginning "011 44" could be - converted to "+44", or in the United Kingdom "00 1" could be converted to "+1". - Once the SSP has an E.164 address, it can use ENUM. + If the target SSP is also an indirect peer, then steps 1-4 may be + repeated. This is reflected in Figure 1 that shows the target SSP + with its own peering functions. - 4.1.1.2. ENUM Lookup +4. Relationships between functions/elements - If an external E.164 address is the target, the originating SSP consults the - public "User ENUM" rooted at e164.arpa, according to the procedures described - in RFC 3761. The SSP must query for the "E2U+sip" enumservice as described in - RFC 3764 [11], but MAY check for other enumservices. The originating SSP MAY - consult a cache or alternate representation of the ENUM data rather than actual - DNS queries. Also, the SSP may skip actual DNS queries if the originating SSP - is sure that the target address country code is not represented in e164.arpa. - If a sip: or sips: URI is chosen the SSP skips to Section 5.1.6. + o An SBE can contain a SF function. - If an im: or pres: URI is chosen for based on an "E2U+im" [8] or "E2U+pres" [9] - enumserver, the SSP follows the procedures for resolving these URIs to URIs for - specific protocols such a SIP or XMPP as described in the previous section. + o An SF can perform LUF and LRF functions. -4.1.2. Location Routing Function (LRF) + o As an additional consideration, in current Session Border + Controller (SBC) implementations, an SBC can contain an SF, SBE + and DBE, and may perform the LUF and LRF functions. - The LRF of an Originating SSP analyzes target address and target domain - identified by the LUF, and discovers the next hop signaling function (SF) in a - peering relationship. The resource to determine the SF of the target domain - might be provided by a third-party as in the assisted-peering case. The - following sections define mechanisms which may be used by the LRF. These are - not in any particular order and, importantly, not all of them may be used. + o The following functions can communicate as follows, depending upon + various real-world implementations: - 4.1.2.1. DNS Resolution + * SF can communicate with LUF, LRF and another SF - The originating SSP uses the procedures in RFC 3263 [4] Section 4 to determine - how to contact the receiving SSP. To summarize the RFC 3263 procedure: unless - these are explicitly encoded in the target URI, a transport is chosen using - NAPTR records, a port is chosen using SRV records, and an address is chosen - using A or AAAA records. + * LUF can communicate with SF - When communicating with another SSP, entities compliant to this document should - select a TLS-protected transport for communication from the originating SSP to - the receiving SSP if available. + * LRF can communicate with SF - 4.1.2.2. Routing Table +5. Recommended SSP Procedures - If there are no End User ENUM records and the Originating SSP cannot discover - the carrier-of-record or if the Originating SSP cannot reach the carrier-of- - record via SIP peering, the Originating SSP may deliver the call to the PSTN or - reject it. Note that the originating SSP may forward the call to another SSP - for PSTN gateway termination by prior arrangement using the routing table. + This section describes the functions in more detail and provides some + recommendations on the role they would play in an example SIP + telephony call scenario. - If so, the originating SSP rewrites the Request-URI to address the gateway - resource in the target SSP's domain and MAY forward the request on to that SSP - using the procedures described in the remainder of these steps. + Some of the information in the section is taken from + [I-D.ietf-speermint-requirements] and is put here for continuity + purposes. - 4.1.2.3. LRF to LRF Routing +5.1. Originating SSP Procedures - Communications between the LRF of two interconnecting SSPs may use DNS or - statically provisioned IP Addresses for reachability. Other inputs to - determine the path may be code-based routing, method-based routing, Time of - day, least cost and/or source-based routing. +5.1.1. The Look-Up Function (LUF) -4.1.3. The Signaling Path Border Element (SBE) + Purpose is to determine the SF of the target domain of a given + request and optionally develop Session Establishment Data. - The purpose of signaling function is to perform routing of SIP messages as well - as optionally implement security and policies on SIP messages, and to assist in - discovery/exchange of parameters to be used by the Media Function (MF). +5.1.1.1. Target Address Analysis - The signaling function performs the routing of SIP messages. The optional - termination and re-initiation of calls may be performed by the signaling path - Session Border Element (SBE), or other signaling elements. + When the originating SSP receives a SIP request, it analyzes the + target URI to determine whether the call needs to be routed internal + or external to its network. - Optionally, a SF may perform additional functions such as Session Admission - Control, SIP Denial of Service protection, SIP Topology Hiding, SIP header - normalization, SIP security, privacy, and encryption. + If the target address does not represent a resource inside the + originating SSP's administrative domain, then the originating SSP + performs a Lookup (LUF) to determine the target domain, and then it + resolves the call routing data by using Location Routing (LRF). - The SF of a SBE can also process SDP payloads for media information such as - media type, bandwidth, and type of codec; then, communicate this information to - the media function. Signaling function may optionally communicate with the - network to pass Layer 3 related policies [10] + For example, if the request to communicate is for an im: or pres: URI + type, the originating SSP follows the procedures in [RFC3861]. If + the highest priority supported URI scheme is sip: or sips: the + originating SSP skips to SIP DNS resolution. Likewise, if the target + address is already a sip: or sips: URI in an external domain, the + originating SSP skips to SIP DNS resolution in Section 5.1.2.1 - 4.1.3.1. Establishing a Trusted Relationship + If the target address corresponds to a specific E.164 address, the + SSP may need to perform some form of number plan mapping according to + local policy. For example, in the United States, a dial string + beginning "011 44" could be converted to "+44", or in the United + Kingdom "00 1" could be converted to "+1". Once the SSP has an E.164 + address, it can use ENUM. - Depending on the security needs and trust relationships between SSPs, different - security mechanism can be used to establish SIP calls. These are discussed in - the following subsections. +5.1.1.2. ENUM Lookup -4.1.3.1.1. IPSec + If an external E.164 address is the target, the originating SSP + consults a private or public ENUM server, according to the procedures + described in [RFC3761]. The SSP must query for the "E2U+sip" + enumservice as described in [RFC3764], but MAY check for other + enumservices. The originating SSP MAY consult a cache or alternate + representation of the ENUM data rather than actual DNS queries. + Also, the SSP may skip actual DNS queries if the target domain is + represented as an IPv4/v6 address. - In certain deployments the use of IPSec between the signaling functions of the - originating and terminating domains can be used as a security mechanism instead - of TLS. + If an im: or pres: URI is chosen for based on an "E2U+im" [RFC3861] + or "E2U+pres" [RFC3953] enumserver, the SSP follows the procedures + for resolving these URIs to URIs for specific protocols such a SIP or + XMPP. -4.1.3.1.2. Co-Location +5.1.2. Location Routing Function (LRF) - In this scenario the SFs are co-located in a physically secure location and/or - are members of a segregated network. In this case messages between the - originating and terminating SSPs would be sent as clear text. + The LRF of an Originating SSP analyzes the target address and target + domain identified by the LUF, and discovers the next hop signaling + function (SF) in a peering relationship. The resource to determine + the SF of the target domain might be provided by a third-party as in + the indirect peering case. The following sections define mechanisms + which may be used by the LRF. These are not in any particular order + and, importantly, not all of them may be used. - 4.1.3.2. Sending the SIP request +5.1.2.1. DNS resolution - Once a trust relationship between the peers is established, the originating SSP - sends the request. + The originating SSP uses the procedures in [RFC3263] to determine how + to contact the target SSP. To summarize the RFC 3263 procedure: + unless these are explicitly encoded in the target URI, a transport is + chosen using Naming Authority Pointer (NAPTR) records, a port is + chosen using SRV records, and an address is chosen using A or AAAA + records. - 4.2. Target SSP Procedures + When communicating with another SSP, entities compliant to this + document should select a TLS-protected transport for communication + from the Originating SSP to the target SSP if available. -4.2.1. The Ingress Signaling Path Border Element (SBE) +5.1.2.2. Routing Table - 4.2.1.1. TLS + If there are no End User ENUM records and the Originating SSP cannot + discover the carrier-of-record or if the Originating SSP cannot reach + the carrier-of-record via SIP peering, the Originating SSP may + deliver the call to the PSTN or reject it. Note that the originating + SSP may forward the call to another SSP for PSTN gateway termination + by prior arrangement using the routing table. - When the receiving SSP receives a TLS client hello, it responds with its - certificate. The Target SSP certificate should be valid and rooted in a well- - known certificate authority. The procedures to authenticate the SSP's - originating domain are specified in [24]. + If so, the originating SSP rewrites the Request-URI to address the + gateway resource in the target SSP's domain and MAY forward the + request on to that SSP using the procedures described in the + remainder of these steps. - The SF of the Target SSP verifies that the Identity header is valid, - corresponds to the message, corresponds to the Identity-Info header, and that - the domain in the From header corresponds to one of the domains in the TLS - client certificate. +5.1.2.3. LRF to LRF Routing - 4.2.1.2. Receive SIP requests + Communication between the LRF of two interconnecting SSPs may use DNS + or statically provisioned IP Addresses for reachability. Other + inputs to determine the path may be code-based routing, method-based + routing, Time of day, least cost and/or source-based routing. - Once a trust relationship is established, the Target SSP is prepared to receive - incoming SIP requests. For new requests (dialog forming or not) the receiving - SSP verifies if the target (request-URI) is a domain that for which it is - responsible. For these requests, there should be no remaining Route header - field values. For in-dialog requests, the receiving SSP can verify that it - corresponds to the top-most Route header field value. +5.1.3. Signaling Path Border Element (SBE) - The receiving SSP may reject incoming requests due to local policy. When a - request is rejected because the originating SSP is not authorized to peer, the - receiving SSP should respond with a 403 response with the reason phrase - "Unsupported Peer". + The purpose of signaling path border element is to perform routing of + SIP messages as well as optionally implement security and policies on + SIP messages, and to assist in discovery/exchange of parameters to be + used by the Media Function (MF). - 4.3. Data Path Border Element (DBE) + The signaling function performs the routing of SIP messages. The + optional termination and re-initiation of calls may be performed by + the signaling path Session Border Element (SBE), or other signaling + elements. - The purpose of the DBE [RFC 5486] is to perform media related functions such as - media transcoding and media security implementation between two SSPs. + Optionally, the SF of a SBE may perform additional functions such as + Session Admission Control, SIP Denial of Service protection, SIP + Topology Hiding, SIP header normalization, SIP security, privacy, and + encryption. - An Example of this is to transform a voice payload from one codec (e.g., G.711) - to another (e.g., EvRC). Additionally, the MF may perform media relaying, - media security, privacy, and encryption. + The SF of a SBE can also process SDP payloads for media information + such as media type, bandwidth, and type of codec; then, communicate + this information to the media function. Signaling function may + optionally communicate with the network to pass Layer 3 related + policies. -5. Address space considerations +5.1.4. Establishing a Trusted Relationship - Peering must occur in a common IP address space, which is defined by the - federation, which may be entirely on the public Internet, or some private - address space. The origination or termination networks may or may not entirely - be in the same address space. If they are not, then a network address - translation (NAT) or similar may be needed before the signaling or media is - presented correctly to the federation. The only requirement is that all - associated entities across the peering interface are reachable. + Depending on the security needs and trust relationships between SSPs, + different security mechanism can be used to establish SIP calls. + These are discussed in the following subsections. -6. Security Considerations +5.1.4.1. IPSec - In all cases, cryptographic-based security should be maintained as an optional - requirement between peering providers conditioned on the presence or absence of - underlying physical security of SSP connections, e.g. within the same secure - physical building. + In certain deployments the use of IPSec between the signaling + functions of the originating and terminating domains can be used as a + security mechanism instead of TLS. - In order to maintain a consistent approach, unique and specialized security - requirements common for the majority of peering relationships, should be - standardized within the IETF. These standardized methods may enable - capabilities such as dynamic peering relationships across publicly maintained - interconnections. +5.1.4.2. Co-Location -7. IANA Considerations + In this scenario the SFs are co-located in a physically secure + location and/or are members of a segregated network. In this case + messages between the originating and terminating SSPs would be sent + as clear text. - There are no IANA considerations at this time. +5.1.4.3. Sending the SIP Request -8. Acknowledgments + Once a trust relationship between the peers is established, the + originating SSP sends the request. - The working group thanks Sohel Khan for his initial architecture - draft that helped to initiate work on this draft. +5.2. Target SSP Procedures +5.2.1. The Ingress SBE - A significant portion of this draft is taken from [14] with - permission from the author R. Mahy. The other important contributor - is Otmar Lendl. Special thanks to Jim McEachern for detailed comments and - feedback. +5.2.1.1. TLS -9. References + When the target SSP receives a TLS client hello, it responds with its + certificate. The Originating SSP certificate should be valid and + rooted in a well-known certificate authority. The procedures to + authenticate the SSP's originating domain are specified in + [I-D.ietf-sip-domain-certs]. - 9.1. Normative References + The SF of the Target SSP verifies that the Identity header is valid, + corresponds to the message, corresponds to the Identity-Info header, + and that the domain in the From header corresponds to one of the + domains in the TLS client certificate. - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", - BCP 14, RFC 2119, March 1997. +5.2.1.2. Receive SIP Requests - [2] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS - Resource Record", RFC 2915, September 2000. + Once a trust relationship is established, the Target SSP is prepared + to receive incoming SIP requests. For new requests (dialog forming + or not) the receiving SSP verifies if the target (request-URI) is a + domain for which it is responsible. For these requests, there should + be no remaining Route header field values. For in-dialog requests, + the receiving SSP can verify that it corresponds to the top-most + Route header field value. - [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, - J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation - Protocol", RFC 3261, June 2002. + The receiving SSP may reject incoming requests due to local policy. + When a request is rejected because the originating SSP is not + authorized to peer, the receiving SSP should respond with a 403 + response with the reason phrase "Unsupported Peer". - [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): - Locating SIP Servers", RFC 3263, June 2002. +5.3. Data Path Border Element (DBE) - [5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. - Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April - 2006. + The purpose of the DBE [RFC5486] is to perform media related + functions such as media transcoding and media security implementation + between two SSPs. - [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A - Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July - 2003. + An Example of this is to transform a voice payload from one codec + (e.g., G.711) to another (e.g., Enhanced Variable Rate Codec (EvRC)). + Additionally, the MF may perform media relaying, media security, + privacy, and encryption. - [7] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers - with the Session Initiation Protocol (SIP)", RFC 3824, June 2004. +6. Acknowledgments - [8] Peterson, J., "Address Resolution for Instant Messaging and - Presence",RFC 3861, August 2004. + The working group thanks Sohel Khan for his initial architecture + draft that helped to initiate work on this draft. - [9] Peterson, J., "Telephone Number Mapping (ENUM) Service Registration for - Presence Services", RFC 3953, January 2005. + Other contributors include Rohan Mahy, Otmar Lendl, Jim McEachern and + John Elwell for detailed comments and feedback. - [10] ETSI TS 102 333: " Telecommunications and Internet converged Services - and Protocols for Advanced Networking (TISPAN); Gate control protocol". +7. IANA Considerations - [11] Peterson, J., "enumservice registration for Session Initiation Protocol - (SIP) Addresses-of-Record", RFC 3764, April 2004. + This memo includes no request to IANA. - [12] Livingood, J. and R. Shockey, "IANA Registration for an - Enumservice Containing PSTN Signaling Information", RFC 4769, November - 2006. +8. Security Considerations - 9.2. Informative References + In all cases, cryptographic-based security should be maintained as an + optional requirement between peering providers conditioned on the + presence or absence of underlying physical security of SSP + connections, e.g. within the same secure physical building. - [13] Malas, D., "SPEERMINT Terminology", draft-ietf-speermint-terminology-16 - (work in progress), February 2008. + In order to maintain a consistent approach, unique and specialized + security requirements common for the majority of peering + relationships, should be standardized within the IETF. These + standardized methods may enable capabilities such as dynamic peering + relationships across publicly maintained interconnections. - [14] Mule, J-F., "SPEERMINT Requirements for SIP-based VoIP Interconnection", - draft-ietf-speermint-requirements-04.txt, February 2008. +9. Normative References - [15] Mahy, R., "A Minimalist Approach to Direct Peering", draft- - mahy-speermint-direct-peering-02.txt, July 2007. + [I-D.ietf-sip-domain-certs] + Gurbani, V., Lawrence, S., and B. Laboratories, "Domain + Certificates in the Session Initiation Protocol (SIP)", + draft-ietf-sip-domain-certs-05 (work in progress), + March 2010. - [16] Penno, R., et al., "SPEERMINT Routing Architecture Message - Flows", draft-ietf-speermint-flows-02.txt", April 2007. + [I-D.ietf-speermint-requirements] + Mule, J., "SPEERMINT Requirements for SIP-based Session + Peering", draft-ietf-speermint-requirements-09 (work in + progress), October 2009. - [17] Houri, A., et al., "RTC Provisioning Requirements", draft- - houri-speermint-rtc-provisioning-reqs-00.txt, June, 2006. + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. - [18] Habler, M., et al., "A Federation based VOIP Peering - Architecture", draft-lendl-speermint-federations-03.txt, September 2006. + [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation + Protocol (SIP): Locating SIP Servers", RFC 3263, + June 2002. - [19] Mahy, R., "A Telephone Number Mapping (ENUM) Service - Registration for Instant Messaging (IM) Services", draft-ietf- - enum-im-service-03 (work in progress), March 2006. + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. - [20] Haberler, M. and R. Stastny, "Combined User and Carrier ENUM in the - e164.arpa tree", draft-haberler-carrier-enum-03 (work in progress), - March 2006. + [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform + Resource Identifiers (URI) Dynamic Delegation Discovery + System (DDDS) Application (ENUM)", RFC 3761, April 2004. - [21] Penno, R., Malas D., and Melampy, P., "A Session Initiation - Protocol (SIP) Event package for Peering", draft-penno-sipping-peering- - package-00 (work in progress), September 2006. + [RFC3764] Peterson, J., "enumservice registration for Session + Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, + April 2004. - [22] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", W3C REC - REC-xml-names-19990114, January 1999. + [RFC3861] Peterson, J., "Address Resolution for Instant Messaging + and Presence", RFC 3861, August 2004. - [23] Burger, E (Ed.), "A Mechanism for Content Indirection in - Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006 + [RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service + Registration for Presence Services", RFC 3953, + January 2005. - [24] Gurbani, V., Lawrence, S., and B. Laboratories, "Domain Certificates in - the Session Initiation Protocol (SIP)", draft-ietf-sip-domain-certs-00 - (work in progress), November 2007. + [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia + Interconnect (SPEERMINT) Terminology", RFC 5486, + March 2009. -Author's Addresses +Authors' Addresses - Adam Uzelac + Adam Uzelac (editor) Global Crossing - Rochester, NY - USA + Rochester, NY + US + Email: adam.uzelac@globalcrossing.com - Reinaldo Penno + Reinadlo Penno Juniper Networks - Sunnyvale, CA - USA + Sunnyvale, CA + US + Email: rpenno@juniper.net Mike Hammer Cisco Systems - Herndon, VA - USA - Email: mhammer@cisco.com - - Sohel Khan, Ph.D. - Comcast Cable Communications - USA - Email: sohel_khan@cable.comcast.com + Herndon, VA + US + Email: mhammer@cisco.com Daryl Malas CableLabs - Louisville, CO - USA + Louisville, CO + US + Email: d.malas@cablelabs.com + Sohel Khan + Comcast + Philadelphia, PA + US + + Email: sohel_khan@cable.comcast.com + Hadriel Kaplan Acme Packet + Burlington, MA + US + Email: hkaplan@acmepacket.com Jason Livingood Comcast - Email: Jason_livingood@cable.comcast.com + Philadelphia, PA + US + + Email: Jason_Livingood@cable.comcast.com David Schwartz - Kayote Systems - Email: david.schwartz@kayote.com + XConnect Global Networks + Jerusalem + Israel + + Email: dschwartz@xconnnect.net + + Richard Shockey + Shockey Consulting + US - Rich Shockey - Unaffiliated Email: Richard@shockey.us