SIPPING S. Srivastava Internet-Draft Nortel Networks Expires: November 25, 2006 May 24, 2006 Loop Avoidance Using Audits on Registration draft-srivastava-sipping-loop-avoidance-00 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 November 25, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document proposes change in registration process of SIP for avoiding installation of looped bindings spread across more than one proxy. This version of the document broadly outlines the solution. Exact details will be provided in the subsequent versions, as the solution progresses. Srivastava Expires November 25, 2006 [Page 1] Internet-Draft Loop Avoidance May 2006 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Modified Call Flow . . . . . . . . . . . . . . . . . . . . 4 3.2. Audit Mechanism . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Querying Proxies For Bindings . . . . . . . . . . . . . 5 3.2.2. Loop Detection using MAX-FORWARDS . . . . . . . . . . . 5 3.3. Action after loop detection . . . . . . . . . . . . . . . . 5 3.4. Addition of Routes Administratively . . . . . . . . . . . . 6 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informational References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Srivastava Expires November 25, 2006 [Page 2] Internet-Draft Loop Avoidance May 2006 1. Terminology 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]. 2. Problem Statement Looped bindings spread across more than one proxy with forking can generate enormous SIP traffic and eventually bring down the SIP network elements. ID.ietf-sip-fork-loop-fix [7] provides the details about the problem scenario. 3. Solution ID.campen-sipping-stack-loop-detect [8] fixes the problem by having a light weight loop detection algorithm instead of using via branch hash computation as specified in RFC 3261 [2]. As verification on the contacts is not performed, it goes further in negotiating the max-breadth as specified in ID.sparks-sipping-max-breadth [9] to contain the amplification. This solution requires loop detection at all proxies for all transactions. Consent framework ID.sipping-consent-framework [10] doesn't deal with the loop detection using audit mechanism defined in this document. Consent framework enables to get the permission from the endpoint before adding the bindings. An attacker can still install the looped bindings by deliberately giving the permissions. It is better for the SIP network elements to check for looped bindings defensively. The proposed solution doesn't let the looped registrations to succeed itself. It proposes to change the registration process as specified in RFC 3261 [2]. When registrar receives a REGISTER message, it checks for the validity of contact. It terminates the REGISTER transaction with "202 Accepted" response. When it gets the result of the audit on the contact specified in REGISTER, it notifies the endpoint the success/ failure of the REGISTER request using REG-EVENT package RFC3680 [3]. Solution requires extending reg-event package for including result of audit. It is assumed that registrar takes care of checking the loops within itself before committing it to location database, i.e. While adding binding A@abc -> B@abc, it searches the location database for B@abc and checks for loop. This check can be performed before returning a Srivastava Expires November 25, 2006 [Page 3] Internet-Draft Loop Avoidance May 2006 final response to REGISTER request. The use case of contacts spanning across multiple proxies is follow-me kind of services, where forwarding is installed using REGISTER. There is no need to run the audit on the contact in case of A)Register Refresh Request B)UnRegister Request C)Register Request where Contact in request doesn't point to another proxy and AOR doesn't contain address of a physical device In the above cases registrar does the normal processing as specified in RFC 3261 [2] 3.1. Modified Call Flow UA Proxy (P1) Proxy for Contact in REGISTER (P2) | | | |-----REGISTER----->| | | | | |<---202 Accepted---| | | | | |<-NOTIFY (REG-EV)--| | | | | |--200 OK (NOTIFY)->| | | | | | |<--Audit on Contact in REGISTER--->| | | | |<-NOTIFY (REG-EV)--| | | | | |--200 OK (NOTIFY)->| | | | | Figure 1 Call Flow With Modified Registration Process Above call flow is similar to REFER method processing as specified in RFC3515 [5]. REGISTER transaction is terminated with "202 Accepted" final response, as it gives ample time for auditing the contact. It might be possible that audit process might consult multiple proxies (e.g. AOR - Contact pair A->B , B->C ..... ). Here no of proxies visited by default is 70 (MAX-FORWARDS default). It can be some configurable value also. The second NOTIFY in the above call flow will have the outcome of audit on the contact in REGISTER message. The other alternative solution is return 1xx response on receipt of REGISTER and then run the audit. This causes un-desirable effect due to long Non-Invite-Transaction processing as specified in RFC4321 [6] Srivastava Expires November 25, 2006 [Page 4] Internet-Draft Loop Avoidance May 2006 3.2. Audit Mechanism There are two possible mechanism for verifying the contacts in the REGISTER message. 3.2.1. Querying Proxies For Bindings If querying capability for third party registration is allowed at the proxy (P2 in Figure 1) in contact header for the proxy in To header (P1 in Figure 1) in REGISTER request, then registering proxy (P1) can query proxy in contact header (P2) for the bindings. Then Registering Proxy (P1) checks whether it is the target in binding obtained from retargeting proxy (P2) with the same user, then it treats as a loop. If it is destined for another proxy then it queries that proxy and repeats the check. In the chain of proxies, a proxy can ask other proxy to get the contacts on its behalf. It assumes the transitive trust relationship, which may not be provided by service provider. 3.2.2. Loop Detection using MAX-FORWARDS Proxy can use increasing MAX-FORWARDS values with OPTIONS message to find the loop from detailed information available in the 483 response as specified in ID.ietf-sip-hop-limit-diagnostics [4]. 3.3. Action after loop detection If there is no loop found, registrar sends the "success" in REG-EVENT NOTIFY, otherwise it sends the "failure" in REG-EVENT NOTIFY. If loop is found due to addition of binding, a Registrar can take one of the following actions for keeping the bindings A)keep the contact in the location database but Proxy doesn't use this for retargeting the further request unless loop is broken by one of the proxies in the loop chain. If request comes to proxy for retargeting in the looped contact time window, it rejects the request with new error code "Loop Removal Needed". Appropriate 4xx code for this will be defined later. B)reject the registration request and doesn't keep the binding. Since these are looped bindings, it is difficult to decide which binding in the looped chain will be deleted later. It is already the error case, so it is better to reject the latest registration which is causing the loop and let endpoints clean up its associated registrations. Srivastava Expires November 25, 2006 [Page 5] Internet-Draft Loop Avoidance May 2006 OPEN ISSUE : Which option A) or B) should be chosen ? 3.4. Addition of Routes Administratively When routes are added by administrator, it is expected from them to run the loop detection audits before committing the routes to location database. 4. Backward Compatibility TBD 5. Security Considerations TBD 6. IANA Considerations TBD. 7. Acknowledgments The author would like to thank Francois Audet and Meenakshi Kaushik for providing valuable feedback. The author would like to thank Robert Sparks and Dale Worley for providing valuable comments on the mailing list while discussing the idea. 8. References 8.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., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [4] Lawrence, S., "Diagnostic Responses for SIP Hop Limit Errors", draft-ietf-sip-hop-limit-diagnostics-00 (work in progress), Srivastava Expires November 25, 2006 [Page 6] Internet-Draft Loop Avoidance May 2006 February 2006. 8.2. Informational References [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [6] Sparks, R., "Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321, January 2006. [7] Sparks, R., "Addressing an Amplification Vulnerability in Forking Proxies", draft-ietf-sip-fork-loop-fix-01 (work in progress), April 2006. [8] Campen, B., "An Efficient Loop Detection Algorithm for SIP Proxies", draft-campen-sipping-stack-loop-detect-00 (work in progress), March 2006. [9] Sparks, R., "Limiting the Damage from Amplification Attacks in SIP Proxies", draft-sparks-sipping-max-breadth-00 (work in progress), March 2006. [10] Rosenberg, J., "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", draft-ietf-sipping-consent-framework-04 (work in progress), March 2006. Srivastava Expires November 25, 2006 [Page 7] Internet-Draft Loop Avoidance May 2006 Author's Address Samir Srivastava Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 US Phone: +1 408 495 5143 Email: samirsr@nortel.com Srivastava Expires November 25, 2006 [Page 8] Internet-Draft Loop Avoidance May 2006 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 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. Srivastava Expires November 25, 2006 [Page 9]