Subject: [Sidrops] operator inputs -- route leak solution

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 21 Mar 2017 18:00:36 +0000

Inviting comments especially from GROW WG folk (network operators). 
Please look at this and address the question posed at the end. Thank you.

The most common form of route leak occurs when multi-homed 
customer AS-C receives a route from its transit provider AS-A
and leaks it to another transit provider AS-B.  
[RFC 7908  https://tools.ietf.org/html/rfc7908  ]

Customer AS-C is often the single point of failure.
AS-A and AS-B may be doing intra-AS community tagging etc. 
perfectly well to prevent route leaks, but AS-C does not and ends up leaking.
The leaked route propagates via AS-B to the rest of Internet 
due to prefer customer route policy.
(Example: Google/Hathway/Airtel leak -
https://bgpmon.net/what-caused-the-google-service-interruption/   
see many more examples in RFC 7908 )

A solution component for this has long been discussed in 
SIDR/GROW/IDR and well documented in IDR (see Section 4) 
( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06  ). 
The solution involves AS-A setting a field (in an optional transitive attribute)
in BGP update to indicate that 
(1) it is sending the route to a customer AS (or lateral peer), and 
(2) the route SHOULD be considered a leak if subsequently received
from a customer or a lateral peer.
This is one component of the overall solution.
It has been presented and discussed and I believe accepted
in SIDR/IDR/GROW over the last few years (at least since 2014).

Question: 
>From an operator point of view,
are you willing to place a piece of relationship info (as stated above)
in the BGP update for the significant gain of a route leak solution
that works well to detect/stop route leaks that do happen,
and prevents single point of failures in incremental/partial
deployment scenarios?

Sriram 

P.S. There is already immense BGP-derived public data out there on AS peering relations:

http://as-rank.caida.org/?mode0=as-info&mode1=as-table&as=3356&data-selected-id=39 

http://bgp.he.net/AS7018#_graph4

---

From: Gert Doering <[email-masked]>
Date: Tue, 21 Mar 2017 21:55:13 +0100

Hi,

> and prevents single point of failures in incremental/partial

I'm not sure it will do any good.

Those ISPs that care about the garbage their customers try to inject
already do prefix/as-path filtering.

Those ISPs that do not care today will not add bother to add a filter on
this well-known community value (... and most likely, the customer
router sending out unfiltered garbage won't have "send-community"
enabled either).

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: Brian Dickson <[email-masked]>
Date: Tue, 21 Mar 2017 15:19:42 -0700

Pre-emptive top-post in case anyone mistakes the technique proposed: This
will NOT be implemented via communities.

The proposal is for a NEW optional transitive attribute.

If any operators can answer the original question, this will be very
helpful. Thank you in advance to any and all operators.

Reminder on optional+transitive logic
- If the attribute is not understood/implemented/enabled, the attribute is
passed unmodified.
- If it is understood & implemented & enabled, behavior is subject to the
applicable standards.
- Thus, optional transitives are "opt-in", by definition.

The proposal itself is an IDR WG I-D, and as such not finalized; input here
is definitely helpful in reaching consensus, understanding requirements,
etc.

Brian

---

From: "Neil J. McRae" <[email-masked]>
Date: Tue, 21 Mar 2017 23:36:40 +0000

It seems a reasonable approach as long as it's kept as simple as described here.

Regards,
Neil.

> On 21 Mar 2017, at 18:00, Sriram, Kotikalapudi (Fed) <[email-masked]> wrote:
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Gert Doering <[email-masked]>
Date: Wed, 22 Mar 2017 15:33:03 +0100

Hi,

> - Thus, optional transitives are "opt-in", by definition.

It does not really matter if this is a well-known community or a new
transitive attribute.

If ISPs do not turn this *on* on their customer connections, it will not
do anything - and given that those ISPs that *need* to turn this on are
the ones that are not caring today, I'm still not seeing why they would
turn this on tomorrow.

So you're adding implementation complexity which will not help anything.

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 23 Mar 2017 00:10:42 +0200

> It does not really matter if this is a well-known community or a new

actually it does.  send-community is disabled by default on most ebgp
stacks.  Transmission of other transitive attributes is enabled by default.

Nick

---

From: Brian Dickson <[email-masked]>
Date: Wed, 22 Mar 2017 15:13:02 -0700

> the ones that are not caring today, I'm still not seeing why they would
There is direct benefit to partial (even very sparse) deployment.

The deployment is self-serving; whoever turns this on protects themselves
and their downstream customers.

This becomes a differentiator with direct benefits, and creates market
pressure to deploy.

Here's the simplest example showing how few parties need to implement this,
for benefit.
(Key: O = originator, T = top-tier ISP, L = leaker; number N disambiguates;
subscript y/n means "implements")

On1 - (arbitrary path) - Tn1 - (arbitrary path) - L - (arbitrary path) -
Tn2 - (arbitrary path) - On2

   - leaks in both directions pass without any tagging/blocking;
   - Path via L is preferred, because T1 and T2 prefer customer routes
   (which include L)
   - All traffic between Tn1 and Tn2 is affected (assuming L leaks the
   entire routing table)
   - In addition to latency caused by extra hops, there will likely be
   queueing-based latency, and significant loss

On1 - (arbitrary path) - Ty3 - (arbitrary path) - L - (arbitrary path) -
Ty4 - (arbitrary path) - On2

   - leaks in both directions are blocked, at Ty3 and Ty4 respectively
   - The leak is blocked despite neither On1 nor On2 activating the protocol
   - The actual path selected will be something else, possibly/probably:
      - On1 - ... - Ty3 - Ty4 - ... - On2
      - Since Ty3 and Ty4 both block the L routes (leaked) inbound, those
      routes are excluded
      - Assuming Ty3 and Ty4 peer, there will not be a better path
      respectively, modulo other peers with shorter AS paths to On1 or On2.

If both of the above paths (Tn1 - L - Tn2, and Ty3 - Ty4) are valid paths,
the following will be the case:

   - In all likelihood, there will be massive latency and packet loss, on
   the first path via L
   - The other path will not have that latency/loss
   - On1 and On2 will both be better served by
      - preferentially routing to Ty3 and Ty4 (apply better  local-pref
      inbound to Ty3 and Ty4)
      - preferentially announcing to Ty3 and Ty4 (prepend to Tn1 and Tn2)
   - On1 and On2 obtain benefit by being able route around L (the leaker)
   - Ty3 and Ty4 get benefit by having more traffic to/from their customers
      - Potential customers may choose Ty3 and Ty4 for those reasons
      - Networks who deploy on their own infrastructure gain similar
      benefits, even if they

All of the above presumes intermediate ASNs that do not implement (all of
the "arbitrary path" bits), yet there is benefit to all the named parties.

The same would be true for ASNs at Tier-2 who peer at various exchange
points, who implement; they would possibly position themselves better than
Tier-1's until any Tier-1's implement.

NB - ASNs who are upstream of L, but downstream of Ty3 and Ty4 would NOT
see the benefit, unless they also implement, so there is further reason to
implement for Tier-N, N>1.

FYI - I worked as a senior network engineer, where inbound peering ACLs of
other Tier-1 networks, allowed us to escape the AS7001 incident unscathed.
This scales a lot better, since there is no need for ACL maintenance.
Applying to customers/peers should be easy, assuming the ISP knows which
BGP neighbors are customers...

Brian

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Mar 2017 18:50:32 -0500

> The solution involves AS-A setting a field (in an optional transitive

glad you liked the attribute approach well enough to plagarize it from
our draft.  now you just need to change from misconfigurable statements
of relationships to plagarize the bgp open part of our draft and your
golden.

randy

---

From: Brian Dickson <[email-masked]>
Date: Wed, 22 Mar 2017 18:09:34 -0700

> of relationships to plagarize the bgp open part of our draft and your
Randy,

With all due respect, your draft fails to acknowledge the earlier work by
me (from 2012), outside of the recent drafts of which I am a co-author.

Specifically:
draft-dickson-sidr-route-leak-def (which became the basis for RFC 7908)
draft-dickson-sidr-route-leak-reqts
draft-dickson-sidr-route-leak-solns

So, perhaps it would be best to avoid claims of plagiarizing, when (a)
there is clear evidence that the source of the material predates your work,
and (b) when your work does not credit the original work by me.

Pot calling the kettle black, throwing stones in glass houses, and all that.

You might want to also read those (expired) I-Ds, to get clarity on
preserving leak prevention across "special" peering sessions
They also cover the ability to prevent leaks, without requiring the
disclosure of customer relationships -- something for which you have
expressed a strong desire.

FWIW, I will be working with my co-authors on the relationship-disclosure
detail.

Maybe we can schedule some white-board time in Chicago.

Brian

P.S.  It is "you're golden".

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Mar 2017 22:21:26 -0500

> me (from 2012), outside of the recent drafts of which I am a

apologies.  this should be corrected,

> and (b) when your work does not credit the original work by me.

word for word

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 23 Mar 2017 03:34:07 +0000

Randy,

To the response that Brian already offered, 
I would like to add the following with due respect.
Our version-00 working group draft was published July 22, 2015, and it stated:
"   The proposed RLP encoding SHOULD be carried in BGP-4 [RFC4271]
   updates in an optional transitive path attribute. " 
https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-00  
 
Your version-00 individual draft was published in March 2016. 

Sriram

---

From: Gert Doering <[email-masked]>
Date: Thu, 23 Mar 2017 08:50:08 +0100

Hi,

> and their downstream customers.

Those that are interested in doing so already do customer route filtering
today.

For those that are not interested, where's the incentive in starting to
do so if you have to do a software upgrade first (*and* the other upstreams
of your customers need to send this attribute)?

> This becomes a differentiator with direct benefits, and creates market

A-ha.  Right, exactly like "filter customer routes" is working today
to give "market pressure".

I always had the impression that *market* pressure is totally in favour
of "accept everything from the customer, send down the pipe whatever
you can, and then bill the customer for the traffic"...

Gert Doering
        -- NetMaster

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Mar 2017 08:54:28 -0400

Brian, Sriram and Randy: 

<IDR co-chair hat on> 

Let me suggest we take the rest of this discussion on these IDR two drafts offline from IDR.  The IDR Chairs noted  when the draft-ietf-idr-route-leak-detection mitigation was adopted  that there was overlap between you two documents.  We also noted interests in both technical approaches.  We asked to you provide a combined document that the chairs could present to the IDR WG.  This IETF is a wonderful time to work on this project.   Chicago has many fine establishments in which to discuss this combined document.   

I suggest we focused on the technical issues on the IDR mail lists.  For discussions of IDR on the grow list, I suggest that we listen to the valuable input from the operators on what their needs and ask clarifying questions.  

<IDR co-chair hat off> 

Thank you, 

Sue Hares 

From: GROW [mailto:[email-masked]] On Behalf Of Brian Dickson
Sent: Wednesday, March 22, 2017 9:10 PM
To: Randy Bush
Cc: [email-masked]; [email-masked]; [email-masked]; sidr wg list ([email-masked]); [email-masked]
Subject: Re: [GROW] [Sidrops] operator inputs -- route leak solution

Randy,

With all due respect, your draft fails to acknowledge the earlier work by me (from 2012), outside of the recent drafts of which I am a co-author.

Specifically:

So, perhaps it would be best to avoid claims of plagiarizing, when (a) there is clear evidence that the source of the material predates your work, and (b) when your work does not credit the original work by me.

You might want to also read those (expired) I-Ds, to get clarity on preserving leak prevention across "special" peering sessions

They also cover the ability to prevent leaks, without requiring the disclosure of customer relationships -- something for which you have expressed a strong desire.

FWIW, I will be working with my co-authors on the relationship-disclosure detail.

Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 23 Mar 2017 10:48:15 -0500

> the ones that are not caring today, I'm still not seeing why they would

not quite.  if ntt and l3 told fiber@home "on or befofe next jan 1st,
have draft-ymbk-idr-bgp-open-policy enabled," (as they do with route:
object reg); beyond that, l3, ntt, and fiber@home need to do no more.
it's all in the open.  the leak does not happen.

imiho, the other draft with the transitive eOTR attribute
(draft-ymbk-idr-bgp-eotr-policy) is not needed.  it is a way to diagnose
at a distance, and i prefer to stop at the source.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 23 Mar 2017 15:17:04 -0500

> Those that are interested in doing so already do customer route filtering

if god had meant us to fly in planes, she would not have given us
trains.  oh wait, americans don't have trains. :)

randy