Inter-domain Working Group S. Hares Internet Draft NextHop Technologies P. Bose Lockheed-Martin Expires: August 2005 February 16, 2005 Dynamic AS Re-Associaiton draft-hares-bose-dynamic_as-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may not be modified, and derivative works of it may not be created. This document may only be posted in an Internet-Draft. 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 August 16, 2005. Hares & Bose Expires August 2005 [Page 1] draft-hares-bose-dynamic_as-00.txt February 2005 Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document provides a mechanism for Autonomous Systems within an AS Confederation to survive the disconnection to other AS within the AS confederation without dropping peers. When all links to the other AS in the Confederation break, this mechanism allows the AS to revert to local AS to continue communication with E-BGP peers. This mechanism has two parts: Capability signaling between the two parties at connection start to save two AS (internal and AS Confederation AS) and a mechanism to signal the switch between AS Confederation AS and internal AS. 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. Overview of Dynamic AS Re-Association..........................3 2. Mechanism overview for Dynamic AS Re-association...............3 3. Dynamic AS Capability..........................................4 4. Capability Message.............................................5 5. Security Considerations........................................6 6. Acknowledgments................................................6 7. References.....................................................6 7.1. Normative References......................................6 Author's Addresses................................................7 Intellectual Property Statement...................................7 Disclaimer of Validity............................................7 Copyright Statement...............................................8 Acknowledgment....................................................8 Hares & Bose Expires August 2005 [Page 2] draft-hares-bose-dynamic_as-00.txt February 2005 1. Overview of Dynamic AS Re-Association This mechanism provides a mechanism for two BGP peers switching AS values within a BGP association without dropping the AS connection. When two BGP wish to re-configure with a different Autonomous numbers, the current mechanisms in BGP require that the AS drop the connection. If an AS has considerable fan-in of peers, this dropping of the connection to re-associate a new AS may cause significant outages. This Dynamic AS re-association capability allows two Autonomous Systems and their BGP peers to collude to reset the AS associated with a BGP peer session without dropping the AS connection. The two BGP peers agree upon a fail-over to another AS based on a list of Autonomous Systems. 2. Mechanism overview for Dynamic AS Re-association The mechanism has two parts: 1) An Dynamic AS capability The Dynamic AS capability signals the ability to use the Dynamic AS Re-association function. The format of the ASConfed-Edge capability is described in section 2 and contains a list of Autonomous systems that the BGP peer may re-associated to. This capability also indicates the mechanism by which the node will signal the switch is the dynamic capabilities message. 2) Signaling the Dynamic AS Switch-over Signaling a Dynamic Switch is done via the Dynamic Capability message with the Dynamic AS capability. Upon receiving this dynamic capability, the BGP speaker associated with the AS-Confederation Edge process the switch of the peer from the current AS number to the one specified in the capability. All checking of the local AS in BGP packets utilizes the new AS. All new routes will be announced with the new AS number. All older routes will be re-announced based on the AS resend flag. Hares & Bose Expires August 2005 [Page 3] draft-hares-bose-dynamic_as-00.txt February 2005 3. Dynamic AS Capability [RFC3992] describes the open capability mechanisms. This document describes a new Capability: Dynamic AS: +------------------------------+ | Capability Code (1 octet) | +------------------------------+ | Capability Length (1 octet) | +------------------------------+ | Capability Value (variable) | +------------------------------+ Where the Capability value is: +------------------------------+ | Length of AS (1 octet) | - length of AS field (2 or 4) +------------------------------+ | resend prefix flag (1 octet) | - Resend/AS Flag +------------------------------+ | Number of AS supported | - Number of AS in re- +------------------------------+ associate list | Autonomous System 1 | - AS 1 - for dynamic re- +------------------------------+ association | ... | +------------------------------+ | Autonomous System n | - AS N - for dynamic re- +------------------------------+ association The resend prefix flag indicates when the AS will resend the routes with the new AS. The flag values are set as a bit pattern to indicate that 0x00 - Resend routes based on local timer (in bataches) 0x01 - Resend routes immediately 0x02 - Don't resend routes (leave with old AS confederation). The number of AS supported field gives the number of the Autonomous Systems fin the dynamic re-associations list. The Autonomous Systems in the AS list are the list of ASes that this peer may switch to in when dynamically re-association from the original AS to a new AS. Hares & Bose Expires August 2005 [Page 4] draft-hares-bose-dynamic_as-00.txt February 2005 Each side of the peer will send a list of Autonomous Systems that it will dynamic re-associate with. Upon start-up the re- associations list can be check by policy to determine that each side can support the required re-associations. 4. Capability Message This BGP dynamic capability uses the new BGP Capability format of: [DYN-CAP] +------------------------------+ | Init/Ack (1 bit) | +------------------------------+ | Ack Request (1 bit) | +------------------------------+ | Reserved (5 bits) | +------------------------------+ | Action (1 bit) | +------------------------------+ | Sequence Number (4 octets) | +------------------------------+ | Capability Code (1 octet) | +------------------------------+ | Capability Length (2 octets) | +------------------------------+ | Capability Value (variable) | +------------------------------+ The capability value is: +------------------------------+ | Length of AS | - length of AS field +------------------------------+ | resend prefix flag (1 octet) | - AS State +------------------------------+ | Current AS number | - Old AS number +------------------------------+ | New AS number | - new AS number +------------------------------+ Resend flag values: 0x00 - Resend routes based on local timer 0x01 - Resend routes immediately 0x02 - Don't resend routes (leave with old AS confederation). Hares & Bose Expires August 2005 [Page 5] draft-hares-bose-dynamic_as-00.txt February 2005 5. Security Considerations The security of the exchange is optionally secured by the TCP MD5 key. Upon discussion with security reviewers, the addition of this feature will neither improve nor detract from the TCP MD5 level of security. The authors considered adding a "cookie" feature to further secure this exchange. Again, review with security experts indicated this "cookied" feature would not improve the security level. The TCP session security will continue across the dynamic BGP peer re-association. The TCP sessions dynamic MD5 re-association or key switch would also allow TCP sessions to continue for a long period. 6. Acknowledgments My thanks to Russ White(Cisco) and Dan Voce (LCM) for reviewing the document. 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2 Informative References [DYN-CAP] Chen, E., Sangli, S. "Dynamic Capability for BGP-4" draft-ietf-idr-dynamic-cap-06.txt [RFC3392] Chandra, R. , Scudder, S., "Capabilities Advertisement with BGP-4", RFC3392, November 2002 Hares & Bose Expires August 2005 [Page 6] draft-hares-bose-dynamic_as-00.txt February 2005 Author's Addresses Susan Hares NextHop Technologies 825 Victors Way, Suite 100 Ann Arbor, MI 48108 Phone: 734.222.1610 Email: skh@nexthop.com Pratik Bose Lockheed Martin Email: Pratik.bose@lmco.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 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. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 Hares & Bose Expires August 2005 [Page 7] draft-hares-bose-dynamic_as-00.txt February 2005 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 (2004). 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. Hares & Bose Expires August 2005 [Page 8]