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