Re: [routing-wg] RFO for RIPE NCC RPKI outage 16 February 2022
Hi, On Wed, Feb 16, 2022 at 05:01:25PM +0100, Ties de Kock wrote: > This afternoon, between 13:00 UTC and 14:10 UTC rrdp.ripe.net was unavailable. [..] Thanks for this great postmortem writeup, and for being open about what happened, and how things always go wrong at the same time (service and monitoring). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/routing-wg
Re: [routing-wg] Open-sourcing of the RIPE NCC???s RPKI core software
Hi, On Thu, Feb 10, 2022 at 06:35:35PM +0100, Shane Kerr wrote: > I'm a little disappointed that you didn't choose a copyleft style > license, like with the RIPE Atlas Software Probe, which uses GPLv3. That > would help ensure that the work of the RIPE NCC employees is not used by > a proprietary product or service by a company unwilling or unable to > share their changes. Probably in the presentation at RIPE 84 there will > be a bit of explanation about the choice of using a license so easy to > convert back to closed source. Just to express a contrapoint - I'm happy that it's not GPLv3, as that license is really intent on getting in the way of getting stuff done. So if someone wants to set up a high-quality RPKI registry with that code base, why shouldn't they? It's not like the NCC is a poor enthusisist that will lose the fruit of years of work to evil companies - and the market for "we will turn this into a highly successful product, stealing all the NCC's work" is not exactly large either. So, MIT is fine with me, and if someone wants to build a commercial RPKI product based on quality source, even better. (I've dealt with MIT and GPLv3 source in the past, and contributed to projects under various licenses, and the only ones that always create friction is the GPL camp. Like "no, you cannot link your GPLv3 program with a library that is Apache licensed") Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/routing-wg
Re: [routing-wg] request to enable ICMP echo-reply on rpki.ripe.net?
Hi, On Wed, May 05, 2021 at 12:30:01PM +0200, Kurt Kayser wrote: > I understand your point. But there is really no big effort to check if > Port 873 is working: > > nc -zvw100 rpki.ripe.net 873 > Connection to rpki.ripe.net 873 port [tcp/rsync] succeeded! > > Let's make a security comparison, if this is really a necessary feature? So where exactly is the *security* drawback of permitting ICMP echo? But yes, of course, we can all do tcpping instead - which is much more likely to have an adverse effect on the actual service... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] request to enable ICMP echo-reply on rpki.ripe.net?
Hi, On Wed, May 05, 2021 at 12:23:15PM +0200, Job Snijders via routing-wg wrote: > In today's troubleshooting adventure, an operator experienced difficulty > pinpointing where exactly a connectivity issue between them and > rpki.ripe.net (193.0.6.138 + 2001:67c:2e8:22::c100:68a) resided. > > It would be helpful if RIPE NCC reverted disabling responding to ICMP > echo requests originating from the Internet. Would it be possible to > adjust the firewall settings to accomodate troubleshooting and > monitoring? Yes, please. Breaking ICMP(v6) troubleshooting is generally not a nice approach for network-relevant services... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] RPKI Route Origin Validation and AS3333
Hi, On Thu, Mar 18, 2021 at 05:13:06PM +0100, Kurt Kayser wrote: > but you are assuming that the person trying to access RIPE NCC Service > is the SAME that is responsible for messing/clearing it up? > > That is for me not necessarily the same person. Well, this is the case that is relevant here: someone in a given network cannot access the LIR portal anymore, because of invalid ROA for their very network, and to *fix* the ROA, this access is needed. Catch-22. Any other sort of "someone messed up routing for someone else, for some reason" is indeed nothing the RIPE NCC needs to concern themselves over - but the case above is something that needs consideration and then a well-communicated decision. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 smime.p7s Description: S/MIME cryptographic signature
Re: [routing-wg] RPKI Route Origin Validation and AS3333
Hi,
On Thu, Mar 18, 2021 at 04:56:22PM +0100, Kurt Kayser wrote:
> They should raise their connectivity issue locally with their network
> provider that should fix the problem.
Uh, no... if someone has a bad ROA, and the NCC does RPKI ROV, that user
has no way to talk *to the NCC portal* anymore. And that is what would
be needed to actually "fix the problem".
OTOH I'm with Erik here - if someone messes up their ROAs, they will
need to find an Internet cafe or a LTE hotspot to hook their laptop to,
and then they can access the portal again to fix it. So I wouldn't
worry too much about that situation.
Maybe the portal can have a double check added ("you connect from
IP 2001:db8::1234, AS 65003, do you really really want to add a ROA
for this network and AS 12345? It will kick you out of the portal!").
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
Re: [routing-wg] 2019-08 Policy Proposal Withdrawn (SLURM file for Unallocated and Unassigned RIPE NCC Address Space)
Hi, On Thu, Jul 09, 2020 at 04:18:35PM +0200, JORDI PALET MARTINEZ via routing-wg wrote: > 2) sending a new proposal > 2 is easier and faster probably. It is not a flooding, is a single proposal. > According the PDP there is no way the chairs can reject a proposal. Repeating the same proposal ad nauseam in the hope that it gets more traction the second time, or that people will tire of repeating their counterarguments again and again is misuse of the PDP. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] 2019-08 Policy Proposal Withdrawn (SLURM file for Unallocated and Unassigned RIPE NCC Address Space)
Hi, On Thu, Jul 09, 2020 at 04:11:25PM +0200, JORDI PALET MARTINEZ via routing-wg wrote: > You confirmed that is not stated in the RIPE-710 that the chairs can object > to publish a proposal and start the discussion. > > Anyway, this is the REAL FACT: the PDP doesn't allow the chairs to reject a > proposal. Again, this is not what I said. Jordi, if you had too much sun, please get some shadow, and do not try to make this into a "I CAN FLOOD THE PDP WITH AS MANY PROPOSALS AS I CAN WRITE!" contest. You can't. Even if it's not explitely written down. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] 2019-08 Policy Proposal Withdrawn (SLURM file for Unallocated and Unassigned RIPE NCC Address Space)
Hi, On Thu, Jul 09, 2020 at 03:59:10PM +0200, JORDI PALET MARTINEZ via routing-wg wrote: > Following the RIPE-710, this right CAN'T BE DENIED, as Gert has confirmed > yesterday. This is not what I said. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] 2019-08 Review Phase (SLURM file for Unallocated and Unassigned RIPE NCC Address Space)
Hi, On Wed, Jul 08, 2020 at 08:04:35PM +0200, JORDI PALET MARTINEZ via routing-wg wrote: > I may be wrong ... but I can't find any text in RIPE-710, where it sets any > filter by the chairs to accept a proposal, neither anyway for the chairs to > reject a proposal, there is only a pre-qualification of the most appropriate > WG. > > I'd actually this debate already with a previous RIPE chair a few years ago, > so I recall it very well. Indeed, it's not written explicitly, but as you well know, it's done that way - the proposer picks a WG to submit to, and the PDO asks the WG chairs if that is OK. An update to write that down sounds like a reasonable plan. (And it very obviously must be that way, otherwise a frustrated proposer can easily DoS a working group - which must be preventable) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] 2019-08 Review Phase (SLURM file for Unallocated and Unassigned RIPE NCC Address Space)
Hi, On Wed, Jul 08, 2020 at 04:32:00PM +0200, JORDI PALET MARTINEZ via routing-wg wrote: > I fully understand that the technical chairs can do that but also that > proposal can be resent, and this is what I've said. So, in my opinion under > that perspective, it is wrong that chairs take that decisions (even if the > PDP allows it), in the sense that it is a non-sense. Chairs take that > decision, and same authors or someone else, resend it and we never end. Chairs are free to not accept the proposal if it's being re-sent again and again with no material changes. Gert Doering -- with some exposure to that -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] Ensuring RPKI ROAs match your routing intent
Hi,
On Thu, Jun 25, 2020 at 07:57:54AM -0700, Randy Bush wrote:
> you point out a serious concern, when creating a ROA will i do damage?
I see a few obvious mistakes
- fatfinger the origin AS, turn all my announcements from "unknown" to
"invalid"
- overlook length restrictions, turn all my more-specifics from "unknown"
to "invalid"
- overlook valid more-specifics originated from a different origin AS
("multihomed customer using part of my space")
> the way the DRL CA gooey has handled this for a decade+ is to have a
> full bgp dump and to compare the prospective new ROA to that dump.
This sounds like a good plan to avoid both types of mistakes.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
Re: [routing-wg] RPSL
Hi, On Thu, May 14, 2020 at 02:00:09PM +, ripede...@yahoo.co.uk wrote: > You are right, this has been an issue for many years. It is not only the > problem of parsing RPSL but also an issue with people understanding it as a > language and applying it correctly. But should this be an issue taken up by > the IETF? Or do you think the RIPE Database could/should do something > different to all other IRRs? Not sure this is something for the DB WG to press, indeed. I saw this mail in the routing-wg, which I find a more logical place to argue about "where do we want to go with RPSL?" - or maybe even push it to IETF. But I have no hopes for IETF, so maybe not. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] RPSL
Hi,
On Thu, May 14, 2020 at 09:52:06AM +, ripedenis--- via routing-wg wrote:
> Just a comment on the RPSL issue from the RIPE 80 session today. RPSL has
> little to do with the accuracy of data in the RIPE IRR. RPSL is just a
> language. Assuming you understand the language, it is your choice whether or
> not you maintain your data and keep it accurate and up to date.
Right.
That said, the data quality regarding import: and output: lines in the
RIPE DB is so poor that "bad and useless" is not halfway sufficient
to describe its badness.
I think import/export is beyond repair - it is too complex to correctly
parse, and at the same time not expressive enough to describe policy
precisely enough ("export to AS X as peer, no further upstreaming permitted"
vs. "export to AS Y as upstream, further distribution expected").
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi, On Sun, Nov 03, 2019 at 07:12:54PM +0300, Alexander Azimov wrote: > Let discuss the next scenario: there are two prefixes: x.x.0.0/24 and > x.x.1.0/24, first one assigned to an ISP, second - unallocated. The > proposal suggests that RIPE should create ROA with AS0 for x.x.1.0/24. Will > it stop an attacker from squatting this address space? > > The answer will be No. An attacker will still be able to hijack x.x.0.0/23, > which will have an 'unknown' status and will be passed on, as a result > finally capturing traffic for x.x.1.0/24. This is unfortunate. But indeed, it would make this change far less effective for the cases I had in mind. So I am reconsidering and joining the "it might be somewhat beneficial, but there are more important RPKI things to fix" camp. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi, On Fri, Nov 01, 2019 at 07:09:42AM +0100, Job Snijders wrote: > So we really have to wonder whether this is worth it, or whether a few > emails or phone calls can also solve the issue. Isn't that the whole question underlying RPKI deployment? What is it that we want to stop with RPKI? Only classic "prefix hijacking" (announcing space that is formally delegated somewhere) or other misuses of BGP, like "announce unallocated space, use that for spamming or other sorts of network attacks, withdraw announcement before people can track things back to you". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Hi, On Thu, Oct 31, 2019 at 07:10:02PM +, Job Snijders wrote: > 1/ What is the ROI? I think there is only a few prefixes in the > default-free zone that are managed by RIPE NCC, but not assigned or > allocated by RIPE NCC. So putting this machinery in place might not have > that much benefit, while the cost of 'getting it wrong' could be > substantial. This was my first thought as well, but then I discovered this IPv6 thing :) > 3/ Once the resource is assigned, the resource holder can create a ROA. > In the lifecycle of a resource it isn't clear to me what the benefit is > to have a ROA covering it when it is not yet assigned/allocated. It does stop people from announcing unassigned space and spam from it (because the announcement would be "invalid" and no longer "unknown"). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] Co-chair position
Hi, On Wed, Oct 02, 2019 at 08:40:25AM +0200, Paul Hoogsteder wrote: > I want to let you know that I'm available for the position as co-chair of > the Routing WG if you wish me to do so. Sounds like a plan :-) - support! Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] New on RIPE Labs: BGP Zombies
Hi, On Wed, Apr 24, 2019 at 08:06:18AM -0700, Randy Bush wrote: > > My conclusion then was that something along the following line happens > > > > - router R1 remembers where an UPDATE was sent to > > - export policy on R1 is changed, changing whether or not a given > >peer would receive an UPDATE for a given prefix > > - R1 receives withdraw from his best (and only) path, prefix is gone > > - R1 sends withdraw to "all peers it remembers" > > - and something goes wrong if that list of peers is not reflecting the > >real set of peers, possibly due to "BGP internal state not fully in > >sync between 'export policy is changed' and 'withdraw comes in'", so > >R1 is no longer aware that one of his neighbours received the prefix > >originally. > > believable conjecture. could and should be tested in lab. Indeed. > but does not explain the cases where we see stuck routes on devices > which have no config changes for a lng time (if you believe rancid). Well, in the scenario above, R1 would have the config change, but *on R1* the route would be gone. A downstream router R2 would have seen the initial UPDATE, but never received a withdraw - so R2 would claim "I have it, and I have it from R1!" while R1 would claim "no such prefix". So, no contradiction. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] New on RIPE Labs: BGP Zombies
Hi, On Wed, Apr 24, 2019 at 07:43:15AM -0700, Randy Bush wrote: > > And while i agree naming confusion is not good, what i care about most > > is that we understand this phenomenon better. > > and i am still waiting. we've seen them for 30 years. and we are still > no nearer understanding them than a conjecture that they are caused by > vendor bugs. > > on a sibling mess, duplicate announcements, folk did real expirments and > found some root causes. i am still waiting for that on stuck routes. One of the issues we found (Philip Smith and I) "back then" was indeed router bugs. The combination of "export policy is changed" with "an update is queued for this neighbour right then" led to control-plane confusion and missing withdraws. This was fixed. My conclusion then was that something along the following line happens - router R1 remembers where an UPDATE was sent to - export policy on R1 is changed, changing whether or not a given peer would receive an UPDATE for a given prefix - R1 receives withdraw from his best (and only) path, prefix is gone - R1 sends withdraw to "all peers it remembers" - and something goes wrong if that list of peers is not reflecting the real set of peers, possibly due to "BGP internal state not fully in sync between 'export policy is changed' and 'withdraw comes in'", so R1 is no longer aware that one of his neighbours received the prefix originally. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] source: RIPE may also contain invalid ROUTEs
Hi, On Wed, Oct 17, 2018 at 08:22:54PM +, denis walker via routing-wg wrote: > AFAIK there isn't yet any alignment mechanism, but it has been talked about > recently, and the cleanup proposal under discussion only applies to source: > RIPE-NONAUTH (but I'm not suggesting you extend it). Although this is a > corner case, it means you can't guarantee all the data in source: RIPE is > still authoritative. It is still authoritative in the sense of "we know that the owner of the address space authorized creation of the route(6) object". If they decide to have multiple different origins in the RIPE-DB, it's still *authorized* data - and there might be good reason (like preparing a move to a new origin AS, or just having moved and not yet cleaned up, etc). We might want to send the object owner a notification from RIS(?) if a conflicting ROA is detected, but I see no incentive to force-delete these objects. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] Fwd: Time to add 2002::/16 to bogon filters?
Hi, On Mon, Jun 18, 2018 at 06:23:28PM -0500, David Farmer wrote: > If you receive packets sourced from 2002::/16 where do you plan to send > responses? They are valid IPv6 packets and addresses. I can see only two ways to handle those - run a local relay to send 2002::/16 -> ipv4 world - drop these packets, hard > If you don't want to provide your customers with a route to 2002::/16 that > is your business, but recommending that 2002::/16 is a bogon mean no one > should accept or advertise the route which means no one can effectively use > 6to4. I'm happy to say that, but not without some data to back it up. No one *can* effectively use anycast 6to4, which was the whole point of the depreciation RFC. It needs to die, horribly, in flames. Anyone using it needs to feel the pain of enabling a broken protocol. ISPs need to have their customers call the help desk if they enable 6to4 on customer routers or in their own network, instead of deploying proper IPv6. (Note that 6rd is not "anycast 6to4" and as thus not subject to this rant) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] looking for online RPKI dashboard / looking glass?
Hi,
On Wed, May 02, 2018 at 06:11:23PM +, Job Snijders wrote:
> On Wed, May 02, 2018 at 08:07:16PM +0200, Gert Doering wrote:
> > The information I was looking for is nicely visible, though... and
> > what I was afraid I'd see... too much "N". The only "I" is something
> > I was aware but had forgotten about ;-) - a sink-a-more-specific-/24
> > test that nicely exposes the problem of "strict /22" ROAs.
>
> "problem" - just create a separate additional ROA for the /24!
I should have worded this as "the issue you run into if you create
a single ROA with a fixed length *and* then decide to announce
something else" - and indeed, since MaxLength opens room for
spoofed-source-with-more-specific hijacks, this is why we set up
our ROAs strictly.
> I recommend to make separate ROAs for everything you announce in BGP.
> The use of MaxLength is easily abused. See this Internet-Draft for more
> considerations:
>
> https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen
How would you recommend handling the case
"normally I only announce a /16, but in case one of our customers i
DDoSed, I want to announce the affected IP address as part of their
/24 out of upstream-that-does-regional-blackholing"?
If I create the /24 ROAs up front, I'm back in square one ("while I am not
announcing the /24, someone else could hijack with a faked origin AS").
If I do not create the /24 ROAs up front, I have propagation delays
(and might not be able to reach the RIPE RPKI tool at all while the
DDoS goes on).
*scratch head*
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
Re: [routing-wg] looking for online RPKI dashboard / looking glass?
Hi, On Wed, May 02, 2018 at 11:18:08AM +0200, Tim Bruijnzeels wrote: > If it???s just origin you???re after then this may help: > http://localcert.ripe.net:8088/bgp-preview This is cool :-) (It does not do "give me the full customer cone of AS ", but since the ASes I'm interested in rightn ow only have a few customer ASes anyway, it's definitely good enough) > This ???BGP Preview??? page lists the announcements seen by RIS Route > Collectors, does the RPKI analysis, and let???s you filter by IP or ASN as > you wish. It does not do any AS path inspection. It's definitely nice. And FAST! [..] > Also, you may know that we are getting very close now to releasing the RPKI > Validator 3.0. We are currently dealing with some minor last issue (related > to rpki-rtr and BGPSec keys) but we will have an official pre-production > release ready before RIPE 76 and I plan to present it during the Opensource > WG. The 3.0 version has a similar BGP Preview page. If you already want to > give it a spin you can find a link to the beta releases on GitHub, and please > let us know if you find any issues :) > > https://github.com/RIPE-NCC/rpki-validator-3/wiki/RIPE-NCC-RPKI-Validator-3-beta-tester-page Not promising anything right now, a bit busy... but thanks for the link. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] Historical routing question
Hi, On Wed, Apr 11, 2018 at 12:47:16PM +0300, Jorma Mellin wrote: > Hot-potato routing can definitely be the reason for such a low AD for eBGP. Since hot-potato only chooses "eBGP vs iBGP", AD has no relevance here. Unless you put your eBGP targets into your OSPF, and we all know that this is not a very good idea :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] Bogon ASN Filter Policy
Hi, On Tue, Jun 14, 2016 at 04:51:40PM +0300, Alexander Azimov wrote: > But I have security consideration that filtering isn't a proper mechanism > to reach this goal. Imagine next situation - if transit accidently prepends > its paths with private AS number it will result in DoS for all stub > networks connected to this transit. This is good. A transit ISP stupid enough to make such mistakes need to pay in blood and money. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [routing-wg] [db-wg] Solving the issue of rogue ROUTE objects in the RIPE Database
Hi, On Thu, Nov 12, 2015 at 12:00:11PM +0900, Randy Bush wrote: > > "Document everything one AS originates in a single database" is the > > primary motivation here (so upstreams/peers can go to a single source > > to build filters, and that single source must not be RADB). > > and why not? RADB? Because anyone can put arbitrary stuff in there and the operators seem more interested in selling maintainers (so you can protect your own objects that you have put in there, which shouldn't be there in the first place for RIPE region stuff). Now, if the RADB would only serve as aggregator for properly authenticated and sanitized objects from the 5 RIR IRRDBs, it would be useful. Right now, it is dangerous, because people building filters from it believe they are spending their efforts in a positive way. They are deluded, as anyone can circumvent these filters easily... (had this happen to a network of ours - the /22 was not announced yet, route: object entered into the RADB, announced for half an hour for spamming, merit refused to remove the rogue object because "please contact the people who put it in" even though it was perfectly clear from comparison with the mirrored RIPE objects that it was bogus). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpOPt7qPdNQE.pgp Description: PGP signature
Re: [routing-wg] Who uses the RIPE IRR and for what?
Hi, On Wed, Nov 19, 2014 at 06:31:56PM -0800, Ronald F. Guilmette wrote: Of the remaining 235,061 route base IP addresses, fully 28,988 of those (12.3%) are being announced by some AS other than the one specified in the ripe.db.route file. To state something that might be obvious or not - for the same prefix, you can have multiple route: entries with different origin ASes, which makes sense when a network moves (add new route: object, start new announcement, eventually remove old route: object). So, some of these might be perfectly fine, some might be forgotten (= a route: object with the proper origin AS exists as well), and some might just be legacy garbage - indeed. Given the considerable number of routing anomalies revealed by my simple experiment, I am inclined to wonder who is actually using all of that route information in the RIPE DB, and what on earth they could be using it for. We use it to build BGP filters for BGP customers. For those, the filter is build using the origin AS as key, so if there are additional route objects for the same prefix but with a different origin AS, our script won't see them, so it's garbage that does not disturb anything. Of course, if the origin AS doesn't match at all, customers' BGP announcements won't go out - and they usually notice that quickly and fix their stuff. (Our upstream providers do the same thing for us, so it's used on a larger scale - unfortunately, not all large transit providers do that, some just take the money and look the other way) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgp7zqd_m7yuW.pgp Description: PGP signature
