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

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

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?