draft-ietf-bfd-optimizing-authentication-05.txt   draft-ietf-bfd-optimizing-authentication-06.txt 
Network Working Group M. Jethanandani Network Working Group M. Jethanandani
Internet-Draft Internet-Draft VMware
Intended status: Standards Track A. Mishra Intended status: Standards Track A. Mishra
Expires: November 26, 2018 SES Networks Expires: April 14, 2019 SES Networks
A. Saxena A. Saxena
Ciena Corporation Ciena Corporation
M. Bhatia M. Bhatia
Nokia Nokia
May 25, 2018 October 11, 2018
Optimizing BFD Authentication Optimizing BFD Authentication
draft-ietf-bfd-optimizing-authentication-05 draft-ietf-bfd-optimizing-authentication-06
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 44 skipping to change at page 1, line 44
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 November 26, 2018. This Internet-Draft will expire on April 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 3, line 6 skipping to change at page 3, line 6
authenticating every packet even more difficult to achieve. authenticating every packet even more difficult to achieve.
This document proposes that only BFD frames that signal a state This document proposes that only BFD frames that signal a state
change in BFD be authenticated. Rest of the frames can be change in BFD be authenticated. Rest of the frames can be
transmitted and received without authentication enabled. Most frames transmitted and received without authentication enabled. Most frames
that are transmitted and received have no state change associated that are transmitted and received have no state change associated
with them. Limiting authentication to frames that affect a BFD with them. Limiting authentication to frames that affect a BFD
session state allows more sessions to be supported for session state allows more sessions to be supported for
authentication. Moreover, most BFD frames that signal a state change authentication. Moreover, most BFD frames that signal a state change
are generally transmitted at a slower interval of 1s leaving enough are generally transmitted at a slower interval of 1s leaving enough
time to compute the hash. time to compute the hash. To detect a Man In the Middle (MITM)
attack, it is also proposed that a non-state change frame be
authenticated occasionally. The interval of this non-state change
frame can be configured depending on the detect multiplier and the
capability of the system. As an example, this could be equal to the
detect multiplier number of packets.
Section 2 talks about the changes to authentication mode as described The rest of the document is structured as follows. Section 2 talks
in BFD [RFC5880]. about the changes to authentication mode as described in BFD
[RFC5880]. Section 3 goes into the details of the new Authentication
TLV.
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 TLV appended. In addition, it states that associated Authentication TLV 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
decide which frames need to be authenticated, and authenticate only are configured for which frames need to be authenticated, and
those frames. For example, the two ends can decide that BFD frames authenticate only those frames. Rest of the frames can be
that indicate a state change should be authenticated and enable transmitted and received without authentication. For example, the
authentication on those frames only. If the two ends have not two ends can be configured such that BFD frames that indicate a state
previously negotiated which frames they will transmit or receive with change should be authenticated and enable authentication on those
authentication enabled, then the BFD session will fail to come up, frames only. If the two ends have previously been configured as
because at least one end will expect every frame to be authenticated. such, but at least one side decides not to authenticate a state
change frame, then the BFD session will fail to come up.
This proposal outlines which frames need to be authenticated (carry
the A-bit), and which frames can be transmitted or received without
authentication enabled. A frame that fails authentication is
discarded, or a frame that was supposed to be authenticated, but was
not, e.g. a state-change frame, is discarded. However, there is no
change to the state machine for BFD, as the decision of a state
change is still decided by how many valid consecutive frames were
received, authenticated or otherwise.
The state changes for which authentication is being suggested The state changes for which authentication is being suggested
include: include:
Read : On state change from <column> to <row> Read : On state change from <column> to <row>
Auth : Authenticate frame Auth : Authenticate frame
NULL : No Authentication. Use NULL AUTH TLV. NULL : No Authentication. Use NULL AUTH TLV.
n/a : Invalid state transition. n/a : Invalid state transition.
Select : Most frames NULL AUTH. Selective (periodic) Select : Most frames NULL AUTH. Selective (periodic)
frames authenticated. frames authenticated.
+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--------+
skipping to change at page 4, line 38 skipping to change at page 4, line 38
MUST contain the TLV specified in Section 3. This enables a MUST contain the TLV 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 frame,
and prevents man-in-the-middle from capturing and replaying the same and prevents man-in-the-middle from capturing and replaying the same
frame again. Since all frames still carry a sequence number, the frame again. Since all frames still carry a sequence number, the
logic for sequence number maintenance remains unchanged from logic for sequence number maintenance remains unchanged from
[RFC5880]. If at a later time, a different scheme is adopted for [RFC5880]. If at a later time, a different scheme is adopted for
changing sequence number, this method can use the updated scheme changing sequence number, this method can use the updated scheme
without any impact. without any impact.
Most frames transmitted on a BFD session are BFD CC UP frames. Most frames transmitted on a BFD session are BFD CC UP frames.
Authenticating a small subset of these frames (one per configured Authenticating a small subset of these frames, for example, a detect
period) significantly reduces the computational demand for the system multiplier number of packets per configured period, significantly
while maintaining security of the session across the configured reduces the computational demand for the system while maintaining
authentication periods. The configuration of the periodic security of the session across the configured authentication periods.
authentication interval for BFD CC UP frames is an open issue. The configuration of the periodic authentication interval for BFD CC
UP frames is an open issue, left for implementations to decide.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved | | Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NULL Auth TLV NULL Auth TLV
where: where:
Auth Type: The Authentication Type, which in this case is 0 (NULL Auth Type: The Authentication Type, which in this case is TBD (NULL
Auth TL) Auth TLV, to be assigned by IANA)
Auth Len: 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
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.
Reserved: The authentication key ID in use for this packet. This Reserved: This byte MUST be set to zero on transmit and ignored on
allows multiple keys to be active simultaneously. receive.
Sequence Number: The sequence number for this packet. Implementation Sequence Number: The sequence number for this packet. Implementation
may use sequence numbers as defined in [RFC5880], or secure sequence may use sequence numbers as defined in [RFC5880], or secure sequence
numbers as defined in [I-D.ietf-bfd-secure-sequence-numbers]. numbers as defined in [I-D.ietf-bfd-secure-sequence-numbers].
The NULL Auth TLV must be used for all frames that are not The NULL Auth TLV must be used for all frames that are not
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 frames session to maintain an incrementing sequence number for all frames
(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 update the Value of 0 Authentication Types". IANA is requested to to assign a new BFD Auth
which is currently named as Reserved to NULL (see Section 3). Type for "NULL Auth TLV" (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
authentication a BFD session by taking away the onerous requirement authentication a BFD session by taking away the onerous requirement
that every frame be authenticated. By authenticating frames that that every frame be authenticated. By authenticating frames that
affect the state of the session, the security of the BFD session is affect the state of the session, the security of the BFD session is
maintained. As such this document does not change the security maintained. As such this document does not change the security
considerations for BFD. considerations for BFD.
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", draft-ietf-bfd-
secure-sequence-numbers-01 (work in progress), November secure-sequence-numbers-02 (work in progress), May 2018.
2017.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 7, line 16 skipping to change at page 7, line 16
Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
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
VMware
USA USA
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
 End of changes. 14 change blocks. 
28 lines changed or deleted 47 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/