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

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/