Subject: [RPSEC] Minutes from IETF-65 (Dallas)

From: Tony Tauber <[email-masked]>
Date: Fri, 24 Mar 2006 18:58:04 -0800 (PST)

Please write in with any corrections by March 31.

Thanks,

Tony
---

Routing Protocol Security Requirements WG (rpsec)

Tuesday, March 21 at 1520-1720 Cortez AB
========================================

CHAIRS: Russ White <[email-masked]>
         Tony Tauber <[email-masked]>

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
===

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Tony Tauber <[email-masked]>
Date: Sun, 26 Mar 2006 19:52:29 -0800 (PST)

Hi folks,

These items were buried within the minutes I posted but I wanted to
draw people's attention to them.  If there are comments or concerns,
send them along.

Thanks,

Tony
----