draft-ietf-bfd-optimizing-authentication-12.txt   draft-ietf-bfd-optimizing-authentication-13.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: August 1, 2021 A. Saxena Expires: 2 February 2022 A. Saxena
Ciena Corporation Ciena Corporation
M. Bhatia M. Bhatia
Nokia Nokia
January 28, 2021 1 August 2021
Optimizing BFD Authentication Optimizing BFD Authentication
draft-ietf-bfd-optimizing-authentication-12 draft-ietf-bfd-optimizing-authentication-13
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 August 1, 2021. This Internet-Draft will expire on 2 February 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . 4 2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 4
3. NULL Auth Type . . . . . . . . . . . . . . . . . . . . . . . 5 3. NULL Auth Type . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
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] control packet with a Simple Authenticating every BFD [RFC5880] control packet with a Simple
Password, or with a MD5 Message-Digest Algorithm [RFC1321] , or Password, or with a MD5 Message-Digest Algorithm [RFC1321] , or
skipping to change at page 3, line 32 skipping to change at page 3, line 37
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119] document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown [RFC8174] when, and only when, they appear in all capitals, as shown
here. here.
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 * Detect Multiplier
o Detection Time * Detection Time
The following terms are introduced in this document. 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 |
| change | a poll sequence change (P or F bit). | | change | bit) or a poll sequence change (P or F bit). |
| | | +--------------------+----------------------------------------------+
| configured | Interval at which BFD control packets are | +--------------------+----------------------------------------------+
| interval | authenticated in the UP state. | | configured | Interval at which BFD control packets are |
+--------------+----------------------------------------------------+ | interval | authenticated in the UP state. |
+--------------------+----------------------------------------------+
Table 1
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
skipping to change at page 5, line 21 skipping to change at page 5, line 32
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| | DOWN | INIT | UP | | | DOWN | INIT | UP |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| DOWN | NULL | Auth | Auth | | DOWN | NULL | Auth | Auth |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| INIT | Auth | NULL | n/a | | INIT | Auth | NULL | n/a |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| UP | Auth | Auth | Select | | UP | Auth | Auth | Select |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Optimized Authentication Map Figure 1: Optimized Authentication Map
If P or F bit changes value, the BFD control packet MUST be If P or F bit changes value, the BFD control packet MUST be
authenticated. If the D bit changes value, the BFD control packet authenticated. If the D bit changes value, the BFD control packet
MUST be authenticated. 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 monotonically increasing sequence number to be carried in each
packet, and prevents man-in-the-middle from capturing and replaying packet, and prevents man-in-the-middle from capturing and replaying
the same packet again. Since all packets still carry a sequence the same packet again. Since all packets still carry a sequence
skipping to change at page 6, line 13 skipping to change at page 6, line 21
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NULL Auth Type Figure 2: NULL Auth Type
where: where:
Auth Type: The Authentication Type, which in this case is TBD (NULL, Auth Type: The Authentication Type, which in this case is TBD (NULL,
to be assigned by IANA) to be assigned by IANA)
Auth Len: The length of the NULL Auth Type, in bytes i.e. 8 bytes Auth Len: The length of the NULL Auth Type, in bytes i.e. 8 bytes
Auth Key ID: The authentication key ID in use for this packet. Must Auth Key ID: The authentication key ID in use for this packet. Must
be set to zero. be set to zero.
skipping to change at page 7, line 25 skipping to change at page 7, line 34
That combined with the proposal of using sequence number defined in That combined with the proposal of using sequence number defined in
Secure BFD Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers] Secure BFD Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers]
further enhances the security of BFD sessions. further enhances the security of BFD sessions.
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-bfd-secure-sequence-numbers] [I-D.ietf-bfd-secure-sequence-numbers]
Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and
A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd- A. DeKok, "Secure BFD Sequence Numbers", Work in Progress,
secure-sequence-numbers-07 (work in progress), December Internet-Draft, draft-ietf-bfd-secure-sequence-numbers-08,
2020. 8 March 2021, <https://www.ietf.org/archive/id/draft-ietf-
bfd-secure-sequence-numbers-08.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
skipping to change at page 8, line 22 skipping to change at page 8, line 31
Full SHA-1", 2005. Full SHA-1", 2005.
[SHA-1-attack2] [SHA-1-attack2]
Wang, X., Yao, A., and F. Yao, "New Collision Search for Wang, X., Yao, A., and F. Yao, "New Collision Search for
SHA-1", 2005. SHA-1", 2005.
Authors' Addresses Authors' Addresses
Mahesh Jethanandani Mahesh Jethanandani
Kloud Services Kloud Services
USA United States of America
Email: mjethanandani@gmail.com Email: mjethanandani@gmail.com
Ashesh Mishra Ashesh Mishra
SES Networks SES Networks
Email: mishra.ashesh@gmail.com Email: mishra.ashesh@gmail.com
Ankur Saxena Ankur Saxena
Ciena Corporation Ciena Corporation
3939 N 1st Street 3939 N 1st Street
San Jose, CA 95134 San Jose, CA 95134
USA United States of America
Email: ankurpsaxena@gmail.com Email: ankurpsaxena@gmail.com
Manav Bhatia Manav Bhatia
Nokia Nokia
Bangalore Bangalore
India India
Email: manav.bhatia@nokia.com Email: manav.bhatia@nokia.com
 End of changes. 15 change blocks. 
34 lines changed or deleted 36 lines changed or added

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