idnits 2.17.1 draft-ietf-bfd-secure-sequence-numbers-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 : ---------------------------------------------------------------------------- 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 (November 21, 2017) is 2348 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-03 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: May 25, 2018 A. Mishra 6 O3b Networks 7 A. Saxena 8 Ciena Corporation 9 A. Dekok 10 Network RADIUS SARL 11 November 21, 2017 13 Secure BFD Sequence Numbers 14 draft-ietf-bfd-secure-sequence-numbers-01 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 May 25, 2018. 44 Copyright Notice 46 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . 4 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 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 6. Acknowledgements 181 7. References 183 7.1. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, 187 DOI 10.17487/RFC2119, March 1997, 188 . 190 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 191 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 192 . 194 7.2. Informative References 196 [I-D.ietf-bfd-optimizing-authentication] 197 Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, 198 "Optimizing BFD Authentication", draft-ietf-bfd- 199 optimizing-authentication-03 (work in progress), June 200 2017. 202 Authors' Addresses 204 Mahesh Jethanandani 205 Cisco Systems, Inc 206 170 West Tasman Drive 207 San Jose, CA 95070 208 USA 210 Email: mjethanandani@gmail.com 212 Sonal Agarwal 213 Cisco Systems, Inc 214 170 W. Tasman Drive 215 San Jose, CA 95070 216 USA 218 Email: agarwaso@cisco.com 219 URI: www.cisco.com 221 Ashesh Mishra 222 O3b Networks 224 Email: mishra.ashesh@gmail.com 226 Ankur Saxena 227 Ciena Corporation 228 3939 North First Street 229 San Jose, CA 95134 230 USA 232 Email: ankurpsaxena@gmail.com 233 Alan DeKok 234 Network RADIUS SARL 235 100 Centrepointe Drive #200 236 Ottowa, ON K2G 6B1 237 Canada 239 Email: aland@networkradious.com