Routing wg draft minutes - RIPE 49
- Previous message (by thread): ARIN is allocating from 72.0.0.0/8
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Joao Damas
Joao_Damas at isc.org
Tue Sep 28 11:52:54 CEST 2004
Hello,
I am hereby posting a revised version of the *draft* minutes for the
routing wg meeting at RIPE 49 last week.
Many thanks go to the scribe, Henk Uijterwaal, of the RIPE NCC for a
good and quick job.
Comments are welcome,
Joao Damas/(co)Chair routing-wg
ISC
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.
- Previous message (by thread): ARIN is allocating from 72.0.0.0/8
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]