Re: looking for hostname router identifier validation

[Large Hadron Collider]

How much did it cost? :-)

On 19-04-30 08 h 38, Bryan Holloway wrote:


On 4/29/19 7:21 PM, Valdis Klētnieks wrote:

On Mon, 29 Apr 2019 16:16:06 -0500, Bryan Holloway said:


I still see references to UUNet in some reverse PTRs.

So, uh, yeah.


I wonder what year we'll get to a point where less than half of NANOG's
membership was around when UUNet was. We're probably there already.
And likely coming up on when less than half the people know what it
was, other than myth and legend



Bought my first T-1 from those guys ... don't even ask how much it cost.

Re: AT contact

[Mehmet Akcin]

7018

On Tue, Apr 30, 2019 at 17:50 Hansen, Christoffer 
wrote:

> Mehmet Akcin,
>
> You write AT ...
>
> I look in PDB ...
>
> Networks (6):
>   AT AP - AS2687 (2687)
>   AT Canada - AS2685 (2685)
>   AT EMEA - AS2686 (2686)
>   AT LA - AS2688 (2688)
>   AT US - 7018 (7018)
>   AT US - AS7132 (7132)
>
> Which one are you mayhaps referring to, when you write AT?
>
> -Christoffer
>
> On 30/04/2019 22:18, Mehmet Akcin wrote:
> > Peering email is broken, looking for an AT contact. Please contact me
> off
> > list.
>
-- 
Mehmet
+1-424-298-1903

Re: AT contact

[Hansen, Christoffer]

Mehmet Akcin,

You write AT ...

I look in PDB ...

Networks (6):
  AT AP - AS2687 (2687)
  AT Canada - AS2685 (2685)
  AT EMEA - AS2686 (2686)
  AT LA - AS2688 (2688)
  AT US - 7018 (7018)
  AT US - AS7132 (7132)

Which one are you mayhaps referring to, when you write AT?

-Christoffer

On 30/04/2019 22:18, Mehmet Akcin wrote:
> Peering email is broken, looking for an AT contact. Please contact me off
> list.

Re: AT contact

[Seth Mattinen]

On 4/30/19 13:18, Mehmet Akcin wrote:
Peering email is broken, looking for an AT contact. Please contact me 
off list.





There's other contacts listed in peeringdb

AT contact

[Mehmet Akcin]

Peering email is broken, looking for an AT contact. Please contact me off
list.

The original message was received at Tue, 30 Apr 2019 16:11:17 -0400
from m0053301.ppops.net [127.0.0.1]

   - The following addresses had permanent fatal errors -

(reason: 550 5.1.1 ... User unknown)

   - Transcript of session follows -
... while talking to [144.160.112.16]:
>>> DATA
<<< 550 5.1.1 ... User unknown
550 5.1.1 ... User unknown
<<< 503 5.0.0 Need RCP
-- 
Mehmet
+1-424-298-1903

Help needed to validate results of topology discovery research

[Bahador Yeganeh]

Hi Nanog members,

I am senior PhD student with the Oregon Network Research Group (
https://onrg.gitlab.io) at the University of Oregon, and sending this email
to seek your help for validating the research results for one of our
network measurement projects.

We have conducted a large scale measurement study to infer the private
(both physical and virtual) and public interconnections between Amazon/AWS
network and all other ASes across the Internet along with their metro area
where they are located. More information about this project can be found at
https://ix.cs.uoregon.edu/~byeganeh/cloudx/. We are interested in
validating at least part of our results against ground truth. If you are
managing an AS that has one or more direct peerings with any of Amazon's
networks (AS7224, AS16509, AS19047, AS14618, AS38895, AS39111, AS8987, and
AS9059) and aware of their IPs and locations, it would be extremely
valuable if you could validate our inferred peering between your AS and
Amazon at the *aggregate level *(i.e. just indicating what fraction of our
inferred interconnections for your network is correct). We will report this
aggregate result in our study without revealing the identity of your
network.

If you have any questions or need more information about this project,
please feel free to contact me.

I appreciate your prompt response as we are trying to submit this study to
a conference in a few weeks.

Regards,
Bahador Yeganeh

Re: looking for hostname router identifier validation

[Matthew Luckie]

Hi,

I am aware that some PTR records are wrong.  Can you please name the
half dozen ISPs / suffixes so I can take a look at those in the data.
In theory the code should score suffixes which have out of date
records poorly.  For suffixes that don't score poorly but have errors,
there are other techniques that could reject incorrect clustering of
router interfaces.

Regarding uu.net (Bryan's email), it looks like those are colored red
on the website after 201207, i.e. I would not use them for anything.
But the transition to alter.net (Paul's email) looks good to me:

https://www.caida.org/~mjl/rnc/201901/alter.net.html

and I would claim the regex for alter.net is very good.  If someone
from alter.net is watching, can you comment on the gw1.iad8
inferences, where six interfaces are colored red as if they are named
wrong (back in Jan 2019).  My hunch is that the training data is
wrong, and those interfaces belong on the same router.  I can see
similar behavior for gw4.lax15.

Matthew

On Mon, Apr 29, 2019 at 01:13:38PM -0700, Eric Kuhnke wrote:
> I would caution against putting much faith in the validity of geolocation
> or site ID by reverse DNS PTR records. There are a vast number of
> unmaintained, ancient, stale, erroneous or wildly wrong PTR records out
> there. I can name at least a half dozen ISPs that have absorbed other ASes,
> some of those which also acquired other ASes earlier in their history,
> forming a turducken of obsolete PTR records that has things with ISP domain
> names last in use in the year 2002.
> 
> 
> 
> On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie  wrote:
> 
> > Hi NANOG,
> >
> > To support Internet topology analysis efforts, I have been working on
> > an algorithm to automatically detect router names inside hostnames
> > (PTR records) for router interfaces, and build regular expressions
> > (regexes) to extract them.  By "router name" inside the hostname, I
> > mean a substring, or set of non-contiguous substrings, that is common
> > among interfaces on a router.  For example, suppose we had the
> > following three routers in the savvis.net domain suffix, each with two
> > interfaces:
> >
> > das1-v3005.nj2.savvis.net
> > das1-v3006.nj2.savvis.net
> >
> > das1-v3005.oc2.savvis.net
> > das1-v3007.oc2.savvis.net
> >
> > das2-v3009.nj2.savvis.net
> > das2-v3012.nj2.savvis.net
> >
> > We might infer the router names are das1|nj2, das1|oc2, and das2|nj2,
> > respectively, and captured by the regex:
> > ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$
> >
> > After much refinement based on smaller sets of ground truth, I'm
> > asking for broader feedback from operators.  I've placed a webpage at
> > https://www.caida.org/~mjl/rnc/ that shows the inferences my algorithm
> > made for 2523 domains.  If you operate one of the domains in that
> > list, I would appreciate it if you could comment (private is probably
> > better but public is fine with me) on whether the regex my algorithm
> > inferred represents your naming intent.  In the first instance, I am
> > most interested in feedback for the suffix / date combinations for
> > suffixes that are colored green, i.e. appear to be reasonable.
> >
> > Each suffix / date combination links to a page that contains the
> > naming convention and corresponding inferences.  The colored part of
> > each hostname is the inferred router name.  The green hostnames appear
> > to be correct, at least as far as the algorithm determined.  Some
> > suffixes have errors due to either stale hostnames or incorrect
> > training data, and those hostnames are colored red or orange.
> >
> > If anyone is interested in sets of hostnames the algorithm may have
> > inferred as 'stale' for their network, because for some operators it
> > was an oversight and they were grateful to learn about it, I can
> > provide that information.
> >
> > Thanks,
> >
> > Matthew
> >


signature.asc
Description: PGP signature

Re: looking for hostname router identifier validation

[Patrick W. Gilmore]

Automation isn’t even that hard - just outsource (e.g. 6Connect).

I get why some things stagnate & collect kruft. But it is actually EASIER, and 
probably cheaper (including people time), to have a 3rd party “just do it” when 
it comes to things like DNS & IPAM.

Then again, if everyone ran everything perfectly … oh, then I could retire. :-)

-- 
TTFN,
patrick



> On Apr 30, 2019, at 8:12 AM, Jared Mauch  wrote:
> 
> While at NTT and at Akamai we have managed to publish sane PTR records and 
> make the forward work as well. You need to automate it by pulling from your 
> router configuration database and publish to your DNS database. If you are 
> still doing either by hand then it’s time to make the switch ASAP. 
> 
> Sent from my iCar
> 
> On Apr 29, 2019, at 4:13 PM, Eric Kuhnke  > wrote:
> 
>> I would caution against putting much faith in the validity of geolocation or 
>> site ID by reverse DNS PTR records. There are a vast number of unmaintained, 
>> ancient, stale, erroneous or wildly wrong PTR records out there. I can name 
>> at least a half dozen ISPs that have absorbed other ASes, some of those 
>> which also acquired other ASes earlier in their history, forming a turducken 
>> of obsolete PTR records that has things with ISP domain names last in use in 
>> the year 2002.
>> 
>> 
>> 
>> On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie > > wrote:
>> Hi NANOG,
>> 
>> To support Internet topology analysis efforts, I have been working on
>> an algorithm to automatically detect router names inside hostnames
>> (PTR records) for router interfaces, and build regular expressions
>> (regexes) to extract them.  By "router name" inside the hostname, I
>> mean a substring, or set of non-contiguous substrings, that is common
>> among interfaces on a router.  For example, suppose we had the
>> following three routers in the savvis.net  domain 
>> suffix, each with two
>> interfaces:
>> 
>> das1-v3005.nj2.savvis.net 
>> das1-v3006.nj2.savvis.net 
>> 
>> das1-v3005.oc2.savvis.net 
>> das1-v3007.oc2.savvis.net 
>> 
>> das2-v3009.nj2.savvis.net 
>> das2-v3012.nj2.savvis.net 
>> 
>> We might infer the router names are das1|nj2, das1|oc2, and das2|nj2,
>> respectively, and captured by the regex:
>> ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$
>> 
>> After much refinement based on smaller sets of ground truth, I'm
>> asking for broader feedback from operators.  I've placed a webpage at
>> https://www.caida.org/~mjl/rnc/  that shows 
>> the inferences my algorithm
>> made for 2523 domains.  If you operate one of the domains in that
>> list, I would appreciate it if you could comment (private is probably
>> better but public is fine with me) on whether the regex my algorithm
>> inferred represents your naming intent.  In the first instance, I am
>> most interested in feedback for the suffix / date combinations for
>> suffixes that are colored green, i.e. appear to be reasonable.
>> 
>> Each suffix / date combination links to a page that contains the
>> naming convention and corresponding inferences.  The colored part of
>> each hostname is the inferred router name.  The green hostnames appear
>> to be correct, at least as far as the algorithm determined.  Some
>> suffixes have errors due to either stale hostnames or incorrect
>> training data, and those hostnames are colored red or orange.
>> 
>> If anyone is interested in sets of hostnames the algorithm may have
>> inferred as 'stale' for their network, because for some operators it
>> was an oversight and they were grateful to learn about it, I can
>> provide that information.
>> 
>> Thanks,
>> 
>> Matthew

Re: looking for hostname router identifier validation

[Bryan Holloway]

On 4/29/19 7:21 PM, Valdis Klētnieks wrote:

On Mon, 29 Apr 2019 16:16:06 -0500, Bryan Holloway said:


I still see references to UUNet in some reverse PTRs.

So, uh, yeah.


I wonder what year we'll get to a point where less than half of NANOG's
membership was around when UUNet was. We're probably there already.
And likely coming up on when less than half the people know what it
was, other than myth and legend



Bought my first T-1 from those guys ... don't even ask how much it cost.

Re: looking for hostname router identifier validation

[Bryan Holloway]

On 4/30/19 7:12 AM, Jared Mauch wrote:
While at NTT and at Akamai we have managed to publish sane PTR records 
and make the forward work as well. You need to automate it by pulling 
from your router configuration database and publish to your DNS 
database. If you are still doing either by hand then it’s time to make 
the switch ASAP.


Sent from my iCar


What's the reverse of your iCar? ;)

Re: looking for hostname router identifier validation

[Jared Mauch]

While at NTT and at Akamai we have managed to publish sane PTR records and make 
the forward work as well. You need to automate it by pulling from your router 
configuration database and publish to your DNS database. If you are still doing 
either by hand then it’s time to make the switch ASAP. 

Sent from my iCar

> On Apr 29, 2019, at 4:13 PM, Eric Kuhnke  wrote:
> 
> I would caution against putting much faith in the validity of geolocation or 
> site ID by reverse DNS PTR records. There are a vast number of unmaintained, 
> ancient, stale, erroneous or wildly wrong PTR records out there. I can name 
> at least a half dozen ISPs that have absorbed other ASes, some of those which 
> also acquired other ASes earlier in their history, forming a turducken of 
> obsolete PTR records that has things with ISP domain names last in use in the 
> year 2002.
> 
> 
> 
>> On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie  wrote:
>> Hi NANOG,
>> 
>> To support Internet topology analysis efforts, I have been working on
>> an algorithm to automatically detect router names inside hostnames
>> (PTR records) for router interfaces, and build regular expressions
>> (regexes) to extract them.  By "router name" inside the hostname, I
>> mean a substring, or set of non-contiguous substrings, that is common
>> among interfaces on a router.  For example, suppose we had the
>> following three routers in the savvis.net domain suffix, each with two
>> interfaces:
>> 
>> das1-v3005.nj2.savvis.net
>> das1-v3006.nj2.savvis.net
>> 
>> das1-v3005.oc2.savvis.net
>> das1-v3007.oc2.savvis.net
>> 
>> das2-v3009.nj2.savvis.net
>> das2-v3012.nj2.savvis.net
>> 
>> We might infer the router names are das1|nj2, das1|oc2, and das2|nj2,
>> respectively, and captured by the regex:
>> ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$
>> 
>> After much refinement based on smaller sets of ground truth, I'm
>> asking for broader feedback from operators.  I've placed a webpage at
>> https://www.caida.org/~mjl/rnc/ that shows the inferences my algorithm
>> made for 2523 domains.  If you operate one of the domains in that
>> list, I would appreciate it if you could comment (private is probably
>> better but public is fine with me) on whether the regex my algorithm
>> inferred represents your naming intent.  In the first instance, I am
>> most interested in feedback for the suffix / date combinations for
>> suffixes that are colored green, i.e. appear to be reasonable.
>> 
>> Each suffix / date combination links to a page that contains the
>> naming convention and corresponding inferences.  The colored part of
>> each hostname is the inferred router name.  The green hostnames appear
>> to be correct, at least as far as the algorithm determined.  Some
>> suffixes have errors due to either stale hostnames or incorrect
>> training data, and those hostnames are colored red or orange.
>> 
>> If anyone is interested in sets of hostnames the algorithm may have
>> inferred as 'stale' for their network, because for some operators it
>> was an oversight and they were grateful to learn about it, I can
>> provide that information.
>> 
>> Thanks,
>> 
>> Matthew

Re: looking for hostname router identifier validation

[Julien Goodwin]

On 30/4/19 10:38 am, Chris Adams wrote:
> I still refer to ASes by companies that haven't existed in ages... 701
> is UUNet, 3561 is MCI, 1 is BBN, etc. :)  I don't handle name changes
> well (I also refer to one of the main roads where I live by a name it
> hasn't had in close to 20 years).

This is especially true with acquisitions, AS3549 will be GBLX for me
until it finally goes offline, and AS3356 likewise L3.

Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd)

[Carlos Friaças via NANOG]

Hi Everyone,

Just a gentle reminder that May 1st is the last day to express 
support for this Open Petition at ARIN's Public Policy Mailing List 
(arin-ppml).


Best Regards,
Carlos



On Fri, 26 Apr 2019, Carlos Friaças via NANOG wrote:



Hi,

Just to let everybody know that a petition was started in order to try to 
enable a policy discussion about "BGP Hijacking is an ARIN Policy Violation".


If you would like to read the proposal, it is available at:
https://www.arin.net/participate/policy/proposals/2019/ARIN_prop_266_v2/

Discussions are already ongoing at RIPE and LACNIC.

Best Regards,
Carlos

(sorry for the duplicates, if you also receive arin-p...@arin.net)

-- Forwarded message --
Date: Fri, 26 Apr 2019 17:13:12
From: ARIN 
To: arin-p...@arin.net
Subject: [arin-ppml] Open Petition for ARIN-prop-266: BGP Hijacking is an 
ARIN

   Policy Violation

A petition has been initiated for the following:

ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation

This proposal was rejected due to scope at the 10 April meeting of the 
Advisory Council.


Anyone may take part in this petition. Per the Policy Development Process 
(PDP), a successful petition against a rejected Proposal requires the support 
of ten individuals from ten organizations.


To support this petition, simply send a response to the Public Policy Mailing 
list stating your support, name, and organization.


This petition window will remain open for five days, closing 1 May.

If successful, the petition will result in the Board of Trustees considering 
the Proposal's scope at their next meeting.


For more information on the PDP, visit: 
https://www.arin.net/participate/policy/pdp/


Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (arin-p...@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.