Sandy Murphy:
	•	introductions, note well
	•	draft status (see slides) 
	•	ltam to die unless someone objects
	•	agenda
Tim Bruijnzeels:
	•	RPKI retrieval Delta Protocol - RRDP 
	•	Discussion 
	◦	Geoff Houston: Distrusting - what does it mean
	◦	Rob: I was going to comment on this.  This is a point of friendly dispute among the implementors.  Tim is very conservative regarding his implementation. 
	▪	all it really means is the protocol is not a trusted conversation.  the objects are what matters; we don't really care about who we're speaking to to get the objects
	▪	so being conservative about believing the web server when it says to delete something
	•	questions/comments?
	◦	Randy Bush: Channeling Dan McPherson .  He's concern about the distribution of the data because he has a product which depends on this work.  
	◦	Tim: no data yet.  The place that is getting work is the notification file. 
	◦	Sandy: I think that you are talking about certificate validation not bgp route validation. 
	◦	Rob: this is really about discovery, not validation
	◦	Tim:  would like to make informational document that explains how both discovery and validation work with RRDP
Sandy:
	•	Randy Bush to talk about transfers.
	•	Geoff pointed out careful synchronization requirements to hand off back in November.
Randy Bush:
	•	Sandy: Do you think your description of the transfer process melds with Geoff' description of careful synchronization? 
	•	Randy: probably, what do you think Geoff
	•	Geoff:
	◦	validation reconsideration gives more latitude
	◦	the two work a lot better
	◦	if you get timing wrong, things are still ok
	•	Sandy not asking about validation process, was asking about (too fast)
	•	Geoff:  take the 5th, can't answer right now without reading carefully
	•	Sandy:  For those of you who are working at the registries, does transfer draft match your operational procedures?
	•	Tim B: no, we support xfers, defined by policies, doc doesn't have to define policies, but needs room for decision points on whether xfer can happen or not.  Currently don't engage.   Can invalidate resource in a certificate in case of xfer, but since we have hosted solution at the moment, doesn't really affect us.  We can shrink ROAs, etc as neeeded.
	•	Randy: You don't do inter-rir transfers?
	•	Tim: not yet, almost
	•	Stephen Kent:  One of the difference between Randy's doc and earlier is earlier distinguished between transfers of unused and live, thought that former was more common. The discussions on the list says having two ways of handling transfers isn't good.  If wg decides having only one way is better, the document needs to say why that choice was made (why not distinguish between the two).  We described in that older draft that ordering constraints aren't that bad.  Ordering should be carefuly revisited in detail.
	•	Sandy:  I do not know of any rir that permits live transfers of live address space. I do not think that xfers are impossible
	•	Randy: I assure you that transfers of live address space have been going on for years.  Mergers and acquisitions
	•	Sandy:  never considered them an xfer 
	•	Andy Newton: we know that transfers have taken. 
	•	rob: One particular data object is the tao object that we sign and transfer.  I recommend people go back and read the document. 
	•	randy:  in original transfer doc, 2007, something like live euro protocol, fantasy to handle what the tao object is doing in a different way.  essentially need an authenticable /verifiable attestation of intent.  tao is one way of approaching that
	•	sandy:  torn euro, not live
	•	tim:  I like the document that randy and all published recently. 
	•	Randy: The transfer document is slowly sneaking up on describing the transfer.  We have so little data on those who are actually doing the transfer.  One is type going up and the other is going down. BBN doc making registry nervous
	◦	both trying to reach the same place, different directions (one going up, other down)
	•	rob:  if you look at either doc, there's a challenge naming recipient.  seller identifiable (holding resource), buyer hard to find.  tao object, something that names the buyer.  where is this supposed to be going?  did the right person get it?
	•	sandy:  would be useful for people to comment.  neither doc is a working group document.  do we want both, or one, or neither to be adopted?
	•	randy:  what do we mean when we adopt?  some wgs will talk endlessly, others if it means we want to discuss it.
	•	kent:  don't both need to be adopted.  ultimately have a solution that will incorporate elements from either document that is adopted.  Randy's document has more details regarding on topic.  BBN has working. 
	•	randy: illustrates the difference in two procedural approaches.  a group that says wg docs are those for discussion, then both should be adopted, then drop both, then adopt a new one.  etc.  in idr these wouldn't be wg docs until something pristine and ready to publish came out
	•	Rob: Ask if the WG wants to work on this topic. 
	•	 Richard Hansen: adopting makes it easy for people interested in sidr to keep track of what's going on, what the group thinks is interesting
	•	: Adopting this work indicate people want to talk about this document 
	•	sandy:  we'll go forward in some fashion
Steve Kent, overview of adverse actions draft
	•	(slide 6) Rob: A question that occurred to me, I agree that outsourcing CAs.  There is a large publication repository (  what if google decides to publish everything?  should we consider that case?  
	•	Steve:  good question, should email so we remember to think about it.
	•	(slide 8) Rob:  not exactly mission drift, but originally manifests had a specific focus.  just here to solve one problem.  but they're useful for other things...   rsync isn't the best.  manifests are pretty important for discovery.  Requirements for manifests may have changed.  may be worthwhile to revisit manifest doc.
	•	steve:  good point.  if plans to switch to rrdp, then need to go back and look at it.  but it's tricky, we're still using rsync.  will have tradeoffs
	•	doug montgomery:  in detection, worth addressing pub point might offer different views to different people/regions of the world.
	•	steve: didn't address that.  certainly is possible if the primary detection is done by the INR themselves, but they keep getting rosy view.  INR might have options for where to get resources.  please send email to list so we remember to talk about this
	•	Rudiger Volk:  As distribution tree gets more differentiated, attacks it is not sure to determine how to monitor or to detect these attacks. It is actually interesting to have some people provide a service of monitoring - so the naive people can ask for the current view This resource view will show the resource holder. It would be 
	•	steve:  One can imagine 3rd party monitors (for money, altruism).  We have this in BGP - so why not here. 
	•	mlepinksi:  What is the bad thing that can happen if a repository offers different views of the world to different people ... provided that both views are otherwise valid (not stale)
	•	steve:  The views could be different due to compromises.  I think Matt was asking question in a slightly different context. 
	•	tim:  we use manifests in a more authoritative manner -- I think they're really useful because they're signed and enumerate what they believe we should find
	•	steve:  complimentary issues:  if i can't find something mentioned, then...  #2 if i find something not on manifest, what then... #3 what if manifest is stale.  should discuss, little squishy
	•	tim:  people seemed to be ok with giving manifest more authority.
	•	steve:  agreed, need more discussion and decisions
	•	matt:  One can imagine a resource holder who wants different people to see different views and therefore creates parallel objects for this purpose. I am not sure that this is good, but I don't think it is something we should spend a lot of effort to stop
	•	steve:  i don't think we ever viewed this as a feature
	•	randy: lta use cases
	•	steve:  local matter, we're talking about global
	•	randy:  local can be big, and can have subsidiaries.  not as bad, intransitive
	•	sean turner:  question #1 adopt?  yes.  #2 expand scope to expand other EE?  no, let's not.
	•	steve:  router certs?
	•	sean:  sure.  for other EE we can add them later
	•	sandy:  was reviewing some of the things that had happened in registries and rpki, some of availability issues where repos were offline, manifest problems cause validation to fail everywhere, do those fit in suppression?
	•	steve:  i'd say yes.  if offline, then equivalent to suppressing availability of updates.  could try to clarify
	•	rob:  several RIRs had CA offline.  pub point was online, but CA wasn't updating so things went stale.  don't know if all rirs have fixed problem of short manifest EE cert lifetimes (were using 2-3 day lifetimes).  The problem with RIR would go down for a weekend, and everything under other the RIRs. 
	◦	rir region would go away for a while
	◦	technically could fit into this category...  more like serious operational error
	•	randy:  have had demonstrations of serious problems.  would be nice if it was obvious to reader of the doc the nature of those problems and how this doc plans to detect and deal with them
	•	rudiger:  would be good to explicitly state whether the intention of this document is to cover all of the things that could happen, including all of the operational screw-ups.  straight forward that ... classified in theoretical way as suppression or similar, but i would guess that addressing seriously all kinds of operational errors would take a different approach to those.  in the interest of op stability, I would like to see all of it addressed, but fine if one doc deals with explicit tampering and another deals with operational errs.  one should have a clear understanding of what is being addressed.
	•	steve:  rob, please send examples.  what we can do is give examples to make it clear that we did intend to include this.
	•	steve: rudiger:  Did intend for this to be comprehensive.  detection is going to be the same.  better job of explaining the implications of these things.  want to make reader understand this is a concern because of this points. 
	•	sandy:  recall happening two registries had issued same resources to different people.  how does that fit?
	•	steve:  send that to the list, need to think about that
	•	sandy:  Possible to do that .. for traffic engineering
	•	steve:  could have daemons looking for these, could have false positives
	•	declan ma:  cover case of ... yes, we are looking at that
	•	all of the above was on slide 8
	•	Stephen: I'm proud of my penguin picture in the slide set. 
	•	Randy: But what is the penguin asking (smile).. 
Sandy:
	•	previous q on whether to adopt leads me to think that adoption is a moot point
	•	clear that people are commenting and interested in the topic
	•	if authors want adoption, authors should request it from the list
	•	next:  david mandelberg
	•	reminder of blue sheet 
David Mandelberg presentation on SLURM
	•	note: David believes this is ready for adoption. 
	•	Rob: The basic mechanism has been around for many implementation. You are suggesting we have a file format. 
	•	david:  and a specific behavior for what the file says
	•	rob:You are specifying a typical usage, but not limiting it.  The typical usage is  layer between validation engine fetching and rpki-rtr stuff.  in my implementation, if you choose the right options -- what can you express in a perl script? -- it's a text filter.  talking about set of actions and file format.  main value is having interchange format in case you want to move them around
	•	david:  yes, that's primary concept,  but additonally some corner cases need to be  hash out
	•	tim:  we are doing similar things in our validator.  can only configure in web ui at the moment.  woudld be good to have a standard format and a dcoument describing behavior.
	•	doug montgomery:  so this is for addrs not globally advertised?
	•	david: primarily for net 10, etc.
	•	doug montgomery: but used locally and not ebgp?
	•	David: I believe that there are people doing strange things. 
	•	doug:  monolithic file per validator?
	•	david:  per rpki-rtr output server
	•	doug:  router to cache peering?
	•	david:  don’t see why not, if you configure properly
	•	doug:  worth discussing to get correct scope of correct slurm?
	•	david:  asking for ops draft?
	•	doug:  how to use if different strange people do different strange things
	•	rob:  is identifier field in slurm format.  draft is open ended about how that's handled, but one way is to limit applicability to certain rpki-rtr instances
	•	rudiger:  ...  people will screw up
	•	david:  would be nice to minimize that
	•	rudiger: It makes the text for writing the RIR easier.  You are not twisting the text for 5 different usage.  And this is important because if the standard was not good, it will helpful. 
	•	doug:  picking up on rob, if localized special views, if some way to bind right router to right view, that would be good
	•	david:  it's in terms of rpki-rtr servers, not routers
	•	steve kent:  if common format is a good thing because of sharing, then we have to have semantics be uniform or else we have problems.  that's why it's good to have this
	•	Jeff Haas: slurm is just a filter.  Without that, you expect what you generate is expected to be largely uniform.  may want to private addresses have scope in some portion but not somewhere else, some bit of prefix squatting on, the way to extend this interpretation -- treating it as output, do something before handing off.  could get same thing if you move the box.
	•	david: are you asking to put in router software?
	•	jeff:  may make sense.  yang, etc. that people know what to do with
	•	david: made these slides before we talked last night.  Being rp implementer, put it where I was comfortable
	•	rob:  leaving slurm out for the moment; from implementation point of view easiest to put it there
	•	randy:  characterization of use of other's address space -- people doing that are not announcing globally, and they want to validate its use.  that's reasonable.  we may or may not like it, but that's reality.  2nd point -- lta-use document tries to address similar needs but at higher level; specifically do editing by producing different repositories.  distribute modifications through repositories.  this is two steps down, not sure which set of needs and how this is implemented is the way i'd go.
	•	david:  draft does reference lta use cases.  agree with most of what you said, personally think it's easier to distribute text file.
	•	randy:   want to reduce description to a distributable syntax.  would recommend json.
	•	rob:  if one were to use slurm to replace some things in ltam, one might want some understanding of way to combine multiple slurm files.  how to merge local with isp.
	•	david:  in the draft.
	•	rob:  yay.  have comment syntax?
	•	david:  yes
declan ma, rpki in china
	•	Sandy: Any questions? 
	•	Rudiger Volk: I wonder if you mentioned any test plans or any details on deployment? 
	•	declan:  yes.  zdns has testbed, ran tests.  developing distribution mechanism (rsync with optimized hash).  We have  testbed to work with manufacturers to see if it works
	•	??? (afrinic):  modified rsync, did it help you?
	•	declan:  paper will be published, can send slides about thisYou know my email address. Please send me a request. 
matthias waehlisch on rpki beacons
	•	randy:  would like to change "interval" to "specific published times", then can measure propagation.  don't care what the object is.  like that each CA does it.  think it's a good idea. I like bgp beacons
	•	kent:  opposite take:  adding churn to the system is something i worry about.  secondly, already have by convention, crls that are changing daily and thus manifests.  if rate that cas should do this is more frequent, then we shouldn't do this.  looking at propagation time using existing stuff is pretty good.  if suggesting doing it more frequently, have to add new objects.  must pay close attention to make sure we don't mess anything up.
	•	matthias:  first idea, still open for discussion.
	•	kent:  1st question:  how frequently?  if not more frequent than existing updates, then we might already be able to do what you want to do.  having every ca do this, since we have a few entities that operate repositories, propagation will probably be the same so it may not add to the precision if each of the hundreds of CAs do this for each CA.  seems excessive. Perhaps you needed to think you about this? 
	•	matthias:  expect more frequent than once a day
	•	kent:  crls get issued daily, thus manifest changes daily, and they have timestamps
	•	randy:  start time on cert is not necessarily publish time.  I agree with kent on managed repositories.  .I am interested in the publishing time... per repository not pub point timing is of interest to me. if it creates too much churn, then i think we have more serious problems
	•	??? (ripe):  like idea, but where do you want to go with this?
	•	matthias:  
	•	(ripe):  idea good, don't support a mandate that all CAs must do this, but think it's good practice.  idea is good
	•	sandy:  cross product of bgp beacons and rpki beacons.  I was trying to see if there's interest in trying to measure the publication time vs. announcement time, and when changes impacted each other.  I don't agree that crl being published daily is sufficient; needs for measurement may not be satisfied by that publishing 
	•	matthias:  should we write a draft?
	•	sandy:  I think that a draft is best to progress this work is important.  There have been complaints in the past that progression without a draft is not good. 
Andreas Reuter:  RPKI MIRO 
	•	Rob: This is awesome - keep it up. I was trying to feed the results into DOTS is difficult. We tried to remove any identifying information.  Is this a independent implementation.  If it becomes an independent implementation, please join the rp implementor interop testing
	•	andreas:  no, using RIPE's validator library
	•	Randy: I do not care about the file names. We went down a similar path for bgpmon.  
sriram- draft-idr-route-lead-detection-mitigation-00 
	•	Lots of discussion on IDR list and GROW list (presentation comes from these comments) 
	•	sandy:  wg chairs list, meetecho ends precisely on time...
	•	questions
	•	randy:  route leaks are a serious problem.  i think this is the only game on the table.  not clear that it wins.  concerns are the idiot leaking also marks, so they're going to do the downgrade attack.  if they have a misconfigured router, why wouldn't their router be misconfigured to downgrade
	•	Siriram: The security is important. 
	•	Randy: We need to take time to think through what happens, and get it right. 
	•	Jeff Haas:  where do we put these things?  community makes sense.   operators use peer groups to associate things together with common policy.  people might do what appears to be a downgrade attack.  One might degrate the peer grouping.  If you want it to be automatic.  with end communities can put it in today, if done correctly, will work.  having policy that is automatically maintained ... 
	•	Siriam: You think automating this is feasible? 
	•	Jeff: what is required mark peering session (peer is customer, peer is provider), would be broadly useful., for this and other stuff. Taking this taxonomy and seeing if it is usefu. 
	•	randy:  #1:  hesitant to use communities because they get manipulated, validly so.  therefore can't sign them, so doesn't work with bgpsec.  #2 based on Gal-Rexford model, been ranting against this for years.  people who have been pushing it have a paper that says that they measured, and it's not the case in a significant portion of the internet.
	•	sandy:  found it listed as a tech report, can be described as publicly available document. 
	•	sriram:  not characterizing peering session as gal-rexford ...
	•	randy: Tjotrnasported between two peers intentionally, this discussion is silly
	•	sandy:  in discussions, always discussed neighbor of leaking party being the discoverer.  neighbors aren't correctly doing their jobs detecting.  advantage of this is permitting later people to detect.
	•	randy:  not necessarily -- if 2 hops away, don't know if the leaker was a bend.  don't know that topology
	•	rob:  assuming they'll get this right but others wrong doesn't work
	•	sriram:  
	•	doug:  that assumption, that you blow everything, is what this addresss.  theory is that google knows what it does when it passes to hathaway.  multiple hops fail, but eventually hits someone who's doing things right, and now that has a chance to detect
sandy:
	•	we're done