Re: [GROW] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation

["Jakob Heitz (jheitz)" <[e-mail]>]

Job, your suggestion kicks a different goal than
draft-ietf-grow-route-leak-detection-mitigation does.

draft-ietf-grow-route-leak-detection-mitigation tries to determine
if your neighbor leaked the route to you.
To do that, you need to know how your neighbor received the route
before he sent it to you.
That's what the ASN in the LC is for.

Regards,
Jakob.

-----Original Message-----
From: GROW <[e-mail]> On Behalf Of Job Snijders
Sent: Tuesday, March 9, 2021 11:59 AM
To: [e-mail]
Subject: Re: [GROW] An alternative approach to draft-ietf-grow-route-leak-detection-mitigation

Dear GROW,

(Removed sidrops@ from CC)

*Wearing a Working Group participant hat*

I reviewed draft-ietf-grow-route-leak-detection-mitigation-04 and it
appears to me there is a shortcut possible in the mitigation algorithm.
This shortcut in turn negates the need to specify any ASN in the "DO
Community". Only requiring a single community opens up the path to use
existing well-known RFC 1997 community as signal between BGP nodes.

The section 4.1 leak mitigation algorithm could be revised such that if
a route path present in the Loc-RIB is considered the best path and
eligible for export to EBGP neighbors, an additional verification step
is performed.

The sender could check whether a 'DO community' is present on the route
in the Loc-RIB, and if the to-be-exported-to EBGP neigbhor is configured
as a 'lateral Peer' or as 'Provider', the route is rejected in the PIB
(Policy Information Base) and thus will not be present in Adj-RIB-Out -
thus blocking a leak from happening. This places the route leak
mitigation solution one step earlier in the BGP 'supply chain' process.

There is an existing well-known BGP Community known as 'NOPEER
Community for BGP Route Scope Control', described in RFC 3765.

Similar to how the mitigation does not truly differentiate between
'Providers' and 'Lateral Peers' (if one considers routing policy puzzles
often can be solved through multiple different combinations of policy in
either of EBGP-IN, IBGP-OUT, IBGP-IN, EBGP-OUT.

The recommendation then simplifies to the following three steps:

1/ Recommend network operators to never strip the RFC 3765 Community
   upon receiving a BGP route from either an IBGP or EBGP neighbor.

2/ Recommend network operators to manually configure (or have BGP OPENv2
   speakers automatically) *add* the NOPEER Community (if it wasn't
   already present) to route paths received from a Lateral Peer or
   Provider. Then proceed with whatever Import Policy applies.

3/ Recommend network operators (or have BGP OPENv2 speakers
   automatically) block routes which contain the NOPEER Community from
   propagating towards EBGP neighbor marked as 'Lateral Peer' or
   'Provider'. The procedure stops.

4/ If the EBGP neighbor is *not* a 'Lateral Peer' or 'Provider', the
   route MAY be added to the Adj-RIB-Out specific to that EBGP neighbor.
   The NOPEER community is not removed (see step 1).

As Nick Hilliard pointed out earlier in this thread, there might be
business requirements which require the operator to override the
autnomous system's default policy, but as the NOPEER Community happens
to be 'just a BGP community', operators can do as they wish with the
received routing information. A case can be made that operators - by
default - would benefit from accepting the NOPEER community and based on
its presence prevent routes from propagating further towards EBGP
neighbors in the Peer/Provider class.

The above proposal is slightly different than the implementation
requirements stemming from honoring GRACEFUL_SHUTDOWN (where the
intention is for the inter-domain signal to be honored on EBGP-IN), the
NOPEER community essentially is best honored in EBGP-OUT policies.

Promoting inter-domain use of the NOPEER community by outlining how
correctly adding & scoping based on this community one can help mitigate
BGP route leaks. The NOPEER community being readily available in most
deployed BGP speakers for any operator wishing to use the mitigation
mechanism, this might make for a compelling argument.

In short 'Down Only' is equivalent to 'Not towards Peers & Providers:

  - in EBGP-IN set NOPEER on routes received from Peers/Providers
  - in EBGP-OUT block NOPEER routes from being announced to Peers/Providers

The above appears incrementally deployable, and compliant with the
specification of NOPEER, and can be promoted through Network Operator
Groups by converting draft-ietf-idr-route-leak-detection-mitigation to
target Best Current Practise (BCP).

Kind regards,

Job

_______________________________________________
GROW mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/grow