Minutes of Workshop on RPKI
July 26 - 27, 2013, Berlin, Germany
Date 27/07/ 2013
All participants agreed upon Chatham House rules.
Minute taker: Markus de Brün
- Round of introduction / Status
- Lunch break
- RPKI and BGPSec
- Monitoring RPKI Origin Validation
- RPKI and Route Origin Validation Deployment Practices
- Discussion on Gap Analysis
- IETF BBQ
- Top level: improving reliability (resilience and trustworthiness) of the global Internet
- We assume RPKI (and follow on BGPSEC) can bring major security contribution to interdomain routing
- Understand who is doing what to deploy
- Understand what is missing for deployment and to create good full operational environment
- Understand how to help relevant parties to deploy
- Do we understand what is missing? (or a threat to success)
- How can we improve on this?
- What needs to be done to fill the gaps?
- Is there a need to organize activities?
- Today: Interactive discussion with a few prepared presentations.
- Try to create overall picture of complete eco-system road map
- (try to help with any current problem)
- In which roles do you/your organization act in RPKI?
- Current status of/plan for deployment?
- Any practical use that could not be done without RPKI?
- Specfic issues standing in your way to deploy?
- What do you see as major blocking factors for general deployment?
- What you expected/wanted to see addressed in this meeting?
- Already working with RPKI data.
- Running a testbed.
- Interested in high-level similarities between DNSSEC and RPKI
- difference is that there is no need to do validation on the router -> use existing code
- for DNSSEC there is a consortium (planning, organizing, long term support)
- discussions are very similar
- A university worked on RTRlib and browser-plug-in that checks web servers address validity.
- A RIR is working on RPKI (2nd version). Origin validation on routers, also looking at offline validation
- Members are concerned on running ROV on routers
- PI-space owner cannot issue ROAs for his prefixes
- Masters thesis on RPKI monitoring
- Workshops and discussions in japan and Asia
- In one case validated RPKI data helps to provide practical solution using the generated routing policy config (not yet origin validation) that could not be done based on the applicable IRR databases.
Points and questions raised during introduction (see also Gaps)
- Most operators will want to run their own stuff.
- Worth the costs? (Hosted in every POP + monitoring)
- Do members of other RIRs have similar concerns as in RIPE region?
- How to motivate people to look into RPKI?
- What is necessary to get it productive
- critical mass
- maximum of invalid but valid ROAs (ROAs that should be valid but are invalid due to misconfiguration or likewise
- A RIR provides a hosted service for their members. Wrote own validator.
- It is hard to get BGP/Routing running. Changing anything is a big hurdle for operators.
- There is a ROA Alert system at some RIR.
- In RPKI the holder controls the registration. In IRR world, can not control what is in AltDB.
RPKI and BGPSec
- Question on BIRD (not part of presentation)
- BIRD does not do rpki-rtr. ROAs must be put into configuration.
Origin Validation LG
- IPv4 prefixes are pretty stable
- IPv6 prefixes change state
- Some ISP has an /16 but they advertise everything in /24s (also creating many ROAs)
- ISP has two ASs. Announcements are covered by one AS but not the other.
- Some ISP has customers and gives them sub-prefixes. By publishing those sub-prefixes they create INVALIDS.
- A RIR spoke with some ISPs in their region that create INVALIDS. Talking to all the other INVALIDS is being considered.
- It would be meaningful to describe the state of RPKI but not mention the state of hijacking.
- RPKI Dashboard assumes that all INVALIDS are misconfiguration.
- In reality INVALIDS might occur because of misconfigurations but more likely due to hijacks.
- state changes might give a clue if this was a hijack or a new customer
- More specifics are an error by a staff engineer, i.e. if the policy of announcing only aggregates is ignored..
- Stateless, i.e. history of prefix is not taken into account.
- A RIR wants to see at least 5 peers.
- Another RIR wants to see 7.
- Comments on slide (local pref)
- Paid upstream is not more preferable from a peer.
- If you get a wrong AS announcement from customer but right AS announcement from upstream and you accept that, then you are offering a service to your customer that "will help you to hijack".
- Discussion is similar to attempts in DNSSEC.
- What is the intention of such a document? Who should read it? (convince your boss, implementation, background information)
- Splitting the according rules, i.e. several documents, starting with very simple first steps.
- How many organizations would run their own CA?
- Some RIR: probably 10, very large 10
- Some smaller organizations are afraid of loosing theirs private keys -> go for hosted CA.
- What should ROAs match - should they match announcements?
- Use max-prefix as close and precise as your real BGP announces.
- If only a small portion of your prefix needs more specific, better create a new ROA.
- Ongoing research on misconfiguration (#prefix-hijacks) to get some statistics that could be used to quantify the value of RPKI.
- IXs want RPKI but they cannot require it of their customers, because most of them have pi space.
- There should be monitoring on what is usual and what is unusual (heuristics, AI).
- It is important to keep ROAs current, since any complaint would cast a damning light on RPKI.
- A RIR is willing to look into ISP-side of RPKI as well, if the know what is needed/required.
- Basically everyone agrees that a test-environment (like a flight simulator) would be very useful.
- Some RIR has such a testbed, which is accessible to their members.
Policy and legal issues
- getting legacy space & PI space covered
- political concerns (e.g. governmental involvement)
Tools & Infrastructure
- router support from vendors
- maintainance of code & repositories
- open source?
- which organization?
- in software
- in repository
- BCPs on deployment (work in progress)
- roadmap to deploy RPKI and ROV in an organization
- deployment decision and implications on operational an business process
- building confidence in RPKI+ROV in your network (first in shadow net, etc)
- operational guidance
- address prefix-holders
- legacy space holders