Re: [Idr] [GROW] Choice of Large vs. Extended Community for Route Leaks Solution

[Brian Dickson <[e-mail]>]

On Thu, Apr 1, 2021 at 6:11 AM Jeffrey Haas <[e-mail]> wrote:

> [Note, commenting as an individual contributor...]
>
> On Wed, Mar 31, 2021 at 03:10:08PM -0700, Brian Dickson wrote:
> > On Wed, Mar 31, 2021 at 7:57 AM Sriram, Kotikalapudi (Fed) <
> > [e-mail]> wrote:
> > > We (authors of the WKLC draft) can continue working on creating an IANA
> > > WKLC registry for the future but I think the route leaks solution
> draft can
> > > switch to using Transitive Extended Community. Especially, if that
> could
> > > help expedite the route leaks draft and its deployment? I would like to
> > > seek advice regarding that (I'm cc'ing GROW also here).
> >
> >
> > Sorry to argue in public, but I disagree very strongly on the second part
> > here.
> >
> > We would like to continue proceeding with use of a LC range for
> > implementation, using a single (or small number) of Global Administrator
> > values.
> >
> > I think we should request that a small block of GAs surrounding the
> initial
> > assignments be tentatively marked something like Reserved for IANA
> > assignment.
> > That is different from actually establishing a registry or assigning them
> > specifically for WKLCs, but would be compatible with subsequent WKLC
> work.
>
> The issue being faced here for WKLC is a few related items:
> - There needs to be some number of global admin (AS) reserved for generic
> use.
> - Since this was not done at the time the feature was shipped, there is no
>   support in anyone's code to treat subsequently allocated ranges as
>   "special".
>


This is correct. However, I am making the claim that lack of special
handling in anyone's code is NOT a blocker to use by operators.
Specifically, the proposed route-leak-detection-mitigation LC range
(assuming a very small number of fixed GA values) would be able
to be used by operators for arbitrary LC matching, which would be
sufficient to implement the detection/mitigation mechanisms.

While code would facilitate automatically doing the mitigation stuff, it is
not the only way mitigation can be achieved.

Having GA values assigned for this is necessary. Having code is not
necessary, but would be desirable (and should be a long-term goal).

The code side of things is true regardless of mechanism used, BTW -- it
could be LC, EC, WC, new attribute, or anything like that.


>
> The two larger criticisms of the WKLC draft to date is that it wanted a LOT
> of the AS space to be used, and that its transitivity functionality would
> not fit well into an incremental deployment of the feature.  If the
> transitivity requirements are removed and the space is narrowed, that at
> least moves it closer to existing community operational practices.  E.g. a
> single AS allocated for the purpose that leaves two unstructured fields, or
> a small number of ASes.
>
> This then would require implementations that want to treat the new
> well-known fields as "special" to have code to do so.  So, we're already
> looking at some level of new code.
>

It is not necessary that this be done in code.

In fact, that is the precise motivation for using LC: no code is strictly
required.

Existing code for matching LC values is sufficient for operators to both
mark prefixes, and match LC values for implementing policy.

E.g. In vendor-agnostic pseudo-code:
IF(PEER_GROUP == MY_CUSTOMER && LC.GA == TBD1 && LC.VALUE1 == TBD2) THEN
DROP # Customer is sending us a marked prefix -- marked prefixes can only
be sent provider->customer
IF(PEER_GROUP == MY_PEER || PEER_GROUP == MY_TRANSIT) THEN ADD LC{LC.GA =
TBD1, LC.VALUE1 = TBD2, LC.VALUE2 = MY_ASN}


>
> Absent that new code, what we have is generic policy, along with the
> implementation's normal propagation behavior - which is behind a knob for
> some implementations.
>

This is correct.

>
> > The move to using LC values was precipitated by the observation that the
> > path for getting attributes deployed would be very long, and that
> operators
> > (actual network operators) are looking for a solution which can be
> deployed
> > *now*.
>
> If the state can fit into an extended community, that similarly can be done
> NOW.  A significant portion of the extended community space is available on
> first-come, first-serve basis.
>
>
> https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml
>
> But it doesn't change the above issues.
>
> > Nothing has changed in this regard; the WKLC draft is IMHO still the
> right
> > path, and only the size of the initial allocation is problematic.
> >
> > Having 1-4 GA values (from the 32-bit range of potential values) is not
> > burdensome IMNSHO, and is a lot less of a concern than the 1/64 (or 1/16)
> > of the range of 32-bit ASNs originally requested/suggested.
> >
> > If we can all agree that 1-4 GA values assigned for this is acceptable, I
> > suggest a revised version of the draft and assessment of consensus on the
> > revised draft for adoption and last call.
> >
> > LC is the ONLY viable path, given the nebulous state of implementation
> and
> > use for EC/WC or attributes. LC is already deployed, and assigning a few
> > GAs by IDR is the only roadblock to the draft in GROW getting approved.
>
> I question your conclusion.
>
> The desire is to have an attribute that is used for route leak mitigation
> purposes.
>
> This thread illustrates that it's very easy for such a control community in
> any flavor (regular, extended, large) to be stripped because the service
> provider hasn't proactively acted to permit it.
>
> Does this really solve the problem?


It solves the problem on an expedited basis.

It is not the exclusive solution, which would be to augment this initial
solution with additional mechanisms (e.g. codify WKLCs generally and this
WKLC specifically; codify the behavior using a new optional transitive
attribute or possibly mandatory transitive attribute).

What is also true about this (proposed mechanism + WKLC) is that there is
an incentive for providers (i.e. ISPs) to ask or tell their customers to
turn the knob on.

Having customers turn the knob on provides a convenient way to detect and
block route leaks.
Observe that any route leak from a customer, if not blocked by other means
or any means (e.g. if the ISP does not filter based on prefix or as_path),
harms the ISP directly.
Turning the knob on is comparatively easy, as it is a session configuration
element, rather than a policy mechanism.
ISPs who want to confirm that their customers have enabled the knob, can
provide further instructions to set an ISP-specific LC on routes the
customer sends, which can be used to validate that LCs are being sent.
(Ideally that should be a "test and remove" step, or a "confirm and apply
LC-stripping on the specific LC" so as to avoid causing more garbage being
sent to the DFZ.

Additionally, this range of WKLCs should never be seen within the DFZ. They
are only set when sending prefixes to customers. Any observed instances of
the GA can and should be addressed via non-technical (out of band, human to
human) processes, to get the leak stopped.

This is one of the rare cases where the problem and (however suboptimal)
solution are not asymmetric. The benefit is seen by the party doing the
thing rather than having to have someone else do the thing to get the
benefit.

Brian