- Test - lists.nanog.org

replacing EPP?
by Ryan Finnesey 22 Dec '16

22 Dec '16

Has there been an discussion about replacing EPP with something more modern? Cheers Ryan

2 1

Re: Recent NTP pool traffic increase (update)
by Denys Fedoryshchenko 21 Dec '16

21 Dec '16

I'm not sure if this issue relevant to discussed topic, Tenda routers here for a while on market, and i think i noticed this issue just now, because NTP servers they are using supposedly for healthcheck went down (or NTP owners blocked ISP's i support, due such routers). At least after checking numerous users, i believe Tenda hardcoded those NTP IPs. What worsen issue, that in Lebanon several times per day, for example at 18pm - short electricity cutoff, and majority of users routers will reboot and surely reconnect, so it will look like a countrywide spike in NTP traffic. I checked for a 10min also this NTP ips in dns responses, none of thousands of users tried to resolve any name with them over any DNS server, so i conclude they are hardcoded somewhere in firmware. Here is traffic of Tenda router after reconnecting (but not full powercycle, i dont have it in my hands). But as you can see, no DNS resolution attempts: 20:15:59.305739 PPPoE [ses 0x1483] CHAP, Success (0x03), id 1, Msg S=XXXXXX M=Authentication succeeded 20:15:59.306100 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 1, length 12 20:15:59.317840 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 1, length 24 20:15:59.317841 PPPoE [ses 0x1483] IPCP, Conf-Ack (0x02), id 1, length 12 20:15:59.317867 PPPoE [ses 0x1483] IPCP, Conf-Nack (0x03), id 1, length 18 20:15:59.325253 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 2, length 24 20:15:59.325273 PPPoE [ses 0x1483] IPCP, Conf-Ack (0x02), id 2, length 24 20:15:59.335589 PPPoE [ses 0x1483] IP 172.17.49.245.123 > 133.100.9.2.123: NTPv3, Client, length 48 20:15:59.335588 PPPoE [ses 0x1483] IP 172.17.49.245.123 > 192.5.41.41.123: NTPv3, Client, length 48 20:15:59.335588 PPPoE [ses 0x1483] IP 172.17.49.245.123 > 192.5.41.40.123: NTPv3, Client, length 48 Here is example of Tenda traffic if it is unable to reach destination, it repeats request each 10 seconds endlessly, my guess they are using ntp to show status of internet connection. So, now that NTP servers getting quite significant DDoS such way. 19:57:52.162863 IP (tos 0x0, ttl 64, id 38515, offset 0, flags [none], proto UDP (17), length 76) 172.16.31.67.123 > 192.5.41.40.123: [udp sum ok] NTPv3, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) 19:57:52.163277 IP (tos 0x0, ttl 64, id 38516, offset 0, flags [none], proto UDP (17), length 76) 172.16.31.67.123 > 192.5.41.41.123: [udp sum ok] NTPv3, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) 19:57:52.164435 IP (tos 0x0, ttl 64, id 38517, offset 0, flags [none], proto UDP (17), length 76) 172.16.31.67.123 > 133.100.9.2.123: [udp sum ok] NTPv3, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) 19:58:02.164781 IP (tos 0x0, ttl 64, id 38518, offset 0, flags [none], proto UDP (17), length 76) 172.16.31.67.123 > 192.5.41.40.123: [udp sum ok] NTPv3, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) 19:58:02.164884 IP (tos 0x0, ttl 64, id 38519, offset 0, flags [none], proto UDP (17), length 76) 172.16.31.67.123 > 192.5.41.41.123: [udp sum ok] NTPv3, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) 19:58:02.165061 IP (tos 0x0, ttl 64, id 38520, offset 0, flags [none], proto UDP (17), length 76) 172.16.31.67.123 > 133.100.9.2.123: [udp sum ok] NTPv3, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) On 2016-12-19 21:40, Roland Dobbins wrote: > On 20 Dec 2016, at 2:22, Denys Fedoryshchenko wrote: > >> If it is necessary i can investigate further. > > Yes, please! > > ----------------------------------- > Roland Dobbins <rdobbins(a)arbor.net>

2 1

[NANOG-announce] 2016 NANOG Election Results
by Dave Temkin 21 Dec '16

21 Dec '16

Greetings NANOG Colleagues, The 2016 NANOG Board and Bylaw election process is now complete. The results were shared during NANOG 68, are posted on the NANOG website, and summarized here. In 2016, there were two regular open positions on the Board of Directors. The appointments are: - Will Charnock - 3 years - Patrick Gilmore - 3 years The officers elected and committee liaisons are: - Chair - Dave Temkin - Vice Chair - Ryan Donnelly - Treasurer - Will Charnock - Secretary - Betty Burke - Communications Committee Liaison - Jezzibell Gilmore - Program Committee Liaison - Patrick Gilmore The proposed amendments to the NANOG Bylaws were accepted. The updated Bylaws document will be posted to the NANOG website. Best Regards, -Dave Temkin Chair, NANOG Board of Directors _______________________________________________ NANOG-announce mailing list NANOG-announce(a)mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 1

Re: Recent NTP pool traffic increase
by Jad Boutros 20 Dec '16

20 Dec '16

Thank you Eduardo, You beat me to it. Apple was quick to approve our release with the fix, we should start seeing a decrease in such traffic. On Tue, Dec 20, 2016 at 2:29 PM, Eduardo Schoedler <listas(a)esds.com.br> wrote: > 2016-12-20 16:58 GMT-02:00 Jad Boutros via NANOG <nanog(a)nanog.org>: > > Immediately after being notified that our latest iOS release was causing > > problems with NTP traffic, we started working to disable the offending > code > > in v9.45. We submitted a new mobile release to the Apple App Store > earlier > > this morning for their review, which should disable these NTP requests. > We > > are hoping Apple will be able to review this release in time before the > > holiday break, and we have stressed its urgency. When the release does > get > > approved, we should very quickly begin to see a decrease in NTP traffic > > from our app as users start upgrading to the new release. > > Just received update to 9.45.2.0. > > -- > Eduardo Schoedler >

1 0

NTT Taipei 3 data center address?
by Rivera, Alberto 20 Dec '16

20 Dec '16

I am searching for NTT Taipei 3 data center address. Do you have it by any chance? Thank you! Alberto Rivera PreSales Engineer PCCW Global 450 Spring Park Place Suite 100 Herndon, VA 20170 Tel: +1(703)774-9459 Office | + (571)315-5309 Cell Email: <mailto:XXXXX@pccwglobal.com> arivera(a)pccwglobal.com Website: www.pccwglobal.com To view PCCW Global's communication videos <https://www.youtube.com/channel/UC4kAsUCpZyxI1R8JWgP4nqw> click here <https://twitter.com/PCCWGlobal> cid:9f4812ce-f4a5-4441-a4e4-1d77c1ee1ad7 <https://www.facebook.com/PCCWG> cid:21f87991-196a-41be-a978-deb2e5059c9b <http://www.linkedin.com/company/314363?trk=saber_s000001e_1000> cid:1d9fa650-71e3-4e53-a84f-f92859afadfa <https://www.youtube.com/channel/UC4kAsUCpZyxI1R8JWgP4nqw> cid:e396fb8d-688f-4d85-befe-85c9f88f81c9 <http://www.pccwglobal.com/> cid:0e7d23dc-f767-4fec-b036-a8410443413f

2 1

South Carolina attempts to repeal Rule 34
by Jay Hennigan 20 Dec '16

20 Dec '16

Break out the popcorn. http://www.charlotteobserver.com/news/local/article121673402.html -- -- Jay Hennigan - CCIE #7880 - Network Engineering - jay(a)impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV

6 5

compliance with Canadian copyright law
by Wido Potters 20 Dec '16

20 Dec '16

Hi, I am involved in the free and open source toolkit AbuseIO (https://abus e.io/). It is a toolkit anyone can use to receive, process, correlate abuse reports and send notifications with specific information regarding the abuse case(s) on your network. AbuseIO's purpose is to consolidate efforts by various companies and individuals to automate and improve the abuse handling process. Last months we have been receiving requests for information about the implementation of AbuseIO in Canadian networks, in order to be compliant with Canadian Copyright Law. It seems our toolkit might be of use for these Canadian networks, but it needs some tweaking to really comply. I am looking for Canadian network operators / abuse desks / compliance officers that might be interested in using AbuseIO and would like to give some input or join efforts in making the software compliant for Canadian law. Please contact me off-list or discuss on- list. Kind regards, Wido

1 0

Google Global Cache Contact
by Jason Rokeach 20 Dec '16

20 Dec '16

Hi folks, could a contact for GGC contact me off-list? Thank you! - Jason R. Rokeach

2 2

Not a representative of gmx.com but their emails are being blocked by those who subscribe to the SORBS RBL.
by Large Hadron Collider 19 Dec '16

19 Dec '16

Does anyone have information on why this is, and if you represent SORBS and/or GMX and/or both, would you please trouble yourself with contacting me off-list?

4 3

Recent NTP pool traffic increase
by Jose Gerardo Perales Soto 19 Dec '16

19 Dec '16

Hi, We've recently experienced a traffic increase on the NTP queries to NTP pool project (pool.ntp.org) servers. One theory is that some service provider NTP infraestructure failed approximately 2 days ago and traffic is now being redirected to servers belonging to the NTP pool project. Does anyone from the service provider community have any comments? Gerardo Perales ________________________________ NOTA: La información de este correo es de propiedad exclusiva y confidencial. Este mensaje es sólo para el destinatario señalado, si usted no lo es, destrúyalo de inmediato. Ninguna información aquí contenida debe ser entendida como dada o avalada por AXTEL, S.A.B. de C.V, sus subsidiarias o sus empleados, salvo cuando ello expresamente se indique. Es responsabilidad de quien recibe este correo de asegurarse que esté libre de virus, por lo tanto ni AXTEL, S.A.B. de C.V, sus subsidiarias ni sus empleados aceptan responsabilidad alguna. NOTE: The information in this email is proprietary and confidential. This message is for the designated recipient only, if you are not the intended recipient, you should destroy it immediately. Any information in this message shall not be understood as given or endorsed by AXTEL, S.A.B. de C.V, its subsidiaries or their employees, unless expressly so stated. It is the responsibility of the recipient to ensure that this email is virus free, therefore neither AXTEL, S.A.B. de C.V, its subsidiaries nor their employees accept any responsibility.

9 14