idnits 2.17.1 draft-sonal-bfd-secure-sequence-numbers-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 22, 2017) is 2614 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 150, but not defined == Missing Reference: 'S' is mentioned on line 113, but not defined == Missing Reference: 'A' is mentioned on line 150, but not defined == Missing Reference: 'H1' is mentioned on line 150, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-bfd-optimizing-authentication-02 Summary: 0 errors (**), 0 flaws (~~), 7 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 26, 2017 A. Mishra 6 A. Saxena 7 Ciena Corporation 8 A. Dekok 9 Network RADIUS SARL 10 February 22, 2017 12 Secure BFD Sequence Numbers 13 draft-sonal-bfd-secure-sequence-numbers-00 15 Abstract 17 This document describes a security enhancements for the BFD packet's 18 sequence number. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 26, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Theory of operations . . . . . . . . . . . . . . . . . . . . 2 62 3. Impact of using a hash . . . . . . . . . . . . . . . . . . . 4 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 7.2. Informative References . . . . . . . . . . . . . . . . . 4 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 BFD [RFC5880] section 6.7 describes the use of monotonically 74 incrementing 32-bit sequence numbers for use in authentication of BFD 75 packets. While this method protects against simple replay attacks, 76 the monotonically incrementing sequence numbers are predictable and 77 vulnerable to more complex attack vectors. This document proposes 78 the use of non-monotonically-incrementing sequence numbers in BFD 79 authentication TLVs to enhance the security of BFD sessions. 80 Specifically, the document presents a method to generate pseudo- 81 random sequence numbers on the frame by algorithmically hashing 82 monotonically increasing sequence numbers. Further security may be 83 introduced by resetting un-encrypted sequence to a random value when 84 the 32-bit sequence number rolls-over. 86 2. Theory of operations 88 Instead of monotonically increasing the sequence number or even 89 occasionally monotonically increasing the sequence number, the next 90 sequence number is generated by computing a hash on what would have 91 been the next sequence number using a shared key. That computed hash 92 is then inserted into the sequence number field of the packet. In 93 case of BFD Authentication [I-D.ietf-bfd-optimizing-authentication], 94 the sequence number used in computing an authenticated packet would 95 be this new computed hash. Even though the BFD Authentication 97 [I-D.ietf-bfd-optimizing-authentication] sequence number is 98 independent of this enhancement, it would benefit by using the 99 computed hash. 101 A normal BFD packet with authentication will undergo the following 102 steps, where: 104 [O]: original RFC 5880 packet with monotonically increasing sequence 105 number 107 [S]: psuedo random sequence number 109 [A]: Authentication 111 Sender Receiver 113 [O] [S] [A] ------------- [A] [S] [O] 115 In order to encode a sequence number, the sender would identify a 116 hash algorithm (symmetric) that would create a 32 bit hash. The 117 hashing key is provisioned securely on the sender and receiver of the 118 BFD session. The mechanism of provisioning such a key is outside the 119 scope of this draft. Instead of using the sequence number, the 120 sender encodes the sequence number with the hashing key to produce a 121 hash. Upon receiving the BFD Control packet, the receiver decodes 122 the hash with the provisioned hashing key by performing a reverse 123 hash. Note: The first sequence number can be obtained using the same 124 logic as the My Discriminator value. 126 k: hashing key 128 s: sequence number 130 O: original RFC 5880 packet with monotonically increasing sequence 131 number 133 R: remainder of packet 135 H1: hash of s 137 H2: hash of entire packet 139 A: H2 + insertion in packet 141 hash(s, k) = H1 143 hash((H1 + R), k) = H2 144 hash'((Packet - H2), k) == H2 ? Good packet : bad packet 146 hash'(H1, k) == s ? Good sequence number : bad sequence number 148 Sender Receiver 150 [O] [H1] [A] -------- [A] [H1] [O] 152 3. Impact of using a hash 154 Under this proposal, every packet's sequence number is encoded within 155 a hash. Therefore there is some impact on the system and its 156 performance while encoding/decoding the hash. As security measures 157 go, this enhancement greatly increases the security of the packet 158 with or without authentication of the entire packet. 160 4. IANA Considerations 162 This document makes no request of IANA. 164 Note to RFC Editor: this section may be removed on publication as an 165 RFC. 167 5. Security Considerations 169 6. Acknowledgements 171 7. References 173 7.1. Normative References 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, 177 DOI 10.17487/RFC2119, March 1997, 178 . 180 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 181 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 182 . 184 7.2. Informative References 186 [I-D.ietf-bfd-optimizing-authentication] 187 Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, 188 "Optimizing BFD Authentication", draft-ietf-bfd- 189 optimizing-authentication-02 (work in progress), January 190 2017. 192 Authors' Addresses 194 Mahesh Jethanandani 195 Cisco Systems, Inc 196 170 West Tasman Drive 197 San Jose, CA 95070 198 USA 200 Email: mjethanandani@gmail.com 202 Sonal Agarwal 203 Cisco Systems, Inc 204 170 W. Tasman Drive 205 San Jose, CA 95070 206 USA 208 Email: agarwaso@cisco.com 209 URI: www.cisco.com 211 Ashesh Mishra 212 Ciena Corporation 213 3939 North First Street 214 San Jose, CA 95134 215 USA 217 Email: mishra.ashesh@gmail.com 219 Ankur Saxena 220 Ciena Corporation 221 3939 North First Street 222 San Jose, CA 95134 223 USA 225 Email: ankurpsaxena@gmail.com 227 Alan DeKok 228 Network RADIUS SARL 229 100 Centrepointe Drive #200 230 Ottowa, ON K2G 6B1 231 Canada 233 Email: aland@networkradious.com