Indeed. To re-iterate what I've been saying for quite a while... https://peering.readthedocs.org/en/latest/
=) M On 17 December 2015 at 14:54, Nick Hilliard <[email protected]> wrote: > I vote for Matthew. He who makes the complaint fixes the problem. > > Nick > > On 17/12/2015 14:18, Peter Knapp wrote: > > So whose volunteering to write the update?! > > > > Peter Knapp > > > > > > > > -----Original Message----- > > From: uknof [mailto:[email protected]] On Behalf Of Nick > Hilliard > > Sent: 17 December 2015 14:16 > > To: Matthew Walster; Gavin Henry > > Cc: [email protected] > > Subject: Re: [uknof] BGP configuration best practices from ANSSI and > others > > > > On 17/12/2015 13:51, Matthew Walster wrote: > >> 1. Don't use uRPF on a peering router, and if you are, loose mode > >> seems pretty dumb on a full transit router. > > > > on system which tie null0 into the urpf mechanism, this is a good means > of implementing s/rtbh. Strict urpf at a peering exchange is obviously > bananas, unless you're a leaf network or if you hate your customers. Fine > at the customer edge; useless everywhere else. > > > >> 2. Those are some really bad filtering examples, and if you just used > >> it as a factsheet there are missing entries which you may falsely > >> assume don't matter. Filtering all >/48 v6 prefixes seems a little odd > too -- why that size? > > > > same as /24 for ipv4: it stops people who accidentally leak their entire > interior routing table from causing damage to everyone else. > > > >> 3. TCP MD5 for BGP. They say it's not cryptographically secure, then > >> go on to say you should use a strong password. Which? How about just > >> using the > >> MD5 password as a prevention of fat-finger incidents as I imagine 90% > >> of people do (the rest assuming that it provides a level of security > >> it doesn't provide)? > > > > md5 for bgp is a good idea at IXPs. The reason why is that IP addresses > are re-used from time to time and unless you clean out your old peering > sessions regularly, you can potentially end up accidentally peering with > chancers who spoof old members' ASNs. Otherwise they're a bit useless, but > hey, if your security policy demands them, there's no reason to have a > fight about it. They're harmless. > > > > Nick > > > > > > > >
