Subject: [RRG] interesting presentations from RIPE

From: Jari Arkko <[email-masked]>
Date: Wed, 07 May 2008 11:58:03 +0200

I'm sitting in the RIPE meeting in Berlin. So far there has been a
couple of interesting presentations related to route scaling.

Paul Francis made a presentation about how ISPs can configure their
(existing) routers to reduce the amount of FIB entries, and hopefully
with the extra configuration effort, buy some more time for the use of
their routers. The idea is based on partitioning the address space into
parts, assigning specific routers to deal with specific parts of the
address space, and using MPLS route traffic through the rest network.
The paper is here: http://www.cs.cornell.edu/people/francis/va-wp.pdf
and the presentation here:
http://rosie.ripe.net/ripe/meetings/ripe-56/presentations/uploads/Monday/Plenary%2016:00/upl/Karrenberg-IPv4_Prefix_Lengths.LGnt.pdf

This might be useful in terms of thinking about operational practices
that help ISPs cope with the route scalability problem. Not a long term
solution perhaps, but something that lets you live while an eventual
solution is being deployed. I'm sure there's other similar practices
that could be employed. Outside the charter of the RRG, of course, but
maybe useful work anyway.

Daniel Karrenberg and few others talked about routing table
fragmentation and why so many entries are /24s. His data points to the
direction that a big fraction of the advertised /24s are from
de-aggregations of bigger allocations. Obviously there are many reasons
for this, including traffic engineering, multihoming, etc. However, at
least for me it was news that one possible reason for doing this would
be to "protect" yourself against prefix hijacking. By advertising /24s
you reduce the likelihood of being hijacked with a more specific route.
If true, one action that needs to be taken to reduce routing scalability
problem is to secure the system in some proper way. Here are the
presentations:
http://rosie.ripe.net/ripe/meetings/ripe-56/presentations/uploads/Monday/Plenary%2016:00/upl/Karrenberg-IPv4_Prefix_Lengths.LGnt.pdf
http://rosie.ripe.net/ripe/meetings/ripe-56/presentations/uploads/Tuesday/Plenary%2014:00/upl/Karrenberg-Response_to_Prefix_Length_Question_from_Yesterday.xXAg.png

Have people here actually seen such "protection" as a reason for someone
to de-aggregate their prefixes?

Jari

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: [email-masked]
Date: Wed, 7 May 2008 08:22:35 -0400

Jari:

Thanks for the pointers.
Commonly, subprefix announcement by legitimate owner
is used as a recovery mechanism after a prefix or
subprefix hijack is detected. Example - Recent YouTube incident:  
http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml
>From Daniel Karrenberg's presentation slides, it not obvious
what fraction of deaggregation is due to "proactive" subprefix announcement
to reduce the likelihood of being hijacked.

PHAS and PGBGP are some of the alert/protection mechanisms
against prefix/subprefix hijacks that are in research:
http://www.cs.arizona.edu/people/bzhang/paper/originChange.pdf
http://www-users.itlabs.umn.edu/classes/Spring-2006/csci8211/Readings/pgbgp.pdf
The following presentation (on Slide 7) lists more generally the various
efforts that seek to secure the system:
http://www.renesys.com/tech/presentations/pdf/apricot-lightning-08.pdf
We (NIST) have a presentation scheduled at the upcoming NANOG-43 
that provides an overview and comparisons of various
BGP Anomaly Detection and Robustness Algorithms. 

Sriram

Quoting Jari Arkko <[email-masked]>:

> http://rosie.ripe.net/ripe/meetings/ripe-
56/presentations/uploads/Monday/Plenary%2016:00/upl/Karrenberg-
IPv4_Prefix_Lengths.LGnt.pdf
> http://rosie.ripe.net/ripe/meetings/ripe-
56/presentations/uploads/Tuesday/Plenary%2014:00/upl/Karrenberg-
Response_to_Prefix_Length_Question_from_Yesterday.xXAg.png

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 May 2008 07:20:58 -0600

> to de-aggregate their prefixes?

Indeed, lots, and some with no solid reasoning.  E.g., have a
look at some of the folks that have /8s and announce /9s as
well - simply to avert prefix hijacking via another /8.

Further, consider for example, that google.com has 4 name
servers out of one /19:

danny@pork% dig google.com ns

; <<>> DiG 9.4.1-P1 <<>> google.com ns
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47647
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;google.com.			IN	NS

;; ANSWER SECTION:
google.com.		44733	IN	NS	ns1.google.com.
google.com.		44733	IN	NS	ns2.google.com.
google.com.		44733	IN	NS	ns3.google.com.
google.com.		44733	IN	NS	ns4.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.		86400	IN	A	216.239.32.10
ns2.google.com.		86400	IN	A	216.239.34.10
ns3.google.com.		86400	IN	A	216.239.36.10
ns4.google.com.		86400	IN	A	216.239.38.10

;; Query time: 143 msec
;; SERVER: 10.0.9.11#53(10.0.9.11)
;; WHEN: Wed May  7 07:16:02 2008
;; MSG SIZE  rcvd: 164

route-views.oregon-ix.net>sh ip bgp 216.239.32.0/19 longer-prefixes |  
include 216.239
*  216.239.32.0/19  209.10.12.156         7002             0 4513  
12182 7018 15169 i
*  216.239.33.0     209.10.12.156         7002             0 4513  
12182 3561 15169 36385 i
*  216.239.34.0     209.10.12.156         7002             0 4513  
12182 3356 15169 i
*  216.239.38.0     209.10.12.156        19702             0 4513  
13789 1239 15169 i
*  216.239.44.0/23  209.10.12.156         7002             0 4513  
12182 7018 15169 36384 i
*  216.239.50.0/23  209.10.12.156         7002             0 4513  
12182 3561 15169 i
*  216.239.58.0/23  209.10.12.156         7002             0 4513  
12182 1239 15169 i
*  216.239.60.0/23  209.10.12.156         7002             0 4513  
12182 3549 15169 i

It's really ugly, but honestly, folks have very little alternative today
to be "proactive", whatever that means...

-danny

---

From: David Meyer <[email-masked]>
Date: Wed, 7 May 2008 07:16:50 -0700

> to de-aggregate their prefixes?

	Its extremely common.

	Dave

---

From: "Simon Schuetz" <[email-masked]>
Date: Thu, 8 May 2008 10:05:48 +0200

> > to de-aggregate their prefixes?

If this is true (and I wouldn't be surprised), how would LISP or any other proposal without added security features help here?

Even though LISP, Six/One, etc helps to make aggregation easier, would ISPs still de-aggregate for the security reasons?

Simon

---

From: Randall Atkinson <[email-masked]>
Date: Thu, 8 May 2008 09:54:09 -0700

% If this is true (and I wouldn't be surprised), how would LISP
% or any other proposal without added security features help here?
%
% Even though LISP, Six/One, etc helps to make aggregation easier,
% would ISPs still de-aggregate for the security reasons?

My understanding is that the IETF's SIDR WG is chartered to address
the issue of authentication and authorisation for routing prefix
advrtisements in the inter-domain context.  I further understand
that they have actual engineering work-in-progress in this area.

<http://www.ietf.org/html.charters/sidr-charter.html>

So I think that any proposal here that does not significantly alter
BGP would be able to use whatever approach(es) that the IETF
SIDR WG might come up with, and hence need not necessarily
come up with an independent solution within the context of
the Routing RG.

On the other hand, if some architectural change were proposed
here that would mean the SIDR approach, whatever that might
be, could not continue to be used, then the proponents of
that change probably should explain how the change being
proposed here can also support both authentication and authorisation
of inter-domain routing prefix advertisements.

Cheers,

Ran
[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 May 2008 08:12:23 +0200

Ran,
> advrtisements in the inter-domain context.
Exactly. More generally, we have a number of different reasons for
de-aggregation, and for our problem to go away, we have to have
something for each (significant) reason.

There is indeed work in the SIDR WG and in the RIR and operator
communities in securing routing advertisements. But it needs to be
deployed. Also, if we come up with a "split" routing model where there
are "core" and "edge" routing tables, we need to provide the security
mechanisms currently being developed to both of these parts.

Jari

---

From: xuxiaohu 41208 <[email-masked]>
Date: Fri, 09 May 2008 22:37:16 +0200

> de-aggregations of bigger allocations. Obviously there are many 
> reasonsfor this, including traffic engineering, multihoming, etc. 
> However, at
> you reduce the likelihood of being hijacked with a more specific 
> route.If true, one action that needs to be taken to reduce routing 
> scalabilityproblem is to secure the system in some proper way. 
> Here are the
> presentations:
> 56/presentations/uploads/Monday/Plenary%2016:00/upl/Karrenberg-IPv4_Prefix_Lengths.LGnt.pdf
> 56/presentations/uploads/Tuesday/Plenary%2014:00/upl/Karrenberg-Response_to_Prefix_Length_Question_from_Yesterday.xXAg.png
> 
> Have people here actually seen such "protection" as a reason for 
> someoneto de-aggregate their prefixes?

There are also a lot of discussions about IPv4 address transfer in this RIPE meeting, and I wonder whether IP transfer will become the forthcoming factor driving the routing table growth. 

In order to maximize the utilization, the IPv4 addresses are better to be transfered in a wider scope. IP transfer among LIRs will make more and more PA addresses become PI addresses. Besides, in order to maximize the utilization of the valuable IP address resource, more and more small fragments of IP address will emerge in the global routing system.
 
Best regards,
Xiaohu XU

---

From: Per Heldal <[email-masked]>
Date: Sun, 11 May 2008 13:49:27 +0200

> Even though LISP, Six/One, etc helps to make aggregation easier, would ISPs still de-aggregate for the security reasons?

With LISP, I think it is more likely that those who operate today's DFZ
will implement strict prefix-length-filtering based on registry
allocation block-sizes. That would stop small-block-hijacking through
the DFZ, but then you need to secure LISP ...

//per