Minutes For KMART BoF, IETF 71, Philadelphia, Pennsylvania Notes taken by Jim Schaad, edited by Donald Eastlake and Acee Lindem -- Agenda Bash - No changes The BoF co-chairs presented the Goals and Ground Rules. Tim Polk (sponsoring AD): Hope to get good collaborative work going... Ross Callon presented: Constraints on Automated Key Management for Routing Protocols Link State Protocols: Can't get inconsistent routing based on some routers having authenticated some data and others have not. OSPF & IS-IS - AKM and routing protocol cannot be cyclic dependent. BGP - has some basic data than could be shared. Some configuration is allowed on each router. Sandy Murphy: Problem with authentication a couple of hops away. Why not an issue for direct neighbors? Ross Callon: If your don't bring up link - then it might partition the network. Advertise to everybody that the link is not present. Problem is if you authenticate the advertisement - problem is that Node A might accept it, Node B might not - cause A->b Gregory Libovitz: Can give guidance if links are down. Sandra Murphy presents: Routing Threats and Key Management Routing Error Problems Summary Data and Routine system can both be affected Look at vulnerabilities of each segment of a routing protocol - Solutions? more problems in the solutions Requirements on Automated Key Management - !! Jabber: How many attacks cleared by SIDR Ancient ones - couple More recent - just about all of them Define SIDR: Secure IDR Allow you to detect inappropriate prefix originations. Ron Bonica presents (no slides): Operational Considerations About 3 years ago nothing was being done to authenticate BGP sessions. Bounce BGP session to change keys - very expensive. Choices: Do nothing, Do TCP/MD5 never change key, change key w/ scheduled maintenance activity. Generally operators did one of first 2 solutions Types of attacks - not cryptographic. blind reset attacks on TCP - people who knew the key (former insiders) Anatha Ramaiah: TCP/MD5 does not say anything about bouncing a session. This was a bug that has been fixed. Ron Bonica: If you change the key on both sides the TCP connection won't break - but it must be done within a time window. George Swallow: ?? David Ward: Much wider set of requirements to come in next presentation. David Ward Presents: Issues with Existing Cryptographic Protection Set of drafts on current state Current Attacks: Replay - Old Crypto - Group Key - Key Transitions draft-00 is missing things - but is a start Manual configuration is common among the operations Acee Lindem: Note automatic key management was not a big issue in the presentation More vulnerable to replay attacks w/ IPSec Sandy Murphy: I would like to add RSVP as a routing protocol Dave Ward: Agree & disagree - how does that help Can be used for Point to point - ?: Are the other protocols in the routing area in scope? Dave Ward: In scope for activity - not for BOF - will maybe add to doc Rigger?: Operators are used to doing manual configuration - it is not desirable but they are not afraid of it. Some weak practices relate to the fact it is manual. - looking for automatic configuration considerations Eric K. Rescorla (EKR) presents: Key Management There are four problems in routing security, particularly for link state protocols: (1) weak algorithms, (2) poor key rollover / lack of key IDs, (3) lack of replay protection, and (4) multicast security. The first four can be improved relatively easily. The fourth is quite difficult. Gregory: Don't have to use certificates - example Gregory: Generally something after random that confirms the identity after the randoms are exchanged Can be operationally complex - can make it simpler Multicast problem - diemo classic solution Chair: Uses separate key per element to bootstrap? --- YES Master control to pertion is always a problem - currently routing is peer-to-peer Impersonation problem is difficult for multi-cast Review of "non-crypto" ways of solving some of the issues. Open Microphone: Ran Atkinson: When I did IS-IS authentication many years ago I proposed a key id but was told to only document current practice with no improvements. One router company was rolling through set of keys. Today - mostly routing protocol design people, rather than users/implementers. Chair: Key-chain does solve key agility problem. Ran Atkinson: Quasi OK from a key agility position. EKR: Small number of keys - can trial verify - or use Key ID if tagged on. Not a crazy idea. If changing integrity algorithms then adding key id is easy Ran Atkinson: If router dies, little to no memory kept across failure. When it rolls over - must start at zero because no state. Has flash memory changed hardware universe? On integrity front - user community is really small for changing to SHA2 - nobody is using what we have. Need to pay attention to management. EKR: anti-replay - have crude hacky ways to deal with it. Chair: use your clock as the starting sequence number - method is must be greater. Hardware has improved with reference to flash have seen crypto deployed in configs Gregory: Usability question - IKE started w/ ~30 knobs - hard to use. Now IKE runs w/ only one switch - on/off. Bells and whistles for crypto agility. auto-key-man - is not hard part anymore. If it is default, then just requires initial creditional config - then it just works. Shana Monte: What is the problem we are trying to solve? Interior vs exterior protocols. Problem is solved on interior. Algorithm strength is not big issue. Interdomain problem needs much work. Draft-bonica key agility TCP sessions. No coordination on key roll-over is a must. Don't need auto-PKI to update everything. Work in SIDR wrt routing information in inter-domain context. Authentication on routing information is valuable --> External prefix filters Phil Hallam Baker (PHB): The IETF has been successful in making systems that work well and are very secure but that nobody uses. Getting deployed is vastly harder problem that getting crypto right. Think of admin of machine + security less than just machine. Danny: Plead that we not block on things that use insecure substrate. Don't Gate waiting on this work to finish. Gregory: Some security things that could be done aren't, because it is too hard to deploy them. Some operational things required - may not be able to do security for. Understand and document in detail 1) operation deployment requirements 2) threat model per routing protocol. ESP protecting adjacencies. Pat Cain: Can’t figure out what problem we are going to solve. Draft charter? Tim Polk: Lots of work going on outside of this room. Trying to figure out how to distribute resources. SIDR, TCP/AO. Looking farther down the road today. Work started on documenting requirements. Short term items we can do in some of the areas listed by Dave. Wanted to get people talking Dave Ward: Update RFC 4107 on automated key manage for all protocols. Ran Atkinson updating documents on security - if nothing more needed, good to go until next version (BPT & TCP protocols). SIDR work is most important. Securing routing advertisement origination. Close some of the items done. Tim Polk: Lots of things on the list. Clarify what Automated key management means. Dave Ward: Routing environment vs transport environment. Different problems. Tim Polk: Helpful to get prioritization of security efforts. Tim Polk: Design team to try and catch up with expired time line. Dan: How do we resolve the block of docs in routing area? Tim Polk: Something Pesi Eronen and I need to resolve. BoF adjourned a few minutes early