1 / 16

Authentication for TCP-based Routing and Management Protocols

This draft proposes an enhanced TCP-layer authentication option for TCP-based routing and management protocols like BGP and LDP. The current BCP (RFC 2385) does not fulfill the operators' requirements and concerns. The proposed approach includes hitless key rollover, stronger cryptography, and enhanced authentication options. Co-authors and contributors include experts from Juniper, Cisco, Alcatel, and BT.

elmerj
Download Presentation

Authentication for TCP-based Routing and Management Protocols

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. Authentication for TCP-based Routing and Management Protocols draft-bonica-tcp-auth-04

  2. Motivation • Many operators do not authenticate TCP based routing protocols • BGP, LDP • Current BCP (RFC 2385) does not fulfill operator requirement

  3. Concerns Regarding RFC 2385 • CPU utilization • Not addressed in the current memo • Key management • Keys need to be refreshed periodically • Key refresh (typically) requires session reset • Weak cryptography • There are many well-know attacks on MD5

  4. Alternative Approaches • Application • In the Protocols (BGP, LDP, etc.) • TLS • Transport • TCP • Network • IKE/IPsec

  5. Chosen Approach • Better TCP-layer authentication • Enhanced TCP Authentication Option • Hitless key rollover • Key chains configured on peer systems • Key Identifiers • Stronger cryptography • CMAC-AES-128-96 • HMAC-SHA-1-89

  6. Enhanced Authentication Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind | Length |T|K| Alg ID |Res| Key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data | | // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  7. Key Chain • Contains up to 64 keys • Each key contains • Identifier [0..63] • Authentication Algorithm • Shared secret • Vector [in|out|both] • Start and end time for sending • Start and end time for receiving

  8. Sending System Procedure • Identify active key candidates • vector == out || vector == both • Start-time for sending <= system-time • End-time for sending > system time • If there are no candidates, log event and discard outbound packet • If there are multiple candidates, select key with most recent start-time for sending

  9. Sending System Procedure (continued) • Calculate MAC using active key • Calculate over TCP pseudo-header, TCP header and TCP payload • By default, include TCP options • Format Enhanced Authentication Option • Active key identifier • Flags • Message Authentication Code (MAC) • Authentication Identifier

  10. Receiving System Procedure • Lookup key specified by TCP Option • Determine whether that key is eligible • Vector == in || vector == both • Start-time for receiving <= system time • End-time for receiving > end time • Calculate MAC • If calculated MAC is equal to received MAC, accept datagram

  11. Authentication Error Procedure • Discard datagram • Log • DO NOT send indication to originator

  12. Coming Soon • Automated session key distribution • Draft-weis-tcp-auth-auto-ks

  13. Rejected Approach: In the Protocols PROs: • Each routing protocol application takes care of itself • Although the IDR WG did just deprecate an earlier BGP attempt because of the TCP RST issue • Independent of network interfaces, just as the protocols themselves are Independent of network interfaces CONs: • Does not protect against a TCP RST attack • Each routing protocol must be modified in a similar way

  14. Rejected Approach: SSL PROs: • Protects the protocol at the highest level without actually modifying the routing protocols • Independent of network interfaces CONs: • Does not protect against a TCP RST attack • TLS can re-establish the connection, but unless it does it within 90 sec. BGP will tear down the session.

  15. Rejected Approach: IKE/IPsec PROs: • Protects against a TCP RST attack • Can be configured to work for directly connected peers because the IPsec policy can be attached to a single interface. CONs: • Policy checking (e.g., access control, QoS, IPsec) is interface specific on a router. But TCP applications are interface agnostic! Therefore a robust solution requires placing IPsec policy on every possible router interface. This can affects the performance of all packets directed toward or routed through the router. • IKE Authentication doesn’t provide for a completely clean roll-over of pre-shared keys, and certificates are not always appropriate

  16. Co-authors and Contributors • Ron Bonica (Juniper) • Brian Weis (Cisco) • Sriram Viswanathan (Cisco) • Andrew Lange (Alcatel) • Owen Wheeler (BT) • Chandrashekhar Appanna (Cisco) • Andy Heffernan (Juniper) • Kapil Jain (Juniper) • David McGrew (Cisco) • Satish Mynam (mynam@cisco.com) • Anantha Ramaiah (ananth@cisco.com)

More Related