--- 1/draft-ietf-bfd-optimizing-authentication-00.txt 2016-02-17 15:15:03.886497218 -0800 +++ 2/draft-ietf-bfd-optimizing-authentication-01.txt 2016-02-17 15:15:03.906497718 -0800 @@ -1,23 +1,22 @@ Network Working Group M. Jethanandani Internet-Draft Cisco Systems Intended status: Standards Track A. Mishra -Expires: June 8, 2016 Ciena Corporation - A. Saxena - Citrix +Expires: August 18, 2016 A. Saxena + Ciena Corporation M. Bhatia Ionos Networks - December 6, 2015 + February 15, 2016 Optimizing BFD Authentication - draft-ietf-bfd-optimizing-authentication-00 + draft-ietf-bfd-optimizing-authentication-01 Abstract This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD [RFC5880]. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -31,47 +30,47 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 8, 2016. + This Internet-Draft will expire on August 18, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 3 - 3. NULL Auth TLV . . . . . . . . . . . . . . . . . . . . . . . . 3 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. NULL Auth TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 - 6.2. Informative References . . . . . . . . . . . . . . . . . 5 + 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Authenticating every BFD [RFC5880] packet with a Simple Password, or with a MD5 Message-Digest Algorithm [RFC1321] , or Secure Hash Algorithm (SHA-1) algorithms is computationally intensive process, making it difficult if not impossible to authenticate every packet - particularly at faster rates. Also, the recent escalating series of attacks on MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise @@ -111,61 +110,93 @@ decide which frames need to be authenticated, and authenticate only those frames. For example, the two ends can decide that BFD frames that indicate a state change should be authenticated and enable authentication on those frames only. If the two ends have not previously negotiated which frames they will transmit or receive with authentication enabled, then the BFD session will fail to come up, because at least one end will expect every frame to be authenticated. The state changes for which authentication is being suggested include: - Poll Sequence + Read : On state change from to + Auth : Authenticate frame + NULL : No Authentication. Use NULL AUTH TLV. + n/a : Invalid state transition. + Select : Most frames NULL AUTH. Selective (periodic) + frames authenticated. + +--------+--------+--------+--------+--------+--------+ + | | DOWN | INIT | UP | POLL | DEMAND | + +--------+--------+--------+--------+--------+--------+ + | DOWN | NULL | Auth | Auth | Auth | Auth | + +--------+--------+--------+--------+--------+--------+ + | INIT | Auth | NULL | Auth | Auth | Auth | + +--------+--------+--------+--------+--------+--------+ + | UP | Auth | n/a | Select | Auth | Auth | + +--------+--------+--------+--------+--------+--------+ + | POLL | Auth | n/a | Auth | Auth | Auth | + +--------+--------+--------+--------+--------+--------+ + | DEMAND | Auth | Auth | Auth | Auth | Auth | + +--------+--------+--------+--------+--------+--------+ - Demand Mode + Optimized Authentication Map - BFD packet with the Diag flag set + All frames already carry the sequence number. The NULL AUTH frames + MUST contain the TLV specified in Section 3. This enables a + monotonically increasing sequence number to be carried in each frame, + and prevents man-in-the-middle from capturing and replaying the same + frame again. Since all frames still carry a sequence number, the + logic for sequence number maintenance remains unchanged from + [RFC5880]. - Authenticated frames already carry the sequence number. The rest of - the frames MUST contain the TLV specified in Section 3. This enables - a monotonically increasing sequence number to be carried in each - frame, and prevents man-in-the-middle from capturing and replaying - the same frame again. + Most frames transmitted on a BFD session are BFD CC UP frames. + Authenticating a small subset of these frames (one per configured + period) significantly reduces the computational demand for the system + while maintaining security of the session across the configured + authentication periods. The configuration of the periodic + authentication interval for BFD CC UP frames is an open issue. 3. NULL Auth TLV This section describes a new Authentication TLV as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TLV Type | TLV Len | + | Auth Type | Auth Len | Auth Key ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Sender timestamp | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NULL Auth TLV where: - TLV Type: The TLV Type. This field MUST be set to . + Auth Type: The Authentication Type, which in this case is 0 (NULL + Auth TL) - TLV Length: The length of the NULL Auth TLV, in bytes i.e. 8 bytes + Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytes - Sequence Number: is a monotonically increasing number while the - session state is UP. Once the session goes down the Sequence number - SHOULD be set to 0. + Auth Key ID: The authentication key ID in use for this packet. Must + be set to zero. - Sender timestamp: is not used by authentication, and is documented to - be compatible with BFD Stability [I-D.ashesh-bfd-stability]. It - should be set to 0, and should be ignored by the receiver. + Reserved: The authentication key ID in use for this packet. This + allows multiple keys to be active simultaneously. + + Sequence Number: The sequence number for this packet. This value is + incremented for each successive packet transmitted for a session. + This provides protection against replay attacks. Must use the same + sequence number counter as the authenticated frames. + + The NULL Auth TLV must be used for all frames that are not + authenticated. This protects against replay-attacks by allowing the + session to maintain an incrementing sequence number for all frames + (authenticated and un-authenticated). 4. IANA Considerations IANA is requested to assign a new Auth Type for the NULL Auth TLV. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations @@ -289,33 +321,32 @@ Authors' Addresses Mahesh Jethanandani Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Phone: +1 (408) 526-8763 Email: mjethanandani@gmail.com - Ashesh Mishra Ciena Corporation 3939 North 1st Street San Jose, CA 95134 USA - Phone: +1 (408) 904-2114 Email: mishra.ashesh@gmail.com Ankur Saxena - Citrix - 4988 Great America Pkwy - Santa Clara, CA 95054 + Ciena Corporation + 3939 N 1st Street + San Jose, CA 95134 USA Email: ankurpsaxena@gmail.com + Manav Bhatia Ionos Networks Bangalore India Email: manav@ionosnetworks.com