[ppml] Fwd: Keeping in reserve

[Iljitsch van Beijnum]

[Originally to ppml, CC to address-policy at ripe, prune as necessary]

On 5-okt-2006, at 18:17, David Conrad wrote:

> Is there any reason PI /48s shouldn't be allocated with the  
> bisection method, thus removing the need to reserve space?

The goal of filtering in BGP is either to keep out accidentally  
injected prefixes, or keep out both accidentially and maliciously  
injected prefixes.

This means that a reasonable filter, i.e., one that can be configured  
on a router with a relatively limited number of filter rules, must  
allow through all prefixes that match legitimate allocations, and  
reject as much of everything else as possible.

This means that ideally, from a certain block of address space,  
prefixes of one size are allocated sequentially with no unused space  
between them. For instance:

192.0.0.0/24 -> /28s:

192.0.0.0/28
192.0.0.16/28
...
192.0.0.192/28
192.0.0.208/28

In this example, only blocks above 192.0.0.208/28 can be successfully  
used to get around the filter, either for the purpose of hijacking  
unused address space for purposes like spamming, or to overload  
routers by injecting large numbers of bogus prefixes.

If we now reserve a /26 for every user of a /28, we'd have:

192.0.0.0/28
192.0.0.64/28
...
192.0.2.0/28
192.0.2.64/28

So a filter would have to allow 192.0.0.0/22 -> /26 - /28. This gives  
an attacker the opportunity to inject three malicious /28 prefixes  
between any two legitimate /28s. Worse, when someone grows out of a / 
28 and gets a /27, such as 192.0.0.64/27, an attacker can inject  
192.0.0.64/28 + 192.0.0.80/28, which cover the same address space but  
the longest match first rule makes packets flow toward the attacker  
rather than the real holder of the addresses.

For this reason and because of temporary instability when moving from  
a smaller to a larger prefix, or maybe because of simple laziness or  
cluelessness, the real holder of the address space may choose to  
inject both 192.0.0.64/28 and 192.0.0.80/28 and maybe also  
192.0.0.64/27. This negates the purpose of keeping some extra space  
in reserve between allocations. In IPv4 we have to be careful not to  
give too much space away, but in IPv6 there is absolutely no reason  
to skimp when people come back for seconds. So if a /48 isn't enough,  
don't grow to a /47 or even a /44, just give a /40 and then a /32.  
The number of extra prefixes in the routing table that this results  
in is minimal because even a /48 is more than enough for the majority  
of organizations, and it allows for much stricter filters. And it  
avoids fragmenting the address space.

With the bisection method, you'd have to use even more liberal  
filters and allow between /25 and /28 in this example.

All in all, it would be best if for every block of address space,  
only a fixed size allocations are given out.