<br>
Last notes of the day...<br>
<br>
Matt<br>
<br>
<br>
<br>
2006.02.14 Tools BOF<br>
Todd Underwood, panel moderator<br>
<br>
A number of interesting tools presented earlier today;<br>
all of them are good and interesting and solve a<br>
particular set of problems.  None are in widespread<br>
use.  There's a lot of possible reasons; do they<br>
solve problems you don't have, in which case they<br>
can move onto something new; or they solve a problem<br>
similar to one you have, but not quite.  Or they solve<br>
a problem you can't quite implement yet.<br>
Discuss use cases, problems they're trying to solve,<br>
and give feedback, as interactively as comfortably<br>
as people can.<br>
<br>
3 tools, OpenBGPD, IRR powertools/webtools (to get<br>
feedback and is the IRR even useful anymore?) and<br>
Flamingo as one of 2 netflow platforms.<br>
<br>
Start with Henning, active in open source software<br>
development; he'll go in more depth on openbgpd.<br>
<br>
<br>
OpenBGPD<br>
Henning Brauer henning at <a href="http://openbsd.org">openbsd.org</a><br>
<br>
3 process design<br>
<br>
Principle of least privilege<br>
the RDE (route decision engine) does not need any special priv<br>
at all, so it runs as __bgpd:__bgpd: chrooted to /var/empty<br>
<br>
SE needs to bind to TCP/179<br>
<br>
parent needs to modify kernel routing table.<br>
<br>
Session Engine (SE)<br>
needs to bind to 179/tcp<br>
<br>
we have the parent open sockets<br>
see recvmsg(2)<br>
<br>
parent needsd to keep track of which fds the SE has open,<br>
so it doesn't bind() again to same ip/port<br>
<br>
the SE can drop all privs, then.<br>
<br>
SE 2<br>
since one process handles all bgpd, need nonblocking sockets.<br>
<br>
on blocking, you call write(2), won't reurn until it's done<br>
or get errors<br>
<br>
on nonblocking, returns as soon as it can't proceed<br>
immediately<br>
So, have to handle buffer managmeent<br>
<br>
SE 3<br>
designed an easy to use buffer API and mesg handling<br>
system.<br>
<br>
Messaging<br>
internal messaging is core comp. in <br>
reused for OpenNTPD, OPenOSPFD, and somee more.<br>
bgpd has more than 52 message types, more than OpenSSH<br>
bgpctl talks to bgpd using same imsg socket<br>
<br>
tcp md5<br>
some very old code in kernel for tcp md5, from 4.4 BSD<br>
never worked<br>
tcp md5 is somewhat similar to ipsec, ah, so implement<br>
 it within IPSec maze.<br>
Had to add pfkey interface to bgpd; committee designed<br>
 API.<br>
that made IPSec that much easier; extended the API so they<br>
can request unused SPIs from kernel, don't have to be<br>
configured manually.<br>
<br>
tcp md5/ipsec<br>
when you don't have tcp md5 or ipsec in place, big tcp<br>
windows are risky<br>
<br>
stay at 16k window unless you have tcp md5 or ipsec,<br>
then you get 64K<br>
so ipsec improves performance.<br>
<br>
Joel Yagli asks how big a tcp window do you need for<br>
a BGP session at all?  initial connection gets faster<br>
with 64K, but thereafter, similar.<br>
<br>
looking glass<br>
just added an optional second control socket that is<br>
restricted to the "show" operations<br>
regular bgpctl binary can be used with it<br>
cgi, yeah, that needs to be hacked in shape, but it's easy.<br>
<br>
Juniper only does static IPSec setup, so requires nasty<br>
setup.  OpenBGPD is dynamic, but interoperates with Junipers.<br>
<br>
So back to looking glass, security<br>
on OpenBSD, the httpd (an apache 1.3 variant)<br>
runs in a chroot jail by default<br>
th readonly socket can be placed inside that jail<br>
bgpd_flags="-r /var/www/bgpd.rsock" in rc.conf.local<br>
<br>
put a statically linked bgpctl binary in the chroot<br>
/path/to/bgpctl -s /bgp.rsock, $<br>
<br>
impressions from road to ipv6<br>
most heinous checkin message yet.  The lower 2 bytes<br>
of the scopeID overwrite part of the v6 address...ugly!<br>
<br>
Performance<br>
<a href="http://hasso.linux.ee/linux/openbgpd.php">http://hasso.linux.ee/linux/openbgpd.php</a><br>
<br>
it's quick openBGPD 3.6 port for linux; can't communicate<br>
with kernel, no v6, no md5; 8 times faster than quagga.<br>
<br>
future plans and ideas<br>
the biggest task waits outside bgpd itself; kernel routing<br>
 table.<br>
<br>
we need to make use of the radix mpath capabilities<br>
added in 2004, and add route source markers (BGP,<br>
OSPF, etc)<br>
 bgpd and ospfd can blindly install their routes<br>
 kernel then knows precedence<br>
hard to do, once it's done, routing will be easier.<br>
<br>
<br>
Also need multiple routing tables, with pf acting as<br>
table selector<br>
so unholy route-to can died, and associated issues<br>
vanish/<br>
<br>
might be useful with bgpd as well.<br>
<br>
iddeas for quite radical changs, speed up packet<br>
forwarding dramatically.<br>
will have fast path where all easy cases can be handled<br>
on specialized PCI cards<br>
multiple 10GE at wire speed within 2 years.  hardware<br>
exists, on way to him.<br>
<br>
for route servers, reversing filter and best path selection<br>
would be good.<br>
<br>
filter generation from RIPE DB or similar<br>
 but IRR toolset sucks hairy moose balls<br>
 should be solvable in perl "someone" has to code it.<br>
<br>
(maybe use IRR power tools for it instead!)<br>
[<br>
we can fail over IP addresses already, thanks to CARP<br>
<br>
we can hve synchronized state tables on multiiple machines,<br>
 gives HA firewall clusters.<br>
<br>
Would be really cool to be able to fail over TCP sessions<br>
and bgp sessions.<br>
could make for BGP hitless failover<br>
syncging BGP stuff shouldn't be too hard<br>
lots of work, not much time.<br>
<br>
<br>
Money has to come from somewhere, obviously.<br>
Unfortunately, people forget about this, just go to mirrors.<br>
Vendors don't help<br>
Never got anything for OpenSSH yet<br>
<br>
it comes down to you.  yes YOU.<br>
buy our CDs, donate cash, tee-shirts, etc.<br>
or sponsor events, plane tickets, etc.<br>
<br>
Matt asks if they can be configured actively only,<br>
not binding on port 179.  Currently, no.  Can bind<br>
to loopbacks for the moment, or modify the code<br>
as appropriate.<br>
<br>
RAS asks if they support the lastest IETF draft<br>
for collision handling.<br>
They don't implement collision detection RFC-wise,<br>
no.  And they're not active only, without passive.<br>
He also asks about comparing a RIB-in; that's been<br>
in the code for 2 weeks now, still has some bugs.<br>
<br>
Add support for passing more than one best path<br>
in case people are using this for a looking-glass.<br>
ie the VRF style hack for getting multiple views<br>
of the same route.<br>
<br>
Todd asks if they log dump output in MRT format.<br>
Short answer, yes.<br>
<br>
Many thanks to Henning!<br>
<br>
<br>
OK, over to RAS for IRR power tools.  One leading<br>
question is whether the IRRs are even worthy of<br>
supporting, or are they a dead horse we've been<br>
flagellating for ten years?<br>
<br>
Todd kicks it off with question--you developed<br>
toolset because you think IRRs are a worthy effort<br>
to support, right?<br>
RAS notes that manual filters aren't a reasonable<br>
means to configure routers.  Our current system is<br>
broken, something needs to change.  Tool was written<br>
for internal use initially, Chris Morrow convinced<br>
him to release it for others.  Not really meant as<br>
a plug for the IRRs, it's more "if you're going to<br>
use the IRRs<br>
<br>
Riverdomain, package base, if it can be a .rpm or .deb<br>
package, it would help; RAS doesn't do Linux, but others<br>
are welcome to package it up.<br>
<br>
When people go to implement this, they find a lot of <br>
cruft lurking around.  Verio is the primary forcer<br>
right now for using IRRs; Level3 proxy objects are<br>
a great pain point.<br>
<br>
No motivation to remove old information out of the<br>
system.<br>
<br>
Larry Blunt with Merit; if you send email to them,<br>
they will remove old stale objects.  It may take a<br>
little while, but it will get done.<br>
They're starting to check for inconsistencies so<br>
you can do bulk deletions of blocks that aren't<br>
being announced.<br>
Could they send out a monthly nag message, send<br>
that initially.<br>
They charge a yearly fee.  When someone doesn't<br>
pay, companies will eventually be phased out.<br>
About 1600 maintainers, some are proactive about<br>
keeping them up to date, others are pretty minimal<br>
or are laggards.<br>
Website will show out-of-date info, but won't allow<br>
cleaning it up; next step is to allow them to clean<br>
it up via the web.<br>
<br>
They're looking to have a simple form vs complex form<br>
coming up, for those who don't have a complete<br>
understanding of BGP.<br>
<br>
Report section works across all registries.  Could<br>
check to see if there's a less specific entry already<br>
with a different MAINT-ID.<br>
What about an INET-num to block any more specifics<br>
from the block from being registered.<br>
Challenge centers around the split between IP<br>
allocation and route registration.<br>
<br>
Peter Shoenmaker, works for Verio; many people mirror<br>
other databases, so there's compounded stale data.<br>
There are certain companies that have large blocks,<br>
and they'll register all the more specifics under it<br>
as well.  Generating those filter lists gets ugly.<br>
RAS notes his tool auto-aggregates to least specific<br>
block possible.<br>
<br>
Samantha Billington, ISC, current maintainers of the<br>
current IRR ToolSet; would love to re-do it if there<br>
were some backing behind it.  Currently trying to <br>
develop peering tools to make keeping track of peerings<br>
more easily.<br>
<br>
Randy Bush, IIJ, peers at the SIX using a perl script<br>
to generate filter lists around peval; it's a decade<br>
later, and we're still hacking more tools on top of<br>
the same broken data.  It's time to do something new;<br>
doing the same thing, and expecting different outcome<br>
is definition of insanity.<br>
He says let's just give up, and change.<br>
Todd asks about SBGP/SO-BGP; they haven't caught on,<br>
and perhaps never well.<br>
But in the meantime, Randy notes it will let you build<br>
filters that are at least rigorously verifiable.  And<br>
it'll be a backend only change in the future to drop<br>
in for the IRR in the future.  It'll be downhill, <br>
incremental work at that point.<br>
Randy doesn't think it makes sense to continue forward<br>
at all.  Let's stop for a year and redo things on better<br>
course before another ten years goes past.<br>
<br>
Randy offers to show Todd his ass...the audience groans,<br>
and we return to a more serious note.<br>
<br>
This is quicksand, let's get out of the quicksand.<br>
it's just an issue of going in the wrong direction.<br>
If you don't mind doing work twice, OK; but if you do, <br>
then save your time and energy, and let's focus on a<br>
PKI system.<br>
<br>
So, let's do PKI now, and we add this into the tools<br>
to jump start the process.<br>
You get a list of signed objects, you traverse the <br>
list of signed attestations that you recieve, you<br>
verify up the chain to IANA, and verify that the<br>
chain is intact.<br>
For Addresses and ASes, IANA is the root.<br>
For the identities of the ISPs and RIRs, may not<br>
be a single root.<br>
IRRs aren't secure enough to use for the database<br>
system.  It's not transport free?<br>
<br>
LDAP would very likely be the storage/retrieval<br>
system.  Let's start coding it; 2585 for queries,<br>
it's over HTTP, lets you talk to PKI certificate<br>
abstraction.  Need to cover changes to certs needed<br>
to cover address space and ASNs.  Can 2585 cover<br>
certificte modification, though?<br>
Needs<br>
<br>
Andy Putnams, Intelliden, config challenge will<br>
exist regardless of the pki; how do you ensure that<br>
you don't have multiple, overlapping entries?<br>
<br>
RAS notes that if we could handle PKI inside the<br>
IRRR, it would jumpstart the data.<br>
<br>
Chris asks why we can't start doing verifications<br>
with the existing infrastructure?<br>
Randy's not saying throw away the existing<br>
infrastructure; just pause on chasing it down,<br>
and change direction for the future.<br>
<br>
RPSL is a huge overkill, 90% of it isn't used at<br>
all, would we want to put PKI in there?<br>
<br>
Sandy Murphy, Sparta.  Could we use the PKI to<br>
prevent people from adding or removing routes<br>
that we don't want touched?  Could the people<br>
RUNNING the IRR check before you stick it in;<br>
then we also check on the way out.<br>
<br>
RFC 2725--her name is on it, but it's really<br>
Curtis Villamizer's proposal, but it does allow<br>
for the web of trust between systems to start<br>
with.<br>
<br>
Now onto Flamingo; Manish will walk through a <br>
live demo off his netflow data.<br>
<a href="http://flamingo.merit.edu:4444">flamingo.merit.edu:4444</a><br>
<br>
it's more for security than traffic engineering;<br>
for those of us doing traffic engineering, though<br>
might still be of some use.<br>
<br>
Gives a large overview when we start it up, use the<br>
minimum threshold to filter out background noise.<br>
Traffic volume based on source AS view is of somewhat<br>
interesting.<br>
Ooops, neighbor AS, actually.  (or origin, depending<br>
on your router setting)<br>
quad tree works same for AS number, just 16 bit<br>
number, not 32 bit archive.<br>
collector is based off flow tools, uses similar<br>
file format.<br>
Can pause updates so you don't loose current data<br>
you're about to zoom in on, for example.<br>
<br>
last view is combined source, dest, port, etc.<br>
everything sampled by netflow all in one window.<br>
sliders are a little crude, would be nice to have<br>
text entry boxes as well as slider bars.<br>
<br>
You can also list specific networks you care about<br>
that you want to see data for.<br>
So you can see traffic sourced from a given subnet.<br>
Every bar will then be a /32 hostname, will show<br>
traffic volumes for each; can shift zoom to limit<br>
what is on the display.<br>
<br>
Can do same visualizations of darknet space.<br>
<br>
They generate darkspace network off an unnumbered<br>
interface, and generating flow data from what is<br>
seen on the scatterback.<br>
Lots of scans from lots of people.  Last 10 seconds<br>
or last 2 seconds, very dynamic.<br>
<br>
so the vertical here is walking across ports.<br>
single source port hitting lots of destination<br>
ports.<br>
<br>
Can also playback feeds from netflow collector<br>
format, etc.<br>
<br>
The platform is displaying pretty well at about 5k<br>
records/second, but scaling up for for a large content<br>
provider would be tough.<br>
<br>
Most of the code is written in-house, on Linux; may<br>
port to other platforms later.<br>
Running on a 3.6ghz p4 right now, nice graphics card,<br>
256MB nvidia graphics card, no other real specs right<br>
now.  Heavy dependencies on openGL, so no licensing<br>
for that.  Software tool is largely GPL free.<br>
Availability is an issue right now.  In trials, happy<br>
to do more trials, that's where they'll leave it for<br>
now.<br>
Manpower issues, no QA, no support, so not sure if<br>
they can really release it to the public yet.<br>
<br>
Are there additional visualizations that might help?<br>
<br>
On the ops side, which of these ways of looking at<br>
this would help the poor folks who run NOCs?  What<br>
about saving profiles the NOC can compare against<br>
to recognize quickly "bad things".<br>
<br>
Mike Hughes (I think) says it's not really a <br>
first-alert type tool, it's for a second or third level<br>
escalation tool; too hard to interpret for a front<br>
line NOC person.<br>
They find it most useful for playback, rather than<br>
realtime 'spot the attack'.  <br>
<br>
Chris--scaling for netflow is always a challenge.  He<br>
has 9 routers reporting 50,000 flows/second; he has 300<br>
others to add.  So the scaling part is a challenge.<br>
The SOC might find it useful.<br>
<br>
It can use pre-existing netflow/flowtool archive files,<br>
server can play those back.<br>
<br>
Chris Morrow would just like to see some rough stats<br>
on what it could support.<br>
<br>
Mike Hughes, runs layer 2 environment, could it be<br>
sFlow and layer 2 aware.<br>
<br>
Walt Prue asks if he could point at a line to see<br>
info about it.  On the feature list.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>