Subject: Re: [RPSEC] proposed message to the IESG

From: Sandy Murphy <[email-masked]>
Date: Fri, 21 Jan 2005 12:11:35 -0500 (EST)

>-- A is allocated 10.1.0.0/16.
>-- A suballocates 10.1.1.0/24 to B.
>...
>Is the originator 
>authorized to advertise the address space in the route? In this case, A can 
>advertise 10.1.0.0/16, and the answer is yes, even though it actually 
>contains 10.1.1.0/24, for which the answer is technically no.

REALLY???????!!!!!!!!!!

I've never seen a suggestion that either in spec or in operational
practice, that allocating an address to someone removes your
ability to announce those addresses yourself.

Does this really truly happen in practice?  If so, this is a big
change to what I understood allocation to imply.  And it would
be a much bigger problem to try to secure such an interpretation
of allocation.  You'd not only have to securely distribute the
information of what you've been allocated but also the information
of what you've NOT suballocated.  That's not easy!

Are you really really sure that this is (a) current practice
and (b) desirable?

Realize that you are advocating taking on a very hard problem here.

--Sandy

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

---

From: [email-masked]
Date: Fri, 21 Jan 2005 18:52:44 +0100

> ability to announce those addresses yourself.

It depends on what the announcement is meant to convey.

If A suballocates 10.1.1.0/24 to B, A can no longer use 10.1.1.0/24
for its own purposes (obviously).

If announcement is meant to convey the right to use a particular bit
of the address space, A should no longer announce 10.1.0.0/16. I think
it is certainly fair game to discuss whether A is *authorized* to
announce 10.1.0.0/16 in this case. And yet, it is done every day, and
it works (due to longest prefix matching).

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Russ White <[email-masked]>
Date: Fri, 21 Jan 2005 14:38:56 -0500 (Eastern Standard Time)

>> Is the originator authorized to advertise the address space in the 
>> route? In this case, A can advertise 10.1.0.0/16, and the answer is yes, 
>> even though it actually contains 10.1.1.0/24, for which the answer is 
>> technically no.
>
> REALLY???????!!!!!!!!!!
>
> practice, that allocating an address to someone removes your ability to 
> announce those addresses yourself.

My point exactly. What's the correct solution here? Security wise, we have 
an ownership ambiguity. Operationally, we can't do business without doing 
it this way. It just won't scale.

> Does this really truly happen in practice?

"Some 59,000 advertisements, or 55% of the total number of routing table 
entries, are being used to punch policy holes in existing aggregate 
announcements." draft-iab-bgparch-02.txt

I think that pretty well sums the answer up, though the numbers are from 
some number of years ago, when a full table was about 120,000 routes. I'd 
actually expect the percentage is about the same, though, in today's table, 
and probably higher when you see a really large provider's table, in the 
range of 250,000 routes or more.

> Realize that you are advocating taking on a very hard problem here.

IMHO, it's not a solvable problem. In other words, it's logically 
impossible to solve, without requiring operationally untenable solutions. 
Two of the examples given in the path considerations draft are built around 
this problem, explicitely.

And this is the reason I say things get a lot harder when you start 
realizing updates aren't transitive, routing information is, and you need 
to ask questions about the routing information, rather than the path of the 
update. In short, if the way the data's arranged precludes certain types of 
security from being tenable, there's no sense is stating you can provide 
those types of security in a security requirements document. And that's the 
nub of the problem with claiming the ability to transitively authorize 
advertisement of prefixes (routes), rather than updates.... But, I don't 
want to go there, just point out that there are logical reasons why I don't 
think we can reach a concensus on the third question from my other email.

In any case, I'd rather not bury it by saying: "we'll secure the processes 
in the BGP draft, and assume the rest will just work."

:-)

Russ

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jan 2005 17:45:17 -0500

At 2:38 PM -0500 1/21/05, Russ White wrote:
>>>route? In this case, A can advertise 10.1.0.0/16, and the answer 
>>>is yes, even though it actually contains 10.1.1.0/24, for which 
>>>the answer is technically no.
>>
>>REALLY???????!!!!!!!!!!
>>
>My point exactly. What's the correct solution here? Security wise, 
>we have an ownership ambiguity. Operationally, we can't do business 
>without doing it this way. It just won't scale.
>
>"Some 59,000 advertisements, or 55% of the total number of routing 
>table entries, are being used to punch policy holes in existing 
>aggregate announcements." draft-iab-bgparch-02.txt
>
>I think that pretty well sums the answer up, though the numbers are 
>from some number of years ago, when a full table was about 120,000 
>routes. I'd actually expect the percentage is about the same, 
>though, in today's table, and probably higher when you see a really 
>large provider's table, in the range of 250,000 routes or more.
>
>impossible to solve, without requiring operationally untenable 
>solutions. Two of the examples given in the path considerations 
>draft are built around this problem, explicitely.
>
>realizing updates aren't transitive, routing information is, and you 
>need to ask questions about the routing information, rather than the 
>path of the update. In short, if the way the data's arranged 
>precludes certain types of security from being tenable, there's no 
>sense is stating you can provide those types of security in a 
>security requirements document. And that's the nub of the problem 
>with claiming the ability to transitively authorize advertisement of 
>prefixes (routes), rather than updates.... But, I don't want to go 
>there, just point out that there are logical reasons why I don't 
>In any case, I'd rather not bury it by saying: "we'll secure the 
>processes in the BGP draft, and assume the rest will just work."

Russ,

I've sent several messages that explain how one should deal with 
advertisements for short and longer prefixes that overlap, and I 
cited text from the BGP spec to substantiate my argument. (Do you 
have a serious mail delivery problem :-)?)

this is not an insolvable problem, except to the extent that your 
assert arbitrary constraints about how to address it. And solving it 
does not require reliance on BGP practice vs. the BGP spec. it just 
requires a careful reading of the spec.

For example, in my message of 1/6/05 (5:15 PM) in response to this 
same sort of example that you presented I said:

>You would not want to stop ISP A from advertising the /16. It is 
>authorized to do so by its initial allocation of this prefix from an 
>RIR or IANA. I'm not sure where you have derived the notion that the 
>ISP is not authorized to advertise the /16 because of its allocation 
>of the /24 to a subscriber.  This is certainly NOT an S-BGP concept. 
>The words you are using suggest to me that you have a vague notion 
>of what I mean when I speak about authorization, but that notion is 
>inaccurate. I think several of my previous messages have included 
>text that make clear that this sort of allocation by an ISP is NOT a 
>problem.

Steve