Authentication for TCP-based Routing and Management Protocols - PowerPoint PPT Presentation

About This Presentation
Title:

Authentication for TCP-based Routing and Management Protocols

Description:

Authentication for TCP-based Routing and Management Protocols. draft ... Draft-weis-tcp-auth-auto-ks. Rejected Approach: In the ... not protect against a ... – PowerPoint PPT presentation

Number of Views:64
Avg rating:3.0/5.0
Slides: 17
Provided by: rbon3
Learn more at: https://www.ietf.org
Category:

less

Transcript and Presenter's Notes

Title: Authentication for TCP-based Routing and Management Protocols


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 TK 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 inoutboth
  • 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 lt system-time
  • End-time for sending gt 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 lt system time
  • End-time for receiving gt 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 doesnt 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_at_cisco.com)
  • Anantha Ramaiah (ananth_at_cisco.com)
Write a Comment
User Comments (0)
About PowerShow.com