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 Chair Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-2.pdf audio archive time: 0:14:50 Meetecho timestamp: 00:14:48 *** RPSL SIG : Brian Haberman Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-1.pdf Sandy (Chair): The RIPE region has an RPSL database with a trust model (APNIC does as well).     How does this work correspond with the authorization/trust model for existing IRR databases? Brian: Robert (co-author) is very familiar with RIPE and believes this is compatible Sandy (Chair): It is not common in the IRR world to follow the trust model.     Do you think these signatures will provide a substitute for using this trust model? Andrei : The current system for authentication/authorization is on input and is completely invisible to outside parties Andrei : If you have a route object with only one signature, is it valid?           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? Volk: You have a nicely signed RPSL object, but you can't get into the IRR database because the RPSS authentication is botched due to some maintainer object is missing/broken    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? Brian H: That will require more discussion in the RIPE region.      We currently see this as complementary to existing practice Kaveh (RIPE) : Is Aut-Num authentication required in the RIPE region or is it just an operational practice?        Volk: YES, it is required in the RPSS  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. Tim B (RIPE): I think that there is a technical solution where we allow something into an IRR EITHER if RPSS authentication succeeds       OR if it has valid RPSL sig as per this document. However, that would be a policy change to be discussed elsewhere George M: The practice for how these RPSL sigs are used, is outside the scope of this document.  Kent: This is in conflict with the current Repository RFC (which says all signed objects for a cert must in the repository) audio archive time: 29:32 Meetecho time stamp: 00:30:32 *** BGPSEC Protocol : Matt Lepinski Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-6.pdf Matt Lepinski explained changes to bgpsec-protocol that arose during WGLC.  See slides for detail. Sriram asked re: the detail (eg per update) of deferred validation visibility.  Matt explained that he was trying to avoid offering a specific recommendation.  No further discussion. 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 the path.  Matt will propose text to Ruediger, Wes, and the list re: this is a place for knobs.  Ruediger: this is obvious.  We expect to be able to define policy per-session.  John Scudder: yes, it's 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. re: possible signature attack.  Sandy: agrees that there's nothing to see here.  Wonders if a way to distinguish the two types of blocks would be useful for debugging/packet capture.  Matt suggests: send text. Issue 4: signing the AFI.  [missed lots of discussion; Rob had a point 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. Issue 5: NLRI trailing bits.  No objections. Issue 6: AS migration.  Jeff Haas: another way to look at this is: you're adding another signature on ingress.  Matt thinks this is a better way to present it.  Wes George requested some help making as-migration say the right thing. Matt expects that the draft will be shipped to the IESG following these changes. Sriram asked for clarification re: issue 5.  Matt clarified that this is NOT an on-the-wire change.  Jeff Hass points to RFC4271. audio archive time 1:00:09 Meetecho timestamp: 01:04:02 **** 6487bis : Richard Hansen Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-0.pdf Rob A: The bit about EKU is slightly over-specified.        "routers and other devices" Geoff H: Rob, This is an already-accepted errata Geoff H: Isn't this taking two bites at the same apple          Isn't this about rejected errata being reconsidered?  Kent:  Errata were deemed inappropriate as errata (since they were technical), not that they had no merit Geoff H: The second errata, the discussion on the SIDR list decided to reject the proposed errata audio archive time: 1:10:30 Meetecho timestamp: 01:14:03 **** Delta Protocol : Tim B Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-3.pdf 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 Rob A: We don't have this type of documentation for the existing fetch protocol.        (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. Rob A: For my implementation the server side is further along than the Relying Party side.  Wes George: HTTP vs HTTPS?      Tim: I would prefer not to use HTTPS, since HTTPS and CDNs are not friends           The objects have object security so discovery should not           We don't trust withdrawal messages (if it hasn't been revoked or removed from the manifest then we don't forget about it) Wes George: There needs to be more discussion. There are worked examples out there of HTTPS with CDN         Documents have a burden of proof as to why they don't use HTTPS Rob A: We are hesitant to use HTTPS because we aren't sure whether or not the CDNs will support it        We are happy to do HTTP since pervasive HTTPS is the world we live in, as long as it doesn't break the protocol 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. Tim B: We aren't saying we will never use HTTPS, but it seems like a decision we can postpone Volk: The object security is fine.        If I can't trust that I am speaking to the right server, then I can be DoS'ed (in "nice" ways)        Tim B: The same concerns apply to Rsync, which did not address these issues Chris (Chair): The HTTP vs HTTPS issue won't be resolved today. We should have that discussion on the list.          There are a number of corner cases that need careful examination audio time: 1:44:25 Meetecho timestamp: 01:45:10 **** BGPsec roll-over : Brian Weis Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-5.pdf Kent:       I am two minds with regards to the last slide.       If it is compromised, then probably both keys are compromised      So this mechanism is probably most useful for replay protection      Is it worth doubling the number of router keys/certs in the RPKI, just to solve this replay issue?      However, maybe if we have separated origin from transport in SIDR, then maybe it makes sense to have origin vs transport keys Need more comments on the list. (List has been silent on this for a while) If there is a heirarchy of dependencies then we are after bgpsec pki profiles and bgpsec algs audio archive time: 1:57:28 Meetecho timestamp: 01:57:24 **** Survey on RPKI/DNSSEC : Matthias Wahlisch Slides: https://www.ietf.org/proceedings/92/slides/slides-92-sidr-4.pdf Randy: For DNSSEC without a single root, I have to manage hundreds (or today thousands) of trust anchors           ... this just isn't possible         With RPKI, it is only 5 or 6 which is managable. Di Ma: From the Chinese Internet community. My team did similar work.      I received feedback, from several networks in China      "The RPKI has operation risk"     I believe that the LTA-use case / suspenders work would help address these concerns Sandy: In China, do operators typically use IRRs for route filtering in China? Di Ma: They [network operators] believe that RPKI is more powerful     [This seems to imply that making routing decisions based on IRR is not so common] audio archive time: 2:15:40 Meetecho timestamp: 02:16:18 **** Extemporaneous Presentation : Rutiger Volk Discussion of AS Zero ROAs My take is that people are surprised to see ROAs pointing to AS zero I am surprised that we haven't seen other people using AS zero ROA'ing RPKI gives us the capability to declare certain address ranges to be invalid / unused At some point in time, there was discussion in this group that certain organizations should issue AS zero ROAs for address space where there should be no BGP advertisements What looks a bit strange for one certain prefix, two ROAs, one says valid for my AS 4320 and the other says AS zero  ... This is a regular operational procedure that got stuck somewhere I have a policy for only announcing the maximum aggregate prefix for my PA space   ... but I ran into a few places where we need to split Make before break ...   ... for splitting a PA aggregrate, first you inject the more specific route, but before that you do the documentation (IRR and RPKI)   ... then remove the covering aggregrate, and finally remove the documentation (IRR and RPKI) 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.   ... Let me put out the two ROAs simultaneously, to make sure that no implementations blow up        (better to try it now when there is very little on the line) Also, I have been busy and so this experiment lasted longer than I intended Terry M: Did you anything you did agree or disagree with RFC 6907 Section 3?         As an author, we should re-visit if we prohibit anything that operators find useful Volk: I do not believe I am violating any specifications Rob A: I believe that everything that he did was legal ... though perhaps a demented use-case Doug M: The goal is that in any transition scenario you never pass through Unknown       ... seems reasonable to me 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)       ... Two: Group Trust anchors, where the manifest expiration is different from the trust anchor expiration 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)          Use a longer expiration time for EE cert (so manifest can go stale without expiring) (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 Kavah: K-root anycast address space has been signed in RPKI