Subject: [Idr] New Version Notification for draft-ymbk-idr-bgp-open-policy-02.txt

From: [email-masked]
Date: Sun, 13 Nov 2016 21:32:27 -0800

A new version of I-D, draft-ymbk-idr-bgp-open-policy-02.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:		draft-ymbk-idr-bgp-open-policy
Revision:	02
Title:		Route Leak Detection and Filtering using Roles in Update and Open messages
Document date:	2016-11-14
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-ymbk-idr-bgp-open-policy-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/
Htmlized:       https://tools.ietf.org/html/draft-ymbk-idr-bgp-open-policy-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ymbk-idr-bgp-open-policy-02

Abstract:
   Route Leaks are the propagation of BGP prefixes which violate
   assumptions of BGP topology relationships; e.g. passing a route
   learned from one peer to another peer or to a transit provider,
   passing a route learned from one transit provider to another transit
   provider or to a peer.  Today, approaches to leak prevention rely on
   marking routes according to operator configuration options without
   any check that the configuration corresponds to that of the BGP
   neighbor, or enforcement that the two BGP speakers agree on the
   relationship.  This document enhances BGP Open to establish agreement
   of the (peer, customer, provider, internal) relationship of two
   neighboring BGP speakers to enforce appropriate configuration on both
   sides.  Propagated routes are then marked with a eOTC and iOTC
   attributes according to agreed relationship allowing prevention and
   detection of route leaks.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Job Snijders <[email-masked]>
Date: Tue, 15 Nov 2016 13:40:27 +0900

Hi,

Reviewing this document, the following question came up:

Have you considered using two BGP Well-known Communities instead of
defining two new attributes 'IOTC' and 'EOTC'?

The advantage of well-known communities would be that one can
incrementally deploy the concepts described in the draft. It can quite
some time to deploy new software on all devices in certain networks,
while on the other hand deploying a new configuration is a much smaller
timescale.

For instance if router A supports 'OPEN', it can mark the routes with
the well-known community IOTC, and router B (which has no support for
'OPEN'), can be configured to act upon the well-known community IOTC.

I'd like to learn more about the considerations.

Kind regards,

Job

On Sun, Nov 13, 2016 at 09:32:27PM -0800, [email-masked] wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Nov 2016 13:41:44 +0900

> defining two new attributes 'IOTC' and 'EOTC'?

yes.  as it says in the introduction to the draft

   [I-D.ietf-idr-route-leak-detection-mitigation] describes a method of
   marking and detecting leaks which relies on operator maintained
   markings.  Unfortunately, in most cases, a leaking router will likely
   also be misconfigured to mark incorrectly.  The mechanism proposed in
   that draft provides the opportunity to detect route leaks made by
   third parties but provides no support to strongly prevent route leak
   creation.  The leak prevention still relies on communities which are
   optional and often missed due to mistakes or misunderstanding of the
   BGP configuration process.

randy

---

From: Job Snijders <[email-masked]>
Date: Tue, 15 Nov 2016 05:49:50 +0100

>    BGP configuration process.

No, the act of marking described in draft-ymbk-idr-bgp-open-policy-02 is
not manual from what i understand. The introduction text argues against
manual marking.

Also, the proposed 'BGP Internal Only To Customer' attribute is
optional, just like communities.

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 15 Nov 2016 00:54:31 -0500

> defining two new attributes 'IOTC' and 'EOTC'?

Some providers seem to strip even well known communities.  :-)

Path attributes deploy a bit more pervasively.  Modulo filtering, of course.

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Nov 2016 15:46:56 +0900

> Some providers seem to strip even well known communities.  :-)

no!  really?  and they never misconfigure them either, of course.

> Path attributes deploy a bit more pervasively.

and rigorously, when open insists that they correspond.

randy

---

From: Peter Hessler <[email-masked]>
Date: Tue, 15 Nov 2016 10:22:11 +0100

On 2016 Nov 15 (Tue) at 00:54:31 -0500 (-0500), Jeffrey Haas wrote:
:On Tue, Nov 15, 2016 at 01:40:27PM +0900, Job Snijders wrote:
:> Have you considered using two BGP Well-known Communities instead of
:> defining two new attributes 'IOTC' and 'EOTC'?
:
:Some providers seem to strip even well known communities.  :-)

As I understand it, this is only intended to matter for directly
connected peers so filtering can (and should) be done before any
stripping is done.

Of course, if a provider is stripping and ignoring even NO_EXPORT, then
you'll have the exact same problems as before.

-- 
The brain is a wonderful organ; it starts working the moment you get up
in the morning, and does not stop until you get to school.

---

From: Gert Doering <[email-masked]>
Date: Tue, 15 Nov 2016 10:25:05 +0100

Hi,

> Some providers seem to strip even well known communities.  :-)

These communities must not leave the local AS (because what is a 
customer prefix to one AS might be a *peer* to another), so stripping
on AS boundaries is a desirable feature.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 15 Nov 2016 19:18:44 -0500

[responding to this item in preference to the others]

> on AS boundaries is a desirable feature.

My sarcasm was missed.  Mostly, communities are not sufficiently safe from
meddling as part of *standard* operational procedures for them to be great
candidates for providing enforcement in this proposal.  As noted in other
conversations, mostly on grow in prior months, they're *sufficient* from an
encoding standpoint to make a start for this.

I support the idea of encoding this in path attributes mostly since it
insulates it better from accidental deletion.

With respect to your point about relationship differences, I'm not sure the
authors of the draft would agree with your assessment.  I'll leave it to
them to comment on the case in question.

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Nov 2016 12:03:05 +0900

> connected peers so filtering can (and should) be done before any

this may all be true, but is irrelevant.  this is not a community, but
an attribute; speifically to avoid my fat fingers.

randy

---

From: Job Snijders <[email-masked]>
Date: Wed, 16 Nov 2016 12:08:53 +0900

> an attribute; speifically to avoid my fat fingers.

yes, however a downside is that there is no "backwards compatibility",
in the sense that I can't implement it myself in routing policy and
require my vendor to give me new software.

Working group should be aware of that consequence.

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Nov 2016 12:11:25 +0900

> Working group should be aware of that consequence.

that's why it is in idr not grow.  our fat fingers have been making
negative news headlines for over two decades, and it needs to stop.

randy

---

From: Marco Marzetti <[email-masked]>
Date: Sat, 19 Nov 2016 14:53:08 +0100

Authors,

I really don't think that we should mix business relationships with
technical needs and, in any case, that you can narrow them down to
what's available in the draft.
Not that the draft is missing anything, but everything gets complex
and "not so clear" when it comes to sales or mutual partnerships.

My understanding is you aim to negotiate the relationship during
session setup so that "who's going to send what" is clear to
everybody.
Have you ever considered to remove that part and let operators to mark
the session as they prefer?

Regards

-- 
Marco

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 19 Nov 2016 14:59:02 +0100

Hi Marco,

What this draft is really about is to enforce by hard coding in RFC bgp
policy from ingress to egress of given network. And while the idea is
brilliant on surface I spoke with one vendor at the IETF who clearly said
"no way" we will provide knob to ignore that new attribute ... hence the
crux of the idea will be gone.

I think if we are really serious about route leaking 4271 should be updates
to add explicit few more BGP session types and by MUST enforce that those
can not be overwritten by local knobs or flags.

Best,
R.