[15:58:39] Melinda joins the room [16:00:43] aman joins the room [16:05:18] jpc joins the room [16:05:53] Agenda bashing [16:05:56] gregory joins the room [16:06:25] The last discussion item is how to actually start work on the protocols [16:06:42] David Cooper joins the room [16:06:50] Three IDs published, with text taken from Greg Lebovitz's roadmap [16:07:08] [blue sheets] [16:07:08] cw-ietf joins the room [16:07:54] Threats and requirements draft [16:08:10] Paul Hoffman joins the room [16:08:11] jimsch joins the room [16:08:30] Greg is editor for threats and reqs doc. [16:08:37] Can anyone remote hear the audio? [16:08:50] Could use a co-editor, let Greg know [16:08:56] kivinen joins the room [16:08:57] No IPR that he knows of [16:09:41] Dan joins the room [16:09:49] He's not going through details of every document (you should have read), just going to talk about open issues [16:09:53] per@nordu.net joins the room [16:10:20] in the process of splitting docs, a whole bunch of stuff went into threats & reqs, framework points to it [16:11:40] Greg is asking who read the document, asking someone in particular what's the goal, what's in-scope and what's out-of-scope [16:12:25] Bruno answered correctly, Greg says he'll give him $10 but only has $5 in his pocket [16:12:25] weiler joins the room [16:12:36] The implication is that the document is sufficiently clear [16:12:55] implication. -) [16:13:18] Still wants feedback if parts of the text aren't clear [16:13:48] Paul is pointing out distinction between wordy and terse, and saying that the document tends towards the former [16:14:35] weiyinxing joins the room [16:14:40] Karp is about protecting how we say it, not what we say (Geoff Huston) [16:15:03] Slide showing what's in scope and what's out-of-scope in the threat model [16:15:04] Brian Weis joins the room [16:15:30] Greg is shocked - shocked! - that we haven't gotten more input yet [16:16:10] DOes saying that sniffing is out-of-scope also suggest that mitm attacks are out-of-scope? [16:16:32] A: No. what we say isn't private [16:17:43] contradiction: delaying a message breaks synchronization, so why is it out-of-scope? [16:18:04] GL: we don't have the mechanisms to prevent it, so it's out-of-scope [16:19:04] GH: the words "messages" and "packets" are used in many ways, confusing [16:19:51] GH: there's an implicit clock in routing messages and jiggering the timing can affect routing [16:20:06] reordering is in scope, thinks timing should be, too [16:20:26] Paul Hoffman leaves the room [16:20:35] Joel: interesting cases that apply to some protocols but not others, and may need to address this on a case-by-case basis [16:20:56] Capture them somewhere but not sure which column they go in [16:21:04] aman leaves the room [16:21:56] GH: in BGP, reordering can cause havoc, bits of information timed relative to other bits of information matters [16:22:17] GL asked GH to write some text, GH responded that he trusts GL to write it [16:22:35] Sam Hartman asks to what extent the scope can be tweaked going forward [16:23:05] JH: the broad outlines are defined by the charter, got some room within that [16:23:14] Confidentiality definitely out-of-scope, though [16:23:47] PH: doesn't understand the text on DOS on transport subsystem. Are we trying to harden transport? [16:24:19] GL: Simply using TLS as transport doesn't solve problem of being able to send reset. [16:24:36] Let's make sure to ask ourselves that question as we look at other protocols [16:25:08] Paul read it as we're supposed to be working at it, hears GL saying that if we get it for free, thats good [16:25:36] GL: when we looked at all possible threats we created two buckets: in-scope and out-of-scope [16:25:43] SH: this is important to work on [16:25:58] GL: the thing that needs addressing is that that text needs to be clearer [16:26:23] SH: we need to look at DOS, the layers above us resilient to attacks on layers below us [16:26:42] If we sit between BGP and TCP, for example [16:27:31] expressing it in terms of layering [16:27:53] We're particularly interested in key management and getting some of those protections, some of those services [16:28:03] (Tim Polk) [16:28:38] TP: just because we're touching on them doesn't mean we're solving them, but maybe enabling their solution [16:29:25] EKR: we're trying to protect routing protocols regardless of where the attackers attacks - this is not a layers problem [16:30:03] GL: you can attack a routing protocol by flooding a segment, we can't solve that within the scope of this effort. What is in scope: you shouldn't be able to send a TCP reset and take down a routing protocol [16:32:06] David McGrew: didn't understand what the document said, problem was preconceptions due to the scope and charter of the working group. Title of this document suggests transport protection, but key management seems to be focus [16:32:20] JH: Both keying and transport are in scope [16:33:32] GL: Let's go incrementally, first look at routing transport, see if we can provide incremental improvements, second phase is key management. Hardest part is how probable is success if we do it in that order [16:34:13] DM: followup - will keymanagement involved with TCP-MD5 be one of those solutions? [16:35:15] Glenn Zorn: points out that TCP-MD5 actually exists [16:35:52] lynch joins the room [16:36:31] PH: back to transport subsystem, there may be more than one communication channel between two routers, trying to prevent DOS means trying to protect all communication. Doesn't think that's true, thinks we're trying to protect just routing protocols, not all possible communications [16:36:44] On to slide 3 ... [16:37:05] Requirements that need further discussion, pages 15-19 of the threats-reqs-00 draft [16:37:17] Requirements 5 & 6 talk about replay protection [16:37:28] 5. inter-connection, 6. intra-connection [16:37:44] usually use a counter in combinatipon with stuff particular to a given connection [16:38:27] not sure if that requirement is valid for routing protocol that are connectionless (don't have connection state) [16:38:42] can connection be leveraged for something like IS-IS? [16:38:53] Is this a relevant requirement? [16:39:50] SH: replay of routing information isn't very interesting but can reset timers, can suppress failure detection. Replaying old routing messages can allow attacker who wasn't on path to come on path [16:40:37] Yes, it's desirable for certain protocols. [16:41:15] GL: replaying information is not a good thing. How to describe requirements ... question is about inter-/intra- distinction [16:41:42] can transport prevent upper-layer message replay? [16:41:51] TCP-AO meets that requirement [16:42:26] show in doc that transport level requirement can address routing protocol requirement [16:42:58] GL: conflates two things, replay protection and sense of connection (state) [16:44:33] lynch is now known as lellel [16:44:37] lellel leaves the room [16:44:39] EKR: analogy in the context of -AO, that said it's useful to say that replay shouldn't interfere with operation of system. Isn't sure about -AO - prevents inservtion but isn't sure it prevents replaying captured packets [16:45:10] Not true for IPSec either [16:45:46] 19: must provide sufficiently large sequence number space ... last requirement makes this go away [16:46:16] PH: Why are you trying to add protection on something that the lower-layer protocol doesn't have? [16:46:35] If lower layer doesn't have replay protection ... ? [16:47:09] GL: that's why approach is incremental [16:47:27] lellel joins the room [16:47:29] SH: if we look at how OSPF handles protection we will look at replay, since it's not in v3 [16:47:46] GL, yes, but we have to stay within the bounds of reason [16:47:59] SH: why is an extra TLV out-of-scope? [16:48:22] GL it's not, but [stuff about not boiling ocean] [16:48:46] BW: OSPF itself might need to be fixed [16:49:53] Req 14: authentication mechanism must be decoupled from key management mechanism [16:51:03] In order to deliver two-step process to operators (and ourselves), make incremental advances, orig. group believed it was required to make clean separation between two [16:51:45] Has a design impact: we can design more efficient, secure system if key mgmt and transport are more tightly coupled [16:52:23] EKR: premature design decision. more convenient in some cases to have tightly coupled KM and transport [16:52:59] EKR: doesn't understand advantages of assuming from the outset that they'll be decoupled [16:54:19] SH: agrees with EKR, wants to emphasize operational impacts. His experience is that loosely-coupled systems are harder to manage. Consider TLS vs. IPSec [16:54:54] Technically harder problem turns into harder-to-deploy system [16:55:12] We already have enough manually-keyed stuff out there that he'd tackle keys first [16:55:40] stuff about keystore being separate should be eliminated [who?] [16:56:03] there's no reason to waste ietf text & time defining formal APIs [16:56:40] GL: what happens when you use manual keys? [16:56:49] There is no local keystore [16:56:57] [at mike] I just invented it [16:57:07] SH: you put it in configuration state [16:57:17] GL: this is getting into framework [16:57:42] SH: problem is that when you start thinking about automated key management that way when someone goes and implements it that way it's not good [16:57:59] All you want to say is "Turn on key management" [16:58:09] If you're having to do much more than that, something has gone horribly wrong [16:59:13] GL: if we do this we throw away incremental advancement benefit - key management has to be complete before you get any individual benefits [17:00:29] Dan Harkins: agrees it may be premature to talk about decoupling, disagrees that it's fundamentally harder to do separate key management. [17:01:09] DH: the reason it's easier to configure TLS than IKE is because of use of cipher suite instead of having to negotiate eveyrthing [17:01:35] GL: agrees with that [17:02:25] [?who?] no reason why you couldn't take keychain and put time limits for start and stop, don't have to use it for traffic keys but just for master keys [17:02:37] Could still have incremental deployment without getting stuck on key store [17:02:39] Shane Amante joins the room [17:03:04] Want to be able to move from a protocol that can't roll keys today to one that can [17:03:46] want to avoid transport layer that can't roll keys without bouncing connection [17:04:24] [GL said that] GL: that's why we want to take incremental, two-stage approach [17:05:39] TP: background: key tables in two documents trying to provide conceptual model [17:06:52] TP: trying to be responsive to several things. 1) incremental deployment is possible seamlessly, thought that's what we were hearing from routing folks [17:07:30] TP: hearing today from routing people is that maybe that's not what they're responding to. Deriving session keys, etc. - great. [17:07:43] From routing protocol point of view, need secure, long-lived keys [17:08:15] EKR: two analogies, 1) AO, 2) TLS vs. IPSec [17:08:55] Doesn't think reasoning from AO to how to build something else is useful [17:09:35] has found the most difficult parts have been coupling to key management system [17:10:28] GL: summarizing, decoupling has advantages for efficiency and reusability [17:10:43] weiler leaves the room [17:10:56] EKR: thinks there's conceptual confusion between what user sees and what's going on under the hood [17:11:24] are we trying to preserve existing code base or trying to improve operator experience? [17:12:43] GL: answer it "both". Router community wants to move to something with more secure properties with existing interface, willing to move to something with more compliocated user interface [17:13:51] thrasher joins the room [17:13:54] Steve Kent: would not try to draw conclusions from TLS vs. IPSec. Modular separation could be good here in many regards. But authentication being decoupled from key manageent in most cases is not something we want to do, with authentication being affected by key management [17:15:03] thrasher leaves the room [17:15:23] GL asks SK: rpd teams don't want to be responsible for security mechanism, want to be able to call out to it, and htat's why "decoupled" was used [17:15:48] SK: when you talk about authn the first thing that comes up is the nature of the thing you're trying to identify, which translates into key management function [17:16:55] GL: what *is* it we want to require of the design teams? What guidance to provide? [17:17:00] SK: there is no free lunch [17:18:02] SH: I'd like to understand what specific security properties the routing community thinks it's going to get? In terms of incremental deployment [17:18:19] GL: key & algo agility, replay protection [17:18:31] SH: how do you get replay protection without key management? [17:18:36] Joel: take it to the list [17:19:16] Requirement 17: authn mechanism should not interfere with the aiblity to prioritize certain protocol packets (OSPF HELLO, for example) [17:19:33] ekr joins the room [17:20:03] ekr leaves the room [17:20:08] weiyinxing leaves the room: Replaced by new connection. [17:20:09] weiyinxing joins the room [17:20:45] Does security community recognize this and thnk it should be preserved? [17:22:32] EKR: if you're going to enforce priorities before an authentication check you can have problems [17:23:00] GL: encapsulation headers can impact software running on i/o cards [17:23:35] GL: stacking encaps. headers means parsing deeper and deeper into the packets [17:24:25] Req 21: must provide backwards compatibility in the message format, transmission, and processing of routing info carried through mixed security environment [17:25:20] Req 22: should care about performance. Related 15: convergence should not be materially affected. Are they the same thing? [17:25:59] Req 25: should not rely on systems external to the routing system [17:26:23] Next steps: clean up known items, more reviews, start design teams [17:26:38] PH: thinks three documents should be merged [17:27:08] lellel leaves the room [17:27:15] lynch joins the room [17:27:38] EKR: doesn't see point of design teams until some of these issues are resolved [17:27:48] JH: start in parallel looking at specific proposals [17:28:01] On to next doc, design guide [17:28:32] should point to threats doc, doesn't yet [17:28:45] categorization: comm. model, keying model [17:28:52] jimsch leaves the room [17:29:32] comm models: one-to-one, one-to-many, and multicast [17:29:57] keying models: peer keying, group keying [17:31:05] why do we need a kmp? [17:31:34] EKR thinks none of the listed reasons are relevant [17:32:14] Ross thinks it's good to include some reasons in the documentation [17:33:16] EKR: key management is for parameter negotiation, re-establishment of new traffic keying material, compatibility [17:34:15] PH: this needs to be taken out because it's wrong, EKR's suggestions are for replacement text. For all of the stuff in the doc [17:35:00] GL: security people need to understand how routing people behave today, addressed by current text [17:35:36] GL: today there is zero understanding. They don't know they have a way to do it without wiping out opex. [17:35:57] 4641 has this and bis is talking about wiping this out and replacing it [17:36:48] [who?] would like to address issues of convergence and performance [17:37:12] GL: operators would love to rotate keys, key management provides a way to do that [17:37:15] SH: How? [17:37:50] GL: a traffic key can be specific to a time or connection and can be rotated automatically if system provides for htat. Same for algorithm agility [17:38:58] EKR: you keep conflating traffic keys w/long-term authn keys [17:39:06] GL: agree that this area needs some work [17:39:10] jpc leaves the room [17:39:53] if these categorizations look good, become basis for design teams [17:40:00] how should protos be grouped? [17:42:07] [who?] this is a good way to group problems [17:42:26] what works for one-to-many would be applicable to one-to-one, too [17:42:48] want one mechanism for protocols in group, not one for each category [17:43:52] dropped priorities on categories. should they be added back? [17:44:41] Q: too much repetition in s6. Gap analysis? [17:44:57] rgonzalez joins the room [17:45:16] suggests we should sync this document better with threats. s6 might not be needed at all [17:45:55] security considerations: were in roadmap, have been lumped into design guide document [17:46:03] "Use strong keys" is targed at operators [17:47:08] PH: shouldn't algorithm agility be part of this? We talk about key size, which assumes that there's not algo agility to elliptic curve [17:47:23] same for keys should be changed at certain rate, goes back to scenario question [17:48:12] weiyinxing leaves the room: Disconnected. [17:48:26] weiyinxing joins the room [17:48:46] DH: are these keys being used to protect traffic, or for KMP authentication [17:48:53] GL: latter [17:49:04] DH: suggests use of word "credential" instead [17:49:38] DH: telling operators stuff like this only makes it harder [17:49:49] GL: this is a design guide document for design teams, not operators [17:52:26] EKR thinks we should get rid of entire text in s7 [17:53:07] Thomas Hardjono: two related efforts outside IETF: IEEE 1619.3 and OASIS ??? [17:53:25] Strongly based on NIST 857 lifecycle model [17:54:39] On to framework document [17:55:21] copy/paste from roadmap [17:55:56] s4 split into s2 (justification/framework elements), and s3 (description of framwork components) [17:56:06] APIs section is nearly completely empty [17:56:25] common framework contains list of elements along with picture [17:57:49] second step adds key management function (identies, proof of identities). different modules for different routing protocols. A single identity serves a router for all protocols it runs [17:58:09] There has to be manual keysetting to support first step [17:58:43] questions in framework components: inc. saag drafts on keytables?, and validation of the usefulness of the framework [17:59:55] framework apis - well-defined as functional descriptions, but no definitions of parameters, , etc. [18:00:30] cw-ietf leaves the room [18:01:01] Russ Housley: stuff about reusing same credential shocked me. Question: would you really use same credential with peers outside and inside network? [18:02:10] EKR: stuff is easy when it's boxes on screen. Code is more complicated. we no idea how to build key management for point-to-oint protocols or groups [18:02:28] EKR: what does this buy you? [18:03:24] Clarification: you defined single unified architecture. Interface is between things on top and things on bottom (both unicast and multicast). To talk on same implied interface between them - what does that mean? [18:03:33] This is the wrong direction (EKR) [18:04:25] Nobody's built single key management protocol supporting multiple protocols, why? [18:05:00] GL: we understand why, but EKR doesn't agree with this particular way to respond to requirements. Instead of repeating "this is wrong," what would be better? [18:05:16] Kingy joins the room [18:05:39] resnick joins the room [18:05:51] EKR doesn't think there's not a straight line from those requirements to this result [18:06:01] resnick leaves the room [18:06:08] Joel is trying to stop this conversation, think we're talking past each other [18:07:01] JH: there are two different issues thinks EKR has raised: 1) the claim that there's single key management across all routing protocols, and 2) separation between key mgmt and security protocols. [18:07:11] cw-ietf joins the room [18:07:25] JH agrees trying to define one thing for all of this won't fly, but disagrees that it will be one per routing protoocol [18:08:38] GL: pretty convinced KMP function has to be at least two, one for one-to-many and one for one-to-one [18:09:03] EKR: keystore box should be erased from diagram. this is a classic example of trying to over-architect [18:10:12] GL: i'm not sure how to fulfill requirements from operators, they don't want to have to put key storage mechanisms into their router for each protocol [18:10:39] TP: is the issue that you don't thik the functions up there are needed conceptually, or that the description of how it's to be instantiated is broken? [18:11:15] EKR: it depends on how it all works [18:12:15] GL: the idea that keystore is uniquely present for each routing protocol, you do not assert it should be like that, what you're objecting to is that there's one keystore? [18:13:00] rgonzalez leaves the room [18:13:17] SH: we don't need to specify it, it's an implementation detail [18:14:29] SH: the way I would do it differently, we're going to provide some common mechanisms for key management that those protocols can consume. The main concern I have is that the assumption that they're separate protocols rather than things that can be modularly consumed within a protocol ... Wants to fully inline the key management [18:15:33] SH: you have a building block in the key management protocol that you invke from the routing protocol is more realistic than assuming you have very well-defined (distinct) protocols [18:16:13] JH: the charter says we should be going to this two-stage approach. Not trying to blow off people's concerns. [18:16:30] SH: I don't think what I said is incompatible with two-stage approach [18:16:44] JH: EKR has said very clearly that the two-stage approach is wrong. [18:16:51] SH: I also think it's wrong [18:17:45] GL: the group of us who've been taling about the lines between functions, those aren't protocols, those are APIs. Trying to describe what APIs should fulfill. [18:17:55] GL: not trying to specify, just describe [18:18:57] Kingy leaves the room [18:19:19] SK: heard a number of time that our customer base is operators, but sometimes our customers want things that aren't rational [18:20:45] SK: rather than a grand unified approach (it's hard doing these things well), if we are too top-down we'll run for a really, really long time ... just an observation [18:21:00] SK: talk to experts on different protocols, look for commonalities [18:22:07] GL: once vendors start implementing we'll never get back to a shared model. [18:22:26] SK: discipline [18:22:56] [back to slides] we have to look at how these things will actually be used, with design teams that understand the protocols [18:24:19] discussion: do we want to cleanly separate traffic protection key and management pieces? [18:24:38] cw-ietf leaves the room [18:24:40] Is there a good technical reason for why an integrated comsec protocol is better [18:24:48] is there a case where it won't work? [18:25:09] how would an integrated comsec protocol give us modularity that RPD teams are asking for? [18:26:11] EKR framework comments: why separate KMP from data security piece, why definite another abstract keystore, claims about security of certs. [18:26:37] kivinen leaves the room [18:26:43] Dan leaves the room [18:26:50] JH: need to take this issues back to list, also need to identify specific actions [18:26:56] Melinda leaves the room [18:26:58] David Cooper leaves the room [18:26:59] lynch leaves the room [18:27:20] per@nordu.net leaves the room [18:29:28] rgonzalez joins the room [18:30:19] Shane Amante leaves the room [18:31:19] Brian Weis leaves the room [18:37:19] Shane Amante joins the room [18:38:59] Shane Amante leaves the room [18:39:39] rgonzalez leaves the room [18:40:56] Shane Amante joins the room [18:46:10] gregory leaves the room [19:17:22] Shane Amante leaves the room [19:42:22] gregory joins the room [19:42:30] weiyinxing leaves the room [20:07:10] Brian Weis joins the room [20:08:49] Brian Weis leaves the room [20:22:30] gregory leaves the room [20:23:01] Brian Weis joins the room [20:23:22] Brian Weis leaves the room [22:39:46] gregory joins the room