A Generic Mechanism to solve Inter-Session Replay Attacks for Routing and Signaling Protocols
draft-bhz-karp-inter-session-replay-00

Abstract

This draft proposes a common solution for routing protocols to enhance their capability in tolerating inter-session replay attacks when using manual keys for securing their protocol packets.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 http://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 08, 2011.

Copyright Notice

Copyright (c) 2011 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 (http://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
• 2. Existing Mechanisms
• 3. Inter-Session Replay Attacks
• 4. Proposal
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

A replay attack is a network attack where an adversary intercepts a valid message transmission and retransmits it sometime later. In certain types of replay attacks, the retransmitted message may also be carefully tampered with. [RFC6039] demonstrates that nearly all the routing protocols and their security mechanisms are vulnerable to replay attacks to some extent. These attacks permit attackers multiple capabilities. Often, by replaying packets, attackers can create a disruption, causing routing information to be removed or signaling to fail because of the attack. Other replays permit an attacker to mask network failures. For example an attacker can maintain an adjacency even when a link or router has failed, allowing the attacker to observe traffic or forcing traffic to be blackholed. Another class of replay attacks permits an attacker to inject old routing information, possibly in place of routing information from a router that is currently down. Successful replay attacks on routing protocols can introduce incorrect routing information into the victims' routing tables, can break their adjacencies, and can eventually disrupt network communication.

Replays may be effective even with very little effort on the part of an attacker. For instance, replaying an OSPF Hello packet with an empty neighbor list can cause all the neighbor adjacencies with the router which originally sent the packet to be reset. All the existing security mechanisms for routing protocols use a non-decreasing cryptographic sequence number to deal with replay attacks. However, this leaves the routers still vulnerable to inter-connection replay attacks where the packets from one session are re-sent and accepted during a later session. None of the existing authentication mechanisms in the routing protocols can prevent this without the assistance of automatic key management mechanisms.

Providing routing protocols with an inter-session replay protection is one of the threats that has been recognized in scope for the work being done in the KARP WG and has been documented in [I-D.ietf-karp-threats-reqs]. This document proposes to provide a generic solution that can be implemented as part of the KARP framework that can be used by all routing and signaling protocols to prevent inter-session replay attacks.

This document proposes introducing a boot count, denoted as the KARP Boot Count (KBC), to enhance the capability of routing protocols in tolerating inter-session replay attacks. KBC is used to record the number of times a router has cold-booted. As a part of the KARP infrastructure, the value of this count must be maintained by all the implementations compliant to this standard in their non-volatile memory.

The following sections explain why the existing security and authentication mechanisms cannot protect the routing and the signaling protocols against inter-session replay attacks. The proposed solution is then introduced and we explain how unlike the existing anti-replay mechanisms, this solution will also work well with automated key management techniques.

2. Existing Mechanisms

Most routing protocols (e.g., OSPF, BFD, and RIP) and signaling protocols (LDP, RSVP, etc) include a non-decreasing cryptographic sequence number within the authentication data of each new packet that a router originates. The receivers keep track of this sequence number and only accept a protocol packet if it carries a cryptographic sequence number that is greater than or equal to the cryptographic sequence number carried in the last valid protocol packet. Using this mechanism, receivers can trivially protect the router against simple replay attacks.

[RFC2328] uses a 32-bit non-decreasing crypto sequence number for every OSPFv2 packet. Once a router has increased its sequence number, an attacker cannot replay an old packet to a neighbor that has an active adjacency without being detected. Note that the sequence numbers are not required to increase for each packet. Additionally, OSPFv2 provides a per-LSA sequence number to prevent an old LSA from being installed.

OSPFv3 [RFC5340] relies on the IP Authentication Header (AH) [RFC4302] and the IP Encapsulating Security Payload (ESP) [RFC4303] to cryptographically sign routing information passed between routers.

[RFC4552] describes the authentication mechanism that OSPFv3 uses. It discusses, at length, the reasoning behind using manually configured keys, rather than some automated key management protocol such as IKEv2 [RFC4306]. The primary problem is the lack of a suitable key management mechanism, as OSPFv3 adjacencies are formed on a one-to-many basis and most key management mechanisms are designed for a one-to-one communication model. Since [RFC4552] uses manual keying it clearly states that it provides no protection against replay attacks. This can be exploited in several ways as described in [RFC6039].

The OSPF WG is currently working on an alternate mechanism [I-D.ietf-ospf-auth-trailer-ospfv3] to protect OSPFv3 protocol packets that does not depend upon IPsec for authentication. This draft proposes a new mechanism that works similar to OSPFv2 [RFC5709] for providing authentication to the OSPFv3 packets and as a side effect also solves the replay protection problems that exists in OSPFv3.

As part of the solution OSPFv3 routers append a special data block, referred to as, the authentication trailer to the end of the OSPFv3 packets. It contains a 32-bit non decreasing cryptographic sequence number that is used to protect against the replay attacks.

Bidirectional Forwarding Detection (BFD) is specified in [RFC5880]. There is a 32-bit cryptographic sequence number associated with every BFD packet that is used to protect against replay attacks. Note that the sequence number is incremented for each successive packet transmitted within a session for Meticulous Keyed (MD5 or SHA-1) Authentication. When using Keyed (MD5 or SHA-1) Authentication (the non-meticulous variant), the receiver of a packet only requires the sequence number of the packet to be greater than or equal to the last sequence number received.

In order to improve the anti-replay capability of RSVP, a 64-bit monotonically increasing sequence number is associated with every RSVP packet[RFC2747].

3. Inter-Session Replay Attacks

In the security mechanisms where the per-packet sequence numbers only need to be updated occasionally, replay attacks can be quite intuitive. For instance, an attacker can replay the last OSPFv2 packet without being detected since a router executing OSPFv2 accepts packets with sequence number greater than or equal to what they had last received. Of course, this issue can be easily addressed by mandating that protocols must only accept protocol packets if they come with a sequence number that is greater than what they have received till now. However, even if the sequence numbers are monotonically increased, the security mechanisms for routing protocols are still vulnerable to "inter-session" replay attacks if automatic key management mechanisms are unavailable. In normal conditions, it will take a very long period for a sequence number to reach its maximum. However, on many occasions (e.g., reboot), a router may re-initialize its sequence number. In this case, the sequence number of new packets is less than the sequence number of packets previously sent on the link. If an adversary replays the packets intercepted before the re-initialization, it is difficult for the victims to distinguish a replayed packet from the valid ones.

4. Proposal

The basic idea of the proposed solution is to guarantee that the sequence number of a router will always monotonically increase even after a cold reboot. The first part of the solution requires that the sequence numbers increase for every packet, updating the requirement of protocols such as OSPFv2 that only require non-decreasing behavior. This also means that BFD should use the meticulous version of the authentication mechanism as against the regular, since the former requires the cryptographic sequence number to increase for each successive packet that is transmitted for a session. It is insufficient to update the behavior of senders in this regard: receivers MUST check that sequence numbers increase for every packet.

The second part of the solution requires routing protocol implementations to maintain a KARP boot count (KBC) that records the number of times the router has cold booted in a non-volatile storage, similar to how it is done in the SNMPv3 security architecture. In fact, the same boot count MAY also be shared by SNMPv3 and the KARP infrastructure. Before sending out a packet, the routing protocols can request for this count value and can append it before the sequence space that it maintains. How each routing protocol achieve this is an implementation specific issue and beyond the scope of this document.

If the sequence number of a routing protocol (e.g., RSVP) is 64 bits, the sequence space is then broken down to two halves. The most significant 32-bits would indicate the KARP boot count. The least significant 32-bits is a counter that increases for every packet sent.

If the cryptographic sequence number of a routing protocol is 32 bits, it is recommended to extend the sequence number space to 64 bits. The most significant 32-bits would indicate the KARP boot count. The least significant 32-bits would carry the current sequence number that protocols maintain, which increases with each successive packet transmitted within a session. Upon receiving a packet, the receiver MUST verify that the sequence number in the packet is strictly greater than the sequence number of the previous packets received.

In the later case, if an implementation does not intend to expand the length of the sequence number, it could divide this 32-bit cryptographic sequence number space into a 7-bit and a 25-bit field. The most significant 7-bits could then indicate the KARP boot count. The least significant 25-bits is a counter that increases for every packet sent.

This solution assumes that boot counts never wrap within the lifetime of a particular encryption key. Also, the solution assumes that nonvolatile storage is always updated on a boot. Under these assumptions, a sequence number will not be re-used. This is sufficient to guarantee that while two routers are exchanging communications, packets from an old session cannot be replayed. However it does not demonstrate freshness. Many routing protocols discard replay state when an adjacency is dropped or when a router reboots. Once this state is discarded, an attacker can successfully replay packets from an old session. See the discussion in Section 5.

5. Security Considerations

This solution does not try to provide guarantees of freshness: it does not protect against the replay of an antique session while a router is down. For instance, if an OSPF router is taken out of service for some reason, an attacker can replay packets as soon as the adjacencies with the router time out. Actually, this issues is a common problem encountered by all existing anti-replay solutions for routing protocols. To address this issue, the liveliness of routers would need to be checked before the generation of any adjacency. The challenge/response solution is proposed in[I-D.bhatia-karp-ospf-ip-layer-protection] to address this issue.

Updates to routing protocols that use this solution need to discuss residual attacks, particularly those resulting from the lack of freshness guarantees. For example this solution would likely be insufficient for RIPv2 because as soon as a router goes down, old packets from that router could be used to inject routing information. However attacks against a link-state protocol may be quite limited and this solution may be appropriate.

The security of this solution depends on the boot count always increasing for each new boot unless the key changes. This creates significant operational requirements. If equipment is replaced but its router identity (an IP address for several protocols) is re-used, then the key MUST be changed or the boot count preserved from the old equipment. Failure to take one of these steps permits attackers to replay packets from the old equipment until the boot count of the new equipment catches up with that of the old equipment. This will very likely permit an attacker to disrupt adjacencies between the new equipment and other routers. More serious attacks may be possible as well.

6. IANA Considerations

The implementations that decide to extend their sequence space from 32 bits to 64 bits need to require a new Auth Type from IANA as this will be incompatible with the earlier authentication mechanisms.

7. Acknowledgements

The funding for Sam Hartman's work on this draft is provided by Huawei.

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses