Network Working Group R. Penno Internet Draft Juniper Networks Expires: October 2006 D. Malas Level 3 S. Khan Sprint April 11, 2006 SPEERMINT Routing Architecture Message Flows draft-penno-message-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 October 11, 2006. Abstract This draft provides the message flows associated with the SPEERMINT routing architecture. We show message flows in several peering scenarios. penno Expires October 11, 2006 [Page 1] Internet-Draft SPEERMINT Message Flows April 2006 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...................................................2 2. Peering Message flows..........................................5 3. On-Demand Peering..............................................7 3.1.1. Transport Layer Security.............................7 3.1.2. Proxy Authentication.................................9 4. Static Peering................................................12 4.1.1. IPSec...............................................12 4.1.2. Co-Location.........................................13 5. Considerations on Private IP addresses........................13 6. Considerations on Media Flows.................................14 6.1. Decomposition............................................14 6.2. QoS......................................................14 7. Considerations on Multilateral Peering........................15 8. SPEERMINT QoS.................................................15 8.1. Problem Statement........................................16 8.2. QoS Policy Exchange......................................16 8.2.1. Service classes.....................................16 8.2.2. Service classes and Next-Hop........................17 8.2.3. Local Ingress Mapping...............................17 8.3. Packet Recognition and Marking...........................18 8.4. Trust....................................................18 9. Security Considerations.......................................18 10. IANA Considerations..........................................19 11. Conclusions..................................................19 12. Acknowledgments..............................................19 References.......................................................20 12.1. Normative References....................................20 12.2. Informative References..................................20 Author's Addresses...............................................21 Intellectual Property Statement..................................21 Disclaimer of Validity...........................................22 Copyright Statement..............................................22 Acknowledgment...................................................22 1. Introduction This document shows the message flows associated with the most relevant SPEERMINT routing architecture peering scenarios. Most of penno Expires October 11, 2006 [Page 2] Internet-Draft SPEERMINT Message Flows April 2006 the messages diagrams were based on previous work done by the SIP and SIPPING working groups. The document focuses on the messages exchanged for the purpose of Layer 5 peering [7] between two domains. Messages exchanged for the purposed of setting up SIP session within a domain are considered out of scope and were already defined in other working groups. 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 gives rises to two different models: o Decomposed: In this model SIP proxies perform Layer 5 peering and media is sent directly between the UAs involved in the session. Signaling and media follow different paths. 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. penno Expires October 11, 2006 [Page 3] Internet-Draft SPEERMINT Message Flows April 2006 ............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | DNS | . . | DNS | . . | 1 | . . | 2 | . . | | . . | | . . +-------+ . . +-------+ . . | . . | . . | . . | . . +-------+ . . +-------+ . . | | . . | | . . | Proxy |--------------| Proxy | . . | 1 | . . | 2 | . . | | . . | | . . / +-------+ . . +-------+ \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . +-------+ . . +-------+ . . | | . . | | . . | | . Media . | | . . | UA 1 |<========================================>| UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. Figure 1 Basic Peering Picture. The collapsed model is shown below ............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | DNS | . . | DNS | . . | 1 | . . | 2 | . . | | . . | | . . +-------+ . . +-------+ . . | . . | . . | . . | . . +-------+ . . +-------+ . . | | . . | | . . | B2BUA |--------------| B2BUA | . penno Expires October 11, 2006 [Page 4] Internet-Draft SPEERMINT Message Flows April 2006 . | 1 |**************| 2 |\ . . /| | . . | | \ . . / +-------+ . . +-------+* \ signaling . . / * . . * \ . . / * . . * \ . . / * . . * \ . . / * media . . * \ . . / * . . * \ . . / * . . * \ . . / * . . * \ . . +-------+ . . +-------+ . . | | . . | | . . | | . . | | . . | UA 1 | . . | UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. Figure 2 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 October 11, 2006 [Page 5] Internet-Draft SPEERMINT Message Flows April 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 October 11, 2006 [Page 6] Internet-Draft SPEERMINT Message Flows April 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 | |<======>|<==================>|<==========>| | | | BYE | 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.1. Transport Layer Security In this scenario, trust between domains A and B is implied by the TLS connection. The TLS connection is only established as a result of the first session between domains A and B. penno Expires October 11, 2006 [Page 7] Internet-Draft SPEERMINT Message Flows April 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 October 11, 2006 [Page 8] Internet-Draft SPEERMINT Message Flows April 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 two succeed. 3.1.2. Proxy Authentication In this scenario we are assuming a new type Proxy authentication method exists that allows mutual authentication between two proxies. This authentication could be driven by a SIP session (on-demand) or happen before any sessions penno Expires October 11, 2006 [Page 9] Internet-Draft SPEERMINT Message Flows April 2006 ALICE Proxy 1(P1) Proxy 2(P2) Bob | | | | | |REGISTER | | | |------------------->| | | | 401 Unauthorized | | | |<-------------------| | | |REGISTER w/Auth | | | |------------------->| | | | 100 Trying | | | |<-------------------| | | | 200 OK w/P2Key | | | |<-------------------| | | | REGISTER | | | |<-------------------| | | | 401 Unauthorized | | | |------------------->| | | | REGISTER w/Auth| | | |<-------------------| | | | 100 Trying | | | |------------------->| | | | 200 OK w/P1Key | | | |------------------->| | | INVITE | | | |--------------->| | | | 100 Trying |INVITE w/P2Key | | |<---------------|------------------->| | | | 100 Trying |INVITE | | |<-------------------|-----------> | | | |180 Ringing | | | 180 Ringing |<----------- | | 180 Ringing|<-------------------| | |<---------------| |200 OK | | | 200 OK |<----------- | | 200 OK |<-------------------| | |<---------------| | | | ACK | | | |--------------->|ACK | | | |------------------->|ACK | | | |-----------> | Proposed OPTIONAL peering authentication requirements: 1. In order for a peering relationship to exist, both parties must agree to the relationship. To facilitate this, a common method for the two peering proxies to authenticate with each other must be defined. penno Expires October 11, 2006 [Page 10] Internet-Draft SPEERMINT Message Flows April 2006 2. The authentication method should utilize established SIP security mechanisms if possible. 3. Upon authentication, the two parties must maintain an authenticated state for continual bi-directional session establishment. This state must be challenged on a variable basis in order to diminish man-in-the-middle (MIM) and external spoofing attacks. 4. Upon an authentication request, a proxy must respond with either an authentication failure response or a mutual (peer) authentication attempt. 5. The authentication request must contain a timer, which allows the peer to mutually authenticate within the specified timeframe. Upon timer expiry, a new authentication dialog must be attempted. 6. If authentication fails, due to incorrect credentials; the proxy must respond with a 401 Unauthorized message. In this case, the peering proxies are acting as registrars for peering proxy relationships. 7. An authorization key must be exchanged by the peering proxies for use within the applicable SIP messages. This will be used to validate the individual session's ability to progress to the pre- supposed user agent (UA) or user agent server (UAS). This eliminates the need for each session to be challenged, creating unnecessary traffic congestion. 8. The authorization key must change upon the variable basis established within requirement 3. This additionally increases security by diminishing MIM and external spoofing attacks. 9. Upon a peering authentication failure, even if by only one proxy in the relationship; the peering relationship must be considered at end and all authorization keys invalidated for new session attempts. 10.If a peering relationship is terminated due to any reason, existing sessions must be maintained until either the peering relationship is re-established or the session is ended. 11.The authorization keys from both peering proxies must be maintained and viable for use throughout sustained sessions until the sessions have ended. This allows applicable user agents to offer additional session changes such as RE-INVITE even if the peering relationship has been terminated. penno Expires October 11, 2006 [Page 11] Internet-Draft SPEERMINT Message Flows April 2006 12.In the case of authorization key failure, the proxy associated with the failure must respond with a 407 Proxy Authentication Required message associated with the session. 13.Upon authorization key failure, the proxy associated with the failure must challenge the peering proxy and update the related key for use in future session validation. 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. 4.1.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 | | | penno Expires October 11, 2006 [Page 12] Internet-Draft SPEERMINT Message Flows April 2006 4.1.2. Co-Location In this scenario the two proxies are co-located in a physical secure location and/or are member of a segregated network. In this case messages between Proxy 1 and Proxy 2 would be sent as clear text. Alice Proxy 1 DNS Proxy 2 Bob | | | | | | | | | | | [Peering] | | | | Co-Location | | | |<------------------>| | | | | | | \ / \ / \ / \ / \ / | | | | | | INVITE | | | | |------->| | | | | 100 | | | | |<-------| | | | \ / \ / \ / \ / \ / | | BYE |<----------| | BYE |<-------------------| | |<-------| | | | 200 | | | 5. Considerations on Private IP addresses In Layer 5 peering scenarios, it does not really matter if the peering fabric is public or private. What is relevant is if one of the SIP devices participating in the session is in a public address space and the other in a private. In this case some observations should be made: o A SIP device in a private address space can only communicate with a device in a public address space if a NAT binding from private to public address is provided. o If a SIP device is in a private address space behind legacy NAT device and does implement a NAT traversal method [8], media relay might be needed for the successful establishment of the session. Media relay is most commonly implemented by a B2BUA or SBC. A legacy Nat is one that does not implement a SIP Application Level Gateway (ALG).[4] penno Expires October 11, 2006 [Page 13] Internet-Draft SPEERMINT Message Flows April 2006 6. Considerations on Media Flows 6.1. Decomposition The scenarios in the previous sections show media flowing between the endpoints involved in the SIP session, but it is important to understand that the domains involved in peering might not carry the media associated with such sessions. Media associated with the sessions established across the peering interface could be carried by a traditional ISP. The picture below depicts such scenario. +---------+ _________ /--->| VSP |<-----\ / | | \ | +---------+ | Signaling | | Signaling (peering) | | (peering) | | +------------+ | | +------------+ | |<-/ +-----------+_ \->| | | | | | | | | Domain A |>------->| ISP |>-------->| Domain B | | |<-------<|___________|<--------<| | |____________| Media | | Media |____________| +------------+ +-----------+ +------------+ 6.2. QoS Media flows for real time communication usually need strict scheduling guarantees in order to not degrade the service. The problem of QoS within an independent administratively domain and across domains is quite different. In the case L5 peering several issues arise around QoS for media flows, especially in the case of on-demand peering. Some of these issues are listed below. o How to reconcile general QoS parameters used in domain A across the peering interface with those announced by domain B's peering policy? penno Expires October 11, 2006 [Page 14] Internet-Draft SPEERMINT Message Flows April 2006 o How domain B can identify media flows crossing the peering interface coming from domain A (and vice-versa) in order to provide the agreed upon QoS treatment? We could potentially be talking about hundreds of call (and consequently new media flows) per second. o Moreover, in a decomposed scenario, how the SIP Proxy can let the router know the identity of such media flows and the QoS parameters associated with it? This problem was discussed under the TISPAN umbrella and NGN networks [6]. o Alternatively or in conjunction with dynamic identification there is the issue of trust. Possibly domain B could trust domain A to mark all media packets appropriately. Domain B would honor such markings and give the appropriate treatment announced on its peering policy 7. Considerations on Multilateral Peering Some of the difficulties discussed in previous sections would be aggravated in the case of multilateral on-demand peering where potentially more than on VSP could carry signaling (and possibly media) to reach a specific endpoint. How peering policies could be compared to find out the best one for a specific case? In the case of routing protocols a combination of metrics, route filtering and others techniques provide a solution. +---------+ | | / | Domain |\ / | C | \ / | | \ / +---------+ \ / \ +--------+ / +---------+ \ +--------+ +-----+ | |---/ | | \----| | | | | Domain | | Domain | | Domain | | UA | | A |-----------| B |-----------| D |-------| | | | | | | | +-----+ +--------+ +---------+ +--------+ 8. SPEERMINT QoS As discussed in section 6.2, there are various QoS aspects that need to be taken into account in the context of SPEERMINT. The next penno Expires October 11, 2006 [Page 15] Internet-Draft SPEERMINT Message Flows April 2006 sections discuss those aspects by first going laying out some groundwork and then going through scenarios. 8.1. Problem Statement When SIP signaling and media packets from UA 1 arrive at peering point destined to UA 2, the Layer 5 peering devices need to make sure those packets receive the proper treatment when crossing domains. This involves three aspects: packet recognition and marking, trust and QoS policy exchange. 8.2. QoS Policy Exchange At any time during the life of the peering agreement, domains 1 and 2 need to exchange QoS policies. This policy will inform the opposite peering domain the rules for marking signaling and media packets. This procedure is more relevant to media as opposed to signaling; since we are assuming the layer 5 peering devices are SIP proxies. Some policy examples with different granularities are show below: 8.2.1. Service classes In this example, the service classes suggested in [7] are used. If Domain 1 receives such a policy from Domain 2, we should read "telephony packets should be marked with EF". ----------------------------------------- | Service | DSCP | DSCP | | Class name | name | value | |===============+=========+=============+ | Telephony | EF | 101110 | |---------------+---------+-------------+ | Signaling | CS5 | 101000 | |---------------+---------+-------------+ | Multimedia |AF41,AF42|100010,100100| | Conferencing | AF43 | 100110 | |---------------+---------+-------------+ | Real-time | CS4 | 100000 | | Interactive | | | |---------------+---------+-------------+ | Multimedia |AF31,AF32|011010,011100| | Streaming | AF33 | 011110 | |---------------+---------+-------------+ |Broadcast Video| CS3 | 011000 | +---------------+---------+-------------+ penno Expires October 11, 2006 [Page 16] Internet-Draft SPEERMINT Message Flows April 2006 8.2.2. Service classes and Next-Hop In this example we have introduced the notion of next-hop as one more classification dimension. If Domain 1 receives such a policy from Domain 2, we should read "multimedia streaming packets destined to 9.0.1/24 should be marked with AF31". +--------------------------------------------------+ | Service | Next-Hop | DSCP | DSCP | | Class name | | name | value | |===============+==========+=========+=============+ | Telephony | 10.0.0.1 | EF | 101110 | |---------------+----------+---------+-------------+ | Telephony | 11.0.0.1 | AF41 | 100010 | |---------------+----------+---------+-------------+ | Signaling | 12.0.0.1 | CS5 | 101000 | |---------------+----------+---------+-------------+ | Multimedia | 9.0.1/24 | AF31 | 011010 | | Streaming | | | | |---------------+----------+---------+-------------+ |Broadcast Video| 12.1/16 | CS3 | 011000 | +---------------+----------+---------+-------------+ 8.2.3. Local Ingress Mapping It is important to understand that a domain would have a local mapping. This could be independent or above and beyond any QoS policy exchanges. We should read "a packet received with an EF DSCP should be marked with AF41". ------------------------- | Ingress | Egress | | DSCP | DSCP | | name | name | +=========+=============+ | EF | AF41 | +---------+-------------+ | CS5 | CS5 | +---------+-------------+ |AF41,AF42| AF41 | | AF43 | | +---------+-------------+ | CS4 | CS4 | +---------+-------------+ penno Expires October 11, 2006 [Page 17] Internet-Draft SPEERMINT Message Flows April 2006 8.3. Packet Recognition and Marking If the layer 5 peering devices (referred as SIP Proxies) are going to mark signaling and media packets, they need to first be able to recognize them. Recognizing and marking SIP signaling is not problematic since we assume the Layer 5 peering devices perform SIP proxy functions. It leaves the media packets. If the SIP Proxy does not inspect the SDP payload in SIP messages to learn how to identify media packets, the only solution is to trust that the endpoints or an upstream proxy have already done it (see section 8.3). On the other hand, if the SIP Proxy performs SDP inspection, it will be able to recognize media packets based on the contents of the c and m lines. Now we come to the problem of which device will mark the packets. In a decomposed scenario, the SIP proxy needs to let the router know how to identify media packets and which marking to use. One possible solution is the use of a Gate Control Protocol [6]. In a collapsed scenario the problem of identifying and marking packets is less severe. 8.4. Trust If Proxy 1 trusts that its users will mark packets correctly, the issue of packet recognition and marking can be mitigated. Of course that does not imply that Proxy 2 trusts Domain 1 to mark packets correctly. That's where a QoS policy exchange comes into play. 9. Security Considerations The level of security required during the establishment and maintenance of a SIP peering relationship between to 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 a 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 VPN), one could argue that basic filtering based on IP address is enough. penno Expires October 11, 2006 [Page 18] Internet-Draft SPEERMINT Message Flows April 2006 10. IANA Considerations There are no IANA considerations at this point 11. Conclusions The purpose of this draft is to show SPEERMINT message flows as specified in charter but also to raise awareness through questions and detailed considerations of several issues the WG might have to deal in different peering scenarios. 12. Acknowledgments TBD penno Expires October 11, 2006 [Page 19] Internet-Draft SPEERMINT Message Flows April 2006 References 12.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. 12.2. Informative References [8] Camarillo, G., Penfield, R., Hawrylyshen, A., "Requirements from SIP (Session Initiation Protocol) Session Border Controller Deployments", Internet Draft, draft-camarillo- sipping-sbc-funcs-03 [9] Meyer, D., "SPEERMINT Requirements and Terminology", Internet Draft, draft-ietf-speermint-reqs-and-terminology-01 [10] Boulton, C., Rosenberg, J., Camarillo, G., "Best Current Practices for NAT Traversal for SIP", Internet Draft, draft- ietf-sipping-nat-scenarios-04 penno Expires October 11, 2006 [Page 20] Internet-Draft SPEERMINT Message Flows April 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 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 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 penno Expires October 11, 2006 [Page 21] Internet-Draft SPEERMINT Message Flows April 2006 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 October 11, 2006 [Page 22]