SAVA BoF H. Deng Internet-Draft Hitachi Intended status: Standards Track June 29, 2007 Expires: December 31, 2007 Problem Statement for SAVA Multihoming draft-deng-sava-multihoming-problem-statement-00.txt 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 December 31, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Deng Expires December 31, 2007 [Page 1] Internet-Draft SAVA Multihome Problem Statement June 2007 Abstract This document specifies the problems for the SAVA (Source Address Verification Architecture) regarding to multihoming issue. The packets coming from the multihoming location may have two different AS numbers, this will be an issue for inter-domain source address verification. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem statement about Multihoming in the Inter-domain SAVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Deng Expires December 31, 2007 [Page 2] Internet-Draft SAVA Multihome Problem Statement June 2007 1. Introduction In the current SAVA BOF proposal[SAVA-FRAMEWORK], the architecture is categorized into three type of defense: access network, intra-domain, and inter-domain. When a host is located in multihoming scenario, the packet coming from this host may go through two different network access providers. In this case, this host may have two AS numbers. But current SAVA only assume the packet coming from only one AS number. This document defines a problem with inter-domain SAVA about multihoming issue. Deng Expires December 31, 2007 [Page 3] Internet-Draft SAVA Multihome Problem Statement June 2007 2. Terminology It is assumed that the reader is familiar with the terminology used in [RFC1654], [RFC2827]. In addition, the following terms are defined: The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. Deng Expires December 31, 2007 [Page 4] Internet-Draft SAVA Multihome Problem Statement June 2007 3. Problem statement about Multihoming in the Inter-domain SAVA A multihoming host in SAVA network architecture may has two AS numbers which may conflict with SAVA inter-domain solution. In this network architecture, as the below Figure 1, the host A have two network access connnections: ISP 1 which has network prefix a.b.c.0/24 and ISP 2 which has network prefix d.e.f.0/24, if host A follow the case of load balance which could enhance multihoming service. the packet from host A could go through left side router which is SAVA supported and the other router which is SAVA supported too, but the top BGP router would find that packet will have two types of AS number label coming from the same network address host A. SAVA may discard the packet which come late than previous and think it is a kind of malicious attack +----------+ | Provider | | | |m.n.o.0/24| +----------+ | | +----------+ |BGP Router| +--------|(SAVA |--------+ | | Support) | | |AS x +----------+ |AS y | | +----------+ +----------+ |BGP Router| |BGP Router| |(SAVA | | (SAVA | | Support) | | Support) | +----------+ +----------+ | | | | +----------+ +----------+ | ISP 1 | | ISP 2 | | Network | | Network | |a.b.c.0/24| |d.e.f.0/24| +----------+ +----------+ | | | +-----------+ | | | Host A | | +-------| |--------+ |Multihoming| +-----------+ Deng Expires December 31, 2007 [Page 5] Internet-Draft SAVA Multihome Problem Statement June 2007 Figure 1: SAVA Inter-domain Network Architecture for Multihoming Deng Expires December 31, 2007 [Page 6] Internet-Draft SAVA Multihome Problem Statement June 2007 4. Security Considerations This specification operates in the security constraints and requirements of about some events and provides the same level of security for all three nodes. Deng Expires December 31, 2007 [Page 7] Internet-Draft SAVA Multihome Problem Statement June 2007 5. IANA Considerations This document provides the problem description for an Inter-domain SAVA network architecture, BGP based routing protocol Deng Expires December 31, 2007 [Page 8] Internet-Draft SAVA Multihome Problem Statement June 2007 6. References 6.1. Normative References [RFC1654] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1654, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3871] Jones, G., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004. 6.2. Informative References [SAVA-E2E] Wu, JP., "A End-to-end Source Address Validation Solution for IPv6", Feb 2007, . [SAVA-FRAMEWORK] Wu, JP., "Source Address Validation Architecture (SAVA) Framework", Feb 2007, . [SAVA-PS] Wu, JP., "Source Address Validation Architecture Problem Statement", Feb 2007, . [SAVA-SIMPLE] Baker, F., "Simple Source Address Validation", March 2007, . [SAVA-TESTBED] Wu, JP., "SAVA Testbed and Experiences to Date", Feb 2007, . Deng Expires December 31, 2007 [Page 9] Internet-Draft SAVA Multihome Problem Statement June 2007 Author's Address Hui Deng Hitachi 301, North Building, Tower C, Raycom Infotech Park, 2, Kexueyuan Nanlu Hai Dian District Beijing 100080 China Email: hdeng@hitachi.cn Deng Expires December 31, 2007 [Page 10] Internet-Draft SAVA Multihome Problem Statement June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Deng Expires December 31, 2007 [Page 11]