1255: delayed start due to slide upload and A/V problems 1500 start of first sidr ops meeting chair slides sandy (notetaker) spoke about status of remaining drafts in SIDR 1507 Brian Wiess = router keying rollover slide 2 - overview critical that a router receive a (new) router certificate in time slide 3 certificate only rollover events slide 4 you have a new certificate and a new key pair emergency rollovers a key (:-) ) concern slide 5 steps in a rollover five steps - generate new key pair, publish new certificate in global RPKI, receivers will get any new key to the bgpsec routers, ues new key to sign slide 6 how long is a rollover event slide 7 when CRL is not required don't need the twilight stage slide 8 - cert only rollover only need first two stages slide 9 - ready for wglc (reference to draft-ietf-sidr-rtr-keying - mentioned in sidr status as ready for wglc) Chris: will ask one more time to the list if it is ready for wglc 15:15 Sriram - bgpsec-protocol draft and extended messages draft slide 2 the IDR extended messaes draft is back in the IDR wg, but bgpsec-protocol has a normative reference slide 3 is extended messages really needed in bgpsec? average over 5 million updates shows averages of AS_PATH that seem to indicate the current bgpsec signatures with ECDSA P-256 alg don't really need extended messages slide 4 Alvaro strategy - change reference to extended message draft to a reference to "maximum message size" slide 5 new wording to follow this strategy slide 6 what if sending Secure_Path_Segmetn and Signature Segment exceeds "maximum message size" (a) convert to unsigned update (b) do not send the update RV at mic: would not like the second option - you would need to send a withdrawal. Sees no problem with the first option Jakob Hietz Cisco - could you have more than one NLRI in a bgp update? Chris: you can, but uncommon Keyur Patel - need text to say what you do if you want to send an unsigned update. probably need to say follow the way to produce an unsinged AS_PATH ROb Austein DRL: does this problem (overflow) ever occur in regular BGP John Scudder: yes, implementations do have to handle this case. would be good to follwo that thought process Wes George: try not to surprise people, make sure you highlight this. Do not loke this - yet another case where we are dropping back and failing open. Can we split things into two updates? Chris/others: no, BGP does not support that RV: a very rare case, requires more than 15 unique ASs in the AS_PATH. WOuld we think people by that time *NOT* have updated their routers to a version taht woudl support extended messages. Warren Kumari: a vulnerability for a attacker, to deliberately produce a A-B-A-B path that exceeds the maximum messae size Job Snijders NTT: My colleagues said 15 was unlikely, but Lacnic sees paths that are easily 15 Chris says: slide said 15 was the average, would need 3 of those in order to blow the maximum message size Wes George: we do need to consider the Warren vulnerability Randy Bush: the problem is that the extended messages is now have to cover all update types - with IDR speed, that could take a while, even so bgpsec speed of deployment is not going to beat it there. put extended messages in the informative and don't try to complicate the bgpsec protcool Doug Montgomery: John Scudder: yes, it would generate an error Keyur Patel: extended messagse has met iDR criteria, should just proceed as is John Scudder: there are several option, that is one, you would have to wait for IDR to finish. Is the wg concerned enough about publication to try to rush this? Randy's comment is Perfect is the Enemy of Good, just make the reference move to informational and leave it at that. Chris: discuss this on the mailing list - He will send msg today and set a two week discussion time. ALvaro: please discuss this in sidr Chris: will send to both ALvaro: does not go back to wg. when we decide send text to wg(s) and IETF as to decided new text, and if no one objects, I will approve and the RFC Editor will publsh Randy: not necesssary to say anything aobut the Update size - it follows rules of BGP Updates. Just need to move the reference. Yossi Gilad substituting for Sharon Goldberg - The use of MaxLength in the RPKI slide 2 - RPKI defezts prefix hijacks slide 3 - but a loose maxlength in the ROA allows a forged origin subprefix hijace to succeed mentioned in RFC about rpki operations slide 4 - maxlength misconfigurations are common - slide 5 - recommends: don't use maxlength have lists of prefixes taht are originated use minimal ROAs where you authorize only originated prefixes slide 6 - wrote tool to take a set of RPKI ROAs with lists of prefixes back to maxlength version RV: I would say just don't sign ROAS for prefixes you don't want to advertise Sandy: there are two implementations of the CA function that warn an operator that a ROA was just about to invalidate current advertised routes. Nothing says that an operator who is trying to produce a ROA won't be as inclined to do the Randy: Tim Br of RIPE wrote the CA implementation for RIPE - and spend some tiee to Chris: there is a tradeoff between wanting to get the data out there and wanting the data to be carefullyu Rob Austeing: are you suggesting lots of ROAs or multiple prefixes in a single ROA. A: the Second ROb: a bad idea. The ROA structure is all ASN focussed. The operators seem to think this is not the right approach, because changing the AS to announce one prefix makes it necessary to change the ROAs for lots of other prefixes. Telling people to pay attention to max-length is OK. RV: current RPKI database, just the first ROAs, looks very much like operators don't know what they are doign. education and additional help in the UI is fine. before max-length, there was a bit that said "allow all more specifics" a surprise to the implementers that NOT what i'm seeing in the database, a ROA for a /16 for an Asian ISP, and also a ROA for a /24 for the very same AS. Looks like two different poeple did this. People need to take this seriously. Randy: many years ago, a fried, Geoff Huston, people were complaining about ipv6 prefixes going to Singapore to get to west coast US Job Snijders: max-length mpas directly into what people do with their prefix space - when they get a DDOS attack, they swing routing for one /24 to behind a DDOS protector. they try to preseed the IRRs with route objects for all possible route objects or use max-length. you correctly observer that people don't understand. Rnady: I need to produce ROA so when the scrubber announces the route, the route is valid. new topic BGP ROles and its applications Alexander Aximove, Randy Bush, Evgeniu Bogomazov, Keyur Patel be vary carefu in creating any new slies 2 engineers prefer flexibility, leave no knobs untruned - but can have very expensive consequences slide 3 consequences - number of prefixes (and number of prefixes leaked) in March slide 4, slide 5 - possible roles and peering relationshipo - need to be represented in BGP - in OPEN msg - would allow agreement between neighbors of their respective roles slide 6 - prevent leaks, detect leaks, detect deliberate leaks. slide 7 - must be in OPEN message, in order not to be circumvented by flexibility and knobs mic: John Scudder: about "hardcoding in OPEN msg is curcial" - what are you going to do to OPEN msg. A: you must be sent to your neighbor JS: it is a capability? A: yes next topic overlap a bit to previous talk about route leak prevention and detection slide 2: description of route leaks slide 3: intra-AS, use ibgp community/attribute/etc, inter-AS, use community (or attribute) cofigure peering relationship per neighbor per prefix slide 4: oob communication between neighbors slide 5: using attribute for inter-AS solution with an optional transitive attribute slide 6: no single point of failure, attribute is set by each ISP, participants can detect a leak whether the ISPs in between are participants or ot slide 7: relationship between OOB communication of role/relationshiop and previous BGP Roles in OPEN msgs approach. Mic: Sue Hares = we (she and Sriram) talked about an issue - about aggregates Job Snijders: we in this room has an idea of customer and peer, but in real world, some of our customers think we are a peer, some of our peers think they are customers. I think the ideas have merit, but think we need to consider what the people who are using this will be able to understand. Randy: I apologize for suggesting this - but you might think people would actually read the documents. Our draft defines the relationshiops. Nothing to do with business relationships, stated in terms of route propagation only.