--- 1/draft-ietf-babel-hmac-04.txt 2019-06-07 14:13:09.451315444 -0700 +++ 2/draft-ietf-babel-hmac-05.txt 2019-06-07 14:13:09.491316435 -0700 @@ -1,20 +1,20 @@ Network Working Group C. Do Internet-Draft W. Kolodziejak Obsoletes: 7298 (if approved) J. Chroboczek Updates: 6126bis (if approved) IRIF, University of Paris-Diderot -Intended status: Standards Track March 9, 2019 -Expires: September 10, 2019 +Intended status: Standards Track June 7, 2019 +Expires: December 9, 2019 HMAC authentication for the Babel routing protocol - draft-ietf-babel-hmac-04 + draft-ietf-babel-hmac-05 Abstract This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document updates RFC 6126bis and obsoletes RFC 7298. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -23,21 +23,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 10, 2019. + This Internet-Draft will expire on December 9, 2019. Copyright Notice Copyright (c) 2019 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 @@ -47,54 +47,55 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Assumptions and security properties . . . . . . . . . . . 3 1.3. Specification of Requirements . . . . . . . . . . . . . . 4 2. Conceptual overview of the protocol . . . . . . . . . . . . . 4 - 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 6 3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 7 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 11 - 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 12 + 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 13 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 13 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informational References . . . . . . . . . . . . . . . . 16 Appendix A. Incremental deployment and key rotation . . . . . . 16 Appendix B. Changes from previous versions . . . . . . . . . . . 17 B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 17 B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 17 B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 17 - B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 17 + B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 18 + B.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction By default, the Babel routing protocol trusts the information - contained in every UDP packet 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: + 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: o spoof a Babel packet, and redirect traffic by announcing a smaller metric, a larger seqno, or a longer prefix; o spoof a malformed packet, which could cause an insufficiently robust implementation to crash or interfere with the rest of the network; o replay a previously captured Babel packet, which could cause traffic to be redirected or otherwise interfere with the network. @@ -179,23 +180,23 @@ 2. Conceptual overview of the protocol When a node B sends out a Babel packet through an interface that is configured for HMAC cryptographic protection, it computes one or more HMACs which it appends to the packet. When a node A receives a packet over an interface that requires HMAC cryptographic protection, it independently computes a set of HMACs and compares them to the HMACs appended to the packet; if there is no match, the packet is discarded. - In order to protect against replay B maintains a per-interface 32-bit - integer known as the "packet counter" (PC). Whenever B sends a - packet through the interface, it embeds the current value of the PC + In order to protect against replay, B maintains a per-interface + 32-bit integer known as the "packet counter" (PC). Whenever B sends + a packet through the interface, it embeds the current value of the PC within the region of the packet that is protected by the HMACs and increases the PC by at least one. When A receives the packet, it compares the value of the PC with the one contained in the previous packet received from B, and unless it is strictly greater, the packet is discarded. By itself, the PC mechanism is not sufficient to protect against replay. Consider a peer A that has no information about a peer B (e.g., because it has recently rebooted). Suppose that A receives a packet ostensibly from B carrying a given PC; since A has no @@ -228,72 +229,73 @@ before (either by drawing it randomly or by using a reliable hardware clock) and starts sending PCs with that index. Whenever A detects that B has changed its index, it challenges B again. With this additional mechanism, this protocol is invulnerable to replay attacks (see Section 1.2 above). 3. Data Structures Every Babel node maintains a set of conceptual data structures - described in [RFC6126bis] Section 3.2. This protocol extends these - data structures as follows. + described in Section 3.2 of [RFC6126bis]. This protocol extends + these data structures as follows. 3.1. The Interface Table Every Babel node maintains an interface table, as described in - [RFC6126bis] Section 3.2.3. Implementations of this protocol MUST + Section 3.2.3 [RFC6126bis]. Implementations of this protocol MUST allow each interface to be provisioned with a set of one or more HMAC keys and the associated HMAC algorithms (see Section 4.1). In order to allow incremental deployment of this protocol (see Appendix A), implementations SHOULD allow an interface to be configured in a mode in which it participates in the HMAC authentication protocol but accepts packets that are not authentified. This protocol extends each entry in this table that is associated with an interface on which HMAC authentication has been configured with two new pieces of data: o a set of one or more HMAC keys, each associated with a given HMAC algorithm ; the length of each key is exactly the hash size of the associated HMAC algorithm (i.e., the key is not subject to the preprocessing described in Section 2 of [RFC2104]); - o a pair (Index, PC), where Index is an arbtrary string of 0 to 32 + o a pair (Index, PC), where Index is an arbitrary string of 0 to 32 octets, and PC is a 32-bit (4-octet) integer. - The Index and PC are initialised to arbitrary values chosen so as to - ensure that a given (Index, PC) pair is never reused. Typically, the - initial Index will be chosen as a random string of sufficient length, - and the initial PC will be set to 0. + We say that an index is fresh when it has never been used before with + any of the keys currently configured on the interface. The Index + field is initialised to a fresh index, for example by drawing a + random string of sufficient length, and the PC is initialised to an + arbitrary value (typically 0). 3.2. The Neighbour table Every Babel node maintains a neighbour table, as described in - [RFC6126bis] Section 3.2.4. This protocol extends each entry in this - table with two new pieces of data: + Section 3.2.4 of [RFC6126bis]. This protocol extends each entry in + this table with two new pieces of data: o a pair (Index, PC), where Index is a string of 0 to 32 octets, and PC is a 32-bit (4-octet) integer; - o a Nonce, an arbitrary string of 0 to 192 octets, and an associated - challenge expiry timer. + o a Nonce, which is an arbitrary string of 0 to 192 octets, and an + associated challenge expiry timer. The Index and PC are initially undefined, and are managed as described in Section 4.3. The Nonce and expiry timer are initially undefined, and used as described in Section 4.3.1.1. 4. Protocol Operation 4.1. HMAC computation - A Babel node computes an HMAC as follows. + A Babel node computes the HMAC of a Babel packet as follows. First, the node builds a pseudo-header that will participate in HMAC computation but will not be sent. If the packet was carried over IPv6, the pseudo-header has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + @@ -332,100 +333,103 @@ Src address The source IP address of the packet. Src port The source UDP port number of the packet. Dest address The destination IP address of the packet. Src port The destination UDP port number of the packet. The node takes the concatenation of the pseudo-header and the packet including the packet header but excluding the packet trailer (from - octet 0 inclusive up to Body Length + 4 exclusive) and computes an + octet 0 inclusive up to (Body Length + 4) exclusive) and computes an HMAC with one of the implemented hash algorithms. Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and MAY implement other HMAC algorithms. 4.2. Packet Transmission - A Babel node may delay actually sending TLVs by a small amount, in + A Babel node might delay actually sending TLVs by a small amount, in order to aggregate multiple TLVs in a single packet up to the interface MTU (Section 4 of [RFC6126bis]). For an interface on which HMAC protection is configured, the TLV aggregation logic MUST take into account the overhead due to PC TLVs (one in each packet) and HMAC TLVs (one per configured key). Before sending a packet, the following actions are performed: o a PC TLV containing the PC and Index associated with the outgoing - interface is appended to the packet body; the PC is incremented by - a strictly positive amount (typically just 1); if the PC - overflows, a fresh index is generated; + interface MUST be appended to the packet body; the PC MUST be + incremented by a strictly positive amount (typically just 1); if + the PC overflows, a fresh index MUST be generated (as defined in + Section 3.1); o for each key configured on the interface, an HMAC is computed as - specified in Section 4.1 above, and an HMAC TLV is appended to the - packet trailer (see Section 4.2 of [RFC6126bis]). + specified in Section 4.1 above, and stored in an HMAC TLV that + MUST be appended to the packet trailer (see Section 4.2 of + [RFC6126bis]). 4.3. Packet Reception When a packet is received on an interface that is configured for HMAC protection, the following steps are performed before the packet is passed to normal processing: o First, the receiver checks whether the trailer of the received - packet carries at least one HMAC TLV; if not, the packet is + packet carries at least one HMAC TLV; if not, the packet MUST be immediately dropped and processing stops. Then, for each key - configured on the receiving interface, the implementation computes - the HMAC of the packet. It then compares every generated HMAC - against every HMAC included in the packet; if there is at least - one match, the packet passes the HMAC test; if there is none, the - packet is silently dropped and processing stops at this point. In - order to avoid memory exhaustion attacks, an entry in the - Neighbour Table MUST NOT be created before the HMAC test has - passed successfully. The HMAC of the packet MUST NOT be computed - for each HMAC TLV contained in the packet, but only once for each + configured on the receiving interface, the receiver computes the + HMAC of the packet. It then compares every generated HMAC against + every HMAC included in the packet; if there is at least one match, + the packet passes the HMAC test; if there is none, the packet MUST + be silently dropped and processing stops at this point. In order + to avoid memory exhaustion attacks, an entry in the Neighbour + Table MUST NOT be created before the HMAC test has passed + successfully. The HMAC of the packet MUST NOT be computed for + each HMAC TLV contained in the packet, but only once for each configured key. o The packet body is then parsed a first time. During this "preparse" phase, the packet body is traversed and all TLVs are ignored except PC TLVs, Challenge Requests and Challenge Replies. When a PC TLV is encountered, the enclosed PC and Index are saved for later processing; if multiple PCs are found, only the first - one is processed, the remaining ones are silently ignored. If a - Challenge Request is encountered, a Challenge Reply is scheduled, - as described in Section 4.3.1.2, and if a Challenge Reply is - encountered, it is tested for validity as described in + one is processed, the remaining ones MUST be silently ignored. If + a Challenge Request is encountered, a Challenge Reply MUST be + scheduled, as described in Section 4.3.1.2. If a Challenge Reply + is encountered, it is tested for validity as described in Section 4.3.1.3 and a note is made of the result of the test. o The preparse phase above has yielded two pieces of data: the PC and Index from the first PC TLV, and a bit indicating whether the packet contains a successful Challenge Reply. If the packet does - not contain a PC TLV, the packet is dropped and processing stops - at this point. If the packet contains a successful Challenge - Reply, then the PC and Index contained in the PC TLV are stored in - the Neighbour Table entry corresponding to the sender (which may - need to be created at this stage), and the packet is accepted. + not contain a PC TLV, the packet MUST be dropped and processing + stops at this point. If the packet contains a successful + Challenge Reply, then the PC and Index contained in the PC TLV + MUST be stored in the Neighbour Table entry corresponding to the + sender (which may need to be created at this stage), and the + packet is accepted. o Otherwise, if there is no entry in the Neighbour Table corresponding to the sender, or if such an entry exists but contains no Index, or if the Index it contains is different from - the Index contained in the PC TLV, then a challenge is sent as - described in Section 4.3.1.1, processing stops at this stage, and - the packet is dropped. + the Index contained in the PC TLV, then a challenge MUST be sent + as described in Section 4.3.1.1, the packet MUST be dropped, and + processing stops at this stage. - o At this stage, the packet contained no successful challenge reply + o At this stage, the packet contains no successful challenge reply and the Index contained in the PC TLV is equal to the Index in the Neighbour Table entry corresponding to the sender. The receiver compares the received PC with the PC contained in the Neighbour Table; if the received PC is smaller or equal than the PC - contained in the Neighbour Table, the packet is silently dropped - and processing stops (no challenge is sent in this case, since the + contained in the Neighbour Table, the packet MUST be dropped and + processing stops (no challenge is sent in this case, since the mismatch might be caused by harmless packet reordering on the link). Otherwise, the PC contained in the Neighbour Table entry is set to the received PC, and the packet is accepted. After the packet has been accepted, it is processed as normal, except that any PC, Challenge Request and Challenge Reply TLVs that it contains are silently ignored. 4.3.1. Challenge Requests and Replies @@ -433,68 +437,70 @@ Index, to which it will react by scheduling a Challenge Request. It might encounter a Challenge Request TLV, to which it will reply with a Challenge Reply TLV. Finally, it might encounter a Challenge Reply TLV, which it will attempt to match with a previously sent Challenge Request TLV in order to update the Neighbour Table entry corresponding to the sender of the packet. 4.3.1.1. Sending challenges When it encounters a mismatched Index during the preparse phase, a - node picks a nonce that it has never used before, for example by + node picks a nonce that it has never used with any of the keys + currently configured on the relevant interface, for example by drawing a sufficiently large random string of bytes or by consulting - a strictly monotonic hardware clock. It stores the nonce in the - entry of the Neighbour Table of the neighbour (the entry might need - to be created at this stage), initialises the neighbour's challenge - expiry timer to 30 seconds, and sends a Challenge Request TLV to the - unicast address corresponding to the neighbour. + a strictly monotonic hardware clock. It MUST then store the nonce in + the entry of the Neighbour Table associated to the neighbour (the + entry might need to be created at this stage), initialise the + neighbour's challenge expiry timer to 30 seconds, and send a + Challenge Request TLV to the unicast address corresponding to the + neighbour. A node MAY aggregate a Challenge Request with other TLVs; in other words, if it has already buffered TLVs to be sent to the unicast - address of the sender of the neighbour, it MAY send the buffered TLVs - in the same packet as the Challenge Request. However, it MUST - arrange for the Challenge Request to be sent in a timely manner, as - any packets received from that neighbour will be silently ignored - until the challenge completes. + address of the neighbour, it MAY send the buffered TLVs in the same + packet as the Challenge Request. However, it MUST arrange for the + Challenge Request to be sent in a timely manner, as any packets + received from that neighbour will be silently ignored until the + challenge completes. - Since a challenge may be prompted by a replayed packet, a node MUST - impose a rate limitation to the challenges it sends; the limit SHOULD - default to one challenge request every 300ms, and MAY be - configurable. + Since a challenge may be prompted by a packet replayed by an + attacker, a node MUST impose a rate limitation to the challenges it + sends; the limit SHOULD default to one challenge request every 300ms, + and MAY be configurable. 4.3.1.2. Replying to challenges When it encounters a Challenge Request during the preparse phase, a node constructs a Challenge Reply TLV by copying the Nonce from the - Challenge Request into the Challenge Reply. It sends the Challenge - Reply to the unicast address from which the Challenge Request was - sent. + Challenge Request into the Challenge Reply. It MUST then send the + Challenge Reply to the unicast address from which the Challenge + Request was sent. A node MAY aggregate a Challenge Reply with other TLVs; in other words, if it has already buffered TLVs to be sent to the unicast address of the sender of the Challenge Request, it MAY send the buffered TLVs in the same packet as the Challenge Reply. However, it MUST arrange for the Challenge Reply to be sent in a timely manner (within a few seconds), and SHOULD NOT send any other packets over the same interface before sending the Challenge Reply, as those would be dropped by the challenger. A challenge sent to a multicast address MUST be silently ignored. 4.3.1.3. Receiving challenge replies When it encounters a Challenge Reply during the preparse phase, a node consults the Neighbour Table entry corresponding to the neighbour that sent the Challenge Reply. If no challenge is in progress, i.e., if there is no Nonce stored in the Neighbour Table entry or the Challenge timer has expired, the Challenge Reply - is silently ignored and the challenge has failed. + MUST be silently ignored and the challenge has failed. Otherwise, the node compares the Nonce contained in the Challenge Reply with the Nonce contained in the Neighbour Table entry. If the two are equal (they have the same length and content), then the challenge has succeeded; otherwise, the challenge has failed. 4.4. Expiring per-neighbour state The per-neighbour (Index, PC) pair is maintained in the neighbour table, and is normally discarded when the neighbour table entry @@ -518,72 +524,73 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 16 | Length | HMAC... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type Set to 16 to indicate an HMAC TLV. - Length The length of the body, exclusive of the Type and Length - fields. The length of the body depends on the hash - function used. + Length The length of the body, in octets, exclusive of the Type + and Length fields. The length of the body depends on the + HMAC algorithm being used. - HMAC The body contains the HMAC of the whole packet plus the - pseudo header. + HMAC The body contains the HMAC of the packet, computed as + described in Section 4.1. This TLV is allowed in the packet trailer (see Section 4.2 of [RFC6126bis]), and MUST be ignored if it is found in the packet body. 5.2. PC TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type = 17 | Length | PC + | Type = 17 | Length | PC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Index... + | | Index... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type Set to 17 to indicate a PC TLV. - Length The length of the body, exclusive of the Type and Length - fields. + Length The length of the body, in octets, exclusive of the Type + and Length fields. PC The Packet Counter (PC), a 32-bit (4 octet) unsigned integer which is increased with every packet sent over this - interface. A fresh index MUST be generated whenever the PC - overflows. + interface. A fresh index (as defined in Section 3.1) MUST + be generated whenever the PC overflows. Index The sender's Index, an opaque string of 0 to 32 octets. Indices are limited to a size of 32 octets: a node MUST NOT send a TLV with an index of size strictly larger than 32 octets, and a node - MAY silently ignore a PC TLV with an index of size strictly larger - than 32 octets. + MAY ignore a PC TLV with an index of size strictly larger than 32 + octets. 5.3. Challenge Request TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 18 | Length | Nonce... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + Fields : Type Set to 18 to indicate a Challenge Request TLV. - Length The length of the body, exclusive of the Type and Length - fields. + Length The length of the body, in octets, exclusive of the Type + and Length fields. Nonce The nonce uniquely identifying the challenge, an opaque string of 0 to 192 octets. Nonces are limited to a size of 192 octets: a node MUST NOT send a Challenge Request TLV with a nonce of size strictly larger than 192 octets, and a node MAY ignore a nonce that is of size strictly larger than 192 octets. 5.4. Challenge Reply TLV @@ -591,23 +598,22 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 19 | Length | Nonce... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type Set to 19 to indicate a Challenge Reply TLV. - Length The length of the body, exclusive of the Type and Length - fields. The length of the body is set to the same size as - the challenge request TLV length received. + Length The length of the body, in octets, exclusive of the Type + and Length fields. Nonce A copy of the nonce contained in the corresponding challenge request. 6. Security Considerations This document defines a mechanism that provides basic security properties for the Babel routing protocol. The scope of this protocol is strictly limited: it only provides authentication (we assume that routing information is not confidential), it only @@ -634,42 +640,42 @@ clock. If uniqueness cannot be guaranteed (e.g., because a hardware clock has been reset), then rekeying is necessary. The expiry mechanism mandated in Section 4.4 is required to prevent an attacker from delaying an authentic packet by an unbounded amount of time. If an attacker is able to delay the delivery of a packet (e.g., because it is located at a layer 2 switch), then the packet will be accepted as long as the corresponding (Index, PC) pair is present at the receiver. If the attacker is able to cause the (Index, PC) pair to persist for arbitrary amounts of time (e.g., by - causing failed challenges), then it is able to delay the packet by - arbitrary amounts of time, even after the sender has left the - network. + repeatedly causing failed challenges), then it is able to delay the + packet by arbitrary amounts of time, even after the sender has left + the network. While it is probably not possible to be immune against denial of service (DoS) attacks in general, this protocol includes a number of mechanisms designed to mitigate such attacks. In particular, reception of a packet with no correct HMAC creates no local state whatsoever (Section 4.3). Reception of a replayed packet with correct hash, on the other hand, causes a challenge to be sent; this is mitigated somewhat by requiring that challenges be rate-limited. At first sight, sending a challenge requires retaining enough information to validate the challenge reply. However, the nonce included in a challenge request and echoed in the challenge reply can be fairly large (up to 192 octets), which should in principle permit encoding the per-challenge state as a secure "cookie" within the nonce itself. 7. IANA Considerations - IANA has allocated the following values in the Babel TLV Numbers + IANA has allocated the following values in the Babel TLV Types registry: +------+-------------------+---------------+ | Type | Name | Reference | +------+-------------------+---------------+ | 16 | HMAC | this document | | | | | | 17 | PC | this document | | | | | | 18 | Challenge Request | this document | @@ -799,20 +805,24 @@ o Use the TLV values allocated by IANA. o Fixed an issue with packets that contain a successful challenge reply: they should be accepted before checking the PC value. o Clarified that keys are the exact value of the HMAC hash size, and not subject to preprocessing; this makes management more deterministic. +B.5. Changes since draft-ietf-babel-hmac-04 + + Use normative language in more places. + Authors' Addresses Clara Do IRIF, University of Paris-Diderot 75205 Paris Cedex 13 France Email: clarado_perso@yahoo.fr Weronika Kolodziejak