Re: [NSE] ASN made more robust and documented - much more to do.

[David Fifield <david () bamsoftware com>]

On Wed, Sep 03, 2008 at 10:02:44PM +0100, jah wrote:
> On 03/09/2008 20:33, David Fifield wrote:
> > You said a newer version of this script queries origin.asn.cymru.com and
> > and peer.asn.cymru.com instead of using nmap.asn.cymru.com. Can you
> > explain more why that is? Team Cymru created the nmap domain in order to
> > track load. If there's something wrong with what nmap returns maybe we
> > can get them to change it.
> The nmap zone returns multiples of two TXT answers and each pair of
> answers are what would be returned by queries for the origin and peer
> cymru zones.  I observed that the answers returned for a query for the
> nmap zone weren't ordered making it difficult to consistently detect
> which answer relates to the origin ASN and which to the peer ASN(s) in
> certain cases (such as multiple origin answers and peer answers
> containing a single ASN).

Okay, I get it now. If I run

        dig +short 31.108.90.212.nmap.asn.cymru.com TXT

I get

        "12780 | 212.90.96.0/20 | UA | ripencc | 1999-11-11"
        "13249 | 212.90.96.0/20 | UA | ripencc | 1999-11-11"

Of the two numbers 12780 and 13249, one of them is the origin ASN and
one is a peer ASN, and there's no way to tell which is which. And like
you said, the order switches sometimes.

> I was exploring the possibility of using the nmap zone and then, when it
> is difficult to determine which is the answer containing the origin ASN,
> sending a query for the origin zone to confirm.  I decided that doing
> this was alot of work for such a simple script and decided not to use
> the nmap zone. 

You're right. There's no reason to query the nmap zone and then the
origin zone as a backup if the origin and peer zones give all the
required information. The nmap zone gives ambiguous results sometimes.
Perhaps Michael's email will get it fixed; I think that's the best
option.

> I was thinking that the best way to display the ASN information would be
> to combine the information for a given BGP prefix and reduce the
> redundancy of fields:
>
> So instead of:
> |  ASN: 4 records found.
> |  Origin ASN: 10565 | BGP: 64.13.128.0/18 | Country: US
> |  Origin ASN: 10565 | BGP: 64.13.128.0/21 | Country: US
> |  Peer ASN: 3561 6461 | BGP: 64.13.128.0/21 | Country: US
> |_ Peer ASN: 174 2914 6461 | BGP: 64.13.128.0/18 | Country: US
>
> present this:
> |  ASN: 4 records found.
> |  BGP: 64.13.128.0/18 | Country: US | Origin ASN: 10565 | Peer ASN: 174
> 2914 6461
> |_BGP: 64.13.128.0/21 | Country: US | Origin ASN: 10565 | Peer ASN: 3561
> 6461

I agree with the shorter form. About the peer ASNs, are we reporting
that just because it happens to be in the results returned by the nmap
zone, or is it useful? It seems to me the AS description ("SVCOLO-AS -
Silicon Valley Colocation, Inc.") is more useful. It appears to require
a second query to asn.cymru.com using the AS number. It would be nice to
have it as part of the nmap zone results.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org