Re: Spitballing IoT Security

Hi Chris, On 10/25/16 1:51 PM, Chris Boyd wrote: >> On Oct 25, 2016, at 3:10 AM, Ronald F. Guilmette >> wrote: >> >> An IoT is -not- a general purpose computer. In the latter case, it is >> assumed that the owner will "pop the hood" when it comes to the software >> configuration. > Ah, but the

Re: Spitballing IoT Security

Hi Mike, On 10/27/16 11:04 AM, Mike Meredith wrote: > On Thu, 27 Oct 2016 07:59:00 +0200, Eliot Lear > may have written: >> Well yes. uPnP is a problem precisely because it is some random device >> asserting on its own that it can be trusted to do what it wants. Had > From my own personal use

Re: Spitballing IoT Security

On 10/28/2016 10:14 PM, b...@theworld.com wrote: > Thus far the goal just seems to be mayhem. Thus far, the goal on the part of the botnet opearators is to make money. The goal of the CUSTOMERS of the botnet operators? Who knows?

Re: Yet another NTP security bug we fixed before the CVE issued

Harlan Stenn : > Interleave is the best way to get the next major step in accurate time > using the NTP Protocol. Yes, it needs work. A reference implementation > is where this work happens. Daniel Franke judges the interleave concept doesn't actually work well enough to be worth its code weight

Re: Spitballing IoT Security

On October 28, 2016 at 00:07 j...@jxh.com (Jim Hickstein) wrote: > On 10/27/16 22:59, b...@theworld.com wrote: > > What would the manufacturers' response be if this virus had instead > > just shut down, possibly in some cases physically damaged the devices > > or otherwise caused them to cease

Re: IPv6 automatic reverse DNS

On Fri, 2016-10-28 at 18:37 -0700, Steve Atkins wrote: > > On Oct 28, 2016, at 6:04 PM, Karl Auer > > wrote: > > It's fine to use no-reverse-lookup as a component of a spamminess > > score. It's not OK to use it as proof of spamminess. > People running large mailservers made that decision some tim

RE: IPv6 automatic reverse DNS

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/Akama

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

I would use LACNIC’s whois server for these queries. They have info from all the registries, which is an amazing service that seems beyond the other RIRs. whois -h whois.lacnic.net 103.11.67.105 HostUS HOSTUS-IPV4-5 (NET-103-11-64-0-1) 103.11.64.0 - 103.11.67.255 Gai

Re: IPv6 automatic reverse DNS

I'd recommend reviewing this document, and contributing as appropriate. I think it covers this pretty thoroughly today, but if there are missing considerations, now is the time to make sure that feedback is captured. https://tools.ietf.org/html/draft-ietf-dnsop-isp-ip6rdns-02

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

On 10/28/2016 04:32 PM, Mark Andrews wrote: > It's not the RIR's job. They already provide the framework for > ISP's to do the job of policing route announcements themselves. > ISP's just need to use that framework. Link to documentation on how to use that framework?

Re: IPv6 automatic reverse DNS

> On Oct 28, 2016, at 6:04 PM, Karl Auer wrote: > >> 1b) anti spam filters believe in the magic of checking >> forward/reverse match. > > Someone in this thread said that only malware-infested end-users are > behind IP addresses with no reverse lookup. Well - no. As long as we > keep telling an

Re: Yet another NTP security bug we fixed before the CVE issued

"Eric S. Raymond" writes: > ... Yawn. We disabled interleave a while ago. Interleave is the best way to get the next major step in accurate time using the NTP Protocol. Yes, it needs work. A reference implementation is where this work happens. Yes, we have another release about to happen. Mo

Re: IPv6 automatic reverse DNS

On Sat, 2016-10-29 at 01:02 +0200, Baldur Norddahl wrote: > It should be simple to build a DNS server that will automatically  > generate a hostname value for every reverse lookup received, and also > be able to parse that hostname value to return the correct IPv6 > address on forward lookups. > >

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

In message <5813e03e.6060...@foobar.org>, Mark Andrews wrote: >Mark Andrews wrote: >> It's not the RIR's job. They already provide the framework for >> ISP's to do the job of policing route announcements themselves. >> ISP's just need to use that framework. > >Ron thinks otherwise. No, I don'

Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications - Interweb is doomed

It's funny you should mention that. I just learned that our CL traffic rides on a single lambda is a Level3 fiber. Oddly, though, the cost to buy that same circuit directly from Level3 is twice as high. Which bodes ill for circuit pricing in the reduced-competition environment following the mer

Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications - Interweb is doomed

Savvis 3561 still exists on Centurylink's side too. 6 networks down to 1 ... How much of that fiber for each network was running in the same conduit to begin with anyway? Centurylink Qwest Savvis Level3 Global Crossing TWTC On Fri, Oct 28, 2016 at 12:24 PM, joel jaeggli wrote: > On 10/28/16 12

Re: IPv6 automatic reverse DNS

Already available: KnotDNS. https://www.knot-dns.cz/docs/2.x/html/configuration.html#synth-record-automatic-forward-reverse-records Olivier > On 29 oct. 2016 à 01:02, Baldur Norddahl wr

Re: IPv6 automatic reverse DNS

Why not have DHCP update dns with both. Sent from my iPad > Luke Guillory Network Operations Manager Tel:985.536.1212 Fax:985.536.0300 Email: lguill...@reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084

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

On Sat, Oct 29, 2016 at 10:32:12AM +1100, Mark Andrews said: >It's not the RIR's job. They already provide the framework for >ISP's to do the job of policing route announcements themselves. >ISP's just need to use that framework. What i

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

In message <5813dacd.3000...@foobar.org>, Nick Hilliard wrote: >Ronald F. Guilmette wrote: >> Will never happen. The RiRs have been crystal clear, and also utterly >> consistant... "Not our job man! We am not the Internetz Police." > >Ron, > >Maybe you could suggest some ideas about how the R

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

In message Doug Clements wrote: >How does one get ARIN to register resources to come up with this result? > >https://whois.arin.net/rest/nets;q=103.11.67.105 > >The /16 is APNIC but there are 2 subnets that appear to be allocated from >ARIN. Having just typed 'whois 103.11.67.105' I completely

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

Mark Andrews wrote: > It's not the RIR's job. They already provide the framework for > ISP's to do the job of policing route announcements themselves. > ISP's just need to use that framework. Ron thinks otherwise. I'd like to understand what he thinks they can do to stop this. Nick

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

In message <5813dacd.3000...@foobar.org>, Nick Hilliard writes: > Ronald F. Guilmette wrote: > > Will never happen. The RiRs have been crystal clear, and also utterly > > consistant... "Not our job man! We am not the Internetz Police." > > Ron, > > Maybe you could suggest some ideas about how

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

Ca By wrote: > If the space is unassigned, could the rir announce the space to park it > to null0. And register it in spamhaus ? > > This would make the rir the custodian of the space in their possession The space isn't unallocated. It's allocated, but the assignee hasn't announced it in the df

Re: IPv6 automatic reverse DNS

> On Oct 28, 2016, at 4:02 PM, Baldur Norddahl > wrote: > > Hello > > Many service providers have IPv4 reverse DNS for all their IP addresses. If > nothing is more relevant, this will often just be the IPv4 address hashed > somehow and tagged to the ISP domain name. For some arcane reason it

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

On Friday, October 28, 2016, Nick Hilliard wrote: > Ronald F. Guilmette wrote: > > Will never happen. The RiRs have been crystal clear, and also utterly > > consistant... "Not our job man! We am not the Internetz Police." > > Ron, > > Maybe you could suggest some ideas about how the RIRs can st

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

Ronald F. Guilmette wrote: > Will never happen. The RiRs have been crystal clear, and also utterly > consistant... "Not our job man! We am not the Internetz Police." Ron, Maybe you could suggest some ideas about how the RIRs can stop someone from illegally squatting space? Nick

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

In message <20161028220510.gf14...@sizone.org>, Ken Chase wrote: >On Fri, Oct 28, 2016 at 02:40:23PM -0700, Ronald F. Guilmette said: > >I'm going to call these turkeys right now and just ask them, point > >blank, what the bleep they think they're doing, routing unallocated > >APNIC space.

IPv6 automatic reverse DNS

Hello Many service providers have IPv4 reverse DNS for all their IP addresses. If nothing is more relevant, this will often just be the IPv4 address hashed somehow and tagged to the ISP domain name. For some arcane reason it is important to have the forward DNS match the reverse DNS or some m

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

Spammers are doing a great job abusing the gaps in the systems. Another common pattern in the last 12-14 months has been a combination of squatting on an AS, forging some business documentation, buying transit to an IX, and proceeding to hijack prefixes over bilateral peering sessions. Pain in the

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

How does one get ARIN to register resources to come up with this result? https://whois.arin.net/rest/nets;q=103.11.67.105 The /16 is APNIC but there are 2 subnets that appear to be allocated from ARIN. Having just typed 'whois 103.11.67.105' I completely missed the fact that the supernet was APNI

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

On Fri, Oct 28, 2016 at 02:40:23PM -0700, Ronald F. Guilmette said: >I'm going to call these turkeys right now and just ask them, point >blank, what the bleep they think they're doing, routing unallocated >APNIC space. Makin' phat stacks. One thing the RIRs could do is put pressure on AS's

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

I just got a spam from 103.11.67.105. The containing /24 appears to be unallocated APNIC space. RIPE tools seem to say that AS18450 has been routing this block since around May 23rd. I see this kind of stuff almost every day now, it seems. And you know, there are days when I really do start t

Re: Need to reach someone in Bell Canada

Good luck with that. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 10/28/16 13:58, Jippen wrote: > Hello

Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications - Interweb is doomed

We were on on 4323 - we are still peered to 4323 (from a config stand point) - but the world sees us thru 3549 It is a mess on convergence On Fri, Oct 28, 2016 at 3:24 PM, joel jaeggli wrote: > On 10/28/16 12:18 PM, Mel Beckman wrote: > > Level3 hasn't even finished migrating its TWTelecom cust

Yet another NTP security bug we fixed before the CVE issued

http://forums.theregister.co.uk/forum/1/2016/10/28/researchers_tag_new_brace_of_bugs_in_ntp_but_theyre_fixable/ That'd be another CVE that NTPsec dodges before it's issued. We removed interleaved mode months ago because the code smelled bad and turned out to have an implementation error in the ti

Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications - Interweb is doomed

On 10/28/16 12:18 PM, Mel Beckman wrote: > Level3 hasn't even finished migrating its TWTelecom customers to the L3 AS > yes, and it's been years. So I don't think you can expect any faster > transition for CL. 3549 still exists... > -mel beckman > >> On Oct 28, 2016, at 2:16 PM, Timothy Lister

Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications - Interweb is doomed

And I'm sure it would go about as well as the TW integration went. Level3 is currently having issues, we lost BGP just a bit ago and also legacy voice trunks have been down since first thing this morning. Sent from my iPhone On Oct 28, 2016, at 2:17 PM, Timothy Lister mailto:incu...@gmail.com>

Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications - Interweb is doomed

Level3 hasn't even finished migrating its TWTelecom customers to the L3 AS yes, and it's been years. So I don't think you can expect any faster transition for CL. -mel beckman > On Oct 28, 2016, at 2:16 PM, Timothy Lister wrote: > > So if this went through, how would it happen? Does 3356 (L

Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications - Interweb is doomed

So if this went through, how would it happen? Does 3356 (L3) absorb 209's (CL) infrastructure and slowly make customers change their peering config to hit 3356 instead? You make a good point, I have at least a couple clients that peer to both providers for redundancy. One of which just recently si

Need to reach someone in Bell Canada

Hello folks - I work for a ticketfly.com - a company that changed a lot of DNS records on wednesday, that are resolving correctly around the world... except Bell CA. If anyone here is @bell.ca and willing to beat their DNS servers briefly on my behalf, I would be very, very grateful. Currently rac

Weekly Routing Table Report

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.

Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications - Interweb is doomed

On 10/27/2016 12:36, Nevin Gonsalves via NANOG wrote: :-) http://www.wsj.com/articles/centurylink-in-advanced-talks-to-merge-with-level-3-communications-1477589011 This is great! Except for all of their mutual customers who had circuits from both for redundancy. (See also: Level 3's and TWTC's

Re: Spitballing IoT Security

On 10/27/16 22:59, b...@theworld.com wrote: What would the manufacturers' response be if this virus had instead just shut down, possibly in some cases physically damaged the devices or otherwise caused them to cease functioning ever again (wiped all their software or broke their bootability), rat

Re: Should abuse mailboxes have quotas?

No. They should not. (Nor should they have spam or malware filters, since of course that's one of the things that people will forward as part of their complaints. Anyone using a sensible email client on a sensible platform will of course incur zero risk by handling either of those.) That said,

Re: Spitballing IoT Security

On Thu, Oct 27, 2016 at 05:13:31PM -0400, Jon Lewis wrote: > This is one of my bigger concerns every time I buy something that's "cloud > controlled". Not so much that the manufacturer will force it's retirement, > but "what happens if they go belly up, or just kill the division that > supports my

RE: Spitballing IoT Security

On Thursday, 27 October, 2016 22:09, Eliot Lear said: > On 10/28/16 1:55 AM, Keith Medcalf wrote: > >>> The problem is in allowing inbound connections and going as far as > doing > >>> UPnP to tell the CPE router to open a inbound door to let hackers > loging > >>> to that IoT pet feeder to tu

Re: [routing-wg] Large BGP Communities beacon in the wild

Hello Owen, While I agree ( and cudos to Job for noticing the issue while the document is still at the draft stage), the current process for allocation is not developer friendly. For ExaBGP, I also had to squat a code point to implement draft-frs-bgp-operational-message. I doubt it will eve ca

Re: Large BGP Communities beacon in the wild

> read the IDR thread(1), the vendors in question actually self reported. > I don't think 'shame' here is quite appropriate, but certainly owen's note > about: "Hey, pls don't do this again" with the added: ""this is not a good > path to continue" were noted by several folks on the IDR list. lucki