Speermint Working Group R. Penno Internet Draft Juniper Networks Expires: February 2007 D. Malas Level 3 S. Khan Sprint A. Uzelac Global Crossing September 19, 2006 SPEERMINT Routing Architecture Message Flows draft-ietf-speermint-flows-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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. Internet-Drafts are draft documents valid for a maximum of six months 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 March 19, 2007. Abstract This draft provides the message flows associated with the SPEERMINT, SIP Peering and Multimedia Interconnect, routing architecture. This penno Expires March 19, 2007 [Page 1] Internet-Draft draft-ietf-speermint-flows-01 September 2006 document provides examples of many different message flows relative to varying peering scenarios. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction...................................................3 2. Peering Message flows..........................................6 3. On-Demand Peering..............................................8 3.1. Transport Layer Security..................................8 3.2. Proxy Authentication: Subscribe/Notify...................10 4. Static Peering................................................11 4.1. IPSec....................................................12 4.2. Co-Location..............................................12 5. Federation Based Peering......................................13 5.1. Simple Federation Match..................................14 5.2. No federation match......................................14 5.3. Federation Referral......................................15 5.4. Federation Specific Call Processing......................16 5.4.1. Central Federation Proxy............................17 5.4.2. VPN Based Federations...............................18 5.4.3. TLS Based Federation................................18 6. Peering Domain Information Exchange...........................18 6.1. Domain Routes............................................18 6.2. Authentication Credentials...............................19 7. Peering Message Flow Phases...................................20 7.1. Discovery Phase..........................................21 7.2. Policy Exchange Phase....................................22 7.3. Security Establishment Phase.............................23 7.4. Signaling Exchange Phase.................................24 7.5. Media Exchange Phase.....................................24 8. Security Considerations.......................................25 9. IANA Considerations...........................................25 10. Acknowledgments..............................................26 11. References...................................................26 11.1. Normative References....................................26 11.2. Informative References..................................27 Author's Addresses...............................................28 Intellectual Property Statement..................................28 Disclaimer of Validity...........................................29 Copyright Statement..............................................29 penno Expires March 19, 2007 [Page 2] Internet-Draft draft-ietf-speermint-flows-01 September 2006 Acknowledgment...................................................29 1. Introduction This document shows the message flows associated with the most relevant SPEERMINT routing architecture peering scenarios. Most of the message diagrams were based on previous work described within existing IETF standards documents. The document focuses on the messages exchanged for the purpose of Layer 5 peering [7] between two domains. Messages exchanged for the purpose of setting up SIP sessions within a domain are considered out of scope and were already defined in other IETF documents. The draft separates the Layer 5 peering scenarios in two major peering scenarios. o On-demand: In this scenario the SIP proxies in domains A and B establish a peering relationship driven by the necessity to deliver a SIP message to another domain. This is sometimes referred as the "email" model. o Static: In this scenario the peering relationship between proxies A and B is statically provisioned independent of the establishment of any SIP session between users in different domains. Normally, media for a given SIP session follows a different path, traversing a different device (most commonly a router) when crossing peering domains. Alternatively, media for a given session can be directed to traverse the same device used for Layer 5 peering, i.e., the same device that handles signaling when crossing domains. This produces two different models: o Decomposed: In this model SIP proxies perform Layer 5 peering and media is sent directly between the User Agent's (UA's) involved in the session. Signaling and media follow different paths. penno Expires March 19, 2007 [Page 3] Internet-Draft draft-ietf-speermint-flows-01 September 2006 o Collapsed: In this model the device that performs Layer 5 peering also processes the associated media when crossing domains. In the light of SPEERMINT these devices may need to process media mainly when peering involves SIP entities in private address spaces. This function is usually referred to as media relay and is usually performed by a B2BUA or SBC (Session Border Controller). See [6] for a complete discussion of SBC functions. The decomposed or basic peering model picture is shown below. It is worth mentioning that Proxy 1 and 2 can be separated by any number of layer 3 hops. We will refer to this picture throughout this document. ............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | DNS | . . | DNS | . . | 1 | . . | 2 | . . | | . . | | . . +-------+ . . +-------+ . . | . . | . . | . . | . . +-------+ . . +-------+ . . | | . . | | . . | Proxy |--------------| Proxy | . . | 1 | . . | 2 | . . | | . . | | . . / +-------+ . . +-------+ \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . +-------+ . . +-------+ . . | | . . | | . . | | . Media . | | . . | UA 1 |<========================================>| UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. Figure 1 Basic Peering Picture. penno Expires March 19, 2007 [Page 4] Internet-Draft draft-ietf-speermint-flows-01 September 2006 The collapsed model is shown below: ............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | DNS | . . | DNS | . . | 1 | . . | 2 | . . | | . . | | . . +-------+ . . +-------+ . . | . . | . . | . . | . . +-------+ . . +-------+ . . | B2BUA | . . | B2BUA | . . | & |--------------| & | . . | other |**************| other |\ . . /| funct | . . | funct | \ . . / +-------+ . . +-------+* \ signaling . . / * . . * \ . . / * . . * \ . . / * . . * \ . . / * media . . * \ . . / * . . * \ . . / * . . * \ . . / * . . * \ . . +-------+ . . +-------+ . . | | . . | | . . | | . . | | . . | UA 1 | . . | UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. Figure 2 Collapsed Peering Picture. In a decomposed model, the signaling function (SF) and the media function (MF) are implemented in separate entities. A B2BUA is generally on the SIP path in the SF. The vertical control protocol between the SF and MF is out of the scope of this document. The decomposed model is shown below: penno Expires March 19, 2007 [Page 5] Internet-Draft draft-ietf-speermint-flows-01 September 2006 ............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | DNS | . . | DNS | . . | 1 | . . | 2 | . . | | . . | | . . +-------+ . . +-------+ . . | . . | . . | . . | . . +-------+ . . +-------+ . . /| B2BUA |--------------| B2BUA |\ . . / +-------+ +-------+ \ . . / +-------+ +-------+ \ . . / | MF |**************| MF | \ . . / +-------+ . . +-------+* \signaling . . / * . . * \ . . / * . . * \ . . / * . . * \ . . / * media . . * \ . . / * . . * \ . . / * . . * \ . . / * . . * \ . . +-------+ . . +-------+ . . | | . . | | . . | | . . | | . . | UA 1 | . . | UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. Figure 3 Collapsed Peering Picture. 2. Peering Message flows We first depict what we call the basic message flow. The various scenarios differ mostly of how and when peering is implemented. As mentioned earlier peering can be establish following the arrival of a message at a border proxy or statically following an agreement between both domains. penno Expires March 19, 2007 [Page 6] Internet-Draft draft-ietf-speermint-flows-01 September 2006 Alice Proxy 1 DNS Proxy 2 Bob | | | | | | | | | | | | Peering | | | | Phase | | | | [Static] | | | |<------------------>| | | INVITE | | | | |------->| | | | | 100 | | | |<-------| | | | | NAPTR | | | | | Query | | | | |--------->| | | | | NAPTR | | | | | Reply | | | | |"SIPS+D2T"| | | | |<---------| | | | | SRV | | | | | Query | | | | |--------->| | | | | SRV | | | | | Reply | | | | |<---------| | | | | | | | | Peering | | | | Phase | | | | [On-Demand] | | | |<------------------>| | | | INVITE | | | |------------------->| INVITE | | | 100 |---------->| | |<-------------------| | | | | 180 | | | 180 |<----------| | 180 |<-------------------| | |<-------| | 200 | | | 200 |<----------| | 200 |<-------------------| | |<-------| | | | ACK | | | |------->| ACK | | | |------------------->| ACK | | | |---------->| | Both Way RTP Media | |<=======================================>| penno Expires March 19, 2007 [Page 7] Internet-Draft draft-ietf-speermint-flows-01 September 2006 | | | BYE | | | BYE |<----------| | BYE |<-------------------| | |<-------| | | | 200 | | | |------->| 200 | | | |------------------->| 200 | | | |---------->| | | | | In the collapsed model, media would follow the path shown below. All other signaling call flows remain the same, except a B2BUA is used instead of a proxy. Alice B2BUA 1 DNS B2BUA 2 Bob | | | | | | | | | | | Both Way RTP Media | |<======>|<==================>|<=========>| | | | | The following sections show the message flows in several different scenarios broken in two categories, on-demand and static. 3. On-Demand Peering In the on demand peering scenario, the relationship between proxies in domains A and B is driven by the arrival of a SIP message at proxy A directed to a user in domain B (or vice-versa). 3.1. Transport Layer Security In the case this is in fact the first call between those two VSPs, than this call will trigger the establishment of the TLS connection. Otherwise we can assume the TLS connection has been established by some other means. penno Expires March 19, 2007 [Page 8] Internet-Draft draft-ietf-speermint-flows-01 September 2006 Alice Proxy 1 DNS Proxy 2 Bob | | | | | | | | | | | INVITE | | | | |------->| | | | | 100 | | | | |<-------| | | | | | NAPTR | | | | | Query | | | | |--------->| | | | | NAPTR | | | | | Reply | | | | |"SIPS+D2T"| | | | |<---------| | | | | SRV | | | | | Query | | | | |--------->| | | | | SRV | | | | | Reply | | | | |<---------| | | | | | | | | | Peering | | | | [TLS Connection] | | | |<------------------>| | | | | | | | INVITE | | | |------------------->| INVITE | | | 100 |---------->| | |<-------------------| | | | | 180 | | | 180 |<----------| | 180 |<-------------------| | |<-------| | 200 | | | 200 |<----------| | 200 |<-------------------| | |<-------| | | | ACK | | | |------->| ACK | | | |------------------->| ACK | | | |---------->| | Both Way RTP Media | |<=======================================>| | | | BYE | | | BYE |<----------| | BYE |<-------------------| | |<-------| | | | 200 | | | penno Expires March 19, 2007 [Page 9] Internet-Draft draft-ietf-speermint-flows-01 September 2006 |------->| 200 | | | |------------------->| 200 | | | |---------->| | | | | TBD: DNS exchange could present proxy 1 with a set of peering policies that need to be met for the peering with proxy 2 too succeed. 3.2. Proxy Authentication: Subscribe/Notify In the following example message flow, the authentication credentials exchange method may take place before any INVITE is sent by ALICE. The P2Key is sent by Proxy 2's NOTIFY and is included within subsections of the peering policy event package (PeerPlcyEvtPkg). The P2Key may be stored on Proxy 1 for the duration of the policy subscription. When the subscription expires, the P2Key becomes invalid. At any time before the subscription expires, the P2Key MAY be updated or refreshed as described in [8]. The message flow and authentication exchange may occur in either direction, but for simplicity reasons is only shown unilaterally. penno Expires March 19, 2007 [Page 10] Internet-Draft draft-ietf-speermint-flows-01 September 2006 ALICE Proxy 1(P1) Proxy 2(P2) Bob | | | | | INVITE | | | |--------------->| | | | 100 Trying | | | |<---------------| | | | | Subscribe w/ PeerPlcyEvtPkg | | | |---------------------------->| | | | 401 Unauthorized | | | |<----------------------------| | | |Subscribe w/Auth | | | |---------------------------->| | | | 202 Accepted | | | |<----------------------------| | | | Notify w/P2Key | | | |<----------------------------| | | | 200 OK | | | |---------------------------->| | | | INVITE | | | |---------------------------->| | | | 401 Unauthorized | | | |<----------------------------| | | | INVITE w/P2Key | | | |---------------------------->| | | | 100 Trying |INVITE | | |<----------------------------|-----------> | | | |180 Ringing | | | 180 Ringing |<----------- | | 180 Ringing|<----------------------------| | |<---------------| |200 OK | | | 200 OK |<----------- | | 200 OK |<----------------------------| | |<---------------| | | | ACK | | | |--------------->|ACK | | | |---------------------------->|ACK | | | |-----------> | 4. Static Peering In the static peering scenario the relationship between proxies A and B is not driven by a SIP session, but before hand through manual provisioning. penno Expires March 19, 2007 [Page 11] Internet-Draft draft-ietf-speermint-flows-01 September 2006 4.1. IPSec In this model an IPSec connection between proxies A and B is provisioned following an agreement between the two domains. Alice Proxy 1 DNS Proxy 2 Bob | | | | | | | | | | | [Peering] | | | | IPSec Connection | | | |<------------------>| | | | | | | \ / \ / \ / \ / \ / | | | | | | INVITE | | | | |------->| | | | | 100 | | | | |<-------| | | | \ / \ / \ / \ / \ / | | BYE |<----------| | BYE |<-------------------| | |<-------| | | | 200 | | | 4.2. Co-Location In this scenario the two proxies are co-located in a physically secure location and/or are members of a segregated network. In this case messages between Proxy 1 and Proxy 2 would be sent as clear text. penno Expires March 19, 2007 [Page 12] Internet-Draft draft-ietf-speermint-flows-01 September 2006 Alice Proxy 1 DNS Proxy 2 Bob | | | | | | | | | | | [Peering] | | | | Co-Location | | | |<------------------>| | | | | | | \ / \ / \ / \ / \ / | | | | | | INVITE | | | | |------->| | | | | 100 | | | | |<-------| | | | \ / \ / \ / \ / \ / | | BYE |<----------| | BYE |<-------------------| | |<-------| | | | 200 | | | 5. Federation Based Peering The Domain Policy DDDS framework [13] can be used to integrate on- demand peering and static peering into one unified setup. The main idea is that the target can use its domain to publish peering-related information in the DNS. Federations as defined in [14] are one way how source and destination network can find a common set of procedures for the peering. Federation based peering is thus not a substitute to the various authentication, routing, and QoS procedures which are described in this document. The following examples demonstrate how Alice can use this scheme to dynamically select the correct peering mechanisms when talking to Bob. The overall message flow is similar to the one from section 3.1. The DP-DDDS queries the DNS for the same NAPTR records as the algorithm from RFC 3263 [3]. While the originating network behavior according to [3] depends solely on the results retrieved from DNS, the DP-DDDS also uses a set of local configuration options to drive the source network behavior. The following examples thus list both the sender configuration and the answers from the DNS. penno Expires March 19, 2007 [Page 13] Internet-Draft draft-ietf-speermint-flows-01 September 2006 5.1. Simple Federation Match The simplest case is when Alice and Bob share membership in one federation ("http://example.com/Wonderland") which stipulates further call-setup according to section 3.1. Configuration at Alice's DNS list Alice's federations (which includes http://example.com/Wonderland) and rules what do to when a federation is chosen for a call. NAPTR RRset at Bob's domain includes: IN NAPTR 10 50 "u" "D2P+SIP:fed" ( "!^.*$!http://example.com/small-federation!" . ) IN NAPTR 20 50 "u" "D2P+SIP:fed" ( "!^.*$!http://example.com/Wonderland!" . ) Alice Proxy 1 DNS Proxy 2 Bob | | | | | | | | | | | INVITE | | | | |------->| | | | | 100 | | | | |<-------| | | | | | NAPTR | | | | | Query | | | | |--------->| | | | | NAPTR | | | | | Reply | | | | |<---------| | | | Parse D2P+SIP RRs | | | | Federation match | | | | successful | | | | | | | | | Parse NAPTR with | | | | "SIPS+D2T" | | | | | | | | | | SRV | | | | | Query | | | | |--------->| | | [Rest according to section 3.1] 5.2. No federation match If Bob does not share a federation with Alice, e.g. by just being a member of the "small-federation", then no direct peering is possible between Alice and Bob. penno Expires March 19, 2007 [Page 14] Internet-Draft draft-ietf-speermint-flows-01 September 2006 Bob's Domain contains: IN NAPTR 10 50 "u" "D2P+SIP:fed" ( "!^.*$!http://example.com/small-federation!" . ) Alice Proxy 1 DNS Proxy 2 Bob | | | | | | | | | | | INVITE | | | | |------->| | | | | 100 | | | | |<-------| | | | | | NAPTR | | | | | Query | | | | |--------->| | | | | NAPTR | | | | | Reply | | | | |<---------| | | | Parse D2P+SIP RRs | | | | Federation match | | | | failed. | | | | | | | | | Bob offers no alternative ways | | No peering is possible. | | | | | | | If no matching federations or referrals are found, Alice can either fall back to PSTN routing or use a transit VSP. 5.3. Federation Referral If Bob buys transit services from Carol, he can announce this in a "D2P+SIP" NAPTR record. We now have at Bob's domain: IN NAPTR 10 50 "u" "D2P+SIP:fed" ( "!^.*$!http://example.com/small-federation!" . ) IN NAPTR 20 50 "u" "D2P+SIP" "" carol.example.com. If Carol is a member of the Wonderland federation, then we have $ORIGIN carol.example.com IN NAPTR 10 50 "u" "D2P+SIP:fed" ( "!^.*$!http://example.com/Wonderland!" . ) penno Expires March 19, 2007 [Page 15] Internet-Draft draft-ietf-speermint-flows-01 September 2006 Alice Proxy 1 DNS Proxy 2 Bob | | | | | | | | | | | INVITE | | | | |------->| | | | | 100 | | | | |<-------| | | | | | NAPTR | | | | | Query | | | | |--------->| | | | | NAPTR | | | | | Reply | | | | |<---------| | | | Parse D2P+SIP RRs | | | | direct federation | | | | match fails | | | | Found non-terminal| | | | | |Alice retargets to Carol | | NAPTR | | | | | Query | | | | |--------->| | | | | NAPTR | | | | | Reply | | | | |<---------| | | | Parse D2P+SIP RRs | | | | Federation match | | | | successful | | | | | | | | | Parse NAPTR with | | | | "SIPS+D2T" | | | | | | | | | | SRV | | | | | Query | | | | |--------->| | | [Rest according to section 3.1] 5.4. Federation Specific Call Processing The output of the federation matching step in the Domain Policy DDDS application is a federation name and a destination domain (which differs from the original destination domain if referrals were followed). Federations as defined in [14] can specify their own specific rules on how the actual call-setup is to be performed between two federation members. If Alice is a member of more than one federation penno Expires March 19, 2007 [Page 16] Internet-Draft draft-ietf-speermint-flows-01 September 2006 then Alice's peering SIP proxy needs to adapt its behavior to the rules of the federation this call is traversing. The following subsections provide some examples of what a federation could imply for the call processing. 5.4.1. Central Federation Proxy Federation rules can dictate that calls are to be routed via a federation-maintained central SIP proxy. In that case no further NAPTR/SRV/A lookups are made. Instead, the INVITE will be sent directly via a preconfigured TLS connection to that proxy. This proxy acts as a redirect proxy. The following message flow provides an example describing this process: Peer Proxy Federation Proxy Peer Proxy Bob | | | | | INVITE | | | |--------------->| | | | 302 | | | |<---------------| | | | ACK | | | |--------------->| | | | INVITE | | |-------------------------------->| INVITE | | 100 |--------------->| |<--------------------------------| 180 | | 180 |<---------------| |<--------------------------------| | | | 200 | | 200 |<---------------| |<--------------------------------| | | ACK | | |-------------------------------->| ACK | | |--------------->| | Both Way RTP Media | |<================================================>| | | BYE | | BYE |<---------------| |<--------------------------------| | | 200 | | |-------------------------------->| 200 | | |--------------->| penno Expires March 19, 2007 [Page 17] Internet-Draft draft-ietf-speermint-flows-01 September 2006 5.4.2. VPN Based Federations If a federation has established some sort of VPN which connects the SIP elements of all participating VSPs, then matching that federation will cause: Proxy1 to use e.g. a private DNS within that VPN for further lookups and will direct all further traffic to be routed into that VPN. IPsec based VPNs are a special case of this. 5.4.3. TLS Based Federation One of the simplest cases is a TLS based federation. In that case the federation rules may prescribe the default NAPTR/SRV lookups and only affect the selection of the correct X.509 certificate for the TLS connection. 6. Peering Domain Information Exchange 6.1. Domain Routes In some cases, it may be required to exchange specific domain route information between peers. The following describes a method for a relationship between proxies in domains A and B to exchange domain routes using a SIP peering policy event package. This event package may contain specific sections, which will provide routing information for the peering proxy server to update its routing table with new peering routes. This method utilizes a SUBSCRIBE method, and routes may be updated through expiry timers and subscription refreshes as defined in [8]. penno Expires March 19, 2007 [Page 18] Internet-Draft draft-ietf-speermint-flows-01 September 2006 Proxy 1 Proxy 2 | | |Subscribe w/PeerPlcyEvtPkg | |---------------------------->| | 401 Unauthorized | |<----------------------------| |Subscribe w/Auth | |---------------------------->| | 202 Accepted | |<----------------------------| | Notify | |<----------------------------| | 200 OK | |---------------------------->| 6.2. Authentication Credentials In some cases, authorization credentials for authentication methods such as HTTP digest may want to be exchanged and utilized by domain proxies for authenticating new message requests from subscribers intended for a UA in another domain. The following describes a method for a relationship between proxies in domains A and B to exchange authentication information using a SIP peering policy event package. This event package may contain specific sections, which will provide authentication methods to be used for authenticating to the peer's proxy. This method utilizes a SUBSCRIBE method similar to the method described in section 3.2. Proxy 1 Proxy 2 | | |Subscribe w/ PeerPlcyEvtPkg | |---------------------------->| | 401 Unauthorized | |<----------------------------| |Subscribe w/Auth | |---------------------------->| | 202 Accepted | |<----------------------------| | Notify | |<----------------------------| | 200 OK | |---------------------------->| penno Expires March 19, 2007 [Page 19] Internet-Draft draft-ietf-speermint-flows-01 September 2006 7. Peering Message Flow Phases The message flow phases are Discovery, Policy Exchange, Security Establishment, Signaling Exchange, and Media Exchange. The following flow provides an overview of the phases. Each of the phases is described individually in the following subsections. In the following flow, the policy and peering proxy have been combined; however, these two functions may be separated. Also, the signaling and media exchange phase descriptions have been omitted for clarity purposes, because their functionality has not changed for the purposes of peering. However, they have been explained further in the following subsections. Alice Peer Proxy DNS Peer Policy/Proxy Bob | | | | | |INVITE | | | | |----------->| | | | | 100| | | | |<-----------| | | | |NAPTR Query | | | +---->|--------------->| | | | | NAPTR Reply| | | Discovery Phase | |<---------------| | | ----------------| |SRV Query | | | | |--------------->| | | | | SRV Reply| | | +---->|<---------------| | | | | | | | INVITE | | |---------------------------->| | | 401 Unauthorized | | |<----------------------------| | | | | | SUBSCRIBE | | +---->|---------------------------->| | | | 202 Accepted | | Policy Exchange | |<----------------------------| | ----------------| | Notify | | Phase | |<----------------------------| | | | 200 OK | | +---->|---------------------------->| | | INVITE | | +---->|---------------------------->| | | | [TLS Connection] | | Security Exch. | |<--------------------------->| | ----------------| | 401 Unauthorized | | penno Expires March 19, 2007 [Page 20] Internet-Draft draft-ietf-speermint-flows-01 September 2006 Phase | |<----------------------------| | | | INVITE | | +---->|---------------------------->|INVITE | | | 100 Trying |------------->| | |<----------------------------| 180 Ringing| | | 180 Ringing |<-------------| | 180 Ringing|<----------------------------| 200OK | |<------------| 200OK |<-------------| | 200OK |<----------------------------| | |<------------| | | | ACK | | | |------------>| ACK | | | |---------------------------->|ACK | | | |------------->| | | Both Way RTP Media | | |<========================================================>| | | | BYE | | | BYE |<-------------| | BYE |<----------------------------| | |<------------| | | | 200OK | | | |------------>| 200OK | | | |---------------------------->|200OK | | | |------------->| 7.1. Discovery Phase The first phase of static or dynamic peering requests is discovery. The discovery process can be summarized by querying the Location Function to determine the next phase in the message flow. The discovery phase can take place via a local or external federation location function. Examples of the function may be comprised of an ENUM/DNS or redirect server. After the discovery phase has completed, the peering process will progress to a subsequent phase, usually the policy or authentication phase. The following message flows provide examples of the discovery phase. Discovery phase utilizing an ENUM/DNS server as a location function: Alice Peer Proxy DNS Peer Proxy | | | | |INVITE | | | |----------->| | | | 100| | | penno Expires March 19, 2007 [Page 21] Internet-Draft draft-ietf-speermint-flows-01 September 2006 |<-----------| | | |NAPTR Query | | +---->|--------------->| | | | NAPTR Reply| | Discovery Phase | |<---------------| | -----------------| |SRV Query | | | |--------------->| | | | SRV Reply| | +---->|<---------------| | |INVITE | |------------------------------->| Discovery phase utilizing a REDIRECT server as a location function: Peer Proxy Federation Proxy Peer Proxy | | | | INVITE | | +---->|--------------->| | Discovery Phase | | 302 | | -----------------| |<---------------| | | | ACK | | +---->|--------------->| | | INVITE | |------------------------------->| 7.2. Policy Exchange Phase Since the originating peer proxy does not know if the destination AOR is a PF or a SF, it must progress with a normal dialog request with the assumption it is a SF. In the event a request fails due to an authentication failure (401 Unauthorized), and no known authentication credentials exist or no longer appear to be working, the requesting proxy may issue a SUBSCRIBE [8] request to the attempted peer's AOR received through the discovery phase. The SUBSCRIBE request should be a request to attain a, currently, undefined peering policy event package. In some cases, the requesting proxy already knows it must attain the peering policy event package, and may forego the initial INVITE attempt and issue a SUBSCRIBE request instead. Once this phase is completed, after extracting and following any specific received policies, the authentication phase is attempted as the policy permits or requires. The following message flow provides an example of the policy exchange phase. The following message flow assumes the discovery phase has already completed using one of the methods described in section 12.1. Peer Proxy Policy Server | | penno Expires March 19, 2007 [Page 22] Internet-Draft draft-ietf-speermint-flows-01 September 2006 | INVITE | |------------------------------->| | 401 Unauthorized | |<-------------------------------| | | | SUBSCRIBE | +---->|------------------------------->| | | 202 Accepted | Policy Exchange | |<-------------------------------| -----------------| | Notify | Phase | |<-------------------------------| | | 200 OK | +---->|------------------------------->| | INVITE | |------------------------------->| 7.3. Security Establishment Phase The security establishment phase follows the described methods in previous sections of this document. After the originating proxy receives the policy event package, it extracts the necessary security policy information. The security policy may contain many different combinations of security requirements. For example, it may contain a simple digest authentication method or may require TLS with digest authentication. This is determined by the destination peer, and must be followed to successfully complete this phase. This phase follows standard methods described in [2], so the following flow provides an example of this phase, but does not incorporate all possibilities. This phase assumes the previous phases were successfully completed or purposefully omitted per peering implementation. Peer Proxy Peer Proxy | | | INVITE | +---->|------------------------------->| | | [TLS Connection] | Security Exch. | |<------------------------------>| ----------------| | 401 Unauthorized | Phase | |<-------------------------------| | | INVITE | +---->|------------------------------->| | 100 Trying | |<-------------------------------| | 180 Ringing | |<-------------------------------| penno Expires March 19, 2007 [Page 23] Internet-Draft draft-ietf-speermint-flows-01 September 2006 7.4. Signaling Exchange Phase The signaling exchange phase is a necessary step to progress towards establishing peering. This phase may incorporate the security exchange phase, but it is not required. This phase follows standard methods described in [2], so the following flow provides an example of this phase, but does not incorporate all possibilities. Peer Proxy Peer Proxy | | | INVITE | +---->|------------------------------->| | | [TLS Connection] | | |<------------------------------>| | | 401 Unauthorized | | |<-------------------------------| | | INVITE | | |------------------------------->| Signaling Exch. | | 100 Trying | -----------------| |<-------------------------------| Phase | | 180 Ringing | | |<-------------------------------| | | 200 OK | | |<-------------------------------| | | ACK | | |------------------------------->| | | BYE | | |<-------------------------------| | | 200 OK | +---->|------------------------------->| | | 7.5. Media Exchange Phase The media exchange phase is negotiated and established during the signaling exchange phase. This phase follows standard methods described in [2], so the following flow provides an example of this phase, but does not incorporate all possibilities. Alice Peer Proxy Peer Proxy Bob +---->|INVITE | | | | |----------->| INVITE | | | | 100 |------------------>| | | |<-----------| [TLS Connection] | | | | |<----------------->| | | | | 401 Unauthorized | | penno Expires March 19, 2007 [Page 24] Internet-Draft draft-ietf-speermint-flows-01 September 2006 | | |<------------------| | Media Exch. | | | INVITE | | ---------------| | |------------------>|INVITE | Phase | | | 100 Trying |----------->| | | |<------------------| 180 | | | | 180 Ringing |<-----------| | | 180 |<------------------| 200 | | |<-----------| 200 OK |<-----------| | | 200 |<------------------| | | |<-----------| | | | |ACK | | | +---->|----------->|ACK | | | |------------------>|ACK | | | |----------->| | Both Way RTP Media | | |<===========================================>| | | | | | | | BYE | | | BYE |<-----------| | BYE|<------------------| | |<-----------| | | |200 | | | |----------->|200 | | | |------------------>|200 | | | |----------->| 8. Security Considerations The level of security required during the establishment and maintenance of a SIP peering relationship between two proxies can vary greatly. In general all security considerations related to the SIP protocol are also applicable in a peering relationship. If the two proxies communicate over an insecure network, and consequently are subject to attacks, the use of TLS or IPSec would be advisable. If there is physical security and the proxies are co-located, or the proxies are situated in a segregated network (such as a VPN), one could argue that basic filtering based on IP address is enough. 9. IANA Considerations N/A penno Expires March 19, 2007 [Page 25] Internet-Draft draft-ietf-speermint-flows-01 September 2006 10. Acknowledgments Thanks to Otmar Lendl for the federation call flows. 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [5] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003. [6] ETSI TS 102 333: " Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Gate control protocol". [7] Babiarz, J., "Configuration Guidelines for DiffServ Service Classes", draft-ietf-tsvwg-diffserv-service-classes-02 (work in progress), February,2006. [8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [9] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [10] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. penno Expires March 19, 2007 [Page 26] Internet-Draft draft-ietf-speermint-flows-01 September 2006 11.2. Informative References [11] Meyer, D., "SPEERMINT Requirements and Terminology", Internet Draft, draft-ietf-speermint-reqs-and-terminology-01 [12] Boulton, C., Rosenberg, J., Camarillo, G., "Best Current Practices for NAT Traversal for SIP", Internet Draft, draft- ietf-sipping-nat-scenarios-04 [13] Lendl, O., "The Domain Policy DDDS Application", draft-lendl- domain-policy-ddds-00 (work in progress), February 2006. [14] Lendl, O., "A Federation based VoIP Peering Architecture", draft-lendl-speermint-federations-02 (work in progress), August 2006. [15] Camarillo, G., Penfield, R., Hawrylyshen, A., "Requirements from SIP (Session Initiation Protocol) Session Border Controller Deployments", Internet Draft, draft-camarillo- sipping-sbc-funcs-03 penno Expires March 19, 2007 [Page 27] Internet-Draft draft-ietf-speermint-flows-01 September 2006 Author's Addresses Daryl Malas Level 3 Communications LLC 1025 Eldorado Blvd. Broomfield, CO 80021 USA EMail: daryl.malas@level3.com Sohel Khan, Ph.D. Technology Strategist Sprint 6220 Sprint Parkway Overland Park, KS 66251 U.S.A Email: Sohel.Q.Khan@sprint.com Reinaldo Penno Juniper Networks 1194 N Mathilda Avenue Sunnyvale, CA USA Email: rpenno@juniper.net Adam Uzelac Global Crossing 1120 Pittsford Victor Road PITTSFORD, NY 14534 USA Email: adam.uzelac@globalcrossing.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this penno Expires March 19, 2007 [Page 28] Internet-Draft draft-ietf-speermint-flows-01 September 2006 specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. penno Expires March 19, 2007 [Page 29]