[07:02:44] Ed Kern joins the room [08:33:22] Ed Kern leaves the room [08:49:50] jpc joins the room [09:00:16] Ed Kern joins the room [09:02:04] Ed Kern leaves the room [10:38:24] jpc leaves the room [10:59:35] wej joins the room [11:00:27] John Scudder joins the room [11:03:34] weiler joins the room [11:04:19] Ed Kern joins the room [11:05:15] russmundy@jabber.org joins the room [11:07:24] WesG joins the room [11:07:28] Karen O'Donoghue joins the room [11:07:35] scribing [11:07:44] currently agendabashing [11:07:51] do you get fries with that? [11:08:17] and mayo for your fries [11:08:48] Karen O'Donoghue leaves the room [11:09:18] randy - recommend a 1-min update on charter [11:09:40] original charter was origin validation only [11:09:53] most docs are moving towards LC [11:09:59] just protecting origin is not sufficient [11:10:08] can append valid origin to bogus path [11:10:30] recharter work was to suggest new work items addressing full path not just origin [11:10:42] new charter is being displayed from mail archives [11:10:55] Benno Overeinder joins the room [11:11:22] things with draft names are holdovers, rest is new wokr [11:11:23] work [11:11:28] now reviewing http://tools.ietf.org/agenda/80/slides/sidr-5.pdf [11:11:33] Steve Kent [11:11:51] slide 2 [11:12:19] terminology is a little more rigorous than traditional IETF threat level doc [11:12:30] slide 3 [11:13:30] slide 4 [11:13:41] Jeff Haas joins the room [11:14:15] slide 5 [11:14:36] paragraphs associated with each of these capabilities in the document [11:14:46] bgp speakers are not technically orgs or individuals [11:15:21] hackers aren't doing MITM attacks on an OC12, they're interacting with teh routeres or mgmt systems [11:16:39] are there other classes of adversaries? capabilities and motiviations? [11:16:41] slide 6 [11:16:43] jpc joins the room [11:16:44] slide 7 [11:17:03] short section that talks about need for on-link securities [11:17:12] there are already tools to manage this - TCP-AO, others [11:17:18] slide 8 [11:18:17] confuse people trying to determine where something has gone wrong [11:18:19] dougm.home joins the room [11:19:31] looking for add'l classes of attacks that should be included [11:19:32] slide 9 [11:19:56] slide 10 [11:20:46] nlri first set of numbers,AS path in parentheses [11:21:04] slide 11 [11:22:02] slide 12 [11:22:10] shane amante [11:22:24] in this example, how is AS122 adv a moer specific [11:22:41] is AS 120 asserting a range? [11:22:54] clarification - as120 was asserting maxlength of /18 [11:22:59] forgot to update the slide [11:23:25] shane - in light of that, why is AS125 believing that 129.7/17 is valid, because the ROA should have AS120 as its origin [11:23:43] steve - it does. It's not making a bad path, it's making a more specific path that doesn't reflect what was sent [11:23:44] Karen O'Donoghue joins the room [11:23:46] back to slide 12 [11:24:18] David Cooper joins the room [11:24:21] often make an AS less preferable via prepends - removing it would change traffic flow [11:25:01] updates don't time out - no timestamp/expiry, so replays are possible [11:25:17] lapela/pilosov - not just a black hole, but can actually use as MITM [11:25:26] kapela, sorry [11:25:37] slide 13 [11:26:02] doesn't need a more specific, just a more specific AS path [11:26:04] peter lothberg [11:26:13] most networks are using MPLS to be under IP [11:26:25] if you want to be MITM, you can attack that plane and it's invisible [11:26:33] ruediger volk [11:26:41] interdomain MPLS is not that common [11:26:44] .... yet [11:26:55] kent - we're solving the problem that exists now [11:27:02] shane amante [11:27:07] Ed Kern leaves the room [11:27:07] randy [11:27:15] this is not attempting to protect the data plane [11:27:29] imc paper in 2009 - 70% of the ASNs have default [11:27:33] not trying to protect policy or intent [11:27:36] cannot know these [11:27:47] protect the protocol [11:27:52] see that the protocol bgp is not gamed [11:28:13] shane - in this instance of dropping an AS, interesting because in practice [11:28:32] if you think about AS sets, which we know are being deprecated, one could assert that this is a legitimate example of dropping an AS [11:28:45] an AS-SEt is considered one AS in path length in the decision process [11:29:09] point is that there are legitimate forms of agg (or thre were) therefore this is more of a malicious attack vs one that was intended [11:29:27] sandy - so you are talking abou tthe fact that the as-set use would shorten the path length, not tha tit woudl eliminate it from the path [11:30:02] impression that MPLS is not used across AS boundaries [11:30:09] gregory - FT [11:30:17] we do MPLS across AS for VPN businesses [11:30:24] across well know/friendly ASNs [11:30:26] asonalker joins the room [11:31:05] bgp speakers that are adversaries are speakers that are behaving badly [11:32:43] rob schape [11:32:56] question about what you can manipulate [11:33:00] Arturo Servin joins the room [11:33:29] untrusted speaker in a single VPN is very different from untrusted speaker in the internet [11:33:49] peter lothberg - goal is to make the internet work better, lots of businesses where carrier is serving carrier [11:33:55] you may not know where your traffic is going [11:34:24] randy - the charter doesn't say to make the internet better [11:34:41] charter is to protect BGP protocol. not isis, ospf, trucks carrying cards [11:35:11] ruediger volk - what may be missing for scope in the charter, we are only caring for public internet [11:35:26] all of the VPN stuff that uses BGP is not taken care of because it uses a diff NLRI [11:35:29] we can't do ROAs [11:36:03] shane - to respond to randy's point, the entire point is in fact implicitly to make the internet better [11:36:27] it doesn't matter if one manipulates the path the traffic takes unless you don' thaev encryption or you care about the performance [11:36:40] it is making the internet better for some def. of better [11:37:05] kent- we have a goal of improving some aspects of the internet, but if we were going to do that, shakespeare woudl say - kill all of the spammers [11:37:39] back to deck, slide 13/14 [11:37:46] kapela/pilosof (1/2) [11:38:00] geoff huston - [11:38:07] what's the difference between that and failure to withdraw? [11:38:19] kent- replays and failures to withdraw are similar [11:38:26] geoff- they cause the samething, but they're not [11:38:33] kent- I'm not sure I can see the difference [11:38:51] geoff - it's still the same outcome, in the terms of analysis of threats... [11:39:06] sandy - difference between withdraw and replay - I don't get attach [11:39:11] don't get traffic [11:39:33] geoff - failure to withdraw is trickier [11:39:42] kent - recommend sending a message to add this ti the list of atacks [11:39:58] last slide - k-p attack 2/2 [11:40:59] return path is poisoned so that the invalid announcement will be dropped by the valid return path [11:41:18] asking for questions [11:41:24] questions in the room [11:41:30] shane - 2 comments [11:42:11] relayed to k-p attack, all I've seen is the presentation from blackhat - not seen I-D or whitepaper that described it in any detail. this is quite important if the majority of this work is solving for this type of attack [11:42:22] kent - it's another example, not necessarily the majority [11:43:14] we can likely provide some add'l documentation, either work with the authors, or Kent can write one [11:43:37] shane - when I talk to people who participate and do not participate in the WG, this attack is asserted as the primary reason for this work [11:44:19] second point - you've described a series of threats, the question is about the realness of these attacks. This was a demonstrated attack, what's not clear to the reader is the relative risk, percentage of times the attack has occurred [11:44:44] this type of attack has only been demonstrated once, never documented, but may be happening more widely [11:45:00] morrow- this has been obeserved by other ISPs of your size in Ashburn VA [11:45:29] shane - probability, demonstrate that we're solving for the likely attacks [11:46:12] kent - IETF doesn't do that because by the time it goes out there'll be new attacks and we'd have to re-evaluate, and because other SPs have said that they feel that they aren't allowed to report other types of issues [11:46:41] ssl or TLS is not that interesting if I'm not using a wireless network, but we've adopted a model that says we're going to try to protect [11:46:58] so over time, the risk level has shifted [11:47:22] shane- understand, concern is either boiling the ocean or fixing a subset of problems that give you good enough security for somethign that can be widely deployed [11:47:52] sandy- one term that steve did not put in his terminology was something about risk - how much damage can you expect and how frequently it occurs [11:48:03] this is very much "beauty is in the eye of the beholder" [11:48:30] brian wies (sp)? [11:48:44] this is a nice set of threats, but do the other items have a list of the threats that they mitigate? [11:48:51] kent - ye [11:48:52] yes [11:49:55] sriram- re; shane's question about aggregation - AS can create a ROA for the aggregate and sign as originating AS [11:50:05] randy - shane I assure that theese were seen in the wild [11:50:25] no one has been able to report, but we were overjoyed to find them so that we could demonstrate that they're present [11:50:34] warren kumari [11:50:53] while we believe most of the misoriginations are accitendal, it's hard to prove that [11:51:00] rob austein - keep timescale in mind [11:51:20] we don't see them now, not a guarantee to do it in the middle [11:51:50] set wayback machine 20 years - theoreticall y you could do a tCP attack if you were on path. now you can buy off the shelf for $99 that does htis - NAT box [11:52:10] sandy - are these intended to be a complete list of the attacks that the WG should addres [11:52:27] kent - these should be a comprehensive characterization of the attacks we care about [11:52:46] not every possible combination, just classes [11:54:00] randy bush speaking [11:54:20] reviewing dfraft-ymbk-bgpsec-reqs-02 [11:54:21] section 3 [11:54:29] (actually reviewing draft, not PPT [11:55:01] big thing is we're trying to validate the protocol, not intent [11:55:34] receiver of an ann'c should have a strong (crypto) validation that the path of ASs down wich the announcement traveled is indeed the path it traveled [11:55:45] incremental deployment, apple pie, motherhood [11:55:52] now looking at sections 3.4/5/6 [11:56:17] solution being proposed is signed paths based on RPKI [11:56:24] russmundy@jabber.org leaves the room [11:56:25] if you do that, you're not likely to do it on a 7200 or M5 [11:56:45] right now we've just got the RPKI and origin validation to test images [11:57:03] RIRs are bareyl signing ROAs. origin rolls out in 2-3 years. this (bgp sec) is a follown [11:57:08] to clarify for remote: there are no slides. the draft itself is on screeen, showing 3.4-3.6 now. [11:57:15] IETF process to get this out the door will take 2-10 years [11:57:33] sandy joins the room [11:57:39] edge routers lifetime is about 5 year lifetime bfeore they get moved [11:57:51] this will be a race to see which is slower [11:57:58] this is not tomorrow's routing, but day after's [11:58:11] now on draft section 3.5 [11:58:28] section 3.6 [11:58:51] 3.7 [11:59:01] 3.8 [11:59:52] there's a draft in IDR that bumps message size to 64K [11:59:56] should be big enough [12:00:16] 3.9 [12:00:20] deprecate AS sets [12:00:24] 3.10 [12:01:11] today, you can pack common updates together and fill the max PDU size [12:01:41] problem is on the receiving router - applying policy. the signed package decomposes and the sig is no longer valid [12:01:48] so you can unpack [12:02:31] presented an experiment a couple of IEPG mtgs ago showing that worst case was 2:1 [12:02:40] when packing was disabled [12:02:43] 3.12 [12:03:50] shane - is this triying to speak to universal deployment of BGP sec or not. it's talking to backward compatibility [12:04:30] randy - all it's saying is that witjh rotuersthat are speaking BGPSec need not be compatible with routers that aren't [12:04:43] if you're both BGPSec speaking routers, BGP doesn't have to be compatible with BGP as we know it today [12:04:50] if you're not both BGPsec, it does [12:04:56] 3.13 [12:05:09] russmundy@jabber.org joins the room [12:05:25] rob - if you're changing BGP, why use BGP at all? [12:05:43] randy - why is an elephant [12:05:51] geoff - understand why I'm confused [12:06:01] issues about incremental deployment vs backward compatibility [12:06:18] distinction beween way info is exchanged and the objects you are exchanging [12:06:38] if we're speaking hinky protocol, I have to translate or drop stuff so that the stuff that doesn't udnerstand what I'm saying [12:06:59] secret squirrel stuff that you and I have, if I send it as BGP4, no one else can put more secret-squirrel stuff on there [12:07:18] when we did BGP4, we allowed the secret-squirrel stuff to go between non-s [12:07:24] we called that incremental deployment [12:07:27] this doesn't do that [12:07:54] randy - this document intentionally finesses the question of whether trust info transits non-trust-speaking oceans between islands [12:08:07] the actual bgpsec doc proposal, the answer is that it doesn't [12:08:18] this is a matter of discussion [12:08:29] trust/security people are fairly adamant that it shouldn't, and I trust them [12:09:35] geoff - in observing some of the transitions such as V4/v6 and it's "backward compatibility" - I understand and appreciate what security folks want [12:09:42] problem is practical deployability [12:10:04] what you just said is very important for everyone in thsi room, eventually gettintg there and how we get there is more impotant than what happens at the end [12:10:17] question about sharon's paper [12:10:33] trying to udnerstand critical mass of deployment is one thing [12:10:59] when incremental deployment happens as a wavefront rather than a disease [12:11:31] big debate over partial path signing [12:11:39] people that are strong propoents of this [12:11:49] randy <- not smart enough to understand the implicatons [12:12:11] john scudder - was trying to understand if Geoff was proposing something different should be in the req's doc, or if that was a tangent [12:12:21] resp - I'm not smart enough to understand the implications [12:12:32] Karen O'Donoghue leaves the room [12:12:33] requirement assumes knowledge of an outcome [12:12:42] partial deployment is great, but weird in the context of path [12:13:17] rob austein [12:13:49] to be clear, it's not lack of interest in partial path signing - whenver we looked at it, it started looking like that old cartoon... step 2, "and then a miracle occurs" and it was hard to bridge that gap [12:14:03] 3.15 [12:14:21] sobgp vs sbgp [12:14:25] wars [12:14:29] russmundy@jabber.org leaves the room [12:15:35] 3.16 [12:16:04] skip to 3.19 [12:16:22] 3.20 [12:16:27] non-transitive [12:16:39] 4.1 [12:16:40] 4.1 [12:16:42] 4.2 [12:16:52] 4.3 [12:16:58] 4.4 [12:17:00] Ed Kern joins the room [12:17:13] 4.5 [12:17:17] 4.7 [12:17:48] validation state only - policy will tell each router what to do [12:17:53] brian weis [12:18:34] what are the restrictions or allowancees on BGPSec in relying on external devices [12:18:40] hard dependence on time [12:18:52] most routers use NTP [12:18:57] send to list [12:19:37] consider AS-override [12:19:57] it probably is a mater of saying "not in scope, doesn't handle" [12:20:40] if you're trying to say that the AS-path is true, then all of the hacks we have to lie about the as-path are sort of a problem [12:20:55] shane - removing private ASN widely deployed [12:21:03] not stated if this is within or out of scope [12:21:27] Karen O'Donoghue joins the room [12:21:38] other issue - confused. if you look at 3.4, discusson says may require new hardware [12:22:14] Ed Kern leaves the room [12:22:32] 3.4 seems to suggest that this is designed to operate strictly in the control plane [12:24:50] andrei - isoc - didn't find anything about scale/convergence in this req. doc [12:25:00] morrow - already very important [12:25:04] andrei - but not in the document [12:25:13] lothberg [12:25:28] getting this into provider networks [12:25:41] but the people who have the biggest budget are the ones that make more money charging for VPNs and such [12:25:48] how do we make this attractive for them too? [12:26:50] lothberg- more generic model that can manage all types [12:26:57] randy - secure INTERDOMAIN routing [12:27:04] me - you can have inter-domain VPNs [12:27:29] now reviewing http://tools.ietf.org/agenda/80/slides/sidr-18.pptx [12:28:16] slide 2 [12:28:25] securing the as path attribute [12:28:52] slide 3 [12:30:22] slide 4 [12:30:59] this is a strawman [12:31:57] question on slide 3 [12:32:00] didn't get speaker's name [12:32:15] ilya varlashkin [12:32:36] thanks [12:34:08] jeff [12:34:25] no different than being able to verify that any path you're receiving is being used for forwarding [12:34:33] bgp may have been lagging behind its advertised state [12:34:42] may ahve selected, but havent made through the queue [12:34:52] you don't wna tto try to couple this too tightly together [12:35:06] slid e4 [12:35:07] slide 56 [12:35:10] 5 [12:36:57] slide 6 [12:37:03] shane [12:37:08] question on 5 [12:37:18] proposing sha 256? [12:37:34] crypto was chosen because that's what we're using in RPKI, but we can discuss as separate items [12:37:46] changing algorithms is hard, so we should talk more about the right one [12:38:19] have you done studies on what the theoretical size of a routing table would look like with all of these signatures? [12:38:23] yes, we'll send to list [12:40:10] slide 6 [12:40:14] pretty pictures [12:41:17] Karen O'Donoghue leaves the room [12:43:11] me - talk about incremental deployment wihin an AS [12:43:16] slide 7 [12:44:24] slide 8 [12:45:46] slide 9 [12:47:17] slide 10 [12:47:56] slide 11 [12:48:01] slide 12 [12:49:29] slide 14 [12:50:27] geoff huston [12:50:48] hypothesis is that the current version of BGP, you accept routes and do whatever validation in your framework [12:50:52] and I receive updates from you [12:51:05] I accept your judgement as to what you thought was good, and process the incremental [12:51:21] I note that I can do a different set of trust anchors from you [12:51:52] when I validate this path, it's possible that even if you validated it, I can come to a different result using a slightly different trust anchors [12:52:06] randy - you compute yours, which includes the chain up to me and including me [12:52:10] you don't recompute mine [12:52:25] the rpki is a distributed database that is not necessarily consistent at any point [12:52:31] so you might hvea different view [12:53:11] I choose what to propagate to you, you receive it and base your actions on your evaluation [12:53:44] you should not be using lots of routes that you think are garbage [12:53:53] protocol does not say you must only sign things that are validated [12:54:14] randy - put another way - when I sign and send, I am attesting that this is what I received [12:54:31] I'm also attesting that I chose for policy reasons to send to my neighbor [12:54:59] slide 15, 16 [12:56:29] slide 17 [12:56:45] slide 18 [12:56:47] Karen O'Donoghue joins the room [12:58:02] slide 19 [12:58:08] slide 20 [12:59:47] operational reports mailed out is how many updates on the internet each week [13:00:02] analysis on bgp updates and how it scales - 4274? [13:00:15] don' have good advice on how to set expire time [13:00:26] maybe days if it's stable [13:00:41] maybe adding 1-2 updates for stable routing every day or two [13:01:05] problem isn't how many per prefix, but how many prefixes there are [13:01:14] understand new hardware may be required [13:01:33] large changes in how scaling and such are managed [13:01:55] jeff [13:02:04] you can make recommendations to implementers of BGP [13:02:21] if it's an update that has no changes but timing, it can be a refresh, not a new update [13:02:46] might help with path hunting algorithms [13:03:09] expiry times that are too short are an attack on systems on the internet [13:03:42] recommend keys that require refresh that they be done in a way that they can be updated as a part of an already pending update [13:03:50] john scudder [13:04:09] report about bgp updates per day - amusing, but not necessarily useful because it's an average [13:04:21] most interesting in bgp implementation is how it processees peak load [13:04:31] hopefully smart enough manage this [13:05:52] peter lothberg - what is time here? [13:06:10] warren kumari [13:06:17] stuff that is changing [13:06:20] benefits too [13:06:25] slide 22 [13:07:49] slide 23 [13:12:32] my comment - statuses ? do we need one for expired instead of just invalid? [13:13:00] jeff - think about the fact that this infra is somewhat reusable - we're not signing the entire packet [13:13:04] we're signing an attribute [13:13:14] Karen O'Donoghue leaves the room [13:13:18] design goal was to sign as litle as possible and still get good security semantics [13:13:49] majority of the requirements for VPN and other NLRI is a means to sign so keep this in mind for reuse [13:13:56] not necessarily design for it as a primary requirement [13:14:08] rob austein [13:14:11] in principle agree [13:14:24] difficulty is that signing isn't a solution [13:14:36] signatures have to be made with keys that are associated with something tha thas the right property [13:14:44] it may not necessarily tell you anything [13:15:02] must analyse to see what attestation you can make based on the data - what is the trust model [13:15:36] doug montgomery [13:15:44] gasps about receive model and fetching keys [13:16:00] assumptions that they'll be preloaded and stored by validating cache [13:16:04] fetch is a better word [13:16:41] Jeff Haas leaves the room [13:18:45] me - give us best estimate of scaling and convergence impacts [13:18:58] doug montgomery at the mic [13:19:01] jeff [13:19:05] comment on convergence [13:19:34] generally not well-understood what the inputs are for single-system convergence, let alone multisystem [13:21:42] asonalker leaves the room [13:22:17] request for adoption [13:22:24] who read the draft [13:24:55] the note taker has to leave in 5 minutes [13:25:01] done [13:25:03] WesG leaves the room [13:25:12] Arturo Servin leaves the room [13:25:17] jpc leaves the room [13:25:25] John Scudder leaves the room [13:25:44] weiler leaves the room [13:26:00] David Cooper leaves the room [13:28:31] Benno Overeinder leaves the room [13:29:09] John Scudder joins the room [13:29:36] Benno Overeinder joins the room [13:29:38] Benno Overeinder leaves the room [13:34:55] John Scudder leaves the room [13:52:59] dougm.home leaves the room [13:58:42] Ed Kern joins the room [13:59:20] Ed Kern leaves the room [14:03:41] Ed Kern joins the room [14:08:06] Ed Kern leaves the room [14:15:26] sandy leaves the room: Computer went to sleep [14:26:21] John Scudder joins the room [14:33:44] Karen O'Donoghue joins the room [14:35:48] John Scudder leaves the room [14:38:18] Karen O'Donoghue leaves the room [15:03:47] wej leaves the room [20:29:14] Arturo Servin joins the room [22:01:58] Arturo Servin leaves the room