Subject: [GROW] draft-mauch-bgp-reject

From: Jared Mauch <[email-masked]>
Date: Sun, 1 Nov 2015 23:18:55 -0500

I plan on covering this briefly in the GROW meeting today and uploaded the revised text that has been sitting in my output queue since August.

This is basically codifying the fact that you MUST NOT default to "bgp unsafe-ebgp-policy” for any BGP speaking device.

- Jared

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 1 Nov 2015 23:28:24 -0500

I recommend people read Jared's draft and provide comments on both IDR and Grow. 

Sue

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jared Mauch
Sent: Sunday, November 01, 2015 11:19 PM
To: [email-masked]; idr wg list
Subject: [Idr] draft-mauch-bgp-reject

- Jared
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Gert Doering <[email-masked]>
Date: Mon, 2 Nov 2015 10:37:33 +0100

Hi,

On Sun, Nov 01, 2015 at 11:18:55PM -0500, Jared Mauch wrote:
> This is basically codifying the fact that you MUST NOT default to "bgp unsafe-ebgp-policy??? for any BGP speaking device.

There is one item I don't understand here:

   o  Software MUST provide protection from internal failures preventing
      the advertisement and acceptance of routes

what does that mean (in other words "more verbose explanation, please")?

(All the rest is obviously the right way forward, so "support!" and "BCP!")

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 2 Nov 2015 10:14:36 +0000

On 02/11/2015 04:18, Jared Mauch wrote:
> I plan on covering this briefly in the GROW meeting today and uploaded
> the revised text that has been sitting in my output queue since August.
> 
> This is basically codifying the fact that you MUST NOT default to "bgp
> unsafe-ebgp-policy” for any BGP speaking device.

definitely support.

Long overdue.  Also, sad that we need to actually document something as
basic as this.

Nick

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 5 Nov 2015 11:19:40 +0900

> On Nov 2, 2015, at 6:37 PM, Gert Doering <[email-masked]> wrote:
> 

I expressed this concern to Jared verbally this week as well (was waiting for adoption which I support as stated previously).

-Jon

---

From: Jared Mauch <[email-masked]>
Date: Thu, 5 Nov 2015 00:48:51 -0500

> On Nov 2, 2015, at 4:37 AM, Gert Doering <[email-masked]> wrote:

Vendor software will actually fail-open and not honor the configured
policy.  I’d like to try and capture this case as implementation guidance
to prevent damage to the global internet.

- Jared

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 5 Nov 2015 18:38:39 +0900

Hi Jared,

​If you are up to fail-open on restart (I guess this is what you mean by
"internal-failures") and in fact in general regarding your entire draft IMO
the only way to really enforce anything of that scope is to update 4271
with the new eBGP rules and state machine.

Otherwise I do not believe that BCP will  be out of the sudden honored by
vendors. Also I do not think it will be justified to be accept globally as
an OS upgrade without such strong enforcement.

Thx,
r.

---

From: Gert Doering <[email-masked]>
Date: Thu, 5 Nov 2015 22:06:31 +0100

Hi,

On Thu, Nov 05, 2015 at 12:48:51AM -0500, Jared Mauch wrote:
> policy.  I???d like to try and capture this case as implementation guidance

So "if there is anything broken in the machinery, kill the bgpd before
you just let routes in or out in an uncontrolled fashion"?

Support :)

Gert Doering
        -- NetMaster

---

From: Rick Casarez <[email-masked]>
Date: Fri, 6 Nov 2015 07:16:17 -0500

This is interesting since it is definitely a best common practice for
operators to do points 1 and 3 on your list. Is the intention of this
document to enforce a BCP by allowing operators to point to a draft/RFC or
did you want to change how BGP works?

If you just want to document a BCP in draft form (eventually RFC) to use it
as a mechanism to force vendors to change their BGP code/daemons it might
work. Some vendors will have no issue conforming or adding it to their road
map. Although most can point to the fact it is really just a BCP draft and
ignore it unless there is a big surge in demand for conformance from their
customers. After all we all know some vendors who do not conform to RFCs.

If you want to change how BGP is implemented, and be able to more
forcefully push this change to vendors, then Robert is correct and 4271
would need to be updated.

So I guess I would ask you: which way did you want to go?

>>Software MUST provide protection from internal failures preventing the
advertisement and acceptance of routes
>"Vendor software will actually fail-open and not honor the configured
policy.  I’d like to try and capture this case as implementation guidance
to prevent damage to the global internet."

So let me ensure I understand this correctly. The point of this draft is to
protect the internet at large by ensuring policies are always in place. So
what you are saying is vendors should never fail-open correct?

-------------------
Cheers, Rick

Experiences not things.

On Thu, Nov 5, 2015 at 4:38 AM, Robert Raszuk <[email-masked]> wrote:

> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>
>

---

From: Gert Doering <[email-masked]>
Date: Fri, 6 Nov 2015 13:29:41 +0100

Hi,

> did you want to change how BGP works?

BCPs for operators exist (RFC7454 for a start).  

Implementations need to change, to "fail safe" - if not configured to do
so, neither accept nor send BGP prefixes on eBGP sessions.

[..]
> So I guess I would ask you: which way did you want to go?

If this is what it takes, updating 4271 sounds like a plan.

Gert Doering
        -- NetMaster

---

From: Rick Casarez <[email-masked]>
Date: Fri, 6 Nov 2015 07:44:31 -0500

I am willing to help either way.

-------------------
Cheers, Rick

Experiences not things.