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

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

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 <[e-mail]> on behalf of Nick Hilliard <[e-mail]>
Sent: Saturday, June 15, 2019 6:22 AM
To: Brian Dickson
Cc: [e-mail]
Subject: Re: [GROW] call for feedback on draft-ietf-grow-route-leak-detection-mitigation

Brian Dickson wrote on 15/06/2019 00:42:
> Please take a look and, if you think this is an important problem to fix
> (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