Subject: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-reqts-02.txt

From: Brian Dickson <[email-masked]>
Date: Mon, 5 Mar 2012 19:32:25 -0500

Greetings, SIDR folks,

Here is the notice on the ID for the route leak "requirements" document.

Comments and feedback are welcomed.

Brian

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Mar 5, 2012 at 7:28 PM
Subject: New Version Notification for
draft-dickson-sidr-route-leak-reqts-02.txt
To: [email-masked]

A new version of I-D, draft-dickson-sidr-route-leak-reqts-02.txt has been
successfully submitted by Brian Dickson and posted to the IETF repository.

Filename:        draft-dickson-sidr-route-leak-reqts
Revision:        02
Title:           Route Leaks -- Requirements for Detection and Prevention
thereof
Creation date:   2012-03-06
WG ID:           Individual Submission
Number of pages: 8

Abstract:
  The Border Gateway Protocol, version 4, (BGP4) provides the means to
  advertise reachability for IP prefixes.  This reachability
  information is propagated in a peer-to-peer topology.  Sometimes
  routes are announced to peers for which the local peering policy does
  not permit.  And sometimes routes are propagated indiscriminantly,
  once they have been accepted.

  This document is a requirements document for detection of (and
  prevention of) route leaks.

  Together with the definitions document, it is intended to suggest
  solutions which meet these criteria, and to facilitate evaluation of
  proposed solutions.

  The fundamental objective is to &quot;solve the route leaks problem&quot;.

The IETF Secretariat

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 11 Mar 2012 17:47:23 -0400

Brian,

> Here is the notice on the ID for the route leak "requirements" document.

I am likely misunderstanding something in this document, but my
interpretation of it is that routes are always colored based on link role.

Consider some prefix, P, sent from AS 1 to AS 2 on two different links.
Link 1 is primarily used for peering traffic.  Link 2 is used for transit
traffic.  If I'm understanding the draft properly, routes received on Link 1
should not be propagated to AS 3 even though it's the same prefix (and path
attribute set) as P received on Link 2.  Is that correct?

-- Jeff

---

From: Jakob Heitz <[email-masked]>
Date: Sun, 11 Mar 2012 18:00:50 -0400

The essence IMO:

If A sends a packet to B,
then A must trust A's provider and B's provider
and by extension, their providers and so on.

A does not trust other customers of those providers
and does not want his packet transiting any of them.

Now, design the routing to make that happen.

--
Jakob Heitz.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Sunday, March 11, 2012 2:47 PM
To: Brian Dickson
Cc: sidr wg list
Subject: Re: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-reqts-02.txt

Brian,

-- Jeff

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

---

From: Brian Dickson <[email-masked]>
Date: Sun, 11 Mar 2012 20:44:41 -0400

> interpretation of it is that routes are always colored based on link role.
This is correct.

This is an extension of common operational mechanisms, where ISPs
frequently color route internally.

The distinction is, this coloring would be universal end-to-end, at least
where contiguous areas using the mechanism exist.

The down-side is, it is nearly impossible to bridge gaps where the
mechanisms are not used.

> attribute set) as P received on Link 2.  Is that correct?

Correct.

This is normally the case anyway, since routes can only be advertised to
AS3 if they are selected as "best".

This means that for transit to function, the customer side of the transit
link must be preferred over the peering link, in one direction.

Typically, in combined transit+peering relationships, the benefit is not
having the transit link used for "on-net" routes of AS 2.

And typically, the peering link is "settlement-free", so this reduces the
costs for AS 1.

Having the choice of link being determined by source address, is "policy
routing", which tends not to be supported at the hardware level.

The announcements at the inter-AS level (based on color) is independent on
the handling of routing and forwarding at the intra-AS level.

Coloring announcements based on link type, and restricting route
propagation based on color, does not preclude internal policy routing.

(This scenario was one that was explicitly analyzed in developing the three
documents.)

Brian

---

From: Brian Dickson <[email-masked]>
Date: Sun, 11 Mar 2012 20:51:21 -0400

> Now, design the routing to make that happen.
Thanks, that is a correct summation of what my documents are intended to do.

Link coloring identifies route leaks. Even if the enhancements to not
prevent intermediaries from propagation of route leaks, they make it
possible to identify route leaks.

However, without strong-ish enforcement for stopping propagation of route
leaks, non-leak paths may be suppressed (because only locally-selected
"best" paths get announced).

So, while it may mean a semantic tightening of the notion of "local policy
can do anything", the fact that changing link types (which in turn changes
link coloring) can accomplish everything that "leaks" can do, means there
isn't a strong case for adopting the "opt-in" mentality.

In other words, adding anti-leak techniques to the protocol spec, does this
("make that happen").

Brian

> Subject: Re: [sidr] Fwd: New Version Notification for