[ncc-services-wg] New service: ip2asn

Dear Hank,

On Wed, 10 Sep 2003, Hank Nussbacher wrote:

> Can the RIPE NCC TTM group explain why such a service is needed when
> there are other packages available that do similar things?

Short summary.
==============

Ip2asn is built as an internal tool in response to requirements raised
inside the TTM WG. It is used to put ASN information into TTM products.

Making this mapping function available externally is not much work at all.

We know of no similar service that meets this particular need.

Long version:
=============

For starters, I disagree with the statement that this is a new service
that was not approved by anybody beforehand.  The TT-WG was set up for
various reasons.  One of them was to provide a forum where (paying)
customers of the TTM service can learn about the development plans for the
project and provide feedback.  The issue of IP-AS mappings has been
discussed several times in the last years, our plans have been presented
at previous meetings, and the presentation that you are referring to, was
in fact the outcome of a specific question raised in the WG.

For those who haven't followed the TT-WG, let me briefly summarize what
happened in the past:

Since the start of the service, TTM has provided the IP-level path that a
packet takes when traveling from source to destination based on
traceroute-like probes. One frequently see changes in these paths.  These
changes can be caused by many things, but amongst the most common are:

 1. Traffic is routed through different routers of the same upstream
    provider.  (For example, when load balancing schemes are in use).

 2. Traffic is routed through a different upstream provider.

In order to quickly distinguish between #1 and #2, one can look at which
AS the IP-addresses in the path belong to. This requires a mapping of
IP-addresses to AS-numbers, at the time that the IP-trace was taken (as IP
blocks may move from one AS to another over time).

Sometime in 2002, we therefor added a column in the output showing the AS
that every IP address belonged to.  This mapping was based on whois
queries.

When this was presented to the TT-WG, the (valid) question was raised how
accurate this mapping was and if it wouldn't be better to use a
routing-table based approach.  As we, nor anybody in the audience, knew
the answer, we (the RIPE NCC TTM-group) agreed with the TT-WG to study
this. The talk you are referring to is the direct result of this question.

>From your previous postings, I have understood that you do not like the
current model where every WG can ask the RIPE NCC for specific actions.
However, this was the procedure at the time.  Even with the advent of the
NCC-services WG it appears to us as the correct procedure for something
like this, because it is germane to the TT-WG and does not involve
a significant amount of resources.

Anyway, the conclusion from this study was that the IRR only produces the
correct mapping in about 80%, switching to an approach based on routing
tables (i.e. the RIS) increases that percentage to about 99%.  Obviously,
the more accurate the results, the more useful the output, and the
conclusion looked simple: the TTM service should switch to a routing table
based approach for IP to AS mappings.

Implementation
==============

Besides being accurate, the implementation also has to be fast, as we have
to process 4000 to 5000 different IP addresses in a relatively short time.
We also believe that we should use routing tables that we are already
collecting for the RIS, this in order to ensure that data from one RIPE
NCC service (TTM) is consistent with another.  This will also give a
performance boost, as all data resides on 1 local network.

The best way to accomplish this, appears to be a daemon that loads all
information into memory.  serves queries and refreshes itself at regular
intervals.

Other tools
===========

We were fully aware that other tools existed to do this job, but we
believe that none of them meets our requirements.  For the ones that you
list:

0)  Both NANOG traceroute and lft have a -A switch
    but get the prefix data from a routing registry (whois.ra.net)
    which has been shown to be incomplete, out of date, not maintained

1)  http://www.cymru.com/Tools/getorgasn2.pl

    Relies on access to a router.

    comments:

    one router does not necessarily see all prefixes and origins
    one needs to combine data collected from various vantage points
    (RIS collectors, route-view peers)

    performance: each lookup is done with a 'sh ip bgp $prefix' command
    on the router, won't scale to thousands of lookups (or hurt router
    performance)

2)  Net::Patricia

    Create ASCII prefix/AS table from a source of routing information
    (route-views quoted), use Net::Patricia to lookup.

    Comments: the idea is good, but the ASCII data and perl
    make it too slow.  An ip2asn server at RIPE NCC could parse the data
    from RIS, keep everything in memory and refresh info daily.

3)  "Routeviews project now has a test/static asn zone up that you can try"

    % dig @archive.routeviews.org 13.142.223.128.asn.routeviews.org txt

    comments: interesting idea but at the time it was still under
    development.

    strange replies on non-matched IPs, e.g. try
    host -t txt 7.227.290.195.asn.routeviews.org

    This could be a solution for traceroute, but in TTM we
    skip time consuming dns lookups on the testboxes and do offline
    processing; performing thousands of dns lookups for ip2as there
    will likely take too long too.

4)  ip2asn scripts from Stephen Gill

    - starting from BGP table dump
    - contacting route server

    comments: BGP table dump covered above (good start, but not complete
    and ASCII is slow), route server is slow, won't scale to thousands
    of queries


Why make this a service?
========================

Mapping IP to AS can be used in many tools, both that are published in the
public domain as in tools used inside LIR's only. All these tools will
benefit from more accurate data.

To use a routing based IP-AS mapping for TTM, we need to develop and
maintain some amount of code.  Adding an interface to access the same data
from the outside, requires very little additional work.  In fact, I think
that we'd be doing the community a dis-service if we would not make this
tool available to everybody.


Henk (with the help of Rene, Daniel and the rest of the TTM group)


------------------------------------------------------------------------------
Henk Uijterwaal                             Email: henk.uijterwaal at ripe.net
RIPE Network Coordination Centre            WWW: http://www.ripe.net/home/henk
P.O.Box 10096          Singel 258           Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam    Fax: +31.20.5354445
The Netherlands        The Netherlands      Mobile: +31.6.55861746
------------------------------------------------------------------------------

That problem that we weren't having yesterday, is it better? (Big ISP NOC)