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

From: Jared Mauch <[email-masked]>
Date: Mon, 20 Jul 2015 12:58:06 -0400

One of the major challenges that we face as a network operator is some of the legacy posture left in internet connected devices.  We’ve seen this history play out with many other protocols and services, such as enabling chargen, echo and other services on devices.  Having SMTP open relays, etc.

It’s time to document the changes and require them as part of the standard behavior of all BGP speaking devices.

https://tools.ietf.org/html/draft-mauch-bgp-reject

Is an attempt to capture the change that may be required by some implementors.

Already Juniper and IOS-XR have this default behavior of not sending any routes unless explicit policy is configured. It’s my understanding that it’s also the default in BIRD but I have not validated this myself.

I’m interested in discussion and feedback on this document.

- Jared

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 20 Jul 2015 17:11:14 +0000

Jared,

Really useful!
BCP seems to be more appropriate track though.

Cheers,
Jeff

-----Original Message-----
From: Jared Mauch <[email-masked]>
Date: Monday, July 20, 2015 at 9:58 AM
To: idr wg list <[email-masked]>
Subject: [Idr] draft-mauch-bgp-reject

>One of the major challenges that we face as a network operator is some of
>the legacy posture left in internet connected devices.  We¹ve seen this
>history play out with many other protocols and services, such as enabling
>chargen, echo and other services on devices.  Having SMTP open relays,
>etc.
>
>It¹s time to document the changes and require them as part of the
>standard behavior of all BGP speaking devices.
>
>Already Juniper and IOS-XR have this default behavior of not sending any
>routes unless explicit policy is configured. It¹s my understanding that
>it¹s also the default in BIRD but I have not validated this myself.
>
>I¹m interested in discussion and feedback on this document.
>
>- Jared
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr

---

From: Jared Mauch <[email-masked]>
Date: Mon, 20 Jul 2015 13:16:47 -0400

Thanks.  This is trying to capture a well known issue and my first
attempt at editing XML myself directly, so please be a wee bit kind when
it comes to the formatting and such.  I am happy to take flames as well,
including in-person should someone have concerns on this.

This is mostly documenting the existing behavior by vendors to keep
the routing ecosystem secured and stable.

- jared

> On Jul 20, 2015, at 1:11 PM, Jeff Tantsura <[email-masked]> wrote:
> 
> Jared,
> 
> Really useful!

---

From: Job Snijders <[email-masked]>
Date: Mon, 20 Jul 2015 19:24:27 +0200

Hi Jared,

On Mon, Jul 20, 2015 at 12:58:06PM -0400, Jared Mauch wrote:
> Already Juniper and IOS-XR have this default behavior of not sending
> any routes unless explicit policy is configured. It’s my understanding
> that it’s also the default in BIRD but I have not validated this
> myself.

I double checked, BIRD is halfway compliant with the draft, the default
is to accept anything and announce nothing:

    $ sudo birdc6 show protocols all | grep filter
      Input filter:   ACCEPT
      Output filter:  REJECT

I'll make an inventory of commonly used platforms.

Kind regards,

Job

---

From: "Russ White" <[email-masked]>
Date: Tue, 21 Jul 2015 03:23:25 -0400

> https://tools.ietf.org/html/draft-mauch-bgp-reject

Very useful -- I would strongly support this for BCP.

:-)

Russ

---

From: Shane Amante <[email-masked]>
Date: Tue, 21 Jul 2015 08:29:29 -0600

Jared,

This is a good draft ... 

Here's a suggestion to consider (or not).  I think you may should be
more specific and prescribe (to BGP implementors) what it means to for
"an operator configuring a policy" to allow receipt or sending of
routes.  Perhaps you wish to say that the routes need to be marked as
"unfeasible" (as per RFC 4271) and thus not considered by BGP for path
selection and potential subsequent advertisement in or beyond the
receiving ASN.

And, now for a more controversial recommendation.  More specifically,
perhaps it's time to (more seriously) consider additional, default
fail-safe mechanism(s) in BGP.  Specifically, what if the _default_
behavior for eBGP learned routes was to tag all received routes with the
standard BGP NO_EXPORT community? In theory, that would obligate an
operator to configure a policy that matched on routes and stripped
NO_EXPORT at eBGP boundaries to send routes to neighboring ASN's.  I can
already hear vociferous complaints the above is much too heavy of a
hammer, particularly when it comes to incremental software upgrades in
large ASN's and the subsequent negative ramifications to operators that
don't read Release Notes, etc.  If that's the case, then what if instead
there was a proposal for a new, standard BGP community called, i.e.:
NEW_NO_EXPORT, which would have a different code point from NO_EXPORT,
but the same properties as NO_EXPORT?  IOW, legacy BGP implementations
would not notice and act upon the NEW_NO_EXPORT community, thus not
creating a dramatic "surprise" on operators.  However, as new routing SW
with NEW_NO_EXPORT gets deployed we incrementally accrue the proper
scoping of routes within an ASN and more gradual improvement in routing
hygiene.

-shane

On Mon, Jul 20, 2015, at 10:58 AM, Jared Mauch wrote:
> the legacy posture left in internet connected devices.  We’ve seen this
> It’s time to document the changes and require them as part of the
> routes unless explicit policy is configured. It’s my understanding that
> it’s also the default in BIRD but I have not validated this myself.
>

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 21 Jul 2015 15:37:01 -0400

(in general I like the proposal as is, shane makes a fun second
option, more below)

> standard BGP NO_EXPORT community? In theory, that would obligate an

why not 'no_advertise' ? why even let the listener send it beyond
itself at all? It's pretty clearn when your whole AS can't hear the
new peer that you messed up.

(slice/dice with NEW_No_Advertise as you will...)

note that any of these solutions does mean that me seeing 'no-export'
to you (or the ability of me to do that that already exists and might
already be used) means policy bits get 'more complicated' because now:
  "if no-export;
     set no-export internal-community etc...
  else;
     delete no-export
  done'

which seems weird... maybe the proposal is some 'hidden' policy such
that once ANY policy exists 'no-export' is just regular no-export...
that seems sane enough.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Jul 2015 21:45:57 +0200

I guess one needs to first answer what does it mean to configure a policy ?

I can already see sys-wish requests for global knob:

*"bgp policy [send | receive | both] all" *

just like we have been typing "no synchronization" for ages. If not vendor
knobs YANG will likely have such construct either standardized or developed
in house.

Assume such knob will show up - how much does this help to the original
issue ?

Thx,
Robert.

On Tue, Jul 21, 2015 at 9:37 PM, Christopher Morrow <[email-masked]
> wrote:

---

From: Shane Amante <[email-masked]>
Date: Tue, 21 Jul 2015 15:34:44 -0600

Chris,

> new peer that you messed up.

IMHO, I think declaring the route as "unfeasible" means it's not even
used for forwarding by the local router that first receives it without
an explicit action on the part of the operator to enable it to be
advertised further within their ASN.  

>      set no-export internal-community etc...

Good point.  This may another reason why we want to define NEW_NO_EXPORT
that is specific to this new default policy of not advertising routes
learned by your ASN, from external peers, to propagate outside your ASN,
toward external peers.

-shane

---

From: Jared Mauch <[email-masked]>
Date: Tue, 21 Jul 2015 17:43:33 -0400

> *"bgp policy [send | receive | both] all" *

	Something as simple as:

route-policy accept-all
  pass
end-policy

policy-statement accept-all {
	then accept;
}

	I'm not asking this be complex.  As mentioned IOS-XR
already has a directive to disable the default secure
behavior.  I think it's clear this is not recommended
by the command name:

bgp unsafe-ebgp-policy

>From the Cisco documentation:

--snip--
External BGP (eBGP) neighbors must have an inbound and outbound policy 
configured. If no policy is configured, no routes are accepted from the 
neighbor, nor are any routes advertised to it. This added security measure 
ensures that routes cannot accidentally be accepted or advertised in the 
case of a configuration omission error.
--snip --

My intent is to codify this has part of the BGP standard.  Knowing
that Cisco, Juniper and others already recognise the security risk is critical
guidance for other implementors.

> knobs YANG will likely have such construct either standardized or developed

	Sure, or things like "bgp redistribute-internal" which are
undesirable in many environments but may be necessary for
network transitions.

> Assume such knob will show up - how much does this help to the original

	I'm not sure what your proposed knob is as this is documenting
the default for IOS-XR, JunOS and others that have recognised this
risk.

	A common issue we see is customers having no policy configured
and reflecting the full table back to us, or sending us the full table
of their other upstreams as a result.  Examples of this are observed in 
data over the past 8 years collected and documented as part of the
route leaks draft.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Dorian Kim <[email-masked]>
Date: Tue, 21 Jul 2015 17:49:14 -0400

Shane and Chris,

> On Jul 21, 2015, at 5:34 PM, Shane Amante <[email-masked]> wrote:
> 
> Chris,
> 

Since the semantics of NO_EXPORT is well established and the behavior you’d want
here is orthogonal to the behavior the existing NO_EXPORT community, I think you’d
want to come up with a complete new community label such as SUPPRESS or REJECT.
I don’t think we have anything to gain from overloading an existing label with a new
behavior or meaning.

One advantage I can think of with your idea compared to the original is that if you advertise
routes with a tag that declares them unfeasible, the peer can still potentially see the
misbehavior without have that negatively effect their forwarding and perhaps poll/monitor
for such to for human intervention.

Having said that I’m ambivalent as to whether this is a better option than the original 
proposal.

-dorian

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Jul 2015 23:49:59 +0200

​Hi Jared,​

> data over the past 8 years collected and documented as part of the

​No doubt.

I am also very much aware about difference of XR/JUNOS vs IOS-XE BGP
behavior.

But my point was that those who do not care to filter ​will just likely
configure a global knob so you will still be receiving full tables of their
upstreams.

So while I am all for documenting it in IETF and even more in
Nanog/RIPE/*NOGs perhaps we need to try to go a bit further and apply
penalty to sessions which send you junk and you recognize it.

Thx,
r.

---

From: Jared Mauch <[email-masked]>
Date: Tue, 21 Jul 2015 17:56:56 -0400

> I am also very much aware about difference of XR/JUNOS vs IOS-XE BGP

	It would be my contention that software which is not
adhering to this best practice SHOULD adopt this measure, at least for
newly configured devices.  This is nothing new for vendors having lived
through the BGP_REORG days of IOS to end with the now more robust multi-afi
support.  The systems know the difference between an old config and a
new device without a config and result with different configuration
directives and defaults as a result which do not compromise the operation
of these networks.

> configure a global knob so you will still be receiving full tables of their

	People often drive without insurance or go outside in
weather improperly prepared.  We can't help people who ice fish
and cut the hole around their own feet.

> penalty to sessions which send you junk and you recognize it.

I'm glad you support this effort.  We do our best to filter customer
sessions despite some attacks on my $dayjob network for being
recently involved in routing leaks.  We all have troubles and reducing
the default behavior impact will make BGP more robust and easier
to troubleshoot across implementations.

	- Jared

---

From: Jared Mauch <[email-masked]>
Date: Tue, 21 Jul 2015 18:03:32 -0400

> I don’t think we have anything to gain from overloading an existing label with a new

	One common frustration I personally have with NO_EXPORT is that
on (for example IOS) when processing communities received by a peer
or customer, if you set any of your own communities and do not
specify "additive" it clears the NO_EXPORT community which is often
not what a operator expects.

	I received feedback releated to the default-reject stance
that other things should be default-on, such as send-community
and other directives that are often part of configuration guides.

	If we believe there should be directives to developers
for additional default behaviors, there is perhaps more work
here we can undertake.

	The lack of predictibility in implementations does lead
to operator confusion.

	- Jared

---

From: Jon Mitchell <[email-masked]>
Date: Wed, 22 Jul 2015 03:33:40 -0400

> This is a good draft ... 

Agreed and support pursueing this as a BCP.

> scoping of routes within an ASN and more gradual improvement in routing

I think this different proposal has limited additional benefit due to
it's added implementation and operations complexity.  The
implementations work to support this is more complex and since it
targets the same fix as making default behavior on TX/RX to be REJECT
(cause user to apply policy with proper intent) the value is very
limited.  If an operator would have this proposal after already their
implementation supports Jared's proposal, the only additional protection
this provides is they applied the wrong policy on inbound peering.
Since an ASN does not actually align with organizational boundaries in
many cases (Private ASN's, etc..) there are many cases where a large
number of their policies will start with the removal of this community
on inbound and tag with a "send to internal/customers" or "send to
peers/transit" community (unless you are also supposing that an operator
can only manipulate this on TX).  If so, this only protects you from
using the wrong policy if it doesn't contain strip of the added
community.  Also, for the most basic of BGP users, having to do
community manipulation at all seems a bit problematic if their policies
today are only aspath or prefix based (which is a perfectly legitimate
way to do filtering).

-Jon

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 22 Jul 2015 15:37:38 -0400

> advertised further within their ASN.

ok, sure, but 'no-export' really means 'send to your whole ASN and use
(if appropriate) but don't pass outside your asn' ... unless you mean
the route is percieved by the receiver as 'has no-export already so
should be infeasible'.

which is another level of cranking the lever over 'no-advertise'.

> learned by your ASN, from external peers, to propagate outside your ASN,

I'm open to discussion, yup.... I think there are likely lots of ways
to solve this, though I bet we don't want 'least surprise' problems...
your comment about infeasible is intriguing, what if all routes were
simply 'infeasible' if there were no policy on the ebgp peering?
(still a naive user might look at 'show bgp neighor' and 'show route
received-protocol bgp' and ... wonder why: "I see routes, why no
routes accepted?"

-chris

---

From: Jared Mauch <[email-masked]>
Date: Wed, 22 Jul 2015 17:54:37 -0400

> which is another level of cranking the lever over 'no-advertise'.

	Yes, but this is certainly drifting OT from the 
draft in the subject line.  My goal is to specify for developers
the default operation of a BGP speaking device to start
in a secure/safe operating mode.  Too often we face peering
partners who turn up a new device missing policy which
has dire consequences.  There have been several recent issues
that appeared in operator forums as a consequence of these
unsafe defaults.  This necessitates informing the developers
of the risks and fail-closed/fail-secure mode necessary.

	Even IOS Clasic/IOS-XE has an open defect to change
this operation to make this the case.

> received-protocol bgp' and ... wonder why: "I see routes, why no

	This is not a new problem as customers without the
unsafe-ebgp knob or similar need to solve.  I'm sure the training
courses and examples on the websites will help the operator, as well
as professional services.  That does seem outside the scope as that
is not a new problem.

---

From: Job Snijders <[email-masked]>
Date: Thu, 23 Jul 2015 07:52:39 +0200

On Wed, Jul 22, 2015 at 03:37:38PM -0400, Christopher Morrow wrote:
> > Good point.  This may another reason why we want to define
> > NEW_NO_EXPORT that is specific to this new default policy of not
> > advertising routes learned by your ASN, from external peers, to
> > propagate outside your ASN, toward external peers.
> >
> 

Yes, you could store the information received from the BGP peer in
Adj-RIB-In and mark it as 'not valid'. To me that is the same as
rejecting.

I am not in favor of using NO_EXPORT / NO_ADVERTISE in this context,
either one hints towards "kind of accepting" rather then rejection.

Kind regards,

Job

---

From: "Thomas Mangin" <[email-masked]>
Date: Thu, 23 Jul 2015 09:25:12 +0100

> Adj-RIB-In and mark it as 'not valid'. To me that is the same as

I prefer this behaviour to not accepting the routes at all.

> either one hints towards "kind of accepting" rather then rejection.

I agree with this position.

Thomas

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2015 10:52:59 +0200

Hi Jared,

Two more comments ...

1.

I think your section 3 should explicitly state that this recommendation/bcp
applies only to SAFI 1 (maybe also SAFI 2).

In other words if I peer eBGP VPNv4 the policy is build into the SAFI 128
of rejecting on intersecting RTs.

Likewise if I eBGP peer with RTC or FlowSpec it would be either interesting
to come up with interesting inbound/outbound policy unless it would be
send/receive all.

And there is many more SAFIs where constructing policy may require a BCP on
its own ;-)

2.

What would be example of inbound policy in case to peering with route
server in IX ?

Thx,
R.

On Mon, Jul 20, 2015 at 6:58 PM, Jared Mauch <[email-masked]> wrote:

> chargen, echo and other services on devices.  Having SMTP open relays, etc.
>

---

From: Job Snijders <[email-masked]>
Date: Thu, 23 Jul 2015 10:57:56 +0200

> What would be example of inbound policy in case to peering with route

Same as with any other eBGP session: If the IX operator did not
configure any policy: reject all import/export. Do you feel this is a
different scenario that deserves different approach?

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2015 11:06:39 +0200

Job,

But we are not talking about rejection based on the peer's policy being
present or not. It is presence of your inbound policy statement which will
trigger the rejection. You really do not know if peer has any policy or not.

/* For a moment I was thinking about adding capability but dropped that

I think IX is a bit different as if you are plugged in to optimize traffic
where you can via shortcut, have no peering relation with the other side
eBGP (skip transparent RS from the picture) then I am not sure how much you
can control inbound what you expect to get.

Best,
r

---

From: Job Snijders <[email-masked]>
Date: Thu, 23 Jul 2015 11:22:22 +0200

On Thu, Jul 23, 2015 at 11:06:39AM +0200, Robert Raszuk wrote:
> But we are not talking about rejection based on the peer's policy
> being present or not. It is presence of your inbound policy statement
> which will trigger the rejection. You really do not know if peer has
> any policy or not.
> 
> I think IX is a bit different as if you are plugged in to optimize
> traffic where you can via shortcut, have no peering relation with the
> other side eBGP (skip transparent RS from the picture) then I am not
> sure how much you can control inbound what you expect to get.

This proposal does not require communication between peers about whether
policy is present or not. If I connect a device to any eBGP speaker, and
I did not configure any policy applied to that neighbor, my device MUST
not accept or advertise any routes. This principle applies to all BGP
speakers (including a Route Server). It is a local (to the device)
decision only.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2015 11:23:58 +0200

Of course.

I was just commenting on your sentence:

"If the IX operator did not configure any policy: reject all import/export."

Cheers,
R.

---

From: Job Snijders <[email-masked]>
Date: Thu, 23 Jul 2015 11:31:18 +0200

> "If the IX operator did not configure any policy: reject all

Good to hear we are on the same page.

A Route Server without any policy sounds like a dangerous thing, I
strongly suspect every route server deployments in the wild has /some/
policy applied to all peers, if only to offer the participants a degree
of propagation control. IX operators use BIRD or Quagga, and therefor
imho just fall in the "BGP speakers" category, like any router.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2015 11:34:40 +0200

But I am not talking about RS in the point #2 at all :)

I am talking about the client side connected via such transparent RS to a
some unknown peers in the IX "cloud" ... and asking what such realistic
inbound policy on the RS clients may be.

RS is a topic on its own.

Best,
R.

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 23 Jul 2015 14:32:57 +0200

> On Jul 23, 2015, at 11:34 AM, Robert Raszuk <[email-masked]> wrote:
> 
> 
> I am talking about the client side connected via such transparent RS to a some unknown peers in the IX "cloud" ... and asking what such realistic inbound policy on the RS clients may be. 

There are plenty of things worth filtering even from IX RS that I don't think that this needs to be called out specifically in the draft.

-Jon

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jul 2015 15:35:16 +0200

Well I wasn't asking to add it to the draft .. but just share on the list.

But I get your point ... it is a good practice to say always filter inbound
for example bogons.

Thx,
r.

On Thu, Jul 23, 2015 at 2:32 PM, Jon Mitchell <[email-masked]>
wrote:

> There are plenty of things worth filtering even from IX RS that I don't
> think that this needs to be called out specifically in the draft.
>
> -Jon
>
>

---

From: "George, Wes" <[email-masked]>
Date: Sat, 25 Jul 2015 21:21:01 -0400

I support the idea of this draft. I agree that it has an uphill climb when
it comes to implementation due to the impact of people who don't read
release notes and have a bunch of BGP stop working when they upgrade code
(or never see the change because they don't upgrade code), but I see the
value in harmonizing the default behavior to something that provides a
little better protection.

That said, I think that we may have an opportunity to go further. Policy
is only as good as the data feeding it, and there are plenty of ways to
have overly permissive policy once it's configured - this draft's
suggestion is only going to protect against "I forgot to apply my policy"
not "I refuse to put any effort into writing policy"

max prefix is often the first circuit breaker before you even get to
policy, but it's not consistently applied either. To that end-
1) Make max prefix a REQUIRED parameter on an eBGP session. (or do this
implicitly by recommending that the default for an eBGP neighbor without a
configured max prefix be an obscenely low number such as 2, or 500 or
something, so that small neighbors still don't have to do anything but are
protected. Warn in the logs if the max is close just like today. Yes,
people can still set an arbitrarily high max prefix by default to defeat
this but I'm hoping that at least in some cases the right thing happens.
2) Since part of the problem with max prefix is that it can be set far too
high to be effective, or someone has to be staring at the log to stay
ahead of it if it gradually grows, implement an on-by-default sliding
window "max-prefix auto" that looks at the last X sizes of the route
announcements from a neighbor, and sets a floating max prefix at a
user-configurable limit above it. Basically, it's watching for a sudden
increase of routes, could be as low as 25%, could be as high as 150% or
even 500%, depending on the size of the neighbor and how hair-trigger you
wanted it to be. It could even have a mode where it simply dampens those
routes with a high penalty rather than tearing down the session completely
as with a normal max-prefix limit exceeded. We're already sort of doing
this floating max prefix when we set max prefix to a calculated amount
above current steady state, and then increasing it when it warns in the
log that it's getting close to max prefix. This is very top-of-my-head at
the moment, and we'd probably need logic to prevent false positives where
you have an event that triggers a large withdraw so that the routes are
lower than usual, and then shortly after those routes are restored,
looking like a spike in route announcements. Might need to do it as a 24
hour high-water-mark or something.

The same sliding window limiter could be applied to outbound eBGP
announcements and be used to apply policy like others have suggested such
as NOACCEPT or NOEXPORT.

Thanks,

Wes George

On 7/20/15, 12:58 PM, "Idr on behalf of Jared Mauch" <[email-masked]

>I’m interested in discussion and feedback on this document.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.