Subject: [GROW] Possible Next Version of route-leak-detection-mitigation

From: Alexander Azimov <[email-masked]>
Date: Mon, 8 Jul 2019 18:06:15 +0300

Dear colleagues,

In the attachment, you can find a candidate to become the next version of
the route-leak-detection draft. It has changed that much, that authors
decided to discuss it in the WG before publishing it in the tracker.

The most important question that was reconsidered - what we should be done
with route leaks?

Previously we had hypotheses that certain circumstances we can't drop it
but should set pref to 0. The main reason was the next scenario:

   - The prefix must have a single path to Tier1;
   - The prefix must not have a less specific prefix with multiple paths
   Tier1;
   - The leak must affect this single path, so it must be inside single
   path to Tier1;
   - The prefix must be marked with leak detection signal;
   - Immediate ISP that accepts leak must learn it from its customer;
   - Immediate ISP that accepts leak must prefer leaked prefix;
   - Immediate ISP that accepts leak should not use leak detection;
   - Immediate ISP must keep detection signal;
   - The upper provider must use leak detection.

In this specific case, the leaked prefix may experience DoS. To fight this
theoretical scenario we suggested to use pref = 0 for leaks that are
learned from customers + additional signal to distribute information.

But such an approach has a tradeoff - if leak affects prefixes that are not
globally visible pref = 0 policy will not stop its propagation. It quite
realistic TE - a common control community is to restrict announcements of
prefixes to selected/all peers, more specifics that are sent only to IXes
etc.

The pref = 0 is also incompatible with future security solutions such as
ASPA and BGPSec - both will require to reject route leaks (pref = 0 can be
abused by mimicking more specific hijacks to route leaks).

So, taking this highly unlikely motivation for pref = 0 and quite a
realistic side effects, it is suggested setting quite simple default
policy: all route leaks must be rejected. With this, we can also drop the
second signal. It also gave us the opportunity to integrate leak detection
and prevention into one community. So, to summarize major changes:

   - A single community is used for both route leak prevention, and
   detection;
   - All route leaks MUST be rejected;
   - L is removed since we don't need it in this case.

We haven't reached consensus among the editors yet, that's why it is quite
important to collect broader feedback from the community. I have also
already asked WG chairs to reserve a slot for this discussion during the
next meeting.

PS: It 3.5 pages long, please read it!
-- 
Best regards,
Alexander Azimov

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 8 Jul 2019 15:24:09 -0400

Alexander,

>    - L is removed since we don't need it in this case.

A default policy of reject all leaks makes sense, I think.

I have a slightly different view of what has been called L above:
Programmatically determining that you are the network of last resort to not
cut off an ASes prefix is tricky.  This is what the NOC phones get used for.

What's somewhat desired, I think, is dealing with the result of that NOC
phone call: An attestation that a provider has permitted a detected leak.
Consider it an "override".

---

An aside question: For service providers that are "peer" types, how are
their own internal networks intended to be flagged?

-- Jeff

---

From: Alexander Azimov <[email-masked]>
Date: Mon, 8 Jul 2019 23:50:38 +0300

Hi Jeff,

> Consider it an "override".
If you are already calling it's better to call not the upper upstream
provider who dropped the leak, but the 'intermediate' provider who accepted
the leak.
Anyway, I'm planning to have another topology study and check how many
prefixes may be theoretically affected with such anomaly.

> their own internal networks intended to be flagged?
If I got your question correctly, there is no marking (or no additional
marking) before prefix is sent to 'external' neighbor. It is also true for
networks with multiple ASNs under control.

-- 
Best regards,
Alexander Azimov