IETF Report: routing security

| Comments (0) | COMSEC
The topic of routing security has started to heat up quite a bit in IETF. Historically, there have been two general types of routing security measures:
  • Trying to defend against outsider attacks by securing adjacencies between routers.
  • Trying to defend against insider attacks by authenticating (and more importantly, authorizing) route advertisements to make sure that routers are only advertising permitted routes.

The second class of mechanisms (e.g., S-BGP) haven't really seen any significant deployment, despite the fact that there is a real threat from incorrect advertisements. (See this post about the Pakistan/YouTube outage for an example.)

The first class of mechanisms have seen modest deployments, but the protocols are fairly primitive, with insecure (or at least pre-modern) MAC function and minimal support for key management. Basically, you used a shared key between the communicating routers (a pair in the case of unicast protocols like BGP or LDP, or a group in the case of multicast/broadcast protocols like IS-IS or OSPF). All was well—or at least quiet—until 2005, when Bonica et al. published a draft which was intended to make key rollover easier for integrity protected TCP and also to update the MAC algorithms. This, coupled with some concerns about the lack of automated keying mechanisms, caused an avalanche efect of interest in revising all the routing adjacency security mechanisms.

IETF 71 had two meetings addressing this topic:

  • TCPM which covered standardizing TCP integrity protection.
  • KMART which covered keying for the average

For some reason that's not entirely clear to me, I got sucked into this stuff. My materials are below:

  • A draft discussing strategies for keying for TCP.
  • Extensive comments on the current TCP authentication option draft
  • A presentation on the generic key management problem.

Leave a comment