[sidr] BGP behavior - changed or not? Was Re: route leaks message to IDR

[Brian Dickson <[e-mail]>]

I've given the issue (of whether the proposal(s) for mechanisms to stop
route leaks constitute(s) changes to BGP behavior) some more thought.

Here's how I think the _mechanisms_ can be characterized:

(The following presumes familiarity with the proposals. If you are
concerned about the issue of BGP behavior, I encourage you to read them.)


   - The proposals use "link coloring" (where "link" refers to a specific
   BGP peering session, with a particular policy that falls into one of four
   classifications).
   - A given "link" has a policy that is mutually agreed upon by the
   parties on either end of the link. Only if they agree, does the "link"
   (BGPSEC-enabled peering session) get established. The possible choices are
   fall-back to non-BGPSEC, or err-disable the peering session.
   - The "link policy" is one of four policies - transit, customer, peer,
   or mutual transit. The purpose of the policy is to put scope on what
   classes of routes are mutually agreed on as acceptable, in each direction.
   - The proposals include enforcement of the agreed-upon "link policy" at
   the protocol level, i.e. that they cannot be over-ridden by the operator.
   Only unmarked routes, or policy-matching marked routes, get sent (and
   accepted).
   - One of the four "link policies" is "mutual transit", which equates to
   "anything can be announced in either direction". So, in essence, if there
   is a need to announce routes that would be blocked by all other policy
   settings, _and both operators agree_, this policy can be used.
   - The set of four policies is consistent with any conceivable local
   policy / peering policy. More restrictions on what is announced or filtered
   can be applied on top of this policy mechanism.


Here is why I do not believe the mechanisms change BGP behavior:

   - _Both_ parties agree to (not send, or block upon receipt) certain
   classes of routes. This is the same in principal as "route filtering", and
   in particular RFC 5291, ORF (outbound route filtering).
   - The rules are to block routes received, which have the "color" applied
   to them (i.e. via BGPSEC with these enhancements), which violate the
   particular link color's restrictions
   - The rules are to block routes from being sent, if they would violate
   the link color vs route color restrictions
   - The doubling up of filtering (sender _and_ receiver) is consistent
   with best practices, and with the semantics of 5291
   - The _result_ is non-propagation of routes that constitute leaks, and
   this is the intent. However, the _mechanics_ involve only blocking routes,
   not modifications of forwarding of received routes
   - The specific restrictions on reception and advertisement of routes,
   _are_ local policy. It merely provides a stronger semantic for identifying
   leaked routes, and for implementing the desired local policy.
   - It does not prevent local policy from choosing and advertising routes.
   However, like RFC 5291, the recipient can advise the sender that routes
   would not be accepted, and the sender should not bother sending them.
   - It does not differ from RFC 5291 in terms of mechanical semantics.
   When the receiver would block a route (because of link coloring vs prefix
   color), the sender doesn't send the route.
   - If the rules were enforced by receiver-only, the semantics would be
   identical to BGP with filtering. The sender-blocking is an optimization,
   really. (And reduces overhead in terms of useless BGPSEC signatures.)

In essence, the information added is exactly analogous to what BGPSEC
already does - add signatures which permit validation of path data - with
one additional element, the ability to identify if/when announcements have
violated agreed-upon peering policy (and validate that that information has
not been modified).

The behavior of BGP is not changed. What is added is a coarse-grained
"knob" for local policy on a per-neighbor-session basis. Links which use
the knob, always apply color to routes that are accepted. Local policy
either blocks routes (on send and/or receipt) or allow routes.

The one critical requirement is that operators know the policy of a
particular neighbor BGP session. This requirement is borne out by
operational experience, and common sense. It passes the "smell" test
trivially.

IMHO, the consensus of the room was based on poor description of the
mechanisms, rather than the mechanisms actually causing new behavior. That
was my fault, and in part due to my remote participation.

However, the three IDs are meant to clarify this issue, and promote
discussion/evaluation of the appropriateness of including route-leak
protection into SIDR,  the rigor and precision of the definition of route
leaks, and evaluation of the requirements document.

In particular, I think a determination of whether the proposals do or do
not change BGP behavior, should be one of the goals of the discussions.

I would request that this last statement be incorporated, in some form or
another, in the message to IDR.

Sincerely,

Brian
On Tue, Mar 13, 2012 at 10:22 AM, Murphy, Sandra
<[e-mail]>wrote:

> In the interim meeting, the consensus was that we needed idr to be
> involved in any definition and solution for route leaks.  It was decided to
> discuss a message to the idr wg on the sidr list.
>
> Brian Dickson has submitted drafts about route leaks, as he offered in the
> meeting.
>
> So here is a first draft at a messate to idr.  Comments please.
>
> ==============
>
> The sidr interim meeting in February discussed the problem of route leaks.
>
> While those in the room could recognize route leaks in a diagram, they
> could not determine a way to determine that from information communicated
> in BGP.
>
> Proposals to stop route leaks add information to BGP updates that would be
> used to restrict the propagation of those updates by the neighbor onward to
> providers, customers, peers, etc.
>
> This is a change to BGP behavior, which now relies on local configuration
> only to choose a best path and advertise it.  Adding features to stop route
> leaks would restrict that advertisement and restrict what local policy
> could choose.
>
> The consensus in the room was that adding a new feature to a protocol as
> part of a security protection  (i.e., not just ensuring an already defined
> behavior but producing brand new behavior) is unwise and leads to problems.
>
> The sidr working group requests that idr discuss the route leaks problem
> with sidr and determine the best path forward.
>
> The idr wg should also be aware that drafts have been submitted about
> route leaks, so work is underway.
>
>
> http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01
> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-01
> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02
> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01
>
> ===================
>
> --Sandy
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr
>