RIPE 49

• content to the Chair of the working group.
• format to [email protected].

Routing WG (Session 1)
======================

1. Introduction/Joao Damas (16:00-16:03).
------------
Joao opens the meeting and deals with the administrative stuff. Henk
Uijterwaal is appointed as scribe, the minutes from RIPE48 are
approved,
the agenda is approved. The group has no outstanding actions. Joao
shows a slide with the dates of the upcoming IRR courses by the RIPE
NCC. These dates will be published on the web shortly.

2. Securing a core network - discussion/Michael Behringer. (16:03-16:39)
------------------------------------
Slides on the web at:


http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing-security-discussion.pdf

Christian Panigl briefly summarised part 2 of Michael Behringer's
talk from morning EOF session. In the morning, Michael Behringer
presented some ideas to secure the core network, keeping operability
in mind:

- Transit ACL's
- Use RFC1918 address space and no export (users cannot see the
core and thus not attack it).
- Use of a non IP-Control plane

The chair then opened the floor for lively discussion:

* Daniel Karrenberg: if you are protecting the core, make it
transparent, the end user then sees it as 1 IP hop. The user
should never see RFC1918 space. Also be consistent, that will
save a lot of work.

* Joao Damas: Wild idea: use a v6 block for your IX.

* Randy Bush: What end user want is good service, does not want to
run traceroute. End user needs to debug both paths. Opaque blob
is not going to let anybody debug it.

* Michael Behringer: This is an old discussion. Traceroute -g and
source route were considered bad too, LG's solved the problem.
While he agrees with Randy Bush' points, why not invent other
tools?

* Randy Bush: does not see benefit in using RFC1918 space to make
core invisible. This hides the fact that it is an IP network, it
is going to get you in trouble sooner or later. IP network
should be open.

* Daniel Karrenberg and Iljitsch van Beijnum agree with Randy
Bush.

* Pedro Marques states that you cannot prevent people from
accessing your core routers without making things invisible.

* Michael Behringer wants to see the discussion on an abstract
level.

* Pedro Marques: if you have daily DDoS attacks, filtering for
network might be a good idea, not a choice, even if it breaks
other things. Host-by-host protection does not work.

* van Beijnum: hiding the core and making the core inaccessible
aren't the same thing. The latter can be good. If you hide the
core, debugging will be the same as debugging ethernet segments.
Not funny.

* Randy Bush DDoS problem of distributed source and target. Needs
to be solved near the edge and source of DDoS. Refers to work
by Bellovin et al on push-back

* David Reader: try traceroute to 213.249.249.129. Lots of 1918
space, his customer cannot see the site, operator of 10/8 can.
The core doesn't see the problem, their neighbours do.

* Michael Behringer asked what if you get proper addresses back.
Randy: now you know who to contact and what's wrong.

* Pedro Marques: one can set-up things such that traceroute works,
but ping doesn't.

Michael concluded with: there are different views, no agreement on
pros and cons. He plans to write this up and give the document
away. People can then decide for themselves what to do.

3. IRR toolset handover/Shane Kerr (16:39-16:46)
--------------------
Slides on the web at:

http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing-irrtoolset-handover.pdf

Shane explained that the RIPE NCC took over maintenance of the
RAToolset from ISI in 2001. The current release contains fixes to all
issues raised at RIPE49 and compiles under gcc 3.x.x.

The maintenance of this toolset does not fit with the current
software model at the RIPE NCC. The RIPE NCC has therefor agreed
with ISC to move maintenance to them. The RIPE NCC has handed
over the code and all documentation to ISC. The mailing list will
be moved soon.

Question from the floor:

Randy Bush asks what licensing model will be used by ISC.
Joao Damas responds that the current license is the BSD license and
that will not be changed.

4. BGP Wedgies/Tim Griffin (16:39-17:07)
-----------

Slides on the web at www.cambridge.intel-research.net/~tgriffin

Tim introduced the concept of a BGP wedgie. A 3/4-wedgie is a
situation where local routing policies make sense locally but
interactions allow for multiple stable routes. A full wedgie is a
situation where no set of operators can find out why a set of
policies result in an unexpected route. Some examples were
shown. Operators should be aware of this. An IETF draft (in the
GROW-WG) is available.

Comments:

Geoff Huston: This would be easier if "depref me" was a transit
property. Should it be?

Tim: if we want this to work: yes.

Pedro Marques: one way to fix it is to get eBGP to advertise best
route and best route that does not come from peer I'm talking
to. (2nd best route). This is in an old RFC. Juniper can support
this.

Tim: this makes it easier, but does not solve general case.

Bill Norton: what tools do you have to figure out the current
situation, what tools would be useful?

Tim: needs common analysis by multiple AS, not a trivial thing to
set up.

Daniel Karrenberg: can this be avoided with pre-pending?

Tim: no, folks prefer customers, it will not work.

5. Measurements on intra domain routing instability/Zhang Shu
(17:07-17:24)
------------------------------------------------
Slides on the web at:


http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing-instability-measurements.pdf

Zhang showed statistics on intra domain routing changes in the
WIDE network. Oscillations are often caused by:

Congestion
Link/IF failure
Misconfiguration
S/W bugs

He then presented the RTANALY tool, a system to detect and
visualise IGP changes. Release early October:

http://rtanaly.koganei.wide.ad.jp/rtanaly
An example was shown.

Question from the floor: How do you get the data?

Zhang: Record them with tcpdump.

Routing WG/Session 2
====================

6. BGP network design/Pedro Marques (11:00-11:50)
------------------
Slides on the web at:

http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing-bgp-design.pdf

This presentation will focused on a set of frequently asked
questions that network operators have regarding the logical design
of BGP networks. These include topics such as route reflector
placement on a network and BGP configuration trade-offs. More a
set of topics to generate discussion based on discussion with
potential customers.

A. How much hierarchy Showed an example of a wrong design aimed at
keeping traffic local. IBGP would have done the same. BGP for
internal traffic is generally a bad idea, it was not designed
for it.

B. Where to place route reflectors?
Goal: reduce routing information.
Non-goals: configuration management, scaling #tcp sessions A
lot of people use Route Reflectors as a configuration.
management tool. Wrong tool for the job. Side effects of path
selection are usually not understood. Should buy a provisioning
system.

Recommendations:
- Keep it simple. Lowest cost solution that solves the problem
- Avoid loosing information in the core
- Avoid centralisation

Cold potato: MED and what are the consequences.

The speaker then ran out of time and briefly went through a number
of slides:

C. Can BGP advertise more than 1 path?
Yes, you can. Showed config example in slides
D. Unadvertised JunOS behaviour changes:

6.3 incoming interface check on eBGP session (drop packet from
non peer)

7.0 TCP path MTU discovery no eBGP poison reverse to neighbour
as

Question from the floor;

Rudiger Volk: objects against the statement that BGP can
advertise more than 1 path. It doesn't. Prefix is the key.

Pedro: 2547 augments the key to be a route discriminator plus prefix.
So effectively it does for a number of applications. A discussion
follows, no conclusion is reached and the discussion is taken
off-line.

Randy Bush showed a case where mixing routers from two different
vendors led to huge numbers of message and slow convergence,
introducing a min.router advert showed slower convergence, less
messages though, not seen on data plane

7. Happy packets/Randy Bush (11:50-12:04)
-------------

Slides on the web at:


http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing-happy.pdf

Randy noticed that there have been numerous publications about the
control-plane (routing) instability. However, what matters is the
quality and stability of the data plane: what counts is if the
data reaches its destination. A huge number of BGP updates is not
a problem as long as the routers can process them without falling
over.

He did an experiment with a BGP beacon and sites all over the
world sending data to it.

One plot showed the effect of an link cut while keeping an
alternative path up. Packets continued to arrive from half the
sources. The other half experienced a 30 second drop, even though
BGP updates continued to float around in the system much longer.

More examples were shown, bottom line was there is no correlation
between BGP activity and data not arriving. On the IP level, some
correlation can (arguably) be seen.

8. RIS status and plans/Matthew Williams (12:04-12:23)
--------------------

Slides on the web at:

http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing-ris.pdf

Matthew gave an update of the RIS project at the RIPE NCC.

Highlights are

* The internal reorganisation announced at RIPE48 has been
successfully completed.

* A route collector is about to be installed in Moscow. RRC08 has
been moved from MAE-WEST to the PAIX.

* myASn v1.0 has been released. myASn is an alarm system for BGP
available at http://www.ris.ripe.net/myasn.html.

* The debogonising effort has been continued. For the new RIPE
NCC block 85/8, it showed that initially 80% of the sites
filtered the block, this was reduced to 17% after a few days.

* Ongoing efforts:

- IPv6 support. Some tools do support IPv6, others don't as the
RIPE NCC ran out of time. New ETA is late November.
Prototypes for unsupported tools are available at:

http://www.ris.ripe.net/cgi-bin/ipv6/prefixquery.cgi
- Looking at requirements for myASn v1.1 and 2.0.
- Future IDR work
- Secure routing
- Collaborate with researchers
- Your suggestion

9. Detecting anomalies/Olaf Maennel (12:23-12:37)
-------------------

Slides not yet on the web.

Olaf presented research aimed at finding the offending AS when an
anomaly in BGP is detected. He uses 3 views: time, location and
prefix. The method then detects the AS that is causing the
problem (in about 93%) of the cases.

The algorithm has been validated using simulations, RIS/Routeviews
data (1100 feeds), formal methods. Olaf has also checked that the
anomalies he detected are related to events seen in syslog files
from real routes.

Limitations of the method are the size of the candidate set. It
is also possible that the offending AS is outside the set of
processed AS's.

Further work includes developing a Topology aware library to identify
clusters and adding this algorithm to BGP alarm systems like myASn.
Collaborators are Gert Doering and the RIPE NCC.

10. AOB?
---
No other business.