MAC Authentication for the Babel Routing Protocol
RFC 8967
Document | Type |
RFC - Proposed Standard
(January 2021; No errata)
Obsoletes RFC 7298
|
|
---|---|---|---|
Authors | Clara Do , Weronika Kolodziejak , Juliusz Chroboczek | ||
Last updated | 2021-01-11 | ||
Replaces | draft-do-babel-hmac | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Donald Eastlake | ||
Shepherd write-up | Show (last changed 2019-03-12) | ||
IESG | IESG state | RFC 8967 (Proposed Standard) | |
Action Holders |
(None)
|
||
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) 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 storingShow full document text