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.