idnits 2.17.1 draft-hares-idr-update-attrib-low-bits-fix-01.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -- The draft header indicates that this document updates RFC4271, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 25, 2013) is 4049 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: 'RFC2119' is defined on line 141, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 InterDomain Routing Group (IDR) S. Hares 3 Internet-Draft Huawei Technologies (USA) 4 Updates: 4271 (if approved) J. Scudder 5 Intended status: Standards Track Juniper Networks 6 Expires: August 29, 2013 February 25, 2013 8 Update Attribute Flag Low Bits Clarification 9 draft-hares-idr-update-attrib-low-bits-fix-01 11 Abstract 13 This draft provides an update to RFC 4721 to clarify the use of the 14 lower-order four bits of the Attribute flag in the Update message. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 29, 2013. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Change to RFC 4271 Section 4.3 . . . . . . . . . . . . . . . . 3 52 3. Known BGP Implementation Habits . . . . . . . . . . . . . . . . 4 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 55 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1. Introduction 60 [RFC4271] specifies in section 4.3 that that the low order four bits 61 of the the Attribute Flags octet are unused, and MUST be zero when 62 sent. There is a disagreement on what when sent means. This draft 63 specifies the meaning. 65 The issue has been that one school of thought considers that "when 66 sent" means when originated. Another holds that "when sent" means 67 when originated or propagated. This draft takes the second approach 68 of "when sent" being when originated or propagated. 70 The real issue is that reserved flags are only useful if there is 71 some hope of someday using them for something. If implementations 72 reset these flags on propagation, then a future revision to the BGP 73 specification which introduces a new flag will not be able to 74 propagate the new attribute flag end to end, since it would be very 75 likely that some well-meaning intermediate router would zero on it. 76 The effort to roll out implementations that transited the new flag 77 would almost certainly be prohibitive. 79 2. Change to RFC 4271 Section 4.3 81 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | Attr. Flags |Attr. Type Code| 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 Original Text: 88 The lower-order four bits of the Attribute Flags octet are 89 unused. They MUST be zero when sent and MUST be ignored when 90 received 92 Corrected Text: 94 The lower-order four bits of the Attribute Flags octet are 95 unused. They MUST be zero when originated or sent. 96 When received, any MUST be accepted and ignored. 98 3. Known BGP Implementation Habits 100 The following are BGP implementation habits regarding the unused flag 101 bits 103 o always ignore bits received, and always send zero (originated or 104 propagated); 106 o always ignore bits received, always send zero bits (originated), 107 and propagate what was received; 109 o if non-zero bits are received, drop the peering session; 111 o by special condition (policy) handle set bits or set bits, and 112 propagate;and 114 o always sets bits under special conditions, and propagates bits. 116 The reset of BGP sessions based on non-zero bits has been documented 117 at: 119 http://mailman.nanog.org/pipermail/nanog/2012-November/053754.html 121 Compliance with this draft, as well as [RFC4271], means that routers 122 should not reset BGP sessions if if non-zero lower bits are received. 124 4. IANA Considerations 126 This document includes no request to IANA. 128 5. Security Considerations 130 This document has no new security cases. 132 It clarifies some BGP UPDATE packet flag values and thus may aid in 133 improving BGP security. In particular, it makes it even clearer that 134 routers must not reset a session upon receiving unexpected flag 135 values. Behaving otherwise exposes a router to a denial-of-service 136 attack since a distant party might be able to inject such flag 137 values. 139 6. Normative References 141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 142 Requirement Levels", BCP 14, RFC 2119, March 1997. 144 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 145 Protocol 4 (BGP-4)", RFC 4271, January 2006. 147 Authors' Addresses 149 Susan Hares 150 Huawei Technologies (USA) 151 2330 Central Expressway 152 Santa Clara, CA 95050 153 USA 155 Email: Susan.Hares@huawei.com 157 John Scudder 158 Juniper Networks 159 1194 N. Mathilda Ave 160 Sunnyvale, CA 94089 161 USA 163 Email: jgs@juniper.net