90 likes | 102 Views
Authentication for TCP-based Routing and Management Protocols. draft-bonica-tcp-auth-02 Ron Bonica Andy Heffernan. Problem Statement. Relatively few ISPs MD5 authenticate BGP peering sessions RFC 2385. Why Don’t ISP’s Authenticate.
E N D
Authentication for TCP-based Routing and Management Protocols draft-bonica-tcp-auth-02 Ron Bonica Andy Heffernan
Problem Statement • Relatively few ISPs MD5 authenticate BGP peering sessions • RFC 2385
Why Don’t ISP’s Authenticate • In order to update the MD5 key, you must bounce the peering session • Concerns about CPU utilization • Concerns about DoS attacks • Saturate CPU • MD5 authentication isn’t very strong
Constraints Upon Solution • Hitless Key Update • Choose authentication algorithm wisely • CPU resources • Length of hash value • Strength • Never require receiving station to calculate a hash value multiple times for a single incoming TCP segment
Proposed Solution • Configuration • Sending station procedures • Receiving station procedures
Configuration • Configuration • Key Chain (contains multiple Authentication Elements) • Tolerance value (significant on receiver only) • Each Authentication Element contains • Authentication Element ID • Authentication Algorithm • Key • Start time
Sending Station Procedure • Identify current Authentication Element • Based on start time • Generate hash value using current Authentication Element • Insert TCP Enhanced Authentication Option • Object ID (assigned by IANA) • Object Length • Authentication Element ID • Hash Value
Receiving Station Procedure • Examine incoming TCP Enhanced Authentication Option • Look Up Authentication Element specified in TCP Option • Determine whether it is acceptable • Using start time, system time and tolerance parameter • Calculate hash and authenticate
Choosing Hash Algorithms • Late binding of hash algorithms to TCP sessions • HMAC-SHA-1-96 is highly desirable • Relatively strong • Not computationally expensive • Twelve byte hash value