2006.06.05 NANOG-NOTES TCP authentication with Ron Bonica

Tue Jun 6 09:26:03 UTC 2006

2006.06.05 Ron Bonica
slides are at
http://www.nanog.org/mtg-0606/pdf/ron-bonica-joint%20presenters.pdf

Authentication for TCP-based routing and management
protocols, from Juniper.

A joint presentation, Alcatel, Cisco, Juniper.

Starts at NANOG at Washington 2 years ago,
security BOF; someone said they would MD5 auth
if they could update keys without bouncing their
sessions.

Suprisingly small number of people actually
using MD5 authentication.

Motivation
many ops don't authenticate TCP based routing
protocols
RFC 2385 doesn't meet operator needs.

Concerns:
CPU utilization
 not so much of an issue for Juniper, [Cisco, Alcatel]
 Juniper architecture separates forwarding and control
 plane
Key management
 hard to change keys
 requires bouncing sessions
Weak cryptography
 easy attacks against MD5

Alternative approaches
Application:
 in the protocols (BGP, LDP, etc)
 TLS
 --too much of a headache
transport
 TCP
Network
 IKE/IPsec

Chosen Approach:
better TCP authentication
 enhanced TCP auth option
Hitless key rollover
 key chains configured on peer systems
 time based key rollover
 key identifier
Stronger cryptography
 HMAC-SHA-1-96
 CMAC-AES-128-96

Enhanced Authentication Option
Kind - Length T/K Alg ID Res Key ID
KEY

Key chain
contains a tolerance parameter up to 64 keys
each key contains
 id [0..63]
 auth algorithm
 shared secret
 start and end time, both for trans and receive

Sending system procedure
identify active key candidates
 start-time <= system-time
 end-time > 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

Calculate MAC using active key
 calculate over TCP pseudo header, TCP header, and TCP
  payload
 by default, include TCP options
 (if you set the T bit, ignore TCP options)
Format enhanced auth option
 active key ID
 ...

Receiving system proc.
lookup key specified by TCP option
determine whether that key is eligible
 startime <= system - tolerance
 end time > endtime + tolerance
 [not sure if that shouldn't be
   end time > system time + tolerance, actually.  --MNP]
Calculate MAC
if calculated MAC matches received MAC, accept the packet

auth error procedure
discard datagram
log
do NOT send indication to originator
(doesn't adjust TCP counters)

Config example:
see examples on slide deck, they went past too
quickly.

Q: how many of us are authenticating IBGP sessions?
A: majority in the room are
Q: how many of us are interested in a better way
 of handling key changes?
A: lots of people!

Q: Russ Bundy?: are you planning on taking this work
into IETF to publish through that path?
A: Yes, went to RPsec, RPsec2, and SAG working group
mailing lists.

Q: Randy Bush, IIJ, were there any simpler proposals?
Clearly this was designed for the IVTF.
A: None that weren't already rejected by the team
themselves.

Q: Steve Bellovin, Columbia U.  No longer security
IAD. Why reject IKE and IPsec?  It does all this, plus
more (which isn't so good)
Why not tie algorithm to the key, get it out of the
header, get more bits for other uses?
A: actually, alg. could be taken from the key; that's
the type of comment they're looking for in the IETF;
one arg for putting it in option is that is a quick way
to check without calculating the MAC,
second Q: is more interesting; why not use IKE with
just auth. -- no need for confidentiality in this
case.  It was discussed, one idea was to just use IPsec
with preshared keys, but then you have same key
rollover system, and key negotiation.  Those are
all probably good ideas.  Would like to do this
as a first phase, allow for manual key rollovers,
and in a second phase, you can negotiate a key
for one-time use.
Q: but in IKE/IPsec, you can use preshared key
 mode in IKE;
A: but in this case, you'd still
 need a system like this to roll over the keys
 since you want to be able to change keys on each
 end asynchronously

Christopher Ranch: Made the right choices, thank
you!

Q: Eric ? from cisco: why is this more complicated?
A: being able to have multiple keys and roll them
over.   There are networks that have used the
same key for 10 years since they don't want to
bounce their sessions.  You just can't do that
with IKE.
This is an operations driven requirement, that
it be hitless.

Q: Jared Mauch, NTT america: how does he go in and
take his iBGP session, roll to this system without
making the NANOG mailing list?
A: [no answer provided]

Q: Bora Kilf?, Broadcom: about IKE not being able to
roll keys without a hit; if you use IKE v1, you can
lose the IKE SA, have the IPsec SA, rekey your
IKE SA, and then rekey your IPsec SA.
He agrees with steve, looks like they're re-iventing
large parts of IKE/IPsec all over again.

Q: Gary? want to avoid colo meets; you want to be able
to re-set keys without having to coordinate people
in different timezones.

Encourage people to participate in SAG to discuss
this and provide feedback.

Research forum speakers up next.