Re: Voip faxing

2016-10-31 Thread John Osmon 
On Mon, Oct 31, 2016 at 04:52:46AM +, Carlos Alcantar wrote:
> Hey Samual,
> 
> 
> you might want to check out the voice ops mailing list, might be a bit more 
> relevant over there.
> 
> 
> https://puck.nether.net/mailman/listinfo/voiceops

Aside from voiceops, here's decade (or more?) old web page that I point
people to when they want to deal with Fax over VoIP:
http://www.soft-switch.org/foip.html

RE: IPv6 automatic reverse DNS

2016-10-31 Thread White, Andrew 
Hi John,

Thanks for the info and background.

One operational suggestion I have is … why link synthesis rules to a specific 
DNS zone?

Most larger operators of auth DNS use an IP management tool, like BT Diamond 
IPAM, BlueCat, or Infoblox. Oftentimes, allocations of IP space will not be on 
classful boundaries, yet most often reverse DNS zones are on classful 
boundaries.

What may be more operationally useful would be an (optional) feature in auth 
DNS software that would process an incoming PTR request as follows:


1.   Answer the PTR with an entry in the corresponding ip6.arpa or 
in-addr.arpa zone file if the PTR exists

2.   Otherwise, examine a rule set of synthetic PTR responses and answer by 
the rule set (e.g. 10.0.0.128 matches rule for “10.0.0.128/27” and returns PTR 
of 10-0-0-128.dhcp.example.com.)

3.   Otherwise, return NXDOMAIN or NOANSWER/NOERROR as appropriate

Such a ruleset could apply to forward zones as well to create the matching 
forward lookup.

Just my two cents!  Caveat: personal opinion and not the official position of 
Charter.

Andrew


Ληdrеw Whiте
Charter Network Operations - DAS DNS
Desk: 314-394-9594 - Cell: 314-452-4386
andrew.whi...@charter.com

From: Woodworth, John R [mailto:john.woodwo...@centurylink.com]
Sent: Monday, October 31, 2016 11:04 PM
To: White, Andrew; 'nanog@nanog.org'
Cc: Ballew, Dean; Woodworth, John R
Subject: RE: IPv6 automatic reverse DNS

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of White, Andrew
>
> There are two competing drafts for synthetic rule-based PTR responses
> for IPv6 rDNS:
>
> Howard Lee, Time Warner Cable (now Charter)
> https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08
>
> J. Woodworth, CenturyLink
> https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
>
> Nominum and Xerocole/Akamai also have proprietary solutions to this
> in their Vantio AuthServ and AuthX products, respectively.
>
> It seems to me that it is still an open question whether the
> recommendations in RFC-1912 that any IP address that accesses the
> Internet should have a PTR and matching forward record. My personal
> thoughts are that the best solution would be an OPTIONAL standards-based
> method of generating DNS responses based on a ruleset if a specific zone
> record is not present, and that implementation of that requirement
> should be left to the developers of the auth nameserver software.

Greetings Andrew,

I am new to the group but one of the authors referenced above.  My
colleagues and I are glad to see the discussion around this issue
see some recent movement.

As indicated by one of our esteemed WG chairs elsewhere in this thread,
I am currently working to provide additional clarity for some of the
more difficult concepts in the draft and have not yet requested the
next step.  Once these changes are complete we will enthusiastically
move forward with this request.

As I am new to this forum, for the moment I wanted to simply state:
synthesized records based on the proposed "bulk rr" method can
_only_exist_where_zone_records_do_not_already_.  One critical goal of
the draft is to make the "intent" of synthesized records easy to
transfer between nameservers in authoritative roles.  Examples for
implementing the draft using fairly straightforward regex
manipulation are included but are more of a guideline for making
the pattern substitution easier for the implementor and provide
a reference for the accompanying examples.  Ultimately, as you
recommend, the auth nameserver software vendor would be free to
provide their own pattern substitution logic (so long as the
intent is not lost).

DNSSEC for synthesized records also poses its own obvious set of…
complications for which we've outlined a number of solutions to
help satisfy this challenge.

Admittedly, it is a bit of a hefty read but we would love the
feedback (directly or in the IETF DNSOP mailing list of course).


Thanks,
John Woodworth


>
> Andrew
>
> Caveat: These thoughts are mine personally and do not represent
> any official position of Charter Communications.
>
>
> Ληdrеw Whiте
> Charter Network Operations - DAS DNS
> Desk: 314-394-9594 ? Cell: 314-452-4386
> andrew.whi...@charter.com
>

-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.

Re: Help interpret a strange traceroute?

2016-10-31 Thread Larry Sheldon 



On 10/31/2016 14:42, William Herrin wrote:

On Mon, Oct 31, 2016 at 3:33 PM, Randy  wrote:

Any idea how a traceroute (into my network) could end up this fubar'd?
Discovered this wierd routing while investigating horrendously slow speeds
(albeit no packet loss) to a particular ISP abroad.


Hi Randy,

This is per-packet load balancing. In the forward path the alternates
are different lengths but the traceroute stops as soon as at least one
of the paths reaches the destination.

The return path is also engaged in per-packet load balancing but the
paths are all the same length.


Seems like a lot of bandwidth trying to save bandwidth.  Or does that 
only happen to ICMP?


--
"Everybody is a genius.  But if you judge a fish by
its ability to climb a tree, it will live its whole
life believing that it is stupid."

--Albert Einstein

From Larry's Cox account.

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24

2016-10-31 Thread Selphie Keller 
Nick,

Very cool, learn something new every day :)

[root@stellarfrost(~)]> nicinfo 103.11.67.167
# NicInfo v.1.1.1

[ NOTICE ] Terms of Service
 1 By using the ARIN RDAP/Whois service, you are agreeing to the
RDAP/Whois Terms of Use
 About https://www.arin.net/whois_tou.html

# Query type is IP4ADDR. Result type is IP.

[ RESPONSE DATA ]
  1= NET-103-11-67-0-1
 |--- 1= Gaiacom, L.C. ( GL-299 )
 ||--- 1= GCM NY NOC ( GNN-ARIN )
 |`--- 2= GCM NET ABUSE ( GNA35-ARIN )
 `--- 2= Los Angeles NOC ( LAN55-ARIN )

   [ IP NETWORK ]
   Handle:  NET-103-11-67-0-1
Start Address:  103.011.067.000
  End Address:  103.011.067.255
   IP Version:  v4
 Last Changed:  Mon, 13 Jun 2016 15:20:51 -0700
 Registration:  Wed, 25 May 2016 17:17:12 -0700

   [ ENTITY ]
   Handle:  GL-299
 Name:  Gaiacom, L.C.
Roles:  Registrant
 Last Changed:  Fri, 15 Aug 2014 11:26:53 -0700
 Registration:  Wed, 04 Dec 2013 13:01:12 -0800

   [ ENTITY ]
   Handle:  GNN-ARIN
 Name:  GCM NY NOC
 Organization:  GCM NY NOC
Email:  n...@gaiacom.net
Phone:  +1-310-421-9099 ( work, voice )
Phone:  +1-310-421-9098 ( work, fax )
Roles:  Noc, Technical, Administrative
   Status:  Validated
 Last Changed:  Sat, 20 Aug 2016 09:21:23 -0700
 Registration:  Tue, 26 Nov 2013 22:58:12 -0800

   [ ENTITY ]
   Handle:  GNA35-ARIN
 Name:  GCM NET ABUSE
 Organization:  GCM NET ABUSE
Email:  n...@maya.net
Phone:  +1-310-421-9099 ( work, voice )
Phone:  +1-310-421-9098 ( work, fax )
Roles:  Abuse
   Status:  Validated
 Last Changed:  Wed, 03 Aug 2016 13:51:02 -0700
 Registration:  Tue, 26 Nov 2013 23:39:45 -0800

   [ ENTITY ]
   Handle:  LAN55-ARIN
 Name:  Los Angeles NOC
 Organization:  Los Angeles NOC
Email:  n...@maya.net
Phone:  +1-213-587-7995 ( work, voice )
Phone:  +1-213-587-7995 ( work, cell )
Phone:  +1-213-587-7995 ( work, fax )
Roles:  Technical, Noc
   Status:  Validated
 Last Changed:  Mon, 13 Jun 2016 15:14:38 -0700
 Registration:  Mon, 13 Jun 2016 15:14:38 -0700

# Use "nicinfo 1=" to show NET-103-11-67-0-1
# Use "nicinfo 1.1=" to show Gaiacom, L.C. ( GL-299 )
# Use "nicinfo 1.2=" to show Los Angeles NOC ( LAN55-ARIN )
# Use "nicinfo https://rdap.arin.net/registry/ip/103.011.067.000; to
directly query this resource in the future.
# Use "nicinfo -h" for help.

On 31 October 2016 at 17:21, Nick Hilliard  wrote:

> Selphie Keller wrote:
> > APNIC -> 103.11.64.0/22 -> then to WebNX 103.11.67.0/24, which would
> show
> > the full chain and a proper abuse contact for this subnet.
>
> the tl;dr on the thread scrollback was:
>
> 1. whois is irredeemably broken
> 2. use rdap, which supports referrals
> 3. open source RDAP client: https://github.com/arineng/nicinfo
>
> Nick
>

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24

2016-10-31 Thread Nick Hilliard 
Selphie Keller wrote:
> APNIC -> 103.11.64.0/22 -> then to WebNX 103.11.67.0/24, which would show
> the full chain and a proper abuse contact for this subnet.

the tl;dr on the thread scrollback was:

1. whois is irredeemably broken
2. use rdap, which supports referrals
3. open source RDAP client: https://github.com/arineng/nicinfo

Nick

Network Maps - Western Europe

2016-10-31 Thread Rod Beck 
Hi,


I am trying to determine the physical diversity of the Zayo and Level3 networks 
vis-a-vis each other on the European racetrack - 
London/Amsterdam/Frankfurt/Paris/London. It is for a client of mine.


Regards,


Roderick.

Re: Help interpret a strange traceroute?

2016-10-31 Thread Bryan Holloway 

On 10/31/16 4:20 PM, Olivier Benghozi wrote:

Hi Randy,


ECMP loadbalancing is most frequently done on layer3+layer4 headers, and 
unixlike traceroute use UDP with increasing destination port number for each 
packet (usually starting at 33434), which allows to see the different available 
paths, as wrote William.

Would you want/need to stick to only one traceroute path, you may use ICMP 
traceroute instead of UDP traceroute (no port in ICMP, so only layer 3 
available to loadbalance, so all packets will go through the same interface).

Usually it is achieved by using traceroute -I yourdest
Windows tracert is ICMP only traceroute by the way. MTR tool is also ICMP based 
by default.

Keep in mind that it looses some useful information, though (since you see only 
one path and don't decide which).
So, you can also use UDP traceroute with fixed port (by example 33434 with no 
port increase), and try again the same traceroute with another destport (with 
fixed port too, by example 33435), which would display two different paths in a 
more readable way. RTFM is required since the options depend on your traceroute 
particular specie :)


Olivier


On 31 oct. 2016 à 20:42, William Herrin  wrote :

On Mon, Oct 31, 2016 at 3:33 PM, Randy  wrote:

Any idea how a traceroute (into my network) could end up this fubar'd?
Discovered this wierd routing while investigating horrendously slow speeds
(albeit no packet loss) to a particular ISP abroad.


Hi Randy,

This is per-packet load balancing. In the forward path the alternates
are different lengths but the traceroute stops as soon as at least one
of the paths reaches the destination.

The return path is also engaged in per-packet load balancing but the
paths are all the same length.




This is also a handy tool that addresses the same issues:

https://paris-traceroute.net/

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24

2016-10-31 Thread Selphie Keller 
Hi,

I noticed this thread and wanted to provide some information, subnet
103.11.67.0/24 is not an illicit squat this subnet is apart of
103.11.64.0/22 which was transferred from APNIC to ARIN back this last
February and is listed publicly at
https://www.arin.net/knowledge/statistics/transfers.html within the
"Inter-RIR Transfers to the ARIN Region", also WebNX AS18450 does have the
LOA's on file for the subnet.

I do agree with the others in this thread about the lack of WHOIS  as
looking up 103.11.67.0/24 does indeed provide very little information to go
on so I can see how this could be misunderstood as a squat of the subnet
due to the lack of whois information which is an updating issue
ARIN/APNIC's part, hopefully can get this resolved so that ARIN shows the
chain:

APNIC -> 103.11.64.0/22 -> then to WebNX 103.11.67.0/24, which would show
the full chain and a proper abuse contact for this subnet.

As for the spamming/spam email part of this thread, please send the said
spam email/emails with headers in question to ab...@webnx.com, this way we
can investigate and sort it out. We do take spamming seriously and will
work quickly to get it resolved.

-Selphie K

Re: Help interpret a strange traceroute?

2016-10-31 Thread Olivier Benghozi 
Hi Randy,


ECMP loadbalancing is most frequently done on layer3+layer4 headers, and 
unixlike traceroute use UDP with increasing destination port number for each 
packet (usually starting at 33434), which allows to see the different available 
paths, as wrote William.

Would you want/need to stick to only one traceroute path, you may use ICMP 
traceroute instead of UDP traceroute (no port in ICMP, so only layer 3 
available to loadbalance, so all packets will go through the same interface).

Usually it is achieved by using traceroute -I yourdest
Windows tracert is ICMP only traceroute by the way. MTR tool is also ICMP based 
by default.

Keep in mind that it looses some useful information, though (since you see only 
one path and don't decide which).
So, you can also use UDP traceroute with fixed port (by example 33434 with no 
port increase), and try again the same traceroute with another destport (with 
fixed port too, by example 33435), which would display two different paths in a 
more readable way. RTFM is required since the options depend on your traceroute 
particular specie :)


Olivier

> On 31 oct. 2016 à 20:42, William Herrin  wrote :
> 
> On Mon, Oct 31, 2016 at 3:33 PM, Randy  wrote:
>> Any idea how a traceroute (into my network) could end up this fubar'd?
>> Discovered this wierd routing while investigating horrendously slow speeds
>> (albeit no packet loss) to a particular ISP abroad.
> 
> Hi Randy,
> 
> This is per-packet load balancing. In the forward path the alternates
> are different lengths but the traceroute stops as soon as at least one
> of the paths reaches the destination.
> 
> The return path is also engaged in per-packet load balancing but the
> paths are all the same length.

Re: Help interpret a strange traceroute?

2016-10-31 Thread William Herrin 
On Mon, Oct 31, 2016 at 3:33 PM, Randy  wrote:
> Any idea how a traceroute (into my network) could end up this fubar'd?
> Discovered this wierd routing while investigating horrendously slow speeds
> (albeit no packet loss) to a particular ISP abroad.

Hi Randy,

This is per-packet load balancing. In the forward path the alternates
are different lengths but the traceroute stops as soon as at least one
of the paths reaches the destination.

The return path is also engaged in per-packet load balancing but the
paths are all the same length.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web:

Help interpret a strange traceroute?

2016-10-31 Thread Randy 

Happy monday all!

Any idea how a traceroute (into my network) could end up this fubar'd?   
Discovered this wierd routing while investigating horrendously slow 
speeds (albeit no packet loss) to a particular ISP abroad.


It's like - coming into us - the packets are taking every available 
path, simultaniously.   Tracing back to him looks perfectly normal.


Thank you in advance for any comments on or off list.

Him to us:
traceroute to mirror.ash.fastserv.com (208.85.240.29), 64 hops max, 52 
byte packets

 1  192.168.1.1 (192.168.1.1)  1.552 ms  1.522 ms  1.261 ms
 2  br1.l.hiweb.ir (46.224.0.12)  17.750 ms  18.932 ms  18.811 ms
 3  172.16.5.65 (172.16.5.65)  18.505 ms  20.044 ms  18.414 ms
 4  int.gr1.s.hiweb.ir (46.224.0.125)  19.096 ms  18.447 ms  18.752 ms
 5  int.gr1.l.hiweb.ir (46.224.0.117)  18.454 ms  18.768 ms  103.441 ms
 6  10.21.252.166 (10.21.252.166)  66.308 ms  18.728 ms  18.867 ms
 7  * * *
 8  185.100.209.139 (185.100.209.139)  162.126 ms
ae5.istanbul1.ist.seabone.net (93.186.132.212)  210.124 ms  126.208 
ms

 9  et7-1-0.franco71.fra.seabone.net (195.22.214.131)  102.694 ms
if-ae-9-3.tcore1.pvu-paris.as6453.net (195.219.87.14)  189.955 ms
185.100.209.197 (185.100.209.197)  218.539 ms
10  te0-3-0-4.rcr21.b023101-0.lon01.atlas.cogentco.com (149.14.144.89)  
201.223 ms  215.996 ms

185.100.209.1 (185.100.209.1)  164.381 ms
11  if-ae-2-2.tcore2.av2-amsterdam.as6453.net (195.219.194.6)  199.161 
ms

be2950.ccr22.lon01.atlas.cogentco.com (130.117.2.109)  216.648 ms
if-ae-3-6.tcore1.l78-london.as6453.net (80.231.130.85)  271.750 ms
12  if-ae-4-2.thar1.njy-newark.as6453.net (80.231.130.34)  183.984 ms *
be2814.ccr42.ams03.atlas.cogentco.com (130.117.0.141)  109.045 ms
13  if-ae-1-3.thar2.njy-newark.as6453.net (216.6.57.2)  207.371 ms
be2870.ccr41.lon13.atlas.cogentco.com (154.54.58.173)  186.804 ms
be12488.ccr42.lon13.atlas.cogentco.com (130.117.51.41)  190.236 ms
14  if-ae-14-14.tcore2.nto-new-york.as6453.net (66.198.111.126)  203.156 
ms
if-ae-9-2.tcore1.n75-new-york.as6453.net (63.243.128.122)  273.177 
ms

be2807.ccr42.dca01.atlas.cogentco.com (154.54.40.110)  235.632 ms
15  66.110.96.134 (66.110.96.134)  182.695 ms
be2806.ccr41.dca01.atlas.cogentco.com (154.54.40.106)  278.593 ms  
240.075 ms

16  66.110.96.142 (66.110.96.142)  245.454 ms
be3084.ccr41.iad02.atlas.cogentco.com (154.54.30.66)  191.973 ms
be3083.ccr41.iad02.atlas.cogentco.com (154.54.30.54)  240.740 ms
17  te0-0-0-0.nr13.b023801-0.iad01.atlas.cogentco.com (154.24.36.18)  
257.027 ms

be3083.ccr41.iad02.atlas.cogentco.com (154.54.30.54)  236.617 ms
hu-1-3-0-2-cr02.newyork.ny.ibone.comcast.net (68.86.83.97)  221.186 
ms
18  be-10102-cr02.ashburn.va.ibone.comcast.net (68.86.85.161)  194.766 
ms  250.493 ms

be-10203-cr01.newark.nj.ibone.comcast.net (68.86.85.185)  191.052 ms
19  be-10102-cr02.ashburn.va.ibone.comcast.net (68.86.85.161)  197.694 
ms
te0-0-2-0.nr11.b023801-0.iad01.atlas.cogentco.com (154.24.36.2)  
266.914 ms  235.444 ms
20  te0-0-2-3.nr11.b023801-0.iad01.atlas.cogentco.com (154.24.36.6)  
255.756 ms

38.88.249.210 (38.88.249.210)  216.677 ms
te0-0-2-0.nr11.b023801-0.iad01.atlas.cogentco.com (154.24.36.2)  
211.364 ms

21  208.85.240.29 (208.85.240.29)  274.692 ms  212.896 ms
ash01-mls-dc-core-a.latisys.net (67.217.175.37)  208.976 ms

And back to him:
traceroute to 46.224.145.65 (46.224.145.65), 30 hops max, 60 byte 
packets

 1  104.153.64.146 (104.153.64.146)  22.067 ms  22.049 ms *
 2  xe-3-1-1.er1.iad10.us.above.net (208.185.24.1)  0.398 ms  0.392 ms  
0.420 ms
 3  zayo-tata.iad10.us.zip.zayo.com (64.125.13.170)  0.708 ms  0.580 ms  
0.623 ms
 4  if-ae-11-2.thar2.NJY-Newark.as6453.net (216.6.87.138)  92.900 ms 
if-ae-11-3.thar2.NJY-Newark.as6453.net (216.6.87.242)  92.802 ms 
if-ae-11-4.thar2.NJY-Newark.as6453.net (216.6.87.169)  97.177 ms
 5  if-ae-1-3.thar1.NJY-Newark.as6453.net (216.6.57.1)  92.940 ms  
93.008 ms  89.431 ms
 6  if-ae-8-2.tcore1.LDN-London.as6453.net (66.198.70.174)  97.315 ms  
96.049 ms  95.855 ms
 7  if-ae-17-2.tcore1.L78-London.as6453.net (80.231.130.129)  98.074 ms 
if-ae-3-6.tcore1.PYE-Paris.as6453.net (80.231.130.86)  92.733 ms  92.898 
ms
 8  if-ae-2-2.tcore1.PVU-Paris.as6453.net (80.231.154.17)  93.636 ms 
if-ae-3-6.tcore1.PYE-Paris.as6453.net (80.231.130.86)  97.917 ms  98.363 
ms
 9  if-ae-2-2.tcore1.PVU-Paris.as6453.net (80.231.154.17)  100.909 ms 
if-ae-9-3.tcore2.FNM-Frankfurt.as6453.net (195.219.87.13)  92.055 ms  
93.173 ms
10  195.219.87.46 (195.219.87.46)  208.894 ms  209.042 ms 
if-ae-9-2.tcore2.FNM-Frankfurt.as6453.net (195.219.87.9)  94.718 ms
11  * 195.219.87.46 (195.219.87.46)  209.640 ms int.gr1.s.hiweb.ir 
(46.224.0.118)  202.201 ms

12  int.cr1.s.hiweb.ir (46.224.0.126)  205.150 ms * *
13  * * *
14  int.gr1.s.hiweb.ir (46.224.0.118)  201.803 ms  201.799 ms 
int.cr1.s.hiweb.ir (46.224.0.126)  201.819 ms

15  int.cr1.s.hiweb.ir (46.224.0.126)  204.952 ms  198.969 ms *
16

Re: Spitballing IoT Security

2016-10-31 Thread Pierre Lamy 
On 30/10/2016 12:43 AM, Eric S. Raymond wrote:
> Ronald F. Guilmette :
>> Two kids with a modest amount of knowledge
>> and a lot of time on their hands can do it from their mom's basement.
> 
> I in turn have to call BS on this.  If it were really that easy, we'd
> be inundated by Mirais -- we'd have several attacks a *day*.
> 

It's not easy, Mirai was closed source until the actor released it. We
see a pattern again and again, where the bad guys find a private
monetization strategy, milk it, and get out before too much attention is
focused on just them. By dumping the code, the Mirai actors obfuscate
attribution.

Now that the code is public, we see a huge surge in dumb & pointless
attacks against gaming/mod sites, Dyn, public schools and so on. We also
see bad code "improvements" which were recently referenced.

http://motherboard.vice.com/read/wannabe-hackers-are-adding-terrible-and-stupid-features-to-mirai

The long term problem isn't any manufacturer or Mirai, it's going to be
the long tail of IoT devices that never see a patch, deployed by people
who don't know anything about security (nor should they need to... flame
suit on). When millions of any type of device are put online, times
thousands of products, it only takes one bad guy's "a-ha" moment for
this to happen again. They'll milk it for a while, the attack
vector/method will get pushed down to the skid level, and we'll see a
massive increase in un-targeted attacks by those script kiddies until
the cycle repeats. There's an endless fresh supply of script kiddies.

While I agree with BCP38 etc, it wouldn't have prevented Mirai.
Self-update functions at some point for these devices are going to get
borked as well, such as a company going bust or forgetting to renew
their auto-update target domain. If you can't get (thousands?) of major
operators to deploy common sense security configurations, how will
similar best practices be implemented by tens of thousands of
manufacturers? Putting device regulations in one country won't impact
the rest of the internet's connected devices either.

Solutions...? Someone's going to have to take out a hammer, not a
scalpel, for these issues.

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24

2016-10-31 Thread Christopher Morrow 
On Fri, Oct 28, 2016 at 7:36 PM, Ronald F. Guilmette 
wrote:

> In my own defense, I didn't see the ARIN allocation because I have a
> normative process that I use for looking up IP addresses.  It's
> hierarchical, and I always start with whatver whois.iana.org has to
> say.  And it says that that 103.0.0.0/8 belongs to APNIC, so of course,
> I only looked at what whois.apnic.net had to say about 103.11.67.105.
> And it says that it's unallocated.  (And apparently, data shown for
> announced prefixes on the bgp.he.net web site is also obtained in this
> same straightforward way, because it also is showing 103.11.67.0/24 as
> registered to "Asia Pacific Network Information Centre".)
>

In this new world of inter-rir transfers your process needs a revision.
it's also not uncommon for hosting folks to allocate address space to
non-local customers.

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24

2016-10-31 Thread Tony Finch 
Ronald F. Guilmette  wrote:
>
> You are correct.  In this case, it would have been helpful if APNIC's WHOIS
> server returned something, when queried about 103.11.67.105, that would
> include an explicit referral to the ARIN WHOIS server.  I mean they
> obviously know all the transfers they've made.

Yes, the state of whois referrals from RIRs is a bit of a mess.

I have changed FreeBSD whois to rely more on referrals than built-in
knowledge, and this mostly works. There are a couple of hacks to cope with
awkward RIRs: AfriNIC's referrals are human-readable though they can be
parsed if you assume the rubric is fixed; for RIPE, if the netname is
NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK it is treated as a referral to ARIN;
there's a similar hack for APNIC's ERX-NETBLOCKs - but evidently this
doesn't apply to more recently transferred net blocks :-(

It's probably time to make whois use RDAP under the covers for address
lookups. Bah.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Southeast Iceland: Westerly veering northwesterly 6 to gale 8, decreasing 4 or
5 for a time. Rough or very rough, occasionally high at first, then becoming
moderate in west. Showers. Good, occasionally poor.

Re: AS6461 (Zayo) LAS->ORD Packet Loss

2016-10-31 Thread Theodore Baschak 
I noticed similar for a couple hours to one host I monitor that took Zayo LGA 
-> ORD around the time you're describing as well.
Only affected IPv4 (v6 takes same path), however that could have been a reverse 
path coming over something else masking the problem there.

Theodore Baschak - AS395089 - Hextet Systems
https://ciscodude.net/ - https://hextet.systems/
http://mbix.ca/

> On Oct 30, 2016, at 6:52 PM, Brandon Yarnell via NANOG  
> wrote:
> 
> Seeing some packet loss between LAS and ORD on the Zayo backbone. Long wait
> times / no answer on the ncc line, no auto-response/ticket creation after
> sending email.
> 
> Anybody know whats up? Alerts cleared after taking the peers out of route.
> 
> 
> 
> -- 
> 
> ===
> 
> 
> Brandon Yarnell
> Senior Network Engineer | Technical Operations
> O: (720) 515-3376