MAC Authentication for the Babel Routing Protocol
RFC 8967

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09
• 10
• 11
• 12



Internet Engineering Task Force (IETF)                             C. Dô
Request for Comments: 8967                                W. Kolodziejak
Obsoletes: 7298                                            J. Chroboczek
Category: Standards Track              IRIF, University of Paris-Diderot
ISSN: 2070-1721                                             January 2021

           MAC Authentication for the Babel Routing Protocol

Abstract

   This document describes a cryptographic authentication mechanism for
   the Babel routing protocol that has provisions for replay avoidance.
   This document obsoletes RFC 7298.

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/rfc8967.

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.  Applicability
     1.2.  Assumptions and Security Properties
     1.3.  Specification of Requirements
   2.  Conceptual Overview of the Protocol
   3.  Data Structures
     3.1.  The Interface Table
     3.2.  The Neighbour Table
   4.  Protocol Operation
     4.1.  MAC Computation
     4.2.  Packet Transmission
     4.3.  Packet Reception
     4.4.  Expiring Per-Neighbour State
   5.  Incremental Deployment and Key Rotation
   6.  Packet Format
     6.1.  MAC TLV
     6.2.  PC TLV
     6.3.  Challenge Request TLV
     6.4.  Challenge Reply TLV
   7.  Security Considerations
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informational References
   Acknowledgments
   Authors' Addresses

1.  Introduction

   By default, the Babel routing protocol [RFC8966] trusts the
   information contained in every UDP datagram that it receives on the
   Babel port.  An attacker can redirect traffic to itself or to a
   different node in the network, causing a variety of potential issues.
   In particular, an attacker might:

   *  spoof a Babel packet and redirect traffic by announcing a route
      with a smaller metric, a larger sequence number, or a longer
      prefix;

   *  spoof a malformed packet, which could cause an insufficiently
      robust implementation to crash or interfere with the rest of the
      network;

   *  replay a previously captured Babel packet, which could cause
      traffic to be redirected or otherwise interfere with the network.

   Protecting a Babel network is challenging due to the fact that the
   Babel protocol uses both unicast and multicast communication.  One
   possible approach, used notably by the Babel over Datagram Transport
   Layer Security (DTLS) protocol [RFC8968], is to use unicast
   communication for all semantically significant communication, and
   then use a standard unicast security protocol to protect the Babel
   traffic.  In this document, we take the opposite approach: we define
   a cryptographic extension to the Babel protocol that is able to
   protect both unicast and multicast traffic and thus requires very few
   changes to the core protocol.  This document obsoletes [RFC7298].

1.1.  Applicability

   The protocol defined in this document assumes that all interfaces on
   a given link are equally trusted and share a small set of symmetric
   keys (usually just one, and two during key rotation).  The protocol
   is inapplicable in situations where asymmetric keying is required,
   where the trust relationship is partial, or where large numbers of
   trusted keys are provisioned on a single link at the same time.

   This protocol supports incremental deployment (where an insecure
   Babel network is made secure with no service interruption), and it
   supports graceful key rotation (where the set of keys is changed with
   no service interruption).

   This protocol does not require synchronised clocks, it does not
   require persistently monotonic clocks, and it does not require
   persistent storage except for what might be required for storing