There were places in the minutes that noted incompleteness, but no comments on the list. I reviewed the audio and filled in the noted places.
Since I had the audio and Meetecho open, I added audio times noted by my player and the timestamps noted in the Meetecho chat room for the beginning of each talk. Diff of old minutes to new minutes below. --Sandy P.S. Note: chat room during the meeting reported a delay in the audio compared to video. This seems to be true in the audio archive as well. 0a1,7 > Audio times taken by observation from audio player. Meetecho timestamps > taken from Meetecho chat entries > > audio URL: > http://www.ietf.org/audio/ietf92/ietf92-parisian-20150323-0900-am1.mp3 > Meetecho URL: > http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_SIDR&chapter=chapter_0 > > audio archive time: 0:05:55 Meetecho timestamp (slide 7): 00:11:23 > 2a10,11 > audio archive time: 0:14:50 Meetecho timestamp: 00:14:48 > 18c27,29 < In the existing model you would need two signatures, right? --- > In the existing trust model you would need two authorizations, > right? > A: What we are mandating is that you must follow the 3779 attributes > Andrei : Understand but do you require two signatures for a route object, to > follow the trust model? 21c32 < Are you suggesting we remove some of the constraints of the existing system? --- > Are you suggesting we remove some of the constraints of the existing > system? That is, if RPSL sigs validate, but RPSS authorization does not > validate, will the system be changed so that the object can be entered into > the database? 29,30c40,45 < Sandy: In IRR databases that do not use RPSS authentication, we have reports of people sneaking in objects for prefixes they were about to hijack. < Is it possible to have --- > Sandy: In IRR databases that do not use RPSS authentication, we have > reports of people sneaking in objects for prefixes they were about to > hijack. If you only have one signature on route objects, that would > continue to allow that behavior. > A: You could have two attributes, one for each authorization. > Or one certificate that included both resources. 38a54,56 > > audio archive time: 29:32 Meetecho time stamp: 00:30:32 > 46c64 < Sriram asked re: the detail of deferred validation visibility. Matt --- > Sriram asked re: the detail (eg per update) of deferred validation > visibility. Matt 50,51c68,69 < Ruediger: made a case for per-session policy (???). Wes George: in < the route policy, you might want to specify something about an AS in --- > Ruediger: made a case for per-session policy versus per-AS policy. Wes > George: in > the route policy, you might also want to specify policy about an AS in 55,56c73,78 < incredibly obvious, but you should probably say it anyway. [missed < Randy's point] --- > incredibly obvious, but you should probably say it anyway. > > Randy: Wes is confusing two things. Documents in other areas say that > you can specify for a peer or a set of prefixes, whether the markings > will be placed on the received path. That is different from deciding > to apply policy if the path includes an AS number. 60c82 < would be useful for debugging/packet capture. [Missed resolution] --- > would be useful for debugging/packet capture. Matt suggests: send text. 63,65c85,117 < re: current code and AFI] Matt jumped to issue 7 re: mandating support < for multiprotocol extensions. No objection to requiring RFC4760 < support. --- > re: current code and AFI] > > John: I wonder if SAFI should also be there. Matt: This version of > BGPSEC only covers the AFI of IPv4 and IPv6, which means SAFI is not a > concern. Rob: There is a SAFI -- the only one allowed is the null SAFI > - hash the non-existent byte. > > Doug Montgomery: We briefly discussed to have BGPsec only use MP BGP - > so no multiple encodings of v4 and v6, and where it is getting the > hashes, so we could simplify things by saying all NLRI are carried in > the MP extensions. AFI is already in there. > > Jeff Haas: One of the reasons why SAFI is a good thing to include is > that when it is time to support VPNs later we don't have to revise the > protocol to change the validation strategy of what we sign. (Matt > says: future proofing.) > > Doug Montgomery: The fact that we have separated origin and path > validation means that we could at some point need to support other AFI > or SAFI, so a good idea to make it possible now, to use later. > > Jeff Hass: Pretty much all code treats the non-MP case (IPv4 unicast) > as MP anyway. For common procedural stuff, instead of treating it as > null 0, treat it as the 1 SAFI, so even in then you are still > consistent even if it is in a different part of the packet. > > Rob: John commented privately that there is no such thing as the null > SAFI in BGP. But there is in the RPKI. In RFC3779 - the SAFI is an > optional byte and in the RPKI as deployed that byte is required to be > absent. So you will have to deal with the fact that there is no SAFI. > > Matt jumped to issue 7 re: mandating support for multiprotocol > extensions. No objection to requiring RFC4760 support. 79a132,133 > audio archive time 1:00:09 Meetecho timestamp: 01:04:02 > 95a150 > audio archive time: 1:10:30 Meetecho timestamp: 01:14:03 101c156,161 < Kent : We should have clear (not informational) documentation somewhere as to exactly what the replying parties MUST do in order to understand the security properties of the system --- > Note: slides used in the meeting were an old version: > https://www.ietf.org/proceedings/92/slides/slides-92-sidr-8.pdf > > Kent : We should have clear (not informational) documentation > somewhere as to exactly what the replying parties MUST do in order to > understand the security properties of the system 104c164,170 < (Not to say that we should, but such relying party documentation shouldn't hold up this rrdp specification) --- > > (Not to say that we shouldn't, but such relying party documentation > shouldn't > hold up this rrdp specification) > > Tim B: would prefer to keep this document clean. Text should take care not > to restrict > relying parties more than necessary. Maybe, if wg agrees, we could > write a document > and share it with the wg. 111c177,178 < We don't trust withdrawl messages (if it hasn't been revoked or removed from the manifest then we don't forget about it) --- > We don't trust withdrawal messages (if it hasn't been revoked or > removed from the > manifest then we don't forget about it) 117c184,185 < We are happy to do HTTP since pervassive HTTPS is the world we live in, as long as it doesn't break the protocol --- > We are happy to do HTTP since pervasive HTTPS is the world we live in, > as long as it > doesn't break the protocol 119c187,189 < Jeff H: We don't care about privacy, but we should want integrety of the transport --- > Jeff H: We don't care about privacy, but we should want integrity of the > transport session. Problem > is also withholding object or getting a stale object. Look at lesson > of SMTP where bootstrapping stuff in a non-secure environment and > that being meddled with. 124c194 < If I can't trust that I am speaking to the right server, then I can be DoS'ed (in nice ways) --- > If I can't trust that I am speaking to the right server, then I can be > DoS'ed (in "nice" ways) 131a202,203 > audio time: 1:44:25 Meetecho timestamp: 01:45:10 > 146a219,220 > audio archive time: 1:57:28 Meetecho timestamp: 01:57:24 > 164a239 > audio archive time: 2:15:40 Meetecho timestamp: 02:16:18 166c241 < **** Extemperaneous Presentation : Rutiger Volk --- > **** Extemporaneous Presentation : Rutiger Volk 185c260,261 < ... for splitting a PA aggregrate, first you inject the more specific route, but before that you do the documenation (IRR and RPKI) --- > ... for splitting a PA aggregrate, first you inject the more specific > route, but before that > you do the documentation (IRR and RPKI) 188c264,265 < Should have an AS zero ROA for the aggregate which will no longer be advertised? --- > I extended the ROA, I created the route objects, I looked a bit ahead and > said I would > eventually need a AS zero ROA for the aggregate that will no longer be > advertised. 194,195c271 < < Terry M: Did you violate any procedure in RFC 6907 Section ??? --- > Terry M: Did you anything you did agree or disagree with RFC 6907 Section 3? 205,206c281,283 < Randy: Two major problems with RPKI deployment < ... Most Egregious: Operators who issue a ROA for their 16 (and clobber customers who have 24, but don't have ROAs) --- > Randy: Two major problems with RPKI deployment and then one more minor thing. > ... Most Egregious: Operators who issue a ROA for their 16 (and clobber > customers who have 24, > but don't have ROAs) 208d284 < ... Three: As RIPE and LACNIC scale up, we will eventually have scaling issues with the transport mechanism 210,212c286,289 < Rob A: 3 of 5 RIRs have had trouble with this < Some implementors have chosen to have the EE cert expiration very similar to the Manifest Next Update < ... This is dangerous if you are --- > Rob A: (interjection) 3 of 5 RIRs have had trouble with this (the manifest > expiration problem) > Some implementors have chosen to have the EE cert expiration very > close to the Manifest Next Update time > ... This is dangerous if you are down for the weekend etc (for > RIRs, this makes all the region > ... go poof) 215c292,296 < Jeff Haas: The SIDR group has a WIKI it would be easy for anyone with an operational comment to toss it into the Wiki --- > (back to Randy): > ... Three: As RIPE and LACNIC scale up, we will eventually have scaling > issues with the transport mechanism > > Jeff Haas: The SIDR group has a WIKI it would be easy for anyone with an > operational comment to toss it > into the Wiki 217c298 < Kavah: K-root address space has been signed in RPKI --- > Kavah: K-root anycast address space has been signed in RPKI
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
