Subject: Re: [GROW] call for feedback on draft-ietf-grow-route-leak-detection-mitigation

From: Brian Dickson <[email-masked]>
Date: Fri, 14 Jun 2019 14:42:21 -0700

On Tue, May 28, 2019 at 9:27 AM Job Snijders <[email-masked]> wrote:

> Dear working group,
>
> We've received a handover draft from IDR - the draft was moved to GROW
> because it no longer specifies changes to the BGP protocol, but now
> specifies operational procedures. Earlier versions of the draft relied
> on a BGP Path Attribute.
>
> you can read the draft here:
>
>
> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation
>
> Your comments and feedback are welcome - if there is sufficient traction
> we can move the document forward in the publication pipeline.
>

I am in favor of this.
NB: I am co-author, and also co-author of the earlier work detailing what a
route leak is and how to know if something is a leak.

As the very recent China Telecom incident shows, these problems are
relatively common and won't stop by themselves.
This draft proposes a very simple and IMNSHO elegant way using a couple of
Large Community ranges that are easy to apply and use.
This is a fairly mature work at this point, notwithstanding some
re-organizing of the draft and trimming it for ease of review.

Please take a look and, if you think this is an important problem to fix
(route leaks), add your voice here.

Thanks,
Brian

P.S. Recent incident coverage, written up quite nicely:
https://blogs.oracle.com/internetintelligence/large-european-routing-leak-sends-traffic-through-china-telecom

P.P.S. I suspect that for widespread useful adoption, it will be necessary
to augment (Job's?) previous stuff on requiring an explicit non-default BGP
config to enable BGP sessions, to add an on-by-default sending of
well-known-communities and these new ranges of reserved-for-this-purpose
communities. But, that's subsequent work, and also safe, and a no-brainer,
IMHO.

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Jun 2019 20:59:20 -0700

speaking as a co-author, i don't much like this draft.  it was
originally a bgp attribute, now it is a community, the hammer which
makes everything look like nail, but does not actually fasten things
very well </allegory>.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 15 Jun 2019 13:22:48 +0300

> (route leaks), add your voice here.

there are two things here: route leaks (important), and the proposal in 
draft-ietf-grow-route-leak-detection-mitigation.  We can probably all 
agree that route leaks are a persistent threat.

What concerns me about this draft is that it takes an over-simplified 
view of real-life networks and there's not a small amount of implied 
pigeon-holing going on.  The difficult with the draft is that many 
networks don't fall into these neatly defined categories.  There are 
back-doors, partial transit configs, PNI arrangements, subnet leaks and 
all sorts of weird things out there, none of which are easy to 
categorise, but which nevertheless make up an important part of the 
routing ecosystem.

Characterisation of these edge cases is a difficult problem.  I'm not 
convinced this can be done adequately without an expressive grammar 
(note: not rpsl).  I'm also not convinced that the approach taken in 
draft-ietf-grow-route-leak-detection-mitigation is generic enough to be 
worth deploying.

Nick

---

From: Alexander Azimov <[email-masked]>
Date: Mon, 17 Jun 2019 00:14:20 +0300

Hi all,

My attitude for this draft has changed several times, so did for
communities vs attributes. But my current opinion can't be explained if I
speak solely about this draft.
There are three sets of documents that are related to detection and
mitigation of mistakes/malicious activity that may happen at the
interdomain routing level.

   - Roles + iOTC: leak prevention, makes configuration quite easier for
   small-medium networks. Adopted, nearly ready for WGLC, will take years to
   deploy widely.
   - ASPA: detection of mistake/malicious activity using RPKI objects.
   Adopted, active work on the draft, will take years to deploy widely (RIRs a
   major concern).
   - Leak detection using community. Adopted, the draft needs significant
   document restructure and clarification before WGLC. The main advantage of
   this work and usage of communities:* it can be deployed now *(at least
   in networks that do support large communities).

That's why I made a commitment to do my best in assisting with text. The
current goal - prepare it to WGLC it before meeting in Montreal.

сб, 15 июн. 2019 г. в 13:23, Nick Hilliard <[email-masked]>:

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

-- 
Best regards,
Alexander Azimov

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 17 Jun 2019 18:21:18 +0000

Nick,

Thank you for your thoughts on this.

This work has been in GROW / IDR since 2014.
Initially in GROW where we published a route leak problem definition RFC:
https://tools.ietf.org/html/rfc7908 

The work then moved to IDR for the route leak solution based on BGP Attribute.
It was moved back to GROW lately because IDR Chairs and others (authors + Ruediger)
felt that a solution based on Community would be deployable a lot faster
-- in months as opposed to years.

First, if you care you may offer your thoughts on Attribute vs. Community.

Second, I would appreciate if you can offer concrete examples of the scenarios
that you mention -- some examples where one saw those types of leaks occur in the real world.
As for the basic principles on which the solution is based, we essentially 
decided that we could readily address route-leak Types 1 through 4 of RFC 7908.
That is what the draft does. I don't think addressing route-leak Types 1 through 4
is narrow pigeon holing. As illustrated in RFC 7908, most real-world route leak
incidents seem to fall in the six types identified in the RFC. 
The RFC lists many observed route-leak incidents and categorizes them.
(Note: Types 5 and 6 are addressed by other solutions such as route filtering, RPKI, max prefix, etc.)
The subnet leak that you mention (AS path intact or AS path removed) was discussed in GROW 
and it was decided that was NOT a route leak type -- OTOH subnet leak is only addressable with ROAs 
and/or BGPsec path validation. GROW WG decided not to include it in RFC 7908
(although it was included in earlier versions of the definition draft).

Sriram

________________________________________
From: GROW <[email-masked]> on behalf of Nick Hilliard <[email-masked]>
Sent: Saturday, June 15, 2019 6:22 AM
To: Brian Dickson
Cc: [email-masked]
Subject: Re: [GROW] call for feedback on draft-ietf-grow-route-leak-detection-mitigation

Nick

---

From: Brian Dickson <[email-masked]>
Date: Mon, 17 Jun 2019 14:18:41 -0700

> First, if you care you may offer your thoughts on Attribute vs. Community.

My own (bpd) view on the attribute vs community is:

   - This is a canonical perfect vs good comparison
   - Deployment experience on Community would allow operators to reap the
   benefits with no required code changes
   - Follow-up work on a corresponding Attribute would be preferred
   - IFF/when sufficient vendor implementation and operator deployment of
   the Attribute exists, the Community can (should) be deprecated
   - Long-term, Attribute has better attributes
      - Mandatory propagation even if a given AS does not "speak" the
      Attribute
      - Distinct prefix attribute (vs overloading Community)
      - Avoid hitting limits within Community attribute (max number)
      - Orthogonality enables better/easier tool integration (automation
      stuff)

Second, I would appreciate if you can offer concrete examples of the
> scenarios
More specifically (pun intended):
Type 6 (leaks of more-specifics) are technically possible to handle, with
very minor modifications to an AS's advertisement policy for those prefixes.

(The assumption here is the more-specifics are advertised to an upstream
ISP for traffic-engineering purposes, but are not intended for distribution
beyond that ISP.)

The ISP's BGP session can be, for the purposes of ONLY THOSE prefixes, as a
"peer-only" connection, and the appropriate community ( RPL:DO=MY_ASN:NULL).
The ISP would need to have a policy of allowing prefixes from customers
whose community set included RLP:CUST_ASN:NULL, but not any other values of
RLP:*:*.
This would allow the ISP to send the more-specifics only to the ISPs
customers, but would block transmission of the more-specifics to peers or
transit providers, assuming the ISP implements this draft.
Further away than the upstream ISP, any third party receiving these marked
prefixes from a customer or peer would detect them as a leak. A third party
might be able to detect (and block) reception of leaked prefixes from its
own upstream ISP, depending on a variety of factors.

The main take-aways are:

   - The party implementing this on the receive-side (blocking prefixes
   based on the received community) benefits the receiving party (since it
   blocks leaks).
   - The party implementing this on the send-side (towards customers)
   benefits if/when any of their customers leak (or customers' customers,
   etc.), and the leak recipient (or upstream thereof) blocks the leak
   - The marking is a trivial policy: mark all outbound prefixes sent to
   customers and peers, with a single global (for your ASN) community
   - You do not mark prefixes sent to transit providers (upstream ISPs), or
   to "special" neighbors.
      - The presumption is that any marking that exists is preserved,
      allowing for treatment of a "cluster" of "special neighbors" as a single
      entity.
      - A marked prefix will generally come from an upstream ISP or a peer.
      - If any "member" of this "cluster" of "special neighbors" announces
      a marked prefix to an upstream ISP or a peer, that would be
detected by the
      recipient as a leak -- and legitimately so.
      - No extra logic is required for these "special" connections, beyond
      whatever is currently in place
   - The detection policy is equally trivial: don't accept marked prefixes
   from customers (with the caveat regarding the customer adding
   RPL:CUST_ASN:NULL, so the prefix can only be sent to your customers), or
   peers (except required RPL:PEER_ASN:NULL).
   - This is incrementally deployable, and those deploying gain immediate
   benefit (when deployed_count >1, obviously)
   - This is extremely compatible with automated build scripts and the
   like: a single outbound policy toward customers and peers; a simple
   two-entry inbound policy towards customers and peers tied to the neighbor
   ASN.

It might be helpful to white-board this, if anyone is interested, we can do
some kind of side meeting in Montreal.
(We authors have done extensive analysis, too much to present on-list,
IMHO.)

Brian

> Subject: Re: [GROW] call for feedback on
> draft-ietf-grow-route-leak-detection-mitigation
>

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 27 Jun 2019 19:41:13 +0000

>From: Brian Dickson <[email-masked]> 
>Sent: Monday, June 17, 2019 5:19 PM
  ... snip ...
>(We authors have done extensive analysis, too much to present on-list, IMHO.)

Authors-team discussion (design rationale) slides with extensive scenario analyses are here:
(some of it presented in IDR/GROW WG meetings)
https://www.nist.gov/sites/default/files/documents/2018/10/22/rlp_using_bgp_community-v4.pdf 

Sriram

________________________________________
From: GROW <mailto:[email-masked]> on behalf of Nick Hilliard <mailto:[email-masked]>
Sent: Saturday, June 15, 2019 6:22 AM
To: Brian Dickson
Cc: mailto:[email-masked]
Subject: Re: [GROW] call for feedback on draft-ietf-grow-route-leak-detection-mitigation

Nick