1 / 15

RPSEC WG

This draft discusses the security issues that arise in routing protocols despite the presence of security mechanisms, and proposes solutions to address these challenges. The main focus is on the lack of key management and automatic key distribution mechanisms. The draft aims to meet reasonable security requirements, be easy to deploy, utilize the available credentials, and support automatic keying in the long-term. It also addresses replay attacks, CPU exhaustion, routing loops, black holes, and traffic redirection.

maym
Download Presentation

RPSEC WG

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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

  4. Replay attacks • CPU Exhaustion • Routing loops • Black holes • Traffic redirection

  5. 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

  6. 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 OSPFv3 issues

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

  8. 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)

  9. 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

  10. 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

  11. 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)

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

  13. 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

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

  15. Feedback?

More Related