IETF
sidr
sidr@jabber.ietf.org
Thursday, 9 February 2012< ^ >
melkins has set the subject to: SIDR WG http://www.ietf.org/proceedings/79/agenda/sidr.html
Room Configuration

GMT+0
[16:58:23] Paul Hoffman joins the room
[17:02:37] ndg joins the room
[17:03:13] <Paul Hoffman> FWIW, I just phoned someone who is in the f2f room, and they say "they're working on it"
[17:03:25] Randy Bush joins the room
[17:03:36] <ndg> thanks. i thought it was just me :-/
[17:03:42] <Randy Bush> sandy is working on webex
[17:04:01] ejk joins the room
[17:04:05] Sean Turner joins the room
[17:04:09] dougm.work joins the room
[17:04:19] MIchael Sinatra joins the room
[17:04:21] weiler joins the room
[17:04:21] weiler leaves the room
[17:04:26] <Sean Turner> hi everybody
[17:04:33] <Randy Bush> hi sean :)
[17:04:36] lepinski joins the room
[17:04:55] <Paul Hoffman> FWIW, there are six people in WebEx. I don't really count because I'm just touristing for a short while.
[17:05:08] <Paul Hoffman> I guess calling Russ on his cell phone was effective. :-)
[17:05:36] <Sean Turner> FYI - the view from this side of the room is quite nice … we can see the water. Kudos for the room selection!
[17:06:18] wkumari@jabber.psg.com joins the room
[17:07:51] <wkumari@jabber.psg.com> Hello.
[17:08:16] <wkumari@jabber.psg.com> Still a workin' on making WebEx work...
[17:09:21] smb joins the room
[17:10:04] Jeffrey Haas joins the room
[17:10:30] lepinski leaves the room
[17:10:59] lepinski joins the room
[17:11:11] wkumari@jabber.psg.com leaves the room: Replaced by new connection
[17:11:14] wkumari@jabber.psg.com joins the room
[17:14:16] lepinski leaves the room
[17:14:45] adrianfarrel joins the room
[17:14:49] lepinski joins the room
[17:16:04] Stewart Bryant joins the room
[17:16:35] dougm.work leaves the room
[17:17:05] Jeffrey Haas leaves the room
[17:17:25] Jeffrey Haas joins the room
[17:17:55] <Stewart Bryant> Is the problem with the audio at the hotel or with the webex?
[17:17:59] Randy Bush leaves the room: Replaced by new connection
[17:18:03] lepinski leaves the room
[17:18:10] <Jeffrey Haas> Both.
[17:18:13] wkumari@jabber.psg.com leaves the room: Replaced by new connection
[17:18:18] Randy Bush joins the room
[17:18:21] wkumari@jabber.psg.com joins the room
[17:18:24] <Jeffrey Haas> We have no dialtone and webex is not working.
[17:18:32] <Jeffrey Haas> Slides may be posted in a well known location.
[17:18:36] lepinski joins the room
[17:18:49] <Stewart Bryant> If necessary I can set up a new webex
[17:19:11] <lepinski> Stewart, thanks but I think the issue is the hotel network not the webex
[17:19:18] <Randy Bush> the problem is the connectivity into the meeting room here
[17:20:12] morrowc joins the room
[17:20:15] <Stewart Bryant> I now have audio
[17:20:27] <Paul Hoffman> We now have WebEx audio
[17:20:42] <smb> Does that include phone dial-in?
[17:20:45] weiler joins the room
[17:20:53] <Jeffrey Haas> Phone dial in is still not active.
[17:20:56] <Stewart Bryant> Yes but I only got a few packets of codex junk
[17:21:01] <weiler> hi
[17:21:27] Karen O'Donoghue joins the room
[17:21:50] <weiler> Our Polycom is doesn't have dialtone, hence the lack of audio. we haven't started.
[17:22:11] <adrianfarrel> Can't someone with a laptop skype into webex and save a little time here?
[17:22:12] <Stewart Bryant> There is now onesided audio
[17:22:26] <morrowc> can hear some audio on the voice bridge.
[17:22:30] wkumari@jabber.psg.com leaves the room: Replaced by new connection
[17:22:33] wkumari@jabber.psg.com joins the room
[17:22:36] Jeffrey Haas leaves the room
[17:22:47] <Paul Hoffman> Whoever "Randy" is on the WebEx really needs to mute.
[17:22:58] <morrowc> who's that talking on the audio?
[17:23:19] <ndg> sounds like he is proxying for the speaker?
[17:23:41] sandy joins the room
[17:23:46] <Paul Hoffman> No, he is just talking loudly.
[17:23:53] <Stewart Bryant> yes we can here you
[17:23:53] <morrowc> yes sandy
[17:23:54] <Paul Hoffman> I can, Sandy
[17:23:55] <Randy Bush> i am not on webex. i do not use webex, it requires a java applet.
[17:24:37] Jeffrey Haas joins the room
[17:25:00] <Paul Hoffman> Sandy: if you can nuke the WebEx user named "Randy", you should
[17:25:19] Jeffrey Haas leaves the room
[17:25:37] <Stewart Bryant> yes the slide seem to be up
[17:25:40] Jeffrey Haas joins the room
[17:25:45] <Paul Hoffman> Yes
[17:25:47] <MIchael Sinatra> Yes.
[17:26:01] <Jeffrey Haas> http://www.ietf.org/proceedings/interim/2012/02/09/sidr/proceedings.html
[17:26:27] <Sean Turner> Okay I got in and webex worked but I jumped out to avoid killing the network here in the hoteol
[17:27:27] Keyur Patel joins the room
[17:31:13] <wkumari@jabber.psg.com> Hello, I'm scribing. Please feel free to SHOUT to get attention, etc...
[17:31:41] <wkumari@jabber.psg.com> Replay and Freshness
[17:32:55] <Sean Turner> cool we're all break dancing now
[17:33:30] <wkumari@jabber.psg.com> Slide 3: "Replay Picture"
[17:33:51] <smb> The Webex audio is working for me, too — thanks, all.
[17:34:34] <morrowc> slides didn't get posted though?
[17:34:37] <Jeffrey Haas> (replay animation is being stepped through)
[17:34:41] <Jeffrey Haas> slides at http://www.ietf.org/proceedings/interim/2012/02/09/sidr/proceedings.html
[17:34:44] <morrowc> if slide owners email me I'll post them ...
[17:34:54] <morrowc> i missed them... hrm.
[17:35:00] <morrowc> oh :) nm.
[17:35:22] <wkumari@jabber.psg.com> Slide 4: "Staleness Picture"
[17:35:22] <Jeffrey Haas> I missed them as well.
[17:35:28] <wkumari@jabber.psg.com> Slide 5.
[17:35:35] <wkumari@jabber.psg.com> From IETF82 - Lepinski
[17:35:40] <wkumari@jabber.psg.com> Slide 6
[17:35:53] <wkumari@jabber.psg.com> "From IETF82-Lepinski:Preventing Replay Attacks
"
[17:36:18] <wkumari@jabber.psg.com> Slide 7: From IETF82:Preventing Replay Attacks
[17:37:11] <Jeffrey Haas> (Now getting Sandy Sriram's slides)
[17:39:15] <Paul Hoffman> Sandy: WebEx is now going fairly well, go ahead and get email
[17:39:17] <Stewart Bryant> yes - can see slides
[17:39:18] <Paul Hoffman> Yes, we see slides
[17:39:19] <ndg> webex slides are fine for me.
[17:40:21] <wkumari@jabber.psg.com> Slide 2 (Sriram's deck)
[17:40:37] <wkumari@jabber.psg.com> "Key Observations for Modeling"
[17:40:41] <weiler> how's net working for folks in the room?
[17:40:48] <weiler> and on which SSID?
[17:40:57] <Jeffrey Haas> Many have moved to Warren's portable hot-spot.
[17:41:09] <weiler> it's doing better for me now (on The Bristol, with SSL tunnel out)
[17:41:25] <morrowc> I'm also uploading pdf versions of the slides which are in ppt form...
[17:41:29] <weiler> I need to know whether to tell the hotel guy to keep doing things or just go away.
[17:42:24] <wkumari@jabber.psg.com> Slide 3:
[17:42:35] <wkumari@jabber.psg.com> Realistic BGPSEC Router Load Model
[17:42:43] Jeffrey Haas leaves the room
[17:42:48] Jeffrey Haas joins the room
[17:43:09] <smb> Chis: URL for your pdf versions?
[17:43:35] kvaradhan3 joins the room
[17:44:00] <Karen O'Donoghue> i'm on Bristol 1 and it is meeting (my admittedly undemanding) reqts
[17:45:41] wkumari@jabber.psg.com leaves the room: Replaced by new connection
[17:45:43] wkumari@jabber.psg.com joins the room
[17:46:00] Jeffrey Haas leaves the room
[17:46:40] Jeffrey Haas joins the room
[17:46:53] <wkumari@jabber.psg.com> Apologies all, Internet hickup...
[17:47:21] <kvaradhan3> Looks like the slides are not back on the webex?
[17:47:24] <Paul Hoffman> We are *not* seeing the slides in WebEx
[17:47:31] <Stewart Bryant> +1
[17:47:37] <wkumari@jabber.psg.com> Fixing....
[17:47:52] <Paul Hoffman> Jay Borkenhagen is the person who can show slides
[17:48:02] <Jeffrey Haas> Is there anyone who can *not* get the current slide decks from the proceedings page?
[17:48:32] weiler leaves the room
[17:48:32] weiler joins the room
[17:48:47] <Stewart Bryant> Which deck - deck?
[17:48:52] <Jeffrey Haas> http://www.ietf.org/proceedings/interim/2012/02/09/sidr/proceedings.html
[17:48:54] <Stewart Bryant> deck 5 ?
[17:49:11] <morrowc> the decks are apparently repeated...
[17:49:12] <Stewart Bryant> There are two set of beaconing slides
[17:49:16] <Stewart Bryant> OK
[17:49:29] <morrowc> 1&2 are the same, 3&4 are the same 5&6 are the same.
[17:49:31] <Paul Hoffman> Yes, now Sandy is back.
[17:49:34] <Jeffrey Haas> sorry, replay slides for sriram don't appear to be uploaded.
[17:49:40] <smb> The slides on that page are weird — sidr-1.ppt and sidr-2.ppt are identical, as are −3 and −4.
[17:49:46] <Paul Hoffman> yes, we see them now
[17:49:50] <wkumari@jabber.psg.com> Can webex folk se the deck now?
[17:49:50] <ndg> ack.
[17:49:53] <wkumari@jabber.psg.com> TY
[17:50:03] <Stewart Bryant> No I have sandys desk no the slides
[17:50:07] <Paul Hoffman> No, wait.
[17:50:12] sandy leaves the room
[17:50:13] Jason Schiller joins the room
[17:50:14] <Stewart Bryant> yes ok on audio
[17:50:30] dougm.work joins the room
[17:50:30] <Paul Hoffman> OK, got the slides again
[17:50:34] <MIchael Sinatra> Slides are good.
[17:50:37] <smb> and −5 and -6
[17:50:38] <wkumari@jabber.psg.com> Slide 4:
Measurement data.
[17:50:45] <wkumari@jabber.psg.com> Slide5
[17:50:46] <smb> "I see everything twice"
[17:50:59] <Randy Bush> i want a lepage glue gun
[17:51:00] <wkumari@jabber.psg.com> Load Due to BGP and Beacons per peer
[17:51:42] <morrowc> a link for all pdfs: http://docs.as701.net/tmp/sidr-interim.tar - for hose with lazy click fingers.
[17:52:10] <wkumari@jabber.psg.com> Slide 6: <same title>
[17:52:23] <wkumari@jabber.psg.com> Sorry: Load Due to BGP and Beacons for 3 peers
[17:53:13] <wkumari@jabber.psg.com> Slide 7: Comparison of Prefix update...
[17:54:16] <wkumari@jabber.psg.com> Slide 8: Conclusions
[17:56:01] <Jason Schiller> So this is load on an end-site connected to 3 upstream ISPs?
[17:57:02] <Paul Hoffman> We can't hear Randy
[17:57:18] <Sean Turner> can you hear him now?
[17:57:24] <Paul Hoffman> Barely
[17:57:27] <morrowc> can't hear/understand.
[17:57:28] <morrowc> no
[17:57:35] <morrowc> tell him to walk to a mike.
[17:57:37] <morrowc> mic
[17:57:54] <Paul Hoffman> Tell him to type it into Jabber. :-)
[17:58:02] <Stewart Bryant> I can hear nothing
[17:58:08] <ndg> +1 no.
[17:58:16] <Paul Hoffman> I can hear him if I strain. I have a good headset
[17:59:09] <Paul Hoffman> We are not, Sandy
[17:59:10] <Sean Turner> we got him a mic
[17:59:28] <Karen O'Donoghue> any better?
[17:59:31] <Paul Hoffman> No
[17:59:32] Jeffrey Haas leaves the room
[17:59:33] <morrowc> not yet...
[17:59:37] adrianfarrel leaves the room
[17:59:41] <Paul Hoffman> Well, a little.
[17:59:47] <Paul Hoffman> Is he not talking into a mic?
[17:59:56] <Sean Turner> nope he is
[18:00:01] Jeffrey Haas joins the room
[18:00:11] <Paul Hoffman> Yes, much better.
[18:00:17] <MIchael Sinatra> perfect
[18:00:19] <Stewart Bryant> Much beter
[18:00:19] <ndg> def better.
[18:00:19] <morrowc> better.
[18:01:04] <Jeffrey Haas> sandy's cell is being passed around. we will have to be observing good mic protocol
[18:01:09] <wkumari@jabber.psg.com> Sorry, seems to only be single channel receiver.
[18:01:10] <wkumari@jabber.psg.com> Swapping mics.
[18:01:29] <Paul Hoffman> I hope none of you have a cold. :-)
[18:02:07] <Jeffrey Haas> Randy: I'm the receiver. I received an Announcement from A for P. Then receive from B for P. B wins
[18:02:16] <Jeffrey Haas> B wins temporarlly
[18:02:20] <Jeffrey Haas> refresh from A.
[18:02:24] <Jeffrey Haas> do not run best path.
[18:02:38] chwhitey joins the room
[18:02:47] <Karen O'Donoghue> russ: how does the receiver distinguish
[18:03:04] <weiler> paul: and there's no bozo nose on the handheld, either.
[18:03:17] <Jeffrey Haas> The signatures will be different.
[18:03:27] <Jeffrey Haas> Randy: It's painful to validate.
[18:03:33] <Jeffrey Haas> The signature has changed.
[18:03:37] <Sean Turner> different because the time changed
[18:04:12] sandy joins the room
[18:07:49] heather.skanks joins the room
[18:10:53] <Jeffrey Haas> apologies to remote participants, we are *not* able to hear you.
[18:11:25] <sandy> try to use the jabber room for comments if you can
[18:11:29] <smb> The replay of my statement was correct: change the units.
[18:11:37] <Sean Turner> what's the appropriate window?
[18:11:44] <Sean Turner> I think that's what Randy was asking
[18:11:56] <sandy> randy: is it useful to have a replay window of a day or of an hour
[18:12:14] <sandy> jeffH: many paths are incredibly stable.
[18:12:17] <Sean Turner> when we look at current internet routing state - many are incredibly stable then having long timers is good
[18:12:56] <smb> Randy: I don't know the answer about the right value. I toss out the suggestion as a technical mechanism *if* the right value can be agreed upon.
[18:13:00] <sandy> JH: we will need to act the fastest when we are hurting the most.
[18:13:18] <weiler> be advised: we do not expect to have a working Polycom until after we take a break (and give the hotel staff more freedom to come in and debug). I'm hopeful that we'll have it after lunch.
[18:13:30] <sandy> russhousely: what reploay attacks are we most worried about. primary and backup path, prime fails, backup in use, prime comes back
[18:15:19] dougm.work leaves the room
[18:15:46] <sandy> but it has given the backup this signed thing.
[18:15:46] <sandy> but if the break to the prime is a change in relationship, there is no intent to ever have traffic come back through that link
[18:17:38] <sandy> randy: if we are talking more than an hour or so, then it might as well be days.
[18:17:38] <sandy> randy: I see the attacks (short spear fishing vs human time scale) as two very different things
[18:18:20] <sandy> heather schiller: nanog case was a business relationship which was broken and the customer took the space went with them. the victim wanted to reclaim the space for reallocation
[18:18:55] <sandy> heather: so if you had previously had relationship with them - you have some ability to contact them
[18:19:33] <sandy> heather: different problem is when you do not have business relationship
[18:19:41] <sandy> randy: that's mis-origination
[18:20:23] Sander Steffann joins the room
[18:20:39] <sandy> heather: no, talking about case where somewhere else someone who does not have a relationship with you - possibly someone down stream has picked up a bad neighbor who is doing bad thing
[18:21:14] <sandy> randy: going back to statement (attributed to Sandy) that rpki can defend against this - by rekeying the router
[18:21:55] <sandy> randy: the long time scale could be helped by rekeying router - you have time for rekey to propagate.
[18:22:09] <sandy> randy: but for short timescale things, the rpki distribution is too slow
[18:22:12] <Sean Turner> many people moving toward the phone ;)
[18:22:38] <sandy> sriram: <<<missed his comment>>>
[18:23:45] <sandy> russhousley: not what I thought randy was saying - thinik randy was saying if you have per router rpki keys, then you can stop replay attack by changing the router key distributed in rpki.
[18:24:11] <smb> Randy: how can you get new RPKI data pushed quickly enough?
[18:24:38] <sandy> russh: but if the short time frame things can't be helped by that strategy - we have to think carefully about what the threat is
[18:25:10] <sandy> matt: per router or per AS keys are a engineerign local choice
[18:25:36] <sandy> russh: but have to be concerned that per AS keys can not be generated on the router
[18:25:40] <wkumari@jabber.psg.com> smb: has this answered your q?
[18:26:25] <sandy> steveK have to look at how often people are pulling from rpki
[18:26:37] <Jason Schiller> If you choose a router key that is same for all routers in the AS… do you get the same functionality as a per router key, but at the operational cost of changing the key everywhere? Or am I missing something more subtle?
[18:26:59] <sandy> randy: (in answer to smb) I think as we see rpki technology - propagation in single digit hours.
[18:27:21] <sandy> randy: three phases - publication, propagation, all routers retrieving from cache
[18:27:37] <sandy> randy: rpki-rtr spec says 1 hr max for cache-rtr pickup
[18:27:39] <smb> Per your comments earlier, is single-digit hours short enough?
[18:27:39] Michael Elkins joins the room
[18:28:32] <sandy> randy: the publication is the issue - may not publish more frequently than once a day (APNIC has said this). APNIC is not necessarily the party you need to have sign a new router kiey
[18:28:55] <wkumari@jabber.psg.com> Jason:Waiting at mic...
[18:29:11] <sandy> randy: NIR has said they are not going to do the "fancy" parts of rpki as ghostbusters
[18:29:48] <Sander Steffann> Did Randy say NIR or RIR?
[18:30:07] <Jason Schiller> Waren: Randy just answered… the subtle difference is how to change the key
[18:30:10] <sandy> randy: two modes of rekeying - router generates a private key vs noc generating and pushing out to router
[18:30:48] <wkumari@jabber.psg.com> RIR's will not do fancy bits...
[18:30:58] <MIchael Sinatra> romeo-india-romeo
[18:31:09] <sandy> (randy did say RIR not NIR, sorry)
[18:31:36] <sandy> jeffH: to operators: what do you set your reset timers to
[18:31:48] <wkumari@jabber.psg.com> s/reset/restart/
[18:31:54] <heather.skanks> "graceful restart"
[18:32:26] <sandy> jeffH: if you look at graceful restarts - after box has rebooted - you have to recover all state and compare to what is running - and representative to time in box to coordinate with all peers
[18:32:47] <sandy> jeffH: so ops have heuristic of how well they can do in that circumstance
[18:33:51] <sandy> jeffH: can you handle the load of getting refresh from peers in 15 min will help us understand what beaconing
[18:34:37] <sandy> jeffH: trying to say graceful restart right now gives us an example of the best we can do right now, we won't do better with beacons
[18:35:06] <sandy> jeffH: we can at least look at running networks and know what the load is
[18:36:22] <sandy> jeffH: if we run RFD ... if we have more memory and we keep around the signed paths, we can deal wiht route churn -- we can deal with churn by looking at a set of paths that you have held on to.
[18:36:34] <wkumari@jabber.psg.com> JeffH: If we have sufficent memory, we may be able to keep old paths (and validation state) in a cache so we don't need tp revalidate during churn.
[18:37:26] <sandy> dougmtg: when we talk about using rpki itself to deal with freshness problem -- i don' thtink that analogy to human time scale current probjems -- not so sure that will scale
[18:37:48] <sandy> dougm: could say every time you change your peering session - you should role your key -- problem is to reuse a path segment or supress a withdrawal
[18:38:16] <sandy> dougm: so if i break my relationshiop to warren, i need to rekey my as and invalidate that link
[18:38:35] <sandy> mattl: is it sufficient to just rekey the router's key?
[18:39:26] <sandy> dougm: that hop will be played out through the world, and you want to invalidate that hop
[18:40:00] <sandy> jeffh: since our signatures are on as connectivity...
[18:41:02] <sandy> randy: but if you have per-router key, you only have to change the effected routers
[18:41:38] <sandy> sandym: if you have more than one peering point, you only have to change the keys for the routers connected to the (former neighbor) AS, not all the routers in your AS
[18:41:59] <sandy> jeffh: but per router keys increase your memory requirements
[18:43:22] lepinski leaves the room
[18:43:24] <Randy Bush> for the visually-oriented remote participant(s), here are two pictures taken in the room http://archive.psg.com/120209.sidr-mtg/
[18:44:11] lepinski joins the room
[18:44:14] <sandy> sriram: if as1 is peering with as 2 and as 3 and today as1 advertises two /17s and tomorrow wants to advertise the aggregate /18. does that also create this the requirement to use per-router keys?
[18:45:15] <sandy> matt: i think the answer is: if you don't have beaconing, then you do have to re-key frequently. if your upstream has never caused problems beforee, maybe you are willing to let the more specifics stay around. local risk decision
[18:45:44] <sandy> matt: you are picking your own level of vulnerability by how often you rekey
[18:46:04] <Michael Elkins> Randy Bush: a fine looking bunch
[18:46:39] <sandy> stevek: can do make before break - can have simultaneous keys - lessen problem of how often people push and pull through rpki
[18:47:15] <weiler> sadly, the in-room net is too slow to download the pics.
[18:47:34] weiler leaves the room
[18:47:47] <sandy> stevek: if i am a big isp and i am not going to rely on the rir to do my certs etc, then i have my own publication point and people will be coming to me
[18:47:54] <sandy> stevek: and publication point has ways of making people come back for more updates - crl rate etc
[18:48:35] <sandy> stevek: smaller isps will be more effected - have to rely on rir (hosted model)
[18:49:08] <sandy> jeffh: what discussion has there been if any of a simple nlri type that runs through bgp system that says "please update, i've changed"
[18:49:15] <sandy> randy: will answer but slowly
[18:49:41] <sandy> randy: once upon a time to dns and it would be expected to take days to make it thorugh system
[18:50:20] <sandy> randy: expectation changed - added "notify" to dns - ask me for an update - instead of turning protocol around from pull to push
[18:50:56] weiler joins the room
[18:50:56] <sandy> randy: change to dns was similarly added to rpki-rtr (and serial numbers etc.)
[18:51:26] Jeffrey Haas leaves the room
[18:51:29] <sandy> randy: propagating through that part of system can be quick - delay will be in certification system (like updating zone files)
[18:52:07] Jeffrey Haas joins the room
[18:52:15] <sandy> randy :expectations changed and people have changed their operations. we can encourage people to change
[18:52:48] <sandy> sriram: if the propagation through rpki means is going to take a day - but we can beacon every 8 hours without too much trouble --
[18:53:43] <Sean Turner> btw that's matt on the phone
[18:53:46] <sandy> sriram: does it give peace of mind to people that expiry time is there to make a 10 hr interval achievable
[18:54:27] <sandy> matt: about yoru slides - was that a beacon of every 8 hrs? A: expiry time every 24 hrs, beaconing every 8 hrs.
[18:55:38] <Jason Schiller> Randy… can you change keys if there is a short term problem? especially if key roll over is easy, and can invalidate the previous key in the roll over?
[18:55:43] <sandy> randy: for protection on the order of a day, the rpki defense is good, i would feel more comfortable with beacons but the additional comfort is not work the additional discomfort of doing the beacons. if beacons can't handle the short time case, they aren't worth the trouble.
[18:55:57] <sandy> sriram: \<<<???>>>
[18:56:45] <sandy> rv: switching of peering relationshiops is not only immediately upstream of the originating AS, so that doesn't work
[18:57:17] <sandy> <<<think sriram was saying announcing a more specific would replace the stale aggregate>>
[18:57:25] Keyur Patel leaves the room
[18:57:46] Keyur Patel joins the room
[18:58:33] <sandy> dougm: that doesn't work because we are considering malicious ASs in the mix and they can just not propagate the update
[18:59:01] Keyur Patel leaves the room
[18:59:12] <sandy> randy: <<< something about running with credit cards>>>
[18:59:38] Jeffrey Haas leaves the room
[18:59:42] <sandy> wes: if you knew that a relationshiop was going bad, you could produce a new key ahead of time for when you flip the router
[18:59:42] Keyur Patel joins the room
[19:00:21] <Sean Turner> better than running with scissors
[19:00:32] Jeffrey Haas joins the room
[19:01:16] <sandy> sriram: if the human approach takes a day, and with ops training gives better response, other AS may not be so well trained - still wondering if that level of comfort is worth the beaconing. pain.
[19:03:55] <sandy> sriram: if the human level response is days, but the automated approach of beacons is hours or less, then it might be worth it to do the beacon.
[19:04:24] smb leaves the room
[19:04:36] <sandy> everyone in the jabber room who was speaking or listening carefully - please correct anything I type that is wrong
[19:04:44] <sandy> randy: about router keying
[19:04:54] <weiler> what time do we think we'll break? (advance warning may help hotel get people together for fixing the polycom)
[19:05:09] <sandy> randy: suppose keys are generated on routers and are not discoverable. i can not pull a ssh key off a router
[19:05:12] <heather.skanks> thought it was going to be now, but randy started in :)
[19:05:23] <weiler> ==heather
[19:05:42] Keyur Patel leaves the room
[19:06:15] Keyur Patel joins the room
[19:06:32] weiler leaves the room
[19:06:51] <sandy> randy: if i accept the public key (on a ssh connection where the key had changed??) and i look around the interfaces on the router - i might say that this looks like the router i expected - and that is the current weak trust model
[19:07:45] <sandy> randy: getting into pks7, pks10, details.
[19:08:18] <sandy> irandy: if i have a failure of a router engine in the field. painful to get it resurrected. adding pain of propagatign a new key into the rpki.
[19:09:09] <sandy> randy: want to push copy of old key onto blade. means key must exist offboard (either it was generated off router or pulled out of router). must be possible to push key into router
[19:09:43] <sandy> randy: so we have those two models of key management
[19:10:24] <morrowc> HANDUP: isn't this really just: "part of the normal reprovosioning process" which includes: "put full config on device" and could easily include: "scp cert rtr:pvt-storage" ??
[19:10:31] <morrowc> this doesn't sound like a giant PITA...
[19:10:36] <morrowc> it sounds like 'normal operations"
[19:10:50] <sandy> warren: key exists on usb key - could be used to transport key to and from router
[19:11:55] <sandy> randy: answer to Chris- just describing change to current model which does not presently include private keys
[19:12:01] <sandy> rv: this might be a good thing
[19:12:50] <morrowc> thnx
[19:13:12] <sandy> wesgeorge: this is a place where the security peole and the router people will intereect wehre they don't always interact. need some careful consideration of how this is handled.
[19:13:22] <wkumari@jabber.psg.com> BREAK!!!!
[19:13:35] Jeffrey Haas leaves the room
[19:13:39] <wkumari@jabber.psg.com> We'll be back at 11:30PST.
[19:13:44] <Stewart Bryant> 7.30 gmt
[19:13:49] <wkumari@jabber.psg.com> 14:30EST.
[19:13:53] <wkumari@jabber.psg.com> thank you.
[19:13:56] <Stewart Bryant> 19.30 GMT
[19:14:02] <Stewart Bryant> Time for tea
[19:14:51] <MIchael Sinatra> I have a conflict after 1130 PST but will try to be back later in the afternoon. This has been a great discussion, thanks,
[19:16:17] <morrowc> wow, nice music.
[19:16:26] <morrowc> you could turn down the volume of course.
[19:16:49] <morrowc> is this a ripe meeting?
[19:17:21] smb joins the room
[19:27:05] lepinski leaves the room
[19:27:43] lepinski joins the room
[19:28:56] Keyur Patel leaves the room
[19:28:57] Keyur Patel joins the room
[19:29:14] Sander Steffann leaves the room: Replaced by new connection
[19:29:17] Sander Steffann joins the room
[19:29:28] wkumari@jabber.psg.com leaves the room: Replaced by new connection
[19:29:31] wkumari@jabber.psg.com joins the room
[19:30:09] Sean Turner leaves the room
[19:30:24] Sean Turner joins the room
[19:36:10] sandy leaves the room
[19:36:12] brian.peter.dickson joins the room
[19:36:48] <Stewart Bryant> are we late on the restart, or have I lost audio?
[19:36:52] <brian.peter.dickson> Testing one two three?
[19:38:09] <heather.skanks> they are still on break
[19:38:15] <Stewart Bryant> Thanks
[19:38:54] <brian.peter.dickson> Just joined, had jabber issues, can someone please confirm my messages show up?
[19:41:01] Michael Elkins leaves the room
[19:41:23] <smb> Brian: I see your message
[19:41:37] <brian.peter.dickson> thanks
[19:42:52] weiler joins the room
[19:47:03] sandy joins the room
[19:49:06] lepinski leaves the room
[19:50:37] lepinski joins the room
[19:50:43] Keyur Patel leaves the room
[19:50:48] Keyur Patel joins the room
[19:52:40] <Stewart Bryant> I am
[19:53:02] <Stewart Bryant> Thank you
[19:53:32] <sandy> resuming meeting
[19:53:40] <brian.peter.dickson> Which is preferred - talking on the phone or jabbering?
[19:53:56] <Sean Turner> okay we're back on
[19:54:37] <Sean Turner> about to test the microphone/phone
[19:54:54] <Karen O'Donoghue> how's the audio?
[19:54:56] <Sean Turner> warren has just duct taped the phone to the speaker
[19:55:02] kvaradhan3 leaves the room
[19:55:02] <weiler> jabbering, BY FAR
[19:55:13] <ndg> not good.
[19:55:14] <weiler> can you hear?
[19:55:30] <ndg> the pre-break audio was much nicer.
[19:55:39] <Stewart Bryant> What sandy said was understandable to one with high freq loss - but not the best
[19:55:40] <brian.peter.dickson> ditto
[19:55:49] <Randy Bush> how about now?
[19:55:49] <weiler> we're asking about sandy's voice ONLY
[19:56:00] <weiler> ignore warren's voice.
[19:56:13] <Stewart Bryant> better
[19:56:13] <ndg> that's ok.
[19:56:13] <weiler> reports?
[19:56:15] <brian.peter.dickson> much better
[19:56:47] <Sean Turner> phone being taped to chair ...
[19:56:54] <Sean Turner> ;)
[19:56:57] <weiler> not being taped. trying to fall off.
[19:57:02] <ndg> send pic :-)
[19:57:07] <weiler> randy will.
[19:58:43] <Randy Bush> randy was not planning to do so
[19:59:31] <sandy> sandy: liked RussH's commnet about the threat model and whether we are throwing effort at the right problem
[20:00:19] <sandy> rv: throwing effort into beaconing and using router re-keying is possibly good - having multiple levels of protection
[20:00:44] <Sean Turner> multiple levels of protection = defense in depth
[20:01:07] <sandy> rv: goal of bgpsec is that knowing the as-path we got actually propagated through those ASs - that does not actually say that the path has not disappeared.
[20:01:28] <sandy> rv: failed links might be receiving traffic - handled by rpki well
[20:02:12] <sandy> rv: scenario that someone pulls a link and traffic gets diverted and diversion is not objvious to others
[20:02:22] <sandy> rv: would like to have second protection mechanism to cover that
[20:02:59] <sandy> randy: if the rpki is not correct, we have many more problems. have to assume that data you are getting from the rpki are sufficiently protected that you can rely on it.
[20:03:34] <sandy> randy: therefore slow threats if logically the rpki protects against them - no use in backing up the rpki because if the rpki is wrong you are dead anyway.
[20:03:35] Kannan V joins the room
[20:04:14] <sandy> randy: fast threats - minus pre-roll publication of key - beacons are not what you want to go through for fast threats
[20:04:39] <sandy> randy: beacons are more expensive the more often they are - you are running against the curve
[20:04:45] <brian.peter.dickson> Difficulty hearing audio now slightly
[20:04:55] <sandy> jeffh: not a case of the rpki is not correct, just that it has a time limit
[20:05:07] <sandy> randy: i can pre-roll publish the key
[20:05:28] <morrowc> 'get to da mic!!!'
[20:05:30] <sandy> jeffh: in make before break, you want the new keys handy.
[20:05:33] <Randy Bush> randy: i can pre-publish the key to which i will roll on change
[20:05:39] beginner0 joins the room
[20:05:46] <morrowc> because srsly, you are not audible on the audio call.
[20:05:59] <brian.peter.dickson> better, yes
[20:06:04] <morrowc> closer, get closer.
[20:06:08] <morrowc> and start over.
[20:06:22] <sandy> jeffh: freshness allows us to elimnate state in the system that has gotten stuck
[20:06:46] <sandy> jeffh: having freshness at low rate (one a day) helps eliminate state that is stuck
[20:07:17] <sandy> jeffh: when we want to react quickly - having pre-placed roll over keys would help that.
[20:07:29] beginner0 leaves the room
[20:07:41] <sandy> jeffh: having a notify ability - to get the people to know that there are new keys
[20:07:52] <brian.peter.dickson> meta-question - do you want jabber folks to talk over phone, or will someone speak what we type?
[20:08:08] <morrowc> warren relayed my question...
[20:08:12] <Randy Bush> jabber is relayed
[20:08:16] <morrowc> from here to the room/audio
[20:08:21] <brian.peter.dickson> okay
[20:08:38] <Randy Bush> we can not hear what remotes say in audio
[20:08:39] <sandy> dougm: problem is getting rid of old signatures - so not only whether the new key is out there but whether people have gotten the word that the old key is bad
[20:09:40] <sandy> stevek: as dougm said, it is the revocation that produces the effect of eliminating the bad state. but you could also control this by the lifetime of the cert.
[20:09:55] <sandy> rnady: you've created a new form of beacons
[20:10:13] dongtingyu joins the room
[20:10:32] <morrowc> i repeat: GET TO THE MIC
[20:10:35] <sandy> dougm: each router then has to regenerate the signature with the new signature with the new cert
[20:10:38] <morrowc> no one can hear you dougm
[20:10:42] <morrowc> (no one on the audio call)
[20:10:49] <sandy> russh: that implies that the signature expires when the cert expires
[20:10:54] <smb> For large values of "no one"
[20:11:08] <brian.peter.dickson> I think the problem is not the origin-specific signatures - RPKI - but rather the intermediate signatures
[20:11:12] <sandy> stevek: never mind, we should go back and talk this about it
[20:11:51] <heather.skanks> ha, we could have done a google hangout
[20:12:12] <sandy> warren: (could not parse what he was saying)
[20:12:20] <sandy> randy: THREAT MODELS
[20:12:32] <brian.peter.dickson> The whole system is presuming that every path heard on a prefix, by every RP, is presumed to be equally trusted or trustworthy
[20:12:41] <sandy> russh: agrees with Brian Dickson
[20:13:04] <brian.peter.dickson> Any place where that assumption could be violated is a place we need to address from the security weakness perspective
[20:13:27] <weiler> remotes could, of course, have a voice conversation among themselves. but we can't presently hear you.
[20:13:39] asonalker joins the room
[20:13:43] <weiler> we have some (minimal?) hope that audio will be better after lunch.
[20:15:28] <Jason Schiller> that was important.. and not sure I got it all
[20:15:50] <Sean Turner> here's what I got: The threat is (according to Randy) long term low frequency replay he's comfortable with rekey as the defencse. high/short frequency replay attacks that he does anticipate - he can do with rekey. high/high only solution so far is beaconing or it's equivalent. Randy's instinct is that the cost is too high.
[20:15:51] <Jason Schiller> Randy, can you type what you just said?
[20:15:59] <Randy Bush> ok. hang on
[20:16:02] <Jason Schiller> Sean thanks
[20:16:26] <brian.peter.dickson> off-axis injection of spoofed routes is the problem, where a single key exposure from a router, is an attack - this is the threat
[20:16:27] <Randy Bush> long / low frequency attacks, i am comfortable with post hoc rekeying
[20:16:38] Jeffrey Haas joins the room
[20:16:44] <brian.peter.dickson> steal one key, and be able to create fake paths
[20:17:13] <heather.skanks> thats *another* threat
[20:17:20] <brian.peter.dickson> ye
[20:17:21] <brian.peter.dickson> okay
[20:17:49] <Randy Bush> short/quick atacks fall into two classes, those i anticipate and pre-publish keys and roll on the policy change. those i do not anticipate, my instinct is that the cost of high freq beacons is not worth the benefit
[20:18:37] <Sean Turner> keeping the private key private is pretty much the corner stone of the whole system ;)
[20:19:52] <sandy> sandy: and any cryptographic system falls apart if the key is compromised. only design change that would remove that problem would be to remove any cryptographic protections.
[20:20:21] <dongtingyu> does rekeying mean changing the private/public key?
[20:20:39] <sandy> sriram: thinks that don't jitter and you rekey - all the 400K routes have to be resigned - a lot of burstiness
[20:21:03] <Randy Bush> @dongtingyu: yes
[20:21:07] <sandy> jeff: <something about a policy change or similar changes would produce same burstiness>
[20:21:20] <sandy> rv: think of link flapping
[20:22:04] <sandy> rv: i don't have a threat analysis of what stupid thing could be engineered - would be bad to rekey on each link flap
[20:22:19] <morrowc> (note that the conf call/audio just went silent)
[20:22:50] <brian.peter.dickson> okay from here, fyi
[20:22:55] <weiler> can you hear warren?
[20:23:00] <ndg> only warren seems clear somehow...
[20:23:19] <morrowc> err, usererror, phone call ended.
[20:23:21] <morrowc> brb
[20:23:34] <weiler> oops
[20:24:10] <sandy> jeffh: cases we are trying to protect are cases when we want to rekey - freshness (beaconing) would do this - rekey if we can ensure people use it
[20:24:28] <morrowc> back
[20:24:45] <brian.peter.dickson> what about flooding invalidation of keys that are being revoked, independent of strict topology of BGP "best path" logic?
[20:24:49] <sandy> jeffh: what warren said: can we do this like a rollover so as soon as you see key 2 you take key 1 out of the system
[20:25:06] <brian.peter.dickson> Separate the two reasons for withdraw - loss of link, vs actual policy change
[20:25:26] <sandy> stevek: without saying that would be a good idea, the validity period (not before A, not after B) should tell you when is mroe recent
[20:25:40] <sandy> jeffh: so you could stop using old key once you see new key
[20:25:55] <brian.peter.dickson> Yes, but you don't need rekey/beacon, and can reduce window to smallest possible value
[20:26:04] <sandy> seanturner: that is only if we decide to actually use this mechanism
[20:26:06] heather.skanks leaves the room
[20:26:12] dongtingyu leaves the room
[20:26:12] lepinski leaves the room
[20:26:17] Jeffrey Haas leaves the room
[20:26:43] lepinski joins the room
[20:26:53] <sandy> jeffh: getting this info from what the certs tell us about a key
[20:27:00] Jeffrey Haas joins the room
[20:27:01] <sandy> jeffh: if you see the same path with a new key...
[20:27:05] lepinski leaves the room
[20:27:27] <sandy> warren: if you see the same prefix, whatever the path, with a new key...
[20:27:44] <sandy> dougm: but then you are turning bgp into a flooding protocol
[20:27:46] lepinski joins the room
[20:27:58] <weiler> engineering guys in back of room got a dialtone!
[20:28:04] <sandy> dougm: this is like a sequence number
[20:28:33] <sandy> dougm: can we publish a months worth of router certificates and as soon as the day was over start using the new key
[20:28:55] dongtingyu joins the room
[20:29:16] <sandy> dougm: trying to get around the need to have the rpki react - preplace enough keys that rpki distribution will work
[20:29:43] weiler leaves the room
[20:29:51] weiler joins the room
[20:30:30] <sandy> jeffh: prepublishing doesn't help unless the key lifetime is short
[20:30:36] <sandy> randy: then you are rebeaconing again
[20:31:48] <Jason Schiller> you could pre-publish a moth's worth of keys (one per day) and also publish a few "emergency keys". the emergency key when used will invalidate and replace that day's key. And a new emergency key needs to be published.
[20:31:59] <sandy> jeffh: have to worry about the problem occuring in intermediate points - might be ok if only the origin could do this, but the origin is not the (only?) place we are trying to protect
[20:32:14] <brian.peter.dickson> You only need to invalidate signatures, not keys. Knowing that a signature is revoked is enough.
[20:32:46] <brian.peter.dickson> It is how to achieve that change of state, when all the rest of the statefulness of BGP is maintained and seen as "good", is IMHO the real objective
[20:33:22] <smb> It's a rare event because most folks are honest (enough) and value their business relationships. *But* not everyone is/cares.
[20:33:29] <sandy> warren: no protection against business relationships go bad - don't see that happeneing today - once or twice a year is probably all you would have to do this. not multiple times a day
[20:33:31] <brian.peter.dickson> Sender is the signer, and getting that revocation (of mid-path signature element) is the crux of the problem
[20:33:46] <sandy> jeffh: biggest problem has been misoriginating
[20:34:01] lepinski leaves the room
[20:34:05] <sandy> jeffh: munging path is reasonably protected by bgpsec
[20:34:25] Sebastian Becker joins the room
[20:34:30] <sandy> jeffh: not quite sure what we are protecting against now.
[20:34:44] <Randy Bush> accidental mis-orig is handled by origin validation. malicious can forge the origin and requires a signed origin to defend
[20:34:59] <brian.peter.dickson> the problem is not between adjacent parties, but when the parties are non-adjacent
[20:35:00] lepinski joins the room
[20:35:23] <brian.peter.dickson> a-b-c-d, b-c goes away, d is the one trying to replay for reasons of their own
[20:35:33] <sandy> warren: when business relationship goes south, before that happens - stop sending routes that way until all signed routes expire - then abandon agreement
[20:35:46] <sandy> jeffh: threat case of someone tryign to steal credit cards
[20:36:01] <brian.peter.dickson> The problem is when neither of the parties that were involved, is aware of the malicious activity
[20:36:05] <sandy> jeffh: malicious attacks - long freshness timers are not going to help us
[20:36:23] <sandy> jeffh: cyber war is another case
[20:37:21] <sandy> jeffh and rv agree with brian's comment
[20:37:25] <brian.peter.dickson> i.e. how do you even detect this?
[20:37:31] <sandy> rv: so there is no trigger for rekey
[20:38:10] <brian.peter.dickson> if you engineer this issue out of the picture, we should be much safer and happier
[20:38:40] Jason Schiller leaves the room
[20:39:41] <sandy> smb: this sort of attack is going to be rare but we won't be able to predict them (as reported thru warren)
[20:42:36] wkumari@jabber.psg.com leaves the room
[20:42:42] <brian.peter.dickson> can't hear sandy
[20:43:13] <brian.peter.dickson> Yes please
[20:43:24] <brian.peter.dickson> Yes
[20:43:30] lepinski leaves the room
[20:43:35] <brian.peter.dickson> sandy?
[20:43:40] weiler leaves the room
[20:43:43] <brian.peter.dickson> hello?
[20:43:46] <brian.peter.dickson> yes
[20:43:58] <brian.peter.dickson> yes i am
[20:43:59] <morrowc> yes
[20:44:07] <brian.peter.dickson> want to re-iterate one comment above...
[20:44:11] Sebastian Becker leaves the room
[20:44:22] <brian.peter.dickson> You only need to invalidate signatures, not keys. Knowing that a signature is revoked is enough.
[20:44:27] <smb> Sandy: about how long will the lunch break be?
[20:44:36] Jeffrey Haas leaves the room
[20:44:46] <brian.peter.dickson> Flooding that out via multiple paths is important
[20:44:58] <brian.peter.dickson> sign the revoked signature
[20:44:59] Sebastian Becker joins the room
[20:45:07] Keyur Patel leaves the room
[20:45:12] <brian.peter.dickson> different message type
[20:45:26] <brian.peter.dickson> yep
[20:45:42] Jeffrey Haas joins the room
[20:45:44] <brian.peter.dickson> in-band via BGP, or out-of-band
[20:45:47] Randy Bush leaves the room
[20:45:59] <brian.peter.dickson> randy - repeat louder?
[20:45:59] Sander Steffann leaves the room
[20:46:32] <brian.peter.dickson> Looks like an LSP thingy
[20:46:55] Sebastian Becker leaves the room
[20:46:56] Karen O'Donoghue leaves the room
[20:46:58] <smb> We could probably come up with a mechanism, but it could mean the need to revoke many signatures if the bad guy keeps misbehaving.
[20:47:19] chwhitey leaves the room
[20:47:28] <Stewart Bryant> However a draft of two might move things on
[20:47:40] <brian.peter.dickson> ignore revocations that do not agree with signatures on validated BGP messages
[20:48:07] <brian.peter.dickson> drafts are expected to follow once discussion is done...
[20:48:08] <Stewart Bryant> 2200GMT
[20:48:11] <brian.peter.dickson> thanks
[20:48:27] Jeffrey Haas leaves the room
[20:48:31] <Stewart Bryant> Drafts are a good way of gelling the discussion
[20:48:40] <brian.peter.dickson> agreed
[20:49:02] ndg leaves the room
[20:50:39] <brian.peter.dickson> Signature revocation (of individual signatures in the signature block of BGPSEC message) is currently there, but implicit only. Withdraw a route, the set of signatures is either withdrawn, or perhaps cached (which would be an error if we want to avoid replay)
[20:51:34] <brian.peter.dickson> a new message type, of "here is a signature I would like you to no longer honor", which is signed by the original signer, using current or next key, is just another "blob" that is signed.
[20:51:51] <brian.peter.dickson> the semantics of it are clear, so I don't know why there is any issue with it being "new".
[20:52:05] <brian.peter.dickson> It is the same as the content or semantic content at least, of a CRL
[20:52:41] <brian.peter.dickson> except that this is the in-band keys (router keys) rather than RPKI keys
[20:56:24] <sandy> brian: about "sandy speak louder" - not sure what you missed. there were comments in the room that we have no known signature revocation system - ie brand new security feature, pushing security boundary, not sidr job. also, need to consider how signature revocation is semantically different from revoking cert.
[20:56:45] <brian.peter.dickson> see my last five messages... ;-)
[20:57:48] <brian.peter.dickson> When you revoke a signature, you are instructing anyone who has received a BGPSEC update message which includes that signature in their signature block, to treat it as EVIL and discard.
[20:58:12] dongtingyu leaves the room
[20:58:57] <brian.peter.dickson> You need to flood that since you are presuming the update path to potentially be compromised by malicious parties (who withhold updates). As long as there exists one channel over which the flooded revocation reaches the listener, all is good.
[20:59:38] <brian.peter.dickson> This even works for "stub x 2" edge networks. They cancel one upstream, flood the revocations via the other upstream. Sorted.
[21:00:05] <brian.peter.dickson> Much better Sandy!!!
[21:04:46] Randy Bush joins the room
[21:08:39] Sean Turner leaves the room
[21:11:06] Randy Bush leaves the room
[21:31:23] Jason Schiller joins the room
[21:31:25] Jason Schiller leaves the room
[21:31:39] asonalker leaves the room
[21:31:55] asonalker joins the room
[21:32:35] smb leaves the room
[21:33:14] Jason Schiller joins the room
[21:33:36] smb joins the room
[21:39:08] asonalker leaves the room
[21:40:03] asonalker joins the room
[21:43:27] ejk leaves the room
[21:45:03] Jeffrey Haas joins the room
[21:45:09] Jeffrey Haas leaves the room
[21:45:46] sandy leaves the room
[21:53:01] dongtingyu joins the room
[21:55:30] <dongtingyu> @brian I think the downside was that you can't guarantee the revocation will find its way around
[21:55:58] <dongtingyu> and that an AS, by policy, may even choose to use the EVIL stuff
[21:57:59] <brian.peter.dickson> Hmm... there is a further problem - replaying AFTER the revocation, isn't prevented per se, unless revocations are cached.
[21:58:51] <brian.peter.dickson> All of this points to use of out-of-band for both revocations and signatures - it removes the replay capability, and keeps things stateful, with the sender having the ability to revoke previous signatures
[21:59:22] <brian.peter.dickson> An AS using EVIL and passing the EVIL along, means the next guy needs to know that it is EVIL.
[22:02:26] <brian.peter.dickson> Re-keying is using a hand grenade to kill a fly, in the instance of a single prefix being filtered out (and thus wanting a single signature to be revoked)
[22:03:42] <brian.peter.dickson> In the case of nobody being EVIL, and all the withdraw messages being honored, the revocations get ignored since there are no signatures that match (having already been discarded by the withdraw)
[22:03:46] Randy Bush joins the room
[22:07:03] Sander Steffann joins the room
[22:08:32] dongtingyu leaves the room
[22:08:38] Sebastian Becker joins the room
[22:10:06] sandy joins the room
[22:10:25] Sebastian Becker leaves the room
[22:10:56] Sebastian Becker joins the room
[22:11:09] dongtingyu joins the room
[22:11:39] Karen O'Donoghue joins the room
[22:11:45] <brian.peter.dickson> a little louder please?
[22:12:03] <Karen O'Donoghue> just starting...
[22:12:13] Keyur Patel joins the room
[22:12:29] wkumari@jabber.psg.com joins the room
[22:13:58] <wkumari@jabber.psg.com> Just FYI (for those not on the voice): WE ARE BACK.
[22:14:40] weiler joins the room
[22:16:03] <brian.peter.dickson> cannot hear speaker
[22:16:41] <wkumari@jabber.psg.com> Ca you now?
[22:16:44] <Randy Bush> can you hear ow?
[22:16:52] <brian.peter.dickson> okay
[22:17:41] chwhitey joins the room
[22:18:40] Jeffrey Haas joins the room
[22:19:10] <wkumari@jabber.psg.com> Dongting presentation.
[22:19:45] <wkumari@jabber.psg.com> "Empirical)Analysis)of)Route)Leaks"
[22:20:10] <wkumari@jabber.psg.com> Slide 2: Confirmed)route)leaks
[22:21:28] morrowc leaves the room
[22:21:51] <wkumari@jabber.psg.com> Slide 3: Findings
[22:22:14] <wkumari@jabber.psg.com> Slide 4: Findings (again)
[22:23:39] dongtingyu leaves the room
[22:24:49] <smb> Justice Potter Stewar, U.S. Supreme Court: "I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it <http://en.wikipedia.org/wiki/I_know_it_when_I_see_it>, and the motion picture involved in this case is not that." (in Jacobellis v. Ohio, 378 U.S. <http://en.wikipedia.org/wiki/United_States_Reports> 184 <http://supreme.justia.com/us/378/184/case.html> (1964))
[22:25:08] <smb> s/Stewar/Stewart/
[22:25:39] <wkumari@jabber.psg.com> Slide 5: Affected)prefixes
[22:27:21] heather.skanks joins the room
[22:27:32] <wkumari@jabber.psg.com> Slide 6: Affected)ASes
[22:27:52] Sebastian Becker leaves the room
[22:28:29] Jeffrey Haas leaves the room
[22:28:38] Sebastian Becker joins the room
[22:28:55] Jeffrey Haas joins the room
[22:30:24] <wkumari@jabber.psg.com> Slide 7: Update'frequency'of'affected'prefixes
[22:30:33] MIchael Sinatra leaves the room
[22:30:53] Jeffrey Haas leaves the room
[22:31:10] Sebastian Becker leaves the room
[22:32:17] <wkumari@jabber.psg.com> Slide 8: Update'frequency'of'affected'prefixes (again)
[22:32:25] Jeffrey Haas joins the room
[22:32:33] <wkumari@jabber.psg.com> Slide 9: Update'frequency'of'affected'prefixes (again)
[22:32:50] <wkumari@jabber.psg.com> Slide 10: Update'frequency'of'affected'prefixes
[22:34:13] <wkumari@jabber.psg.com> Slide 11: Peak'57minute'interval'update'frequencies
[22:34:41] <wkumari@jabber.psg.com> Slide12: Number'of'ASNs'that'had'their'originated'prefix'changed
[22:35:20] Sean Turner joins the room
[22:35:30] <Sean Turner> ah jabber
[22:35:36] <wkumari@jabber.psg.com> Slide 13: Discussion
[22:35:51] Sander Steffann leaves the room: Replaced by new connection
[22:35:53] Sander Steffann joins the room
[22:36:49] Jeffrey Haas leaves the room
[22:36:50] Sebastian Becker joins the room
[22:37:06] <wkumari@jabber.psg.com> Jabberites — how is the audio for you?
[22:37:45] Jeffrey Haas joins the room
[22:38:41] Jeffrey Haas leaves the room
[22:39:26] <Jason Schiller> people sound a little distant
[22:39:31] <Jason Schiller> but audable
[22:39:56] <wkumari@jabber.psg.com> Better?
[22:39:58] <wkumari@jabber.psg.com> :-P
[22:40:21] Jeffrey Haas joins the room
[22:40:35] <Jason Schiller> yes
[22:41:57] MIchael Sinatra joins the room
[22:45:18] dongtingyu joins the room
[22:45:43] <wkumari@jabber.psg.com> SIDR-4
[22:46:02] Sebastian Becker leaves the room
[22:46:12] <wkumari@jabber.psg.com> Slide 2: Is This a Route Leak?
[22:46:38] <wkumari@jabber.psg.com> Slide 3: Is This a Route Leak
[22:46:40] Sebastian Becker joins the room
[22:47:12] <Jeffrey Haas> http://tools.ietf.org/html/rfc4271#section-9.2.2.2 for those who care to discuss post-session.
[22:47:35] <wkumari@jabber.psg.com> Slide 4: Is This a Route Leak?
[22:47:53] <wkumari@jabber.psg.com> Slide 5: Is This a Route Leak
[22:48:06] <wkumari@jabber.psg.com> S;lide 6:
[22:48:12] <wkumari@jabber.psg.com> Slide 7
[22:48:21] <wkumari@jabber.psg.com> Slide 8
[22:48:29] <wkumari@jabber.psg.com> Slide 9
[22:48:35] <wkumari@jabber.psg.com> Slide 10
[22:48:38] <wkumari@jabber.psg.com> Slide 11
[22:51:29] <Jason Schiller> Warren: the intention under question is the customer intention, which thier transit provider should honor (Or they should get a new ISP)
[22:53:09] <brian.peter.dickson> The relationship between two ASes is something that cannot be asserted unilaterally, but rather is something they have to agree on. Cust->Transit is only possible if both agree that that is the case.
[22:53:38] <brian.peter.dickson> If you have the relationships established on the BGP session level, and can use that info, valley-free is possible.
[22:54:48] <brian.peter.dickson> The trust model of info can be handled if the presence of info is an assertion of cust-transit, and absence implies otherwise. Stripping at exit (towards customers or peers) may be enough.
[22:55:06] Jeffrey Haas leaves the room
[22:55:07] Kannan Varadhan joins the room
[22:55:27] <brian.peter.dickson> If things are valley-free, there can be only one "apex" where apex is a true apex or a peering link.
[22:55:29] Jason Schiller leaves the room
[22:55:46] <brian.peter.dickson> Count the peer/apex links. If it is more than one, it is a leak.
[22:55:48] Jeffrey Haas joins the room
[22:56:11] <brian.peter.dickson> Downhill implies the top of the hill is automatically an apex (i.e. originated by the transit provider)
[22:58:23] lepinski joins the room
[22:58:24] Jason Schiller joins the room
[22:58:39] asonalker leaves the room
[22:58:50] Sebastian Becker leaves the room
[22:59:05] asonalker joins the room
[22:59:24] Sebastian Becker joins the room
[23:01:22] <brian.peter.dickson> There are too many ASNs in the world now - sensible defaults and safeties are necessary
[23:02:02] <brian.peter.dickson> It should be possible for someone to shoot themselves in the head or the foot, but it should require the operator to turn the safeties off
[23:02:03] lepinski leaves the room
[23:02:17] Jason Schiller leaves the room
[23:02:24] lepinski joins the room
[23:02:54] <brian.peter.dickson> Valley free is always enforceable and possible, as long as the non-standard relationship is treated as a "special" but that is never the default, and only possible if both sides agree
[23:03:07] <brian.peter.dickson> It cannot be done without BGPSEC to enforce this
[23:03:37] <brian.peter.dickson> since the BGP paths and valley-free are tail-wagging-dog
[23:03:40] <brian.peter.dickson> situations
[23:04:20] Randy Bush leaves the room
[23:04:38] Randy Bush joins the room
[23:04:59] dongtingyu leaves the room
[23:07:06] <brian.peter.dickson> If the policy issue in generally can be described well (customer/transit, peer, other), the valley-free rule is all that is needed to prevent route leaks.
[23:08:11] dongtingyu joins the room
[23:09:08] <brian.peter.dickson> Here's the reason I think BGPSEC is necessary for this - if the relationship is established at origin via RPKI, and kept in such a way as to encode cust->transit as it crosses boundaries, it is clear to all whether the rules are broken. However, without signing the update, the state information (cust->transit) can be overwritten or stripped.
[23:10:02] Keyur Patel leaves the room
[23:10:23] <brian.peter.dickson> peer-peer is a valley
[23:10:37] <Randy Bush> bullshit
[23:10:58] wkumari@jabber.psg.com leaves the room: Replaced by new connection
[23:11:02] wkumari@jabber.psg.com joins the room
[23:11:02] <brian.peter.dickson> sorry, mean apex, but with limit of one apex per path.
[23:11:09] <brian.peter.dickson> peer-peer-peer is two apexes
[23:12:18] <Stewart Bryant> Hm - I now seem to be webex host - not sure that is safe on my flaky vnp link to my house
[23:12:19] <brian.peter.dickson> The idea that relationship data is kept only within the client->transit part of the graph. Strip on exit allows the transit to hide the relationship
[23:12:50] <brian.peter.dickson> absence of evidence of relationship means we have hit one apex, and cannot pass to a peer or transit provider
[23:12:58] <Stewart Bryant> can some get sandy to get back into webex so I can give host back?
[23:13:43] <Stewart Bryant> tks
[23:13:48] <brian.peter.dickson> exceptions can be handled by "exception", with treated as mutual transit (all the rest of the rules mutually apply)
[23:13:51] <wkumari@jabber.psg.com> Trying...
[23:14:05] <Stewart Bryant> sandy now host again
[23:14:19] <wkumari@jabber.psg.com> Internet access went bye bye (we were using my MiFi type thing, the battery finally went away...)
[23:14:48] <brian.peter.dickson> Let me answer that if I may...
[23:15:31] <brian.peter.dickson> If there is the colored area with special, the rules don't apply, and leaks cannot be stopped on the first AS hop, but can be stopped on the second AS hop.
[23:15:37] <brian.peter.dickson> This won't stop every leak
[23:15:52] <brian.peter.dickson> it will stop any leak going more than one AS hop - which is 99.9999% of the problem
[23:16:04] sandy leaves the room
[23:18:55] Randy Bush leaves the room
[23:19:06] Randy Bush joins the room
[23:19:46] <brian.peter.dickson> If the exact mirror of signatures is kept on path, and upstream_path with both being required for sending to transit ASNs, then the removal of a signature is all that is needed. The absence of a signature cannot be forged except by someone with the originator's keys, which by definition would allow the evil guy to inject forged routes
[23:20:23] <brian.peter.dickson> (removal of the second signature on upstream_path is what is done on sending to peer or customer)
[23:20:25] <Jeffrey Haas> I think the real problem is defining the coloring problem.
[23:20:41] <Jeffrey Haas> This needs to not only be on a per-AS basis, but potentially per prefix
[23:20:51] <Jeffrey Haas> It *is* something that can be semantically defined.
[23:20:53] <wkumari@jabber.psg.com> Decl 7: Dealing with Route :eals
[23:20:56] <brian.peter.dickson> yep
[23:21:04] <wkumari@jabber.psg.com> "Route Leaks Defined"
[23:21:10] <Jeffrey Haas> And in the simple degenerate case of transit behaviors at the AS level, it's easy
[23:21:11] <wkumari@jabber.psg.com> The $1M Question
[23:21:32] <Jeffrey Haas> The per-prefix case is not pretty.
[23:21:39] <wkumari@jabber.psg.com> And now ... Discuss
[23:21:46] <Jeffrey Haas> I'd suggest considering the RPSL case.
[23:21:55] <Jeffrey Haas> It leads to some very ugly conclusions.
[23:22:28] <brian.peter.dickson> signatures are done per-prefix, so applying per-AS rules using signatures is exactly the same level of pretty/ugly
[23:22:49] <Jeffrey Haas> no, because the transitive relationships must be defined at multiple levels
[23:23:09] lepinski leaves the room
[23:23:23] Jason Schiller joins the room
[23:23:30] <wkumari@jabber.psg.com> Please make it clear when you want something asked on mic….
[23:23:30] <Jeffrey Haas> if you have AS path A B C, A must enforce B's policies as well.
[23:23:37] lepinski joins the room
[23:23:43] <wkumari@jabber.psg.com> I feel that te current is a side cnversation...
[23:23:50] <Jeffrey Haas> indeed
[23:23:54] <brian.peter.dickson> it has nothing to do with BGP semantics, it is a policy enforcement thing. It sits above the protocol per se, but can only be implemented at the protocol level - it involves third/forth parties
[23:24:02] <brian.peter.dickson> Okay
[23:24:08] <Jeffrey Haas> it can be implemented as policy
[23:24:18] <Jeffrey Haas> enforcement at protocol level is untenable, imo.
[23:24:21] <wkumari@jabber.psg.com> Thanks…
[23:24:42] <Jeffrey Haas> I'm happy to have good counterexamples.
[23:24:43] <Stewart Bryant> I think that you should give IDR some help by writing some of this up
[23:25:05] <brian.peter.dickson> At mic please: if BGPSEC passes on this, BGPSEC may be seen by operators as a non-starter
[23:25:32] <Randy Bush> might be. might not be. i personally do not think so.
[23:26:38] <brian.peter.dickson> at mic please - we may be better served by deferring evaluating this, until the cost is understood, e.g. some definition or implementation or draft is produced. Too early now.
[23:27:35] <wkumari@jabber.psg.com> waiting inline
[23:28:05] Sebastian Becker leaves the room
[23:28:21] <Randy Bush> you have more faith in idr defining, detecting, and protecting against route leaks than i. and withot that faith, i see no reason to serialize on it.
[23:28:37] <heather.skanks> it can be enforced at a layer other than protocol.. but it involves lawyers
[23:30:04] Karen O'Donoghue leaves the room
[23:31:56] <brian.peter.dickson> didn't say useless, but less likely to gain enough tractino
[23:32:23] <brian.peter.dickson> The problem REALLY is that as currently defined, BGPSEC requires near-universal adoption to be useful, there is no incremental path signing
[23:34:31] <brian.peter.dickson> Let me try to use one-line ascii art to demonstrate the uphill-apex-downhill signatures that I think will work:
[23:36:04] <brian.peter.dickson> (a+b) - (aa+bb) - (aaa+bbbb) - (aaaa) - (aaaaa) - where sigs "aaa" mean path sig of length 3, and "bbb" is uphill sig of length 3. Stripping b* means passing apex, and bbbbb cannot be forged. Absence of bbbbb means "send to customers only".
[23:37:22] <Jeffrey Haas> IMO, as-diameter isn't terribly helpful.
[23:37:34] <Jeffrey Haas> at least for this.
[23:37:59] <Jeffrey Haas> it may help for traffic attraction, but not for accidental transit
[23:38:23] <Jeffrey Haas> also, that's a bunch of sigs. :-)
[23:38:32] <brian.peter.dickson> If the "bits" to define "not a leak" cannot be protect via BGPSEC, it won't work, but as long as whatever anti-leak stuff is protected, then it may work. What we need to understand is, it will come back to BGPSEC eventually. If we can do it now, it gets us there faster.
[23:38:36] sandy joins the room
[23:38:55] <Jeffrey Haas> I believe that the bits are already there.
[23:39:02] <Jeffrey Haas> we have a prefix, and a policy
[23:39:07] Sebastian Becker joins the room
[23:39:43] <brian.peter.dickson> The decision to strip "bbbbbb" is handled if/when neighbors are not cust->transit, by their mutually agreed assertion. Once stripped, it stays stripped.
[23:40:00] <brian.peter.dickson> The "policy" is just one-apex.
[23:41:13] <brian.peter.dickson> The two-transit stub can leak and that will pass BGPSEC validation. What I am suggesting is adding the second signature block to assert (or not) cust->transit
[23:41:48] <brian.peter.dickson> Whatever is used for route-leak prevention MUST MUST MUST be mandatory. E.g. select what your relationship is - peer/peer, cust->transit, or "special".
[23:42:07] <brian.peter.dickson> RPSL is not mandatory, so unless we add mandatory RPSL to RPKI, it won't work.
[23:43:03] <brian.peter.dickson> one-apex (with "special" being treated kind of like confederations of mutual transit, as an upper limit of what is allowed to be announced), should be enough
[23:43:39] <Jeffrey Haas> I don't insist on rpsl. I'm just saying it is expressive enough to show what the solution will look like.
[23:46:33] <brian.peter.dickson> So, let me attempt to suggest the following: maybe the suggestion I have won't solve route leaks, but I don't think it breaks any known scenarios where it stops announcements between consenting adults.
[23:46:59] <Sean Turner> stewart still there?
[23:47:08] <Stewart Bryant> I am here
[23:47:22] <brian.peter.dickson> The machinery I suggest using, is exactly identical - two signatures using the exact same functions and semantics, except when crossing to peers or customers.
[23:47:33] <brian.peter.dickson> (where they get stripped).
[23:47:52] <Stewart Bryant> I think that the first step is to write down problem so that those outside he mtg can undestand the point where you got to
[23:48:06] <brian.peter.dickson> It is easy to implement, is what I am saying, and either works or is harmless.... Can we do it on an experimental basis, and if it doesn't work, chuck it out?
[23:48:12] <Jeffrey Haas> I agree. I'm only following ~50% of Brian's specific solution suggestion.
[23:48:19] <Randy Bush> stewart: room agrees
[23:48:25] <Jeffrey Haas> but the additional crypto sounds scary
[23:48:25] <brian.peter.dickson> Cool. Will write it down.
[23:48:36] <Stewart Bryant> Then we can figure out how to take the problem forward
[23:48:39] <weiler> brian: thank you.
[23:49:15] dougm.work joins the room
[23:52:03] <brian.peter.dickson> Can the room review the during-lunch stuff I jabbered on, maybe? Out-of-band allows things in-band cannot, fundamentally - e.g. revoke signatures rather than keys, and cache those revocations
[23:52:21] Paul Hoffman leaves the room
[23:52:25] <Jeffrey Haas> I believe it will go to the list.
[23:52:27] <brian.peter.dickson> scales much better, and shrinks the real-world window to seconds.
[23:52:29] <brian.peter.dickson> Yep
[23:53:36] <wkumari@jabber.psg.com> Brian: I don't see this discussion in the room. Can toy repoaste?
[23:54:14] <brian.peter.dickson> Sure, just a sec
[23:54:22] Keyur Patel joins the room
[23:55:27] <brian.peter.dickson> sorry, about to spam ton of messages....
[23:55:38] Jeffrey Haas leaves the room
[23:55:42] <brian.peter.dickson> want to re-iterate one comment above...
sebastian.oliver.becker@googlemail.com <mailto:sebastian.oliver.becker@googlemail.com> has left this chat.
You only need to invalidate signatures, not keys. Knowing that a signature is revoked is enough.
Sandy: about how long will the lunch break be?
smb@jabber.psg.com <mailto:smb@jabber.psg.com>
malleus.errata@gmail.com <mailto:malleus.errata@gmail.com> has left this chat.
Flooding that out via multiple paths is important
sign the revoked signature
sebastian.oliver.becker@googlemail.com <mailto:sebastian.oliver.becker@googlemail.com> has joined this chat.
keyupate@cisco.com <mailto:keyupate@cisco.com> has left this chat.
different message type
yep
malleus.errata@gmail.com <mailto:malleus.errata@gmail.com> has joined this chat.
in-band via BGP, or out-of-band
randy@jabber.psg.com <mailto:randy@jabber.psg.com> has left this chat.
randy - repeat louder?
sjms@jabber.no <mailto:sjms@jabber.no> has left this chat.
Looks like an LSP thingy
sebastian.oliver.becker@googlemail.com <mailto:sebastian.oliver.becker@googlemail.com> has left this chat.
odonoghue@jabber.isoc.org <mailto:odonoghue@jabber.isoc.org> has left this chat.
We could probably come up with a mechanism, but it could mean the need to revoke many signatures if the bad guy keeps misbehaving.
smb@jabber.psg.com <mailto:smb@jabber.psg.com>
chwhitey@gmail.com <mailto:chwhitey@gmail.com> has left this chat.
However a draft of two might move things on
stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>
ignore revocations that do not agree with signatures on validated BGP messages
drafts are expected to follow once discussion is done...
2200GMT
stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>
thanks
malleus.errata@gmail.com <mailto:malleus.errata@gmail.com> has left this chat.
Drafts are a good way of gelling the discussion
stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>
agreed
nishal@afrinic.net <mailto:nishal@afrinic.net> has left this chat.
Signature revocation (of individual signatures in the signature block of BGPSEC message) is currently there, but implicit only. Withdraw a route, the set of signatures is either withdrawn, or perhaps cached (which would be an error if we want to avoid replay)
a new message type, of "here is a signature I would like you to no longer honor", which is signed by the original signer, using current or next key, is just another "blob" that is signed.
the semantics of it are clear, so I don't know why there is any issue with it being "new".
It is the same as the content or semantic content at least, of a CRL
except that this is the in-band keys (router keys) rather than RPKI keys
3:56 PM
brian: about "sandy speak louder" - not sure what you missed.  there were comments in the room that we have no known signature revocation system - ie brand new security feature, pushing security boundary, not sidr job.  also, need to consider how signature revocation is semantically different from revoking cert.
sandy@jabber.psg.com <mailto:sandy@jabber.psg.com>
see my last five messages... ;-)
When you revoke a signature, you are instructing anyone who has received a BGPSEC update message which includes that signature in their signature block, to treat it as EVIL and discard.
dongtingyu@gmail.com <mailto:dongtingyu@gmail.com> has left this chat.
You need to flood that since you are presuming the update path to potentially be compromised by malicious parties (who withhold updates). As long as there exists one channel over which the flooded revocation reaches the listener, all is good.
This even works for "stub x 2" edge networks. They cancel one upstream, flood the revocations via the other upstream. Sorted.
Much better Sandy!!!
4:04 PM
randy@jabber.psg.com <mailto:randy@jabber.psg.com> has joined this chat.
4:08 PM
spturner@jabber.org <mailto:spturner@jabber.org> has left this chat.
randy@jabber.psg.com <mailto:randy@jabber.psg.com> has left this chat.
4:31 PM
jschiller@google.com <mailto:jschiller@google.com> has joined this chat.
jschiller@google.com <mailto:jschiller@google.com> has left this chat.
asonalker@jabber.org <mailto:asonalker@jabber.org> has left this chat.
asonalker@jabber.org <mailto:asonalker@jabber.org> has joined this chat.
smb@jabber.psg.com <mailto:smb@jabber.psg.com> has left this chat.
jschiller@google.com <mailto:jschiller@google.com> has joined this chat.
smb@jabber.psg.com <mailto:smb@jabber.psg.com> has joined this chat.
4:39 PM
asonalker@jabber.org <mailto:asonalker@jabber.org> has left this chat.
asonalker@jabber.org <mailto:asonalker@jabber.org> has joined this chat.
4:43 PM
ejk@cisco.com <mailto:ejk@cisco.com> has left this chat.
malleus.errata@gmail.com <mailto:malleus.errata@gmail.com> has joined this chat.
malleus.errata@gmail.com <mailto:malleus.errata@gmail.com> has left this chat.
sandy@jabber.psg.com <mailto:sandy@jabber.psg.com> has left this chat.
4:53 PM
dongtingyu@gmail.com <mailto:dongtingyu@gmail.com> has joined this chat.
@brian I think the downside was that you can't guarantee the revocation will find its way around
dongtingyu@gmail.com <mailto:dongtingyu@gmail.com>
and that an AS, by policy, may even choose to use the EVIL stuff
dongtingyu@gmail.com <mailto:dongtingyu@gmail.com>
Hmm... there is a further problem - replaying AFTER the revocation, isn't prevented per se, unless revocations are cached.
All of this points to use of out-of-band for both revocations and signatures - it removes the replay capability, and keeps things stateful, with the sender having the ability to revoke previous signatures
An AS using EVIL and passing the EVIL along, means the next guy needs to know that it is EVIL.
5:02 PM
Re-keying is using a hand grenade to kill a fly, in the instance of a single prefix being filtered out (and thus wanting a single signature to be revoked)
In the case of nobody being EVIL, and all the withdraw messages being honored, the revocations get ignored since there are no signatures that match (having already been discarded by the withdraw)
[23:56:09] <brian.peter.dickson> want to re-iterate one comment above...
sebastian.oliver.becker@googlemail.com <mailto:sebastian.oliver.becker@googlemail.com> has left this chat.
You only need to invalidate signatures, not keys. Knowing that a signature is revoked is enough.
Sandy: about how long will the lunch break be?
smb@jabber.psg.com <mailto:smb@jabber.psg.com>
malleus.errata@gmail.com <mailto:malleus.errata@gmail.com> has left this chat.
Flooding that out via multiple paths is important
sign the revoked signature
sebastian.oliver.becker@googlemail.com <mailto:sebastian.oliver.becker@googlemail.com> has joined this chat.
keyupate@cisco.com <mailto:keyupate@cisco.com> has left this chat.
different message type
yep
malleus.errata@gmail.com <mailto:malleus.errata@gmail.com> has joined this chat.
in-band via BGP, or out-of-band
randy@jabber.psg.com <mailto:randy@jabber.psg.com> has left this chat.
randy - repeat louder?
sjms@jabber.no <mailto:sjms@jabber.no> has left this chat.
Looks like an LSP thingy
sebastian.oliver.becker@googlemail.com <mailto:sebastian.oliver.becker@googlemail.com> has left this chat.
odonoghue@jabber.isoc.org <mailto:odonoghue@jabber.isoc.org> has left this chat.
We could probably come up with a mechanism, but it could mean the need to revoke many signatures if the bad guy keeps misbehaving.
smb@jabber.psg.com <mailto:smb@jabber.psg.com>
chwhitey@gmail.com <mailto:chwhitey@gmail.com> has left this chat.
However a draft of two might move things on
stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>
ignore revocations that do not agree with signatures on validated BGP messages
drafts are expected to follow once discussion is done...
2200GMT
stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>
thanks
malleus.errata@gmail.com <mailto:malleus.errata@gmail.com> has left this chat.
Drafts are a good way of gelling the discussion
stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>
agreed
nishal@afrinic.net <mailto:nishal@afrinic.net> has left this chat.
Signature revocation (of individual signatures in the signature block of BGPSEC message) is currently there, but implicit only. Withdraw a route, the set of signatures is either withdrawn, or perhaps cached (which would be an error if we want to avoid replay)
a new message type, of "here is a signature I would like you to no longer honor", which is signed by the original signer, using current or next key, is just another "blob" that is signed.
the semantics of it are clear, so I don't know why there is any issue with it being "new".
It is the same as the content or semantic content at least, of a CRL
except that this is the in-band keys (router keys) rather than RPKI keys
3:56 PM
brian: about "sandy speak louder" - not sure what you missed.  there were comments in the room that we have no known signature revocation system - ie brand new security feature, pushing security boundary, not sidr job.  also, need to consider how signature revocation is semantically different from revoking cert.
sandy@jabber.psg.com <mailto:sandy@jabber.psg.com>
see my last five messages... ;-)
When you revoke a signature, you are instructing anyone who has received a BGPSEC update message which includes that signature in their signature block, to treat it as EVIL and discard.
dongtingyu@gmail.com <mailto:dongtingyu@gmail.com> has left this chat.
You need to flood that since you are presuming the update path to potentially be compromised by malicious parties (who withhold updates). As long as there exists one channel over which the flooded revocation reaches the listener, all is good.
This even works for "stub x 2" edge networks. They cancel one upstream, flood the revocations via the other upstream. Sorted.
Much better Sandy!!!
4:04 PM
randy@jabber.psg.com <mailto:randy@jabber.psg.com> has joined this chat.
4:08 PM
spturner@jabber.org <mailto:spturner@jabber.org> has left this chat.
randy@jabber.psg.com <mailto:randy@jabber.psg.com> has left this chat.
4:31 PM
jschiller@google.com <mailto:jschiller@google.com> has joined this chat.
jschiller@google.com <mailto:jschiller@google.com> has left this chat.
asonalker@jabber.org <mailto:asonalker@jabber.org> has left this chat.
asonalker@jabber.org <mailto:asonalker@jabber.org> has joined this chat.
smb@jabber.psg.com <mailto:smb@jabber.psg.com> has left this chat.
jschiller@google.com <mailto:jschiller@google.com> has joined this chat.
smb@jabber.psg.com <mailto:smb@jabber.psg.com> has joined this chat.
4:39 PM
asonalker@jabber.org <mailto:asonalker@jabber.org> has left this chat.
asonalker@jabber.org <mailto:asonalker@jabber.org> has joined this chat.
4:43 PM
ejk@cisco.com <mailto:ejk@cisco.com> has left this chat.
malleus.errata@gmail.com <mailto:malleus.errata@gmail.com> has joined this chat.
malleus.errata@gmail.com <mailto:malleus.errata@gmail.com> has left this chat.
sandy@jabber.psg.com <mailto:sandy@jabber.psg.com> has left this chat.
4:53 PM
dongtingyu@gmail.com <mailto:dongtingyu@gmail.com> has joined this chat.
@brian I think the downside was that you can't guarantee the revocation will find its way around
dongtingyu@gmail.com <mailto:dongtingyu@gmail.com>
and that an AS, by policy, may even choose to use the EVIL stuff
dongtingyu@gmail.com <mailto:dongtingyu@gmail.com>
Hmm... there is a further problem - replaying AFTER the revocation, isn't prevented per se, unless revocations are cached.
All of this points to use of out-of-band for both revocations and signatures - it removes the replay capability, and keeps things stateful, with the sender having the ability to revoke previous signatures
An AS using EVIL and passing the EVIL along, means the next guy needs to know that it is EVIL.
5:02 PM
Re-keying is using a hand grenade to kill a fly, in the instance of a single prefix being filtered out (and thus wanting a single signature to be revoked)
In the case of nobody being EVIL, and all the withdraw messages being honored, the revocations get ignored since there are no signatures that match (having already been discarded by the withdraw)
[23:56:24] <brian.peter.dickson> arg - double paste error, my bad
[23:57:16] MIchael Sinatra leaves the room
[23:58:33] <weiler> oops
[23:58:34] <brian.peter.dickson> When you roll keys, you need to re-sign all messages. If you use OOB methods, only surgical revocation (of signatures) occurs, and can extend past/around "blocking" parties.
[23:58:59] dougm.work leaves the room
[23:59:11] <brian.peter.dickson> Bulk revocation can be done in large blocks, with the large block covered by a single signature. The revocation itself need a signature, of course.
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!