Routing Protocol Security Requirements WG (rpsec) Tuesday, March 21 at 1520-1720 Cortez AB ======================================== CHAIRS: Russ White Tony Tauber AGENDA: Agenda Bashing and Administrivia Old Document Status Generic Threats OSPF Vulnerabilities BGP Attack Tree BGP Security Requirements T. Tauber draft-ietf-rpsec-bgpsecrec-04 Authentication for TCP-based Routing and Management Protocols draft-bonica-tcp-auth-04 R. Bonica Charter update and futures discussion R. White --- Minutes --- Agenda Bashing (Tony) No changes from the published agenda. Old Work (Tony) Generic Threats Hit an administrative speed-bump w/in the RFC-Editor's Queue. Looks like it should be shaken loose soon. ADs will help. Pekka Savola: Looks like it was deleted from the editor's queue. Tony: We'll get it fixed. OSPF Vulnerabilities Analysis done by Emanuele Jones, et. al. expired. We'll look at re-submitting and getting it published as Informational. BGP Attack Tree Analysis done by Sean Convery, Dave Cook, Michael Franz. Similarly, bring it to the list, see if there are comments/etc. If not, possibly last call it, and be done with it. BGP Security Requirements (Tony) (See Presentation slides) SIDR BOF/WG-to-be is waiting for consensus output to begin. === Consensus call: How should we proceed? Is there concensus on the draft outside the AS Path considerations? 4 or 5 How many are opposed? 1 Sense of the room is the draft is okay as it is, outside the AS Path Leave AS Path in, but state there is no consensus on the AS Path parts of the draft? Sense of the room is this is the correct path === Describe these results on the list. Steve Kent has submitted some mark-up so the doc may be revised with these changes and the change to call out the AS_Path issues as not having consent. Authentication for TCP Based Routing Protocols (Ron Bonica) (See presentation slides.) Steve Kent: To clarify, the keys used in IPsec are authentication keys, the keys we are talking about in this solution are different. Rolling over identification keys is possible with existing systems. SK: Chains of keys have the same exposure possibility as preshared keys used for the life of the BGP session. Ron Bonica: We are trying to solve the problem of how long these keys are used. SK: How long do these session stay up? Tony Tauber: Months SK: There's no requirement to kill the child SAs when you swap keys. When you create a new child SA you would normally establish a new child SA, and the traffic would migrate to the new SA when the old one times out. Ron: Had we gone the ipsec route, if we change the key on one side, and not the other side, and something causes the SA to bounce. SK: Only two things will cause that: The SA times out, one side or the other side crashes. If the key is changed on one side, and the other side times the SA out, we are out of business until the keys are changed. Alex Zinin: Let's continue the slides, and continue this discussion later Greg Lebovitz: Why is TLS problematic? Ron: The attacks we're trying to gaurd against are against TCP (e.g. forged resets), rather than BGP. If TCP can be forced into an ACK war, it can take minutes for BGP to recover, so we need to protect TCP. Greg: TLS has the concept of contexts, the flow is considered part of a flow context. If TCP resets, the BGP session could be recovered from the context state. Wouldn't this be a feature. Ron: We would have to define BGP and others (LDP, etc) over TLS. Steve: The receiver is making a choice between keys and some timing checks. This implies some level of time synchronization between the peer routers. If you have a large number of peers, this turns into a requirement to maintain time among all the peers on a per peer basis. Ron: This is why the keychain has a start and end time for sending and receiving. If you believe the peers have fairly synchronized times, you can set the end time to some time in the future, so that the receiver will accept the key for a long time. Steve: In which case you're dependant on the other peer to change keys, if both peers have bad time, then the keys won't ever change. Ron: The sender always determines which key is used. The sender can switch keys, since the sender chooses which key the receiver should accept. Steve: I'll ask the question again in a different fashion. If both peers have problems with keeping clock straight, is there any safe algorithm to ever take a key out? Ron: There is a potential problem. If clocks are skewed by months or years. There's no way to know for the receiver to know when it's safe to delete a key from the keychain. Steve: This raises questions about how far this is from a system where the sender just arbitrarily chooses which key to use. You've had to take the time element and make it almost a no-op. It's going to take a lot of effort when writing the operational guidance or security considerations what the assumptions are. Ross Callon: How useful is it to worry about clocks that are off 20 years. The document should clearly state that you should have your clocks to within some period of time if this is going to be useful. Ron: I think it's reasonable to put something in the security considerations section stating the clocks must be within some degree of coordination. Dave Ward: This doc is useful, the clock stuff we run into in all the protocols. There is a draft I wrote a couple of years ago on how to secure BGP with IPsec, but not all routing protocols can run on IPsec, so that isn't a complete solution. Alex: It is reasonable to assume the clocks on routers will be synchronized within minutes or hours. I'm in favor, being a prime contributor. Geoff Huston: If you have a peering session not coming up, you don't normally look at the time of day. There should be some pointer in implementations to look at the time if there's a failure; a notification to the Operator to indicate what the error was (e.g., time out of range.) Greg: A comment on IPsec with preshared keys. The only preshared key large scale IPsec systems that work are vendor proprietary. It's operationally infeasible to believe that interdomain routing will be able to use preshared keys and be able to roll over those keys in an automated fashion. Certificates could be used to make this a nonproblem, with a little more work. See work going on in the PKI4IPSEC Working Group. Chris Hopps: Is it envisioned that you will configure large keychains that will slowly roll keys over time, or are you looking at transitioning keys over time. Ron: A keychain normally can hold 64 keys, so the most would be about 2 months. Chris Hopps: So it's not reaction? Ron: There is a mechanism to handle the situation where you believe your keys have been compromised you can roll your keys now. Andrew Dul: We would have to reconfigure the keychain every two months? Ron: How often do you want to do it? Keys are easier to break the more you use them. There's an RFC that talks about how often you should roll your keys if you're using MD5. Andrew: As an operator, I don't want to touch my routers every 2 months to roll keys. Ron: You could use a time of about 10 days, and touch them once a year. === Next Steps: === Since the changes here would be to TCP, the thing to do would be have RPSEC recommend to the TCPM Working Group to take on this work. RPsec Charter Update - Russ White (See presentation slides.) Consensus call: === Do these look like these are the right things? Four or Five Hands Not the right direction? Crickets ===