Babel Routing Protocol over Datagram Transport Layer Security
RFC 8968

Document Type RFC - Proposed Standard (January 2021; No errata)
Authors Antonin Décimo  , David Schinazi  , Juliusz Chroboczek 
Last updated 2021-01-11
Replaces draft-decimo-babel-dtls
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Donald Eastlake
Shepherd write-up Show (last changed 2019-02-08)
IESG IESG state RFC 8968 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Martin Vigoureux
Send notices to Donald Eastlake <d3e3e3@gmail.com>
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack


Internet Engineering Task Force (IETF)                         A. Décimo
Request for Comments: 8968             IRIF, University of Paris-Diderot
Category: Standards Track                                    D. Schinazi
ISSN: 2070-1721                                               Google LLC
                                                           J. Chroboczek
                                       IRIF, University of Paris-Diderot
                                                            January 2021

     Babel Routing Protocol over Datagram Transport Layer Security

Abstract

   The Babel Routing Protocol does not contain any means to authenticate
   neighbours or provide integrity or confidentiality for messages sent
   between them.  This document specifies a mechanism to ensure these
   properties using Datagram Transport Layer Security (DTLS).

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8968.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
     1.1.  Specification of Requirements
     1.2.  Applicability
   2.  Operation of the Protocol
     2.1.  DTLS Connection Initiation
     2.2.  Protocol Encoding
     2.3.  Transmission
     2.4.  Reception
     2.5.  Neighbour Table Entry
     2.6.  Simultaneous Operation of Babel over DTLS and Unprotected
           Babel on a Node
     2.7.  Simultaneous Operation of Babel over DTLS and Unprotected
           Babel on a Network
   3.  Interface Maximum Transmission Unit Issues
   4.  IANA Considerations
   5.  Security Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Appendix A.  Performance Considerations
   Acknowledgments
   Authors' Addresses

1.  Introduction

   The Babel routing protocol [RFC8966] does not contain any means to
   authenticate neighbours or protect messages sent between them.
   Because of this, an attacker is able to send maliciously crafted
   Babel messages that could lead a network to route traffic to an
   attacker or to an under-resourced target, causing denial of service.
   This document specifies a mechanism to prevent such attacks using
   Datagram Transport Layer Security (DTLS) [RFC6347].

1.1.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Applicability

   The protocol described in this document protects Babel packets with
   DTLS.  As such, it inherits the features offered by DTLS, notably
   authentication, integrity, optional replay protection,
   confidentiality, and asymmetric keying.  It is therefore expected to
   be applicable in a wide range of environments.

   There exists another mechanism for securing Babel, namely Message
   Authentication Code (MAC) authentication for Babel (Babel-MAC)
   [RFC8967].  Babel-MAC only offers basic features, namely
   authentication, integrity, and replay protection with a small number
   of symmetric keys.  A comparison of Babel security mechanisms and
   their applicability can be found in [RFC8966].

   Note that Babel over DTLS provides a single authentication domain,
   meaning that all nodes that have the right credentials can convey any
   and all routing information.

   DTLS supports several mechanisms by which nodes can identify
   themselves and prove possession of secrets tied to these identities.
   This document does not prescribe which of these mechanisms to use;
   details of identity management are left to deployment profiles of
   Babel over DTLS.

2.  Operation of the Protocol

   Babel over DTLS requires some changes to how Babel operates.  First,
Show full document text