idnits 2.17.1 draft-ietf-bfd-secure-sequence-numbers-05.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 -- The document date (February 27, 2020) is 1513 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) == Missing Reference: 'O' is mentioned on line 160, but not defined == Missing Reference: 'S' is mentioned on line 114, but not defined == Missing Reference: 'A' is mentioned on line 160, but not defined == Missing Reference: 'H1' is mentioned on line 160, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-bfd-optimizing-authentication-09 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jethanandani 3 Internet-Draft S. Agarwal 4 Intended status: Standards Track Cisco Systems, Inc 5 Expires: August 30, 2020 A. Mishra 6 O3b Networks 7 A. Saxena 8 Ciena Corporation 9 A. Dekok 10 Network RADIUS SARL 11 February 27, 2020 13 Secure BFD Sequence Numbers 14 draft-ietf-bfd-secure-sequence-numbers-05 16 Abstract 18 This document describes a security enhancements for the BFD packet's 19 sequence number. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 30, 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Theory of operations . . . . . . . . . . . . . . . . . . . . 2 63 3. Impact of using a hash . . . . . . . . . . . . . . . . . . . 4 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 7.2. Informative References . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 BFD [RFC5880] section 6.7 describes the use of monotonically 75 incrementing 32-bit sequence numbers for use in authentication of BFD 76 packets. While this method protects against simple replay attacks, 77 the monotonically incrementing sequence numbers are predictable and 78 vulnerable to more complex attack vectors. This document proposes 79 the use of non-monotonically-incrementing sequence numbers in BFD 80 authentication TLVs to enhance the security of BFD sessions. 81 Specifically, the document presents a method to generate pseudo- 82 random sequence numbers on the frame by algorithmically hashing 83 monotonically increasing sequence numbers. Further security may be 84 introduced by resetting un-encrypted sequence to a random value when 85 the 32-bit sequence number rolls-over. 87 2. Theory of operations 89 Instead of monotonically increasing the sequence number or even 90 occasionally monotonically increasing the sequence number, the next 91 sequence number is generated by computing a hash on what would have 92 been the next sequence number using a shared key. That computed hash 93 is then inserted into the sequence number field of the packet. In 94 case of BFD Authentication [I-D.ietf-bfd-optimizing-authentication], 95 the sequence number used in computing an authenticated packet would 96 be this new computed hash. Even though the BFD Authentication 98 [I-D.ietf-bfd-optimizing-authentication] sequence number is 99 independent of this enhancement, it would benefit by using the 100 computed hash. 102 A normal BFD packet with authentication will undergo the following 103 steps, where: 105 [O]: original RFC 5880 packet with monotonically increasing sequence 106 number 108 [S]: psuedo random sequence number 110 [A]: Authentication 112 Sender Receiver 114 [O] [S] [A] ------------- [A] [S] [O] 116 In order to encode a sequence number, the sender would identify a 117 hash algorithm (symmetric) that would create a 32 bit hash. The 118 hashing key is provisioned securely on the sender and receiver of the 119 BFD session. The mechanism of provisioning such a key is outside the 120 scope of this draft. Instead of using the sequence number, the 121 sender encodes the sequence number with the hashing key to produce a 122 hash. 124 Upon receiving the BFD Control packet, the receiver compares the 125 received sequence number against the expected sequence number. The 126 mechanism used for comparing is an implementation detail 127 (implementations may pre-calculate the expected hashed sequence 128 number, or decrypt the received sequence number before comparing 129 against expected value). To tolerate dropped frames, the receiver 130 MUST compare the received sequence number against the current 131 expected seuqence number (previous received sequence number + 1) and 132 N subsequent expected sequence numbers (where N is greater than or 133 equal to the detect multiplier). Note: The first sequence number can 134 be obtained using the same logic as the My Discriminator value. 136 k: hashing key 138 s: sequence number 140 O: original RFC 5880 packet with monotonically increasing sequence 141 number 143 R: remainder of packet 145 H1: hash of s 146 H2: hash of entire packet 148 A: H2 + insertion in packet 150 hash(s, k) = H1 152 hash((H1 + R), k) = H2 154 hash'((Packet - H2), k) == H2 ? Good packet : bad packet 156 hash'(H1, k) == s ? Good sequence number : bad sequence number 158 Sender Receiver 160 [O] [H1] [A] -------- [A] [H1] [O] 162 3. Impact of using a hash 164 Under this proposal, every packet's sequence number is encoded within 165 a hash. Therefore there is some impact on the system and its 166 performance while encoding/decoding the hash. As security measures 167 go, this enhancement greatly increases the security of the packet 168 with or without authentication of the entire packet. 170 4. IANA Considerations 172 This document makes no request of IANA. 174 Note to RFC Editor: this section may be removed on publication as an 175 RFC. 177 5. Security Considerations 179 While the proposed mechanism improves overall security of BFD 180 mechanism, the security consderations are listed below: 182 Because of the fast rate of BFD sesions and it is difficult to change 183 the keys (used for hashing the sequence number) during the operation 184 of a BFD session without affecting the stabiluty of the BFD session. 185 It is, therefore, recommended to admistratively disable the BFD 186 session before changing the keys. If the keys are not changed, an 187 attacker can use a replay attack. 189 Using this method allows the BFD end-points to detect a malicious 190 packet (the decrypted sequence number will not be in sequence) the 191 behavior of the session when such a packet is detected is based on 192 the implementation. A flood of such malicious packets may cause a 193 session to report BFD session to be operationally down. 195 The hashing algorithm and key size will determine the difficulty for 196 an attacker to decipher the key from the transmitted BFD frames. 197 Sequential nature of the payload (sequence numbers) simplifies the 198 decoding of the key. It is, therefore, recommended to use longer 199 keys or more secure hashing algorithms. 201 6. Acknowledgements 203 7. References 205 7.1. Normative References 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, 209 DOI 10.17487/RFC2119, March 1997, 210 . 212 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 213 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 214 . 216 7.2. Informative References 218 [I-D.ietf-bfd-optimizing-authentication] 219 Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, 220 "Optimizing BFD Authentication", draft-ietf-bfd- 221 optimizing-authentication-09 (work in progress), December 222 2019. 224 Authors' Addresses 226 Mahesh Jethanandani 227 Cisco Systems, Inc 228 170 West Tasman Drive 229 San Jose, CA 95070 230 USA 232 Email: mjethanandani@gmail.com 234 Sonal Agarwal 235 Cisco Systems, Inc 236 170 W. Tasman Drive 237 San Jose, CA 95070 238 USA 240 Email: agarwaso@cisco.com 241 URI: www.cisco.com 242 Ashesh Mishra 243 O3b Networks 245 Email: mishra.ashesh@gmail.com 247 Ankur Saxena 248 Ciena Corporation 249 3939 North First Street 250 San Jose, CA 95134 251 USA 253 Email: ankurpsaxena@gmail.com 255 Alan DeKok 256 Network RADIUS SARL 257 100 Centrepointe Drive #200 258 Ottowa, ON K2G 6B1 259 Canada 261 Email: aland@freeradius.org