draft-ietf-bfd-optimizing-authentication-10.txt   draft-ietf-bfd-optimizing-authentication-11.txt 
Network Working Group M. Jethanandani Network Working Group M. Jethanandani
Internet-Draft Kloud Services Internet-Draft Kloud Services
Updates: 5880 (if approved) A. Mishra Updates: 5880 (if approved) A. Mishra
Intended status: Standards Track SES Networks Intended status: Standards Track SES Networks
Expires: January 14, 2021 A. Saxena Expires: January 29, 2021 A. Saxena
Ciena Corporation Ciena Corporation
M. Bhatia M. Bhatia
Nokia Nokia
July 13, 2020 July 28, 2020
Optimizing BFD Authentication Optimizing BFD Authentication
draft-ietf-bfd-optimizing-authentication-10 draft-ietf-bfd-optimizing-authentication-11
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 RFC 5880. This document updates RFC described in Section 6.7 of BFD RFC 5880. This document updates RFC
5880. 5880.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 January 14, 2021. This Internet-Draft will expire on January 29, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 3 2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 4
3. NULL Auth Type . . . . . . . . . . . . . . . . . . . . . . . 6 3. NULL Auth Type . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Authenticating every BFD [RFC5880] packet with a Simple Password, or Authenticating every BFD [RFC5880] control packet with a Simple
with a MD5 Message-Digest Algorithm [RFC1321] , or Secure Hash Password, or with a MD5 Message-Digest Algorithm [RFC1321] , or
Algorithm (SHA-1) algorithms is a computationally intensive process. Secure Hash Algorithm (SHA-1) algorithms is a computationally
This makes it difficult, if not impossible to authenticate every intensive process. This makes it difficult, if not impossible to
packet - particularly at faster rates. Also, the recent escalating authenticate every packet - particularly at faster rates. Also, the
series of attacks on MD5 and SHA-1 described in Finding Collisions in recent escalating series of attacks on MD5 and SHA-1 described in
the Full SHA-1 [SHA-1-attack1] and New Collision Search for SHA-1 Finding Collisions in the Full SHA-1 [SHA-1-attack1] and New
[SHA-1-attack2] raise concerns about their remaining useful lifetime Collision Search for SHA-1 [SHA-1-attack2] raise concerns about their
as outlined in Updated Security Considerations for the MD5 Message- remaining useful lifetime as outlined in Updated Security
Digest and the HMAC-MD5 Algorithm [RFC6151] and Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm
Considerations for the SHA-0 and SHA-1 Message-Digest Algorithm [RFC6151] and Security Considerations for the SHA-0 and SHA-1
[RFC6194]. If replaced by stronger algorithms, the computational Message-Digest Algorithm [RFC6194]. If replaced by stronger
overhead, will make the task of authenticating every packet even more algorithms, the computational overhead, will make the task of
difficult to achieve. authenticating every packet even more difficult to achieve.
This document proposes that only BFD packets that signal a state This document proposes that only BFD control packets that signal a
change, a demand mode change (to D bit) or a poll sequence change (P state change, a demand mode change (to D bit) or a poll sequence
or F bit change) in a BFD packet be categorized as a significant change (P or F bit change) in a BFD control packet be categorized as
change. This document also proposes that all BFD control packets a significant change. This document also proposes that all BFD
which signal a significant change MUST be authenticated if the control packets which signal a significant change MUST be
session's bfd.AuthType is non-zero. Other BFD Control packets MAY be authenticated if the session's bfd.AuthType is non-zero. Other BFD
transmitted and received without the A bit set. control packets MAY be transmitted and received without the A bit
set.
Most packets that are transmitted and received have no state change Most packets that are transmitted and received have no state change
associated with them. Limiting authentication to packets that affect associated with them. Limiting authentication to packets that affect
a BFD session state allows more sessions to be supported with this a BFD session state allows more sessions to be supported with this
optimized method of authentication. Moreover, most BFD packets that optimized method of authentication. Moreover, most BFD control
signal a significant change are generally transmitted at a slower packets that signal a significant change are generally transmitted at
interval of 1s, leaving enough time to compute the hash. a slower interval of 1s, leaving enough time to compute the hash.
To detect a Man In the Middle (MITM) attack, it is also proposed that To detect a Man In the Middle (MITM) attack, it is also proposed that
a BFD control packet without a significant change be authenticated a BFD control packet without a significant change be authenticated
occasionally. The interval of this non-state change frame can be occasionally. The interval of the BFD control packets without a
configured depending on the detect multiplier and the capability of significant change can be configured depending on the detect
the system. As an example, this could be equal to the detect multiplier and the capability of the system. As an example, this
multiplier number of packets. could be equal to the detect multiplier number of packets.
The rest of the document is structured as follows. Section 2 talks The rest of the document is structured as follows. Section 2 talks
about the changes to authentication mode as described in BFD about the changes to authentication mode as described in BFD
[RFC5880]. Section 3 goes into the details of the new Authentication [RFC5880]. Section 3 goes into the details of the new Authentication
Type. Type.
1.1. Requirements Language 1.1. 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 3, line 36 skipping to change at page 3, line 36
1.2. Terminology 1.2. Terminology
The following terms used in this document have been defined in BFD The following terms used in this document have been defined in BFD
[RFC5880]. [RFC5880].
o Detect Multiplier o Detect Multiplier
o Detection Time o Detection Time
The following terms are introduced in this document.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Term | Meaning | | Term | Meaning |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| significant | State change, a demand model change (to D bit) or | | significant | State change, a demand model change (to D bit) or |
| change | a poll sequence change (P or F bit). | | change | a poll sequence change (P or F bit). |
| configured | configured authentication periodic interval | | | |
| interval | | | configured | Interval at which BFD control packets are |
| interval | authenticated in the UP state. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
2. Authentication Mode 2. Authentication Mode
The cryptographic authentication mechanisms specified in BFD The cryptographic authentication mechanisms specified in BFD
[RFC5880] describes enabling and disabling of authentication as a one [RFC5880] describes enabling and disabling of authentication as a one
time operation. As a security precaution, it mentions that time operation. As a security precaution, it mentions that
authentication state be allowed to change at most once. Once authentication state be allowed to change at most once. Once
enabled, every packet must have Authentication Bit set and the enabled, every packet must have Authentication Bit set and the
associated Authentication Type appended. In addition, it states that associated Authentication Type appended. In addition, it states that
an implementation SHOULD NOT allow the authentication state to be an implementation SHOULD NOT allow the authentication state to be
changed based on the receipt of a BFD Control packet. changed based on the receipt of a BFD control packet.
This document proposes that the authentication mode be modified to be This document proposes that the authentication mode be modified to be
enabled on demand. Instead of authenticating every packet, BFD peers enabled on demand. Instead of authenticating every packet, BFD peers
are configured for which packets need to be authenticated, and are configured for which packets need to be authenticated, and
authenticate only those packets. Rest of the packets can be authenticate only those packets. Rest of the packets can be
transmitted and received without authentication. For example, the transmitted and received without authentication. For example, the
two ends can be configured such that BFD packets that indicate a two ends can be configured such that BFD control packets that
significant change should be authenticated and enable authentication indicate a significant change should be authenticated and enable
on those packets only. If the two ends have previously been authentication on those packets only. If the two ends have
configured as such, but at least one side decides not to authenticate previously been configured as such, but at least one side decides not
a significant change frame, then the BFD session will fail to come to authenticate a significant change packet, then the BFD session
up. will fail to come up.
This proposal outlines which packets need to be authenticated (carry This proposal outlines which BFD control packets need to be
the A-bit), and which packets can be transmitted or received without authenticated (carry the A-bit), and which packets can be transmitted
authentication enabled. A frame that fails authentication is or received without authentication enabled. A BFD control packet
discarded, or a frame that was supposed to be authenticated, but was that fails authentication is discarded, or a BFD control packet that
not, e.g. a significant change frame, is discarded. However, there was supposed to be authenticated, but was not, e.g. a significant
is no change to the state machine for BFD, as the decision of a change packet, is discarded. However, there is no change to the
significant change is still decided by how many valid consecutive state machine for BFD, as the decision of a significant change is
packets were received, authenticated or otherwise. still decided by how many valid consecutive packets were received,
authenticated or otherwise.
The following table summarizes when the A bit should be set. The The following table summarizes when the A bit should be set. The
table should be read with the column indicating the BFD state the table should be read with the column indicating the BFD state the
receiver is currently in, and the row indicating the BFD state the receiver is currently in, and the row indicating the BFD state the
receiver might transition to based on the packet received. The receiver might transition to based on the BFD control packet
interesection of the two indicates whether the received packet should received. The interesection of the two indicates whether the
have the A bit set (Auth), no authentication is needed (NULL), most received BFD control packet should have the A bit set (Auth), no
packets are NULL AUTH (Select) or the state transition is not authentication is needed (NULL), most packets are NULL AUTH (Select)
applicable. or the state transition is not applicable. The BFD state refers to
the states in BFD state machine described in Section 6.2 of BFD
[RFC5880].
Read : On state change from <column> to <row> Read : On state change from <column> to <row>
Auth : Authenticate frame Auth : Authenticate BFD control packet
NULL : No Authentication. Use NULL AUTH Type. NULL : No Authentication. Use NULL AUTH Type.
n/a : Invalid state transition. n/a : Invalid state transition.
Select : Most packets NULL AUTH. Selective (periodic) Select : Most packets NULL AUTH. Selective (periodic)
packets authenticated. packets authenticated.
+--------+--------+--------+--------+------------+ +--------+--------+--------+--------+
| | DOWN | INIT | UP | ADMIN DOWN | | | DOWN | INIT | UP |
+--------+--------+--------+--------+------------+ +--------+--------+--------+--------+
| DOWN | NULL | Auth | Auth | NULL | | DOWN | NULL | Auth | Auth |
+--------+--------+--------+--------+------------+ +--------+--------+--------+--------+
| INIT | Auth | NULL | n/a | n/a | | INIT | Auth | NULL | n/a |
+--------+--------+--------+--------+------------+ +--------+--------+--------+--------+
| UP | Auth | Auth | Select | n/a | | UP | Auth | Auth | Select |
+--------+--------+--------+--------+------------+ +--------+--------+--------+--------+
| ADMIN | NULL | Auth | Auth | NULL |
+--------+--------+--------+--------+------------+
Optimized Authentication Map Optimized Authentication Map
If P or F bit changes value, the packet MUST be authenticated. If If P or F bit changes value, the BFD control packet MUST be
the D bit changes value, the packet MUST be authenticated. authenticated. If the D bit changes value, the BFD control packet
MUST be authenticated.
All packets already carry the sequence number. The NULL AUTH packets All packets already carry the sequence number. The NULL AUTH packets
MUST contain the Type specified in Section 3. This enables a MUST contain the Type specified in Section 3. This enables a
monotonically increasing sequence number to be carried in each frame, monotonically increasing sequence number to be carried in each
and prevents man-in-the-middle from capturing and replaying the same packet, and prevents man-in-the-middle from capturing and replaying
frame again. Since all packets still carry a sequence number, the the same packet again. Since all packets still carry a sequence
logic for sequence number maintenance remains unchanged from BFD number, the logic for sequence number maintenance remains unchanged
[RFC5880]. If at a later time, a different scheme is adopted for from BFD [RFC5880]. If at a later time, a different scheme is
changing sequence number, e.g. Secure BFD Sequence Numbers adopted for changing sequence number, e.g. Secure BFD Sequence
[I-D.ietf-bfd-secure-sequence-numbers], this method can use the Numbers [I-D.ietf-bfd-secure-sequence-numbers], this method can use
updated scheme without any impact. the updated scheme without any impact.
Most packets transmitted on a BFD session are BFD UP packets. Most packets transmitted on a BFD session are BFD UP packets.
Authenticating a small subset of these packets, for example, a detect Authenticating a small subset of these packets, for example, a detect
multiplier number of packets per configured period, significantly multiplier number of packets per configured interval, significantly
reduces the computational demand for the system while maintaining reduces the computational demand for the system while maintaining
security of the session across the configured authentication periods. security of the session across the configured interval. A minimum of
A minimum of Detect Multiplier packets MUST be transmitted per Detect Multiplier packets MUST be transmitted per configured
configured periodic authentication interval. This ensures that the interval. This ensures that the BFD session should see at least one
BFD session should see at least one authenticated packet during that authenticated packet during that interval.
interval.
3. NULL Auth Type 3. NULL Auth Type
This section describes a new Authentication Type as: This section describes a new Authentication Type 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved | | Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 48 skipping to change at page 6, line 44
authenticated. This protects against replay-attacks by allowing the authenticated. This protects against replay-attacks by allowing the
session to maintain an incrementing sequence number for all packets session to maintain an incrementing sequence number for all packets
(authenticated and un-authenticated). (authenticated and un-authenticated).
In the future, if a new scheme is adopted for changing the sequence In the future, if a new scheme is adopted for changing the sequence
number, this method can adopt the new scheme without any impact. number, this method can adopt the new scheme without any impact.
4. IANA Considerations 4. IANA Considerations
This document requests an update to the registry titled "BFD This document requests an update to the registry titled "BFD
Authentication Types". IANA is requested to to assign a new BFD Auth Authentication Types". IANA is requested to assign a new BFD Auth
Type for "NULL" (see Section 3). Type for "NULL" (see Section 3).
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
The approach described in this document enhances the ability to The approach described in this document enhances the ability to
authenticate a BFD session by taking away the onerous requirement authenticate a BFD session by taking away the onerous requirement
that every BFD control packet be authenticated. By authenticating that every BFD control packet be authenticated. By authenticating
 End of changes. 22 change blocks. 
85 lines changed or deleted 90 lines changed or added

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