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. And while today your peering partner may announce a pristine set of routes, tomorrow that might be different. Your EBGP peer could update their configuration, upgrade the software, or swap out their implementation for something with poor defaults. This can lead to surprises (outages) to both parties if they are not incentivized to ensure that both sides of the EBGP session make a conscience decision what to accept and what to reject. You may want to align with feela@ since it appears you have different opinions on the matter. Ondrej Filip told me that 2.0.x would be the right place for a change like this and earlier on committed to support this secure default behaviour. Kind regards, Job
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
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
On 5/1/17 8:12 AM, Charles van Niman wrote:
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.
In general I find it necessary to template safe by default import/export policy,and then apply more progressive policy, irrespective of platform. given that the minimal policy neccessary to over-ride a safe by default import policy is something like: accept; that seems like a pretty low bar.
/Charles
On Mon, May 1, 2017 at 8:36 AM, Stefan Jakob <tinysammy@gmail.com <mailto: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
On 01/05/17 17:27, joel jaeggli wrote:
On 5/1/17 8:12 AM, Charles van Niman wrote:
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. In general I find it necessary to template safe by default import/export policy,and then apply more progressive policy, irrespective of platform.
given that the minimal policy neccessary to over-ride a safe by default import policy is something like:
accept;
that seems like a pretty low bar.
I agree, and a major bump is the perfect time to do it! If necessary, converting existing configuration is also simple, the upgrade script can check for the presence of an import policy, if it's not there, then accept all is assumed, an explicit policy can be added for it during the upgrade. -- Wilco
participants (5)
-
Charles van Niman -
Job Snijders -
joel jaeggli -
Stefan Jakob -
Wilco Baan Hofman