draft-ietf-bfd-optimizing-authentication-01.txt   draft-ietf-bfd-optimizing-authentication-02.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: August 18, 2016 A. Saxena Expires: July 9, 2017 A. Saxena
Ciena Corporation Ciena Corporation
M. Bhatia M. Bhatia
Ionos Networks Ionos Networks
February 15, 2016 January 5, 2017
Optimizing BFD Authentication Optimizing BFD Authentication
draft-ietf-bfd-optimizing-authentication-01 draft-ietf-bfd-optimizing-authentication-02
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 41 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 August 18, 2016. This Internet-Draft will expire on July 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 4, line 7 skipping to change at page 4, line 7
+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--------+
Optimized Authentication Map Optimized Authentication Map
All frames already carry the sequence number. The NULL AUTH frames All frames already carry the sequence number. The NULL AUTH frames
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]. [RFC5880]. If at a later time, a different scheme is adopted for
changing sequence number, this method can use the updated scheme
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 (one per configured
period) significantly reduces the computational demand for the system period) significantly reduces the computational demand for the system
while maintaining security of the session across the configured while maintaining security of the session across the configured
authentication periods. The configuration of the periodic authentication periods. The configuration of the periodic
authentication interval for BFD CC UP frames is an open issue. authentication interval for BFD CC UP frames is an open issue.
3. NULL Auth TLV 3. NULL Auth TLV
skipping to change at page 5, line 5 skipping to change at page 5, line 7
Sequence Number: The sequence number for this packet. This value is Sequence Number: The sequence number for this packet. This value is
incremented for each successive packet transmitted for a session. incremented for each successive packet transmitted for a session.
This provides protection against replay attacks. Must use the same This provides protection against replay attacks. Must use the same
sequence number counter as the authenticated frames. sequence number counter as the authenticated frames.
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
number, this method can adopt the new scheme without any impact.
4. IANA Considerations 4. IANA Considerations
IANA is requested to assign a new Auth Type for the NULL Auth TLV. This document requests an update to the registry titled "BFD
Authentication Types". IANA is requested to update the Value of 0
which is currently named as Reserved to 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
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
skipping to change at page 5, line 38 skipping to change at page 5, line 45
(HMAC)", August 2002. (HMAC)", August 2002.
[FIPS-198] [FIPS-198]
National Institute of Standards and Technology, FIPS PUB National Institute of Standards and Technology, FIPS PUB
198, "The Keyed-Hash Message Authentication Code (HMAC)", 198, "The Keyed-Hash Message Authentication Code (HMAC)",
March 2002. March 2002.
[I-D.ashesh-bfd-stability] [I-D.ashesh-bfd-stability]
Mishra, A., Jethanandani, M., Saxena, A., Networks, J., Mishra, A., Jethanandani, M., Saxena, A., Networks, J.,
Chen, M., and P. Fan, "BFD Stability", draft-ashesh-bfd- Chen, M., and P. Fan, "BFD Stability", draft-ashesh-bfd-
stability-03 (work in progress), June 2015. stability-04 (work in progress), March 2016.
[I-D.ietf-bfd-generic-crypto-auth] [I-D.ietf-bfd-generic-crypto-auth]
Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani,
"BFD Generic Cryptographic Authentication", draft-ietf- "BFD Generic Cryptographic Authentication", draft-ietf-
bfd-generic-crypto-auth-06 (work in progress), April 2014. bfd-generic-crypto-auth-06 (work in progress), April 2014.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 8, line 25 skipping to change at page 8, line 34
San Jose, CA 95134 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: manavbhatia@gmail.com
 End of changes. 10 change blocks. 
8 lines changed or deleted 15 lines changed or added

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