RPSEC WG Issues with Routing Protocols security mechanisms Vishwas Manral, SiNett Russ White, Cisco Sue Hares, Next Hop IETF 63, Paris, France

Basic Idea of the draft Security Issues in Unicast Routing Protocols Not about issues when no security mechanisms in place e.g. draft-ietf-rpsec-ospf-vuln-01.txt Issues that arise despite security mechanisms in place

Brief idea of overall work Security Issues even with security mechanisms in place Main issue - no key management and automatic key distribution mechanism Problem statement draft Decide on the problems to solve Come up with solution. Meet reasonable security requirements Be easy to deploy Use the credentials people actually have available Support automatic keying in the long-term

Replay attacks CPU Exhaustion Routing loops Black holes Traffic redirection

OSPFv3 Uses IPSec security RFC2401bis states: - If the key used to compute an ICV is manually distributed, a compliant implementation SHOULD NOT provide anti-replay service. Authentication/ Confidentiality for OSPFv3 states: - As it is not possible as per the current standards to provide replay protection while using manual keying, the proposed solution will not provide protection against replay attacks.

OSPFv3 issues Problem OSPF is stricter with receiving packets not expected Replaying packets (CPU Exhaustion/ Routing loops/ black holes/ traffic redirection) Hello Packets Database Description Packets LS Request Packets LS Acknowledgement packets LS Update Packets

OSPFv2 Provides inbuilt authentication mechanism Sender has to send packets in ascending order of sequence number Receiver can acknowledge as many packets with the same sequence number, but drop with lower sequence number

OSPFv2 issues Works over IP which can reorder packets Mechanisms like different prioritization of different packets cannot be done. Is a smaller issue (sometimes can result in adjacency reformation over VL) Manual keying is used. If all packets from a previous session between routers are stored and resent the neighbor could be misled to believing it is talking to the same router. Replay can be done till the next sequence number (no mechanism on how the sender needs to take care of sequence numbers - no perfect forward secrecy)

OSPFv2 issues Also Keyed MD5 is the default authentication algorithm used While there are no openly published attacks on that mechanism, some reports [Dobb96a, Dobb96b] create concern about the ultimate strength of the MD5 cryptographic hash function. Further, some end users, particularly several different governments, require the use of the SHA-1 hash function rather than any other such function for policy reasons. Draft to recommend HMAC construct already there for RIP/ IS-IS

IS-IS Provides for HMAC-MD5 While there are no openly published attacks on that mechanism, some reports [Dobb96a, Dobb96b] create concern about the ultimate strength of the MD5 cryptographic hash function. Further, some end users, particularly several different governments, require the use of the SHA-1 hash function rather than any other such function for policy reasons. TLV – Value field has Auth Type defined for HMAC-MD5

IS-IS issues No sequence number hence liable to replay attacks Slightly less vulnerable Wrong packets got are silently discarded Works directly over Layer-2 Entire flooding domain should have the same keys (changing keys difficult)

BGP Uses TCP for transporting information between peers. Suggestion of choosing Manual keys in RFC3562.

BGP Issues Most BGP implementations will hold packets for an interval negotiated at peering startup This technique allows a short period of time during which an attacker may inject BGP packets with false MD5 signatures into the network, and can expect those packets to be accepted, even though their MD5 signatures are not valid. Most vulnerabilities resolved

RIP Issues RIPv1 provides no security at all RIPv2 has authentication mechanism but provides no counter for replay protection

Feedback?