idnits 2.17.1 draft-ietf-idr-fsm-subcode-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4271, updated by this document, for RFC5378 checks: 2006-01-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2012) is 4453 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BFMR2010' is defined on line 178, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft M. Chen 4 Updates: 4271 (if approved) Huawei Technologies 5 Intended status: Standards Track A. Suryanarayana 6 Expires: August 17, 2012 Cisco Systems 7 February 14, 2012 9 Subcodes for BGP Finite State Machine Error 10 draft-ietf-idr-fsm-subcode-03 12 Abstract 14 This document defines several subcodes for BGP Finite State Machine 15 (FSM) Error that could provide more information to help network 16 operators in diagnosing BGP FSM issues and correlating network 17 events. This document updates RFC 4271. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 17, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definition of Finite State Machine Error Subcodes . . . . . . . 3 61 3. Usage of FSM Error Subcodes . . . . . . . . . . . . . . . . . . 3 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 64 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 This document defines several subcodes for BGP [RFC4271] Finite State 74 Machine Error that could provide more information to help network 75 operators in diagnosing BGP FSM issues and correlating network 76 events. This information is also helpful to developers in lab 77 situations. This document updates [RFC4271] by requiring BGP 78 implementations to insert appropriate FSM Error subcodes in 79 NOTIFICATION messages for BGP FSM errors. 81 2. Definition of Finite State Machine Error Subcodes 83 This document defines following subcodes for BGP Finite State Machine 84 Error: 86 0 - Unspecific Error 88 1 - Receive Unexpected Message in OpenSent State 90 2 - Receive Unexpected Message in OpenConfirm State 92 3 - Receive Unexpected Message in Established State 94 3. Usage of FSM Error Subcodes 96 If a BGP speaker receives an unexpected message (e.g. KEEPALIVE/ 97 UPDATE/ROUTE-REFRESH message) on a session in OpenSent state, it MUST 98 send to the neighbor a NOTIFICATION message with the Error Code 99 Finite State Machine Error and the Error Subcode "Receive Unexpected 100 Message in OpenSent State". The Data field is a 1-octet unsigned 101 integer which indicates type of the unexpected message. 103 If a BGP speaker receives an unexpected message (e.g. OPEN/UPDATE/ 104 ROUTE-REFRESH message) on a session in OpenConfirm state, it MUST 105 send to the neighbor a NOTIFICATION message with the Error Code 106 Finite State Machine Error and the Error Subcode "Receive Unexpected 107 Message in OpenConfirm State". The Data field is a 1-octet unsigned 108 integer which indicates type of the unexpected message. 110 If a BGP speaker receives an unexpected message (e.g. OPEN message) 111 on a session in Established state, it MUST send to the neighbor a 112 NOTIFICATION message with the Error Code Finite State Machine Error 113 and the Error Subcode "Receive Unexpected Message in Established 114 State". The Data field is a 1-octet unsigned integer which indicates 115 type of the unexpected message. 117 4. Security Considerations 119 Specification, implementation, and deployment of the proposed BGP FSM 120 Error subcodes could make BGP implementation fingerprinting easier 121 and probably more accurate. Operators using BGP need to consider 122 this as an operational security consideration of their BGP deployment 123 decisions. 125 [BFMR2010]discusses a number of BGP security issues and potential 126 solutions that might be relevant both to BGP implementers and BGP 127 operators. 129 5. IANA Considerations 131 IANA is requested to create the registry "BGP Finite State Machine 132 Error Subcodes", within the "BGP Error Subcodes" registry, with a 133 Registration Procedure of "Standards Action" as defined in [RFC5226]. 134 (early allocation of such subcodes is allowed, in accordance with 135 [RFC4020]) 137 The registry should be populated with the following values: 139 Value Name 140 0 Unspecified Error 141 1 Receive Unexpected Message in OpenSent State 142 2 Receive Unexpected Message in OpenConfirm State 143 3 Receive Unexpected Message in Established State 145 6. Contributors 147 The following individuals contributed to this document: 149 Xiaoming Gu EMail: guxiaoming@huawei.com 151 Chong Wang EMail: chongwang@huawei.com 153 7. Acknowledgements 155 The authors would like to thank John Scudder, Jeffrey Haas, Susan 156 Hares, Keyur Patel, Enke Chen, Ruediger Volk and Ran Atkinson for 157 their valuable suggestions and comments to this document. 159 8. References 160 8.1. Normative References 162 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 163 Requirement Levels", BCP 14, RFC 2119, March 1997. 165 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 166 Standards Track Code Points", BCP 100, RFC 4020, 167 February 2005. 169 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 170 Protocol 4 (BGP-4)", RFC 4271, January 2006. 172 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 173 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 174 May 2008. 176 8.2. Informative References 178 [BFMR2010] 179 Butler, K., Farley, T., Mcdaniel, P., and J. Rexford, "A 180 Survey of BGP Security Issues and Solutions", 181 January 2010. 183 Authors' Addresses 185 Jie Dong 186 Huawei Technologies 187 Huawei Building, No.156 Beiqing Rd 188 Beijing 100095 189 China 191 Email: jie.dong@huawei.com 193 Mach Chen 194 Huawei Technologies 195 Huawei Building, No.156 Beiqing Rd 196 Beijing 100095 197 China 199 Email: mach.chen@huawei.com 200 Anantharamu Suryanarayana 201 Cisco Systems 202 USA 204 Email: asuryana@cisco.com