Subject: Re: [RPSEC] BGP Requirements Draft

From: Sandy Murphy <[email-masked]>
Date: Mon, 26 Sep 2005 09:48:41 -0400 (EDT)

>Further, the counter proposal also would have 7018 declare exactly
>who is allowed to carry traffic for it, so my understanding is that
>$SOMEONE would see that 7018 did not authorise 1239 to carry traffic
>to it.

Well, yes, the counter proposal (the "route passed through every AS
in the AS_PATH" proposal) would catch it if 1239 said 7018 announced
something to it that 7018 did not announce.  But we're talking about
the path adjacency check here, which would not catch it.

--Sandy

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Russ White <[email-masked]>
Date: Mon, 26 Sep 2005 09:59:14 -0400

> the path adjacency check here, which would not catch it.

In the case of aggregation, it would not.

Further, it is possible for the path adjacency check to catch this, by 
adding various capabilities. You're trying to make an apples to oranges 
comparison.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Sep 2005 11:26:47 -0400

Russ,

You have used aggregation often in  examples, to illustrate the 
notion that it is legitimate to discard AS path info in normal 
operation.  That's true, but its also fair to note that a security 
mechanism is free to retain the info that is discarded today, to 
facilitate path validation, so long as the mechanism does this in a 
way that does not change the functioning of BGP. For example, the 
route computation algorithm  could still work with the aggregated AS 
path info, but the security algorithm would be able to verify that 
the aggregation was "authorized."

You have also noted that AS numbers appearing in sets are unordered, 
but I don't think that undermines the basic definition of an UPDATE 
traversing the indicated path. The text I cited explicitly refers to 
AS sets, not just sequences, and a reasonable interpretation of that 
text accommodates the processing to which you have alluded.

Steve

---

From: Russ White <[email-masked]>
Date: Mon, 26 Sep 2005 11:55:01 -0400

> You have used aggregation often in  examples, to illustrate the notion 
> that it is legitimate to discard AS path info in normal operation.  
> That's true, but its also fair to note that a security mechanism is free 
> to retain the info that is discarded today, to facilitate path 
> validation, so long as the mechanism does this in a way that does not 
> change the functioning of BGP. For example, the route computation 
> algorithm  could still work with the aggregated AS path info, but the 
> security algorithm would be able to verify that the aggregation was 
> "authorized."
> 
> You have also noted that AS numbers appearing in sets are unordered, but 
> I don't think that undermines the basic definition of an UPDATE 
> traversing the indicated path. The text I cited explicitly refers to AS 
> sets, not just sequences, and a reasonable interpretation of that text 
> accommodates the processing to which you have alluded.

Let's say I receive two routes:

10.1.0.0/24 via A,B
10.1.1.0/24 via C,D

Now, how would I build an aggregate for 10.1.0.0/23 that's "ordered?" I 
can't use [{A,B},{C,D}], since this implies {A,B} is "before" {C,D}, 
which isn't true. You can retain all the information you want to, but AS 
Sets are not ordered, because they just aren't.

The problem goes back to what you're trying to authorize. Are you trying 
to authorize me to send a bag of bits to my neighbor, or are you trying 
to authorize me to advertise reachability to networks you know how to 
reach? The point of BGP is the second, not the first.

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Sep 2005 13:26:40 -0400

At 11:55 AM -0400 9/26/05, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>

I said nothing about the members of an AS set being ordered. In fact 
I acknowledged that they were unordered, above.  Assume that the AS 
that received both routes (call it Z) wants to aggregate and 
advertise the /23 you cite. Then it could emit a route of the form:

	10.1.0.0/23 via Z, {A,B,C,D}

and that would be valid under the definitions provided in the BGP 
RFC. With a security mechanism that retained and forwarded the inputs 
(but hid them from the routing computation) the recipient of this 
route would be able to determine that Z received the two routes cited 
above, and determine that the resulting advertisement is legitimate.

Steve

---

From: Russ White <[email-masked]>
Date: Mon, 26 Sep 2005 13:56:50 -0400

>>>  but
> I said nothing about the members of an AS set being ordered. In fact I 
> acknowledged that they were unordered, above.  Assume that the AS that 
> received both routes (call it Z) wants to aggregate and advertise the 
> /23 you cite. Then it could emit a route of the form:
> 

 From this advertisement, how would you ascertain whether the aggregate 
was actually composed of:

- -- 10.1.0.0/24 {Z,A,B} & 10.1.1.0/24 {Z,C,D}
- -- 10.1.0.0/24 {Z,A,B} & 10.1.1.0/24 {Z,C} & 10.1.1.128/25 {Z,D}
- -- 10.1.0.0/25 {Z,A} & 10.1.0.128/25 {Z,B} & 10.1.1.0/25 {Z,C} & 
10.1.1.128/25 {Z,D}
- -- 10.1.0.0/26 {Z,A} & 10.1.0.64/26 {Z,B} & 10.1.0/128/25 {Z,C} & 
10.1.1.0/26 {Z,D} & 10.1.1.64/26 {Z,A} & 10.1.1.128/24 {Z,B}

Or any other of the practially infinite possibilities? There is 
precisely one way, and that is to carry all the routes that make up the 
aggregate as well as the aggregate, which means, in short, don't aggregate.

> and that would be valid under the definitions provided in the BGP RFC. 
> With a security mechanism that retained and forwarded the inputs (but 
> hid them from the routing computation) the recipient of this route would 
> be able to determine that Z received the two routes cited above, and 
> determine that the resulting advertisement is legitimate.

And the resulting system would collapse in about one day of real usage.

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Sep 2005 14:04:22 -0400

>And the resulting system would collapse in about one day of real usage.

My note said that security mechanisms can arrange to carry the data 
which is normally discarded in aggregation, which answers your first 
question above. This makes me wonder why you bothered to devote a 
dozen lines to posing the question.

Your response to my answer is trite, i.e., without any technical 
explanation you declare that any such solution would fail within a 
day.  Unsubstantiated assertions about technical matters are not a 
useful way to debate this issue.

Steve

---

From: Stefan Mink <[email-masked]>
Date: Mon, 26 Sep 2005 21:56:37 +0200

> And the resulting system would collapse in about one day of real usage.

I'm not an expert in aggregation, so I tried to get a feeling about
how many people actually aggregate routes non atomically. These are
the as-paths that have an non-empty AS-SET in the AS_PATH:

     3356 701 668 {13} I () Aggregator: 668 138.18.11.253
     3257 2497 2500 4725 11537 6509 {271 2884 7860 8111 26677} I Aggregator: 
6509 205.189.32.44
     3356 7381 {14033 14455 35938} I () Aggregator: 7381 216.83.181.33
     3356 701 7381 {14455} I () Aggregator: 7381 216.203.53.2
     3356 7381 {14455} I () Aggregator: 7381 216.83.181.33
     3356 14041 {12145 16519} I () Aggregator: 14041 192.43.217.5
     3356 14041 {16519} I () Aggregator: 14041 192.43.217.5
     1239 1239 13576 20412 {14507} I Aggregator: 20412 67.158.0.128
     3356 3549 30167 20412 {14507} I () Aggregator: 20412 67.158.0.129
     3356 4323 {18664} I () Aggregator: 4323 168.215.52.64
     286 3561 1299 8764 8764 8764 {31006 34037} I () Aggregator: 8764 212.59.0.33
     3257 702 22351 12455 {30994} I () Aggregator: 12455 62.24.96.162
     4766 3608 3608 3608 17832 {9494} I () Aggregator: 17832 202.30.89.71
     3356 7911 2552 {25662 25887} I () Aggregator: 2552 128.252.2.225
     3356 701 668 {132 3381} I () Aggregator: 668 138.18.11.253
     3356 6453 7491 {23862} I () Aggregator: 7491 210.23.232.5
     1239 1239 26134 {30060} I () Aggregator: 26134 10.171.0.3
     3356 10913 26134 {30060} I () Aggregator: 26134 10.171.0.2
     3356 4323 {11636} I () Aggregator: 4323 168.215.52.196
     3257 3561 26085 {14776} I () Aggregator: 26085 66.163.160.249
     3356 6517 {21953} I () Aggregator: 6517 172.31.22.3
     3356 701 30092 {174 13331 32286} I () Aggregator: 30092 66.154.120.1
     6939 14390 {27481} I (Atomic) Aggregator: 14390 209.163.112.8
     3356 4323 {30340} I () Aggregator: 4323 168.215.52.160
     3356 2914 4688 4688 4688 {18071} I () Aggregator: 4688 202.224.158.229
     3257 3549 26617 {17079} I () Aggregator: 26617 12.172.224.245
     1239 1668 10796 {11060 12262} I (Atomic) Aggregator: 10796 24.95.80.203
     3356 701 668 {22 5957 14077} I () Aggregator: 668 138.18.11.253
     3356 701 11486 {12156} I () Aggregator: 11486 206.112.65.129
     1239 5511 18747 {26596} I Aggregator: 18747 200.62.0.121
     3257 5511 18747 {26596} I () Aggregator: 18747 200.62.0.121
     1239 1668 10796 {11060 12262} I () Aggregator: 10796 24.95.80.207

so there aren't that many paths with an AS_SET in it.
Many paths have only one AS in the AS_SET - can somebody tell me
what is the background of this?

It would now be interesting to know how many routes are aggregated
insides these paths.

    tschuess
              Stefan
-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA

---

From: Russ White <[email-masked]>
Date: Mon, 26 Sep 2005 16:15:33 -0400

> the as-paths that have an non-empty AS-SET in the AS_PATH:

Certainly--but how many people use aggregation to aggregate? Most people 
don't use aggregates to aggregate routes.

:-)

Russ

- --

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Sep 2005 16:36:06 -0400

Stefan,

> so there aren't that many paths with an AS_SET in it.

I think this is consistent over the last five years or so.

> what is the background of this?

Some ASes may be removed due to private AS removal.
Some providers may be aggregating semi-internal (customer) routes.

> It would now be interesting to know how many routes are aggregated

Probably not so many.

Set aggregation has two huge problems that discourage its use:
1. Flapping aggregate contributors that cause changes to the AS_PATH
   may trigger route flap damping.  Given that the aggregate is realistically
   (in most cases) a new route, "brief" aggregation will help provide
   more stability.
2. Set-based paths inherently deny the aggregate to those who contribute
   to it.  When set aggregation is used, you must distribute all contributing
   routes back to all contributors.  Brief aggregation usually doesn't
   have this problem.  

   Not distributing the contributing routes also helps prevent sloppy
   policy by the contributing ASes from leaking the contributing routes.

-- 
Jeff Haas 
NextHop Technologies