I would also support this change. Currently, on software that doesn't have this policy, I feel my only safe action is to install sessions disabled, ensure that an import and export filter is in place, and only then enable a session. Avoiding this action, and following draft-ietf-grow-bgp-reject makes this more convenient and safer for all I feel. There is something to be said for the disruption of default behavior change, but I think a major point release is one of the best opportunities to do this.
/Charles On Mon, May 1, 2017 at 8:36 AM, Stefan Jakob <tinysa...@gmail.com> wrote: > On 01.05.17 11:55, Job Snijders wrote: > > On Mon, May 01, 2017 at 11:45:58AM +0200, Ondrej Zajicek wrote: > >> On Sun, Apr 30, 2017 at 10:42:19AM +0200, Job Snijders wrote: > >>> On Sun, Apr 30, 2017 at 12:46:04AM +0200, Ondrej Filip wrote: > >>>> Let me announce a new addition to 2.0.x branch. > >>> > >>> Congratulations! > >>> > >>> Does this 2.0.0-pre1 version follow draft-ietf-grow-bgp-reject ? > >> > >> No, like 1.6.x, it has default policy of import all, export none. > >> > >> While i see that it is a good idea to have export none as default, i > >> do not see much advantage to have import none as default. > > > > I'd argue this is insecure behaviour and I'm disappointed you do not see > > an advantage. > > > > The default of "import all" fully relies on the EBGP neighbor not > > announcing crap to you. Relying on others to do the right thing means > > you are operating from a position of weakness rather then strength. > > I totally support the "default deny" pattern. This forces people to > think what they want to achieve. > > This pattern is used on lot of device classes like FW devices, > loadbalancers and even in router software like IOS-XR in most of the > corners. > > default deny +1 > > Imho, SJ > > > > > >
