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
> 
> 
> 


Reply via email to