Re: Spitballing IoT Security

[Stephen Satchell]

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

[Eric S. Raymond]

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, and that Mills believed otherwise
because of an error he failed to notice in the timestamp handling.  I
have not looked myself, but I have found Daniel very reliable when he
says such things.

> Yes, we have another release about to happen.  Mostly "security" bugs
> that folks will not see, if they're being at all responsible.

They certainly won't see those bugs in NTPsec -- Daniel briefed me about
90 minutes ago, and even if we hadn't I knew we were pre-armored
against 3/4ths of the CVEs that hit you guys this year.  Might just have
something to do with having removed 153KLOC of useless code and winding
up with less than a third of the attack surface you guys have exposed. 

> Eric, you are loved and appreciated, and respected and admired.

That's nice.  It's a damn shame you didn't "admire" me (and my team
members) enough to join forces with us when we were trying to avoid a
fork, rather than fighting us and forcing one to happen.  Your choice,
your consequences.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Spitballing IoT Security

[bzs]

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 functioning ever again (wiped all
 > > their software or broke their bootability), rather than just hijacked
 > > them for a while?
 > 
 > A virus that kills its host (too much of the time) is not successful.

Hmm. So now we assume we are dealing with rational actors?

I suppose one can find some rational motives in bringing down Dyn but
I don't see that it's all that different from bricking half a million
(for starters) IoT devices.

Thus far the goal just seems to be mayhem.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: IPv6 automatic reverse DNS

[Karl Auer]

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 time
> ago. Disagreeing with them won't make them accept your email.

I didn't say it would. IMHO reverse lookups are excellent and useful.
My only beef is with the idea that the absence of a reverse lookup
entry has any useful meaning any more, or, in particular, is proof of
spamminess.

It would be interesting (and would alter my opinion) to see statistics
of real spamminess positives ("is spam") dropping significantly if
failed reverse lookups are removed from the calculation.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4

RE: IPv6 automatic reverse DNS

[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.

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


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Steve Atkins
Sent: Friday, October 28, 2016 6:29 PM
To: NANOG list
Subject: 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 is 
> important to have the forward DNS match the reverse DNS or some mail servers 
> might reject your mails.
> 
> However with IPv6 it is not practical to build such a complete reverse DNS 
> zone. You could do a star entry but that would fail the reverse/forward match 
> test.
> 
> 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.
> 
> Does any DNS server have that feature?

It's easy enough to implement with plugins on some servers.

> Should we have it?

Meh.

> Why not?

Because having an automatically generated reverse DNS is a sign that the IP 
address is not really intended to be offering public services, rather it's a 
malware-infested end user machine.

> 
> I know of some arguments for:
> 
> 1a) mail servers like it

... because it's a sign that the mail is coming from a real mailserver 
configured by a competent admin, rather than being a random compromised 
machine. That's not the case if you're just synthesizing reverse DNS for 
arbitrary IP addresses on your network.

> 
> 1b) anti spam filters believe in the magic of checking forward/reverse match.

For the same reason as above. Spam filters are also often smart enough to 
recognize, and treat as dubious, synthesized reverse DNS.

If you have synthesized reverse DNS on your smarthost you're likely to have a 
bad time, perhaps initially, perhaps the first time someone notices bad mail 
coming from it and doesn't recognize it as a legitimate smarthost.

> 
> 2) traceroute will be nicer

Most of those hosts a traceroute goes through should hopefully have stable IP 
addresses and meaningful, not synthesized, reverse DNS, I'd think. Consumer 
endpoints are the only ones where you might expect that not to be the case and 
synthesized reverse DNS might be an improvement there.

> 
> 3) http://ipv6-test.com/ will give me 20/20 instead of 19/20 (yes that was 
> what got me going on this post)
> 
> 4) Output from "who" command on Unix will look nicer (maybe).
> 
> Regards,
> 
> Baldur

Cheers,
  Steve

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

[Michael Smith]

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
Gaiacom, L.C. SOLVPS-103-11-67-0-24 (NET-103-11-67-0-1) 103.11.67.0 - 
103.11.67.255

Mike

> On Oct 28, 2016, at 4:36 PM, Ronald F. Guilmette  
> wrote:
> 
> 
> 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 missed the fact
>> that the supernet was APNIC until I checked the web interface.
> 
> Oh!!  Wow!!  I totally missed this also, i.e. that ARIN is showing an
> allocation for 103.11.64.0/22 to HostUs.Us in Texas.
> 
> That's really weird, but even that doesn't either explain or excuse
> what still looks like an illicit squat (by an unrelated Los Angeles
> company) on the 103.11.67.0/24 block to me... perhaps one that's been
> re-sold to a spammer (which seems possible, given the spam I got).
> 
> 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".)
> 
> This isn't the first time I've wished that the right hand knew (or cared)
> what the left hand was doing.  I've asked the folks at IANA about this
> sort of thing in the past, i.e. them giving pointers to the apparently
> wrong RiR whois server, and they just won't fix it.  They just shrug and
> say "Not our problem man!"  And in this case, maybe they're right.  If
> APNIC gave two subparts of 103/8 to ARIN, it might have been helpful
> if their own whois server was made aware of that fact.
> 
> Sigh.  I have to keep reminding myself of what one friend of mine keeps
> on telling me... "Ron, there you go again, trying to think about these
> things logically."
> 
> 
> Regards,
> rfg

Re: IPv6 automatic reverse DNS

[Wesley George]

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 


Wes George


> On Oct 28, 2016, at 7: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 is 
> important to have the forward DNS match the reverse DNS or some mail servers 
> might reject your mails.
> 
> However with IPv6 it is not practical to build such a complete reverse DNS 
> zone. You could do a star entry but that would fail the reverse/forward match 
> test.
> 
> 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.
> 
> Does any DNS server have that feature? Should we have it? Why not?
> 
> I know of some arguments for:
> 
> 1a) mail servers like it
> 
> 1b) anti spam filters believe in the magic of checking forward/reverse match.
> 
> 2) traceroute will be nicer
> 
> 3) http://ipv6-test.com/ will give me 20/20 instead of 19/20 (yes that was 
> what got me going on this post)
> 
> 4) Output from "who" command on Unix will look nicer (maybe).
> 
> Regards,
> 
> Baldur



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Stephen Satchell]

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

[Steve Atkins]

> 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 anyone who isn't running a full-bore commercial network to
> "consume, be silent, die", we are holding everyone back, including
> ourselves.

If you send mail over IPv6 from an address with no reverse DNS you
will see quite a lot of this sort of thing:

550 5.7.1 [*] Our system has detected that this message
5.7.1 does not meet IPv6 sending guidelines regarding PTR records and
5.7.1 authentication. Please review
5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error for more
5.7.1 information.

> 
> 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 time
ago. Disagreeing with them won't make them accept your email.

Cheers,
  Steve

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

[Harlan Stenn]

"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.  Mostly "security" bugs
that folks will not see, if they're being at all responsible.

Eric, you are loved and appreciated, and respected and admired.

--
Harlan Stenn 
http://networktimefoundation.org - be a member!

Re: IPv6 automatic reverse DNS

[Karl Auer]

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.
> 
> Does any DNS server have that feature? Should we have it? Why not?

Nominum's nameserver software has these features. Industrial strength
nameservice, with lots of industrial-strength features, but at an
industrial-strength price.

I thought BIND had grown that feature, but I haven't used BIND for a
while now, so maybe not.

> 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 anyone who isn't running a full-bore commercial network to
"consume, be silent, die", we are holding everyone back, including
ourselves.

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.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4

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

[Ronald F. Guilmette]

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't.  You have made a incorrect inference from the text of my
actual comment.

In my actual comment I merely noted that RIRs are in fact -not- the
Internet Police, and that none of them have ever displayed even the
slightest desire to become that (and indeed, when asked, they have,
without exception, exhibited a clear desire -not- to be assigned any
such role).

These observations on my part are all merely recitations of well-
established historical facts, all of which are easily verifiable by
anyone with a browser.  I made no comment at all about who, if anyone,
should be tasked to take on the role of The Routing Police.

And indeed, if asked, I would express some degree of skepticism about
the ability of RIRs to even reliably execute their existing data base
maintenance responsibilities to a level which I personally would find
entirely satisfactory.  (The apparent goofyness relating to 103.11.64.0/22
is just one very small example of this, there being also many other and
more serious issues that I could also cite, if pressed, relating strictly
to allocation functions and/or to WHOIS data base issues.)

Given that I do not have an entirely unequivocal admiration for the
quality and consistancy of the work that RIRs are already clearly
responsible for, do you really believe that it would be my first
choice to assign an entirely seperate but equally critical set of
-new- authorities and responsibilities to the RiRs?  If so, please
allow me to disabuse you of that notion.  (I am also and likewise not
likely to support any effort any any part of the United States federal
government to assign new authorities and responsibilities to the Office
of Personnel Management.)


Regards,
rfg


P.S.  I may be wrong about this, but it has come to my attention that
many, most, or all of the WHOIS records reflecting allocations made by
the AFRINIC RIR are utterly devoid of either (a) information specifying
the dates on which the relevant allocations were made or (b) email
contact addresses for the relevant number resource registrants.

I am, of course, utterly appalled by the apparent inability of this RIR
to maintain a WHOIS data base which even approximates the modest and
minimal level of relevant information commonly available from the WHOIS
data bases of other and older RIRs.

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

[Mel Beckman]

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 merger. A similar thing happened to us when L3 bought TWT. In 
both cases L3 says "but you're getting such a better network!" Alas, that 
turned out to be not the case with the TWT acquisition, as merger mishaps 
caused numerous outages. 

 -mel

> On Oct 28, 2016, at 7:25 PM, Jared Geiger  wrote:
> 
> 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: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  wrote:
 
 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 signed an agreement
 with CenturyLink for the sole purpose of fail over.
 
 -Original Message-
 Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
 Interweb is doomed
 From: Jima 
 To: 
>>> 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 mutual
 customers, and probably a long list of other M I'm not thinking of
 off-hand.)
 
 OK, I lied about it being great anyway.
 
 Jima
 
 
 
 -Original Message-
 Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
 Interweb is doomed
 From: Jima 
 To: 
>> 
>> 
>> 
>> 

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

[Jared Geiger]

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: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  wrote:
> >>
> >> 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 signed an agreement
> >> with CenturyLink for the sole purpose of fail over.
> >>
> >> -Original Message-
> >> Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
> >> Interweb is doomed
> >> From: Jima 
> >> To: 
> > 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 mutual
> >> customers, and probably a long list of other M I'm not thinking of
> >> off-hand.)
> >>
> >> OK, I lied about it being great anyway.
> >>
> >>  Jima
> >>
> >>
> >>
> >> -Original Message-
> >> Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
> >> Interweb is doomed
> >> From: Jima 
> >> To: 
>
>
>
>

Re: IPv6 automatic reverse DNS

[Olivier Benghozi]

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  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.
> 
> Does any DNS server have that feature? Should we have it? Why not?

Re: IPv6 automatic reverse DNS

[Luke Guillory]

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

_

Disclaimer:
The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material which should not disseminate, distribute or be 
copied. Please notify Luke Guillory immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. Luke Guillory therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission. .

On Oct 28, 2016, at 6:04 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 is 
> important to have the forward DNS match the reverse DNS or some mail servers 
> might reject your mails.
>
> However with IPv6 it is not practical to build such a complete reverse DNS 
> zone. You could do a star entry but that would fail the reverse/forward match 
> test.
>
> 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.
>
> Does any DNS server have that feature? Should we have it? Why not?
>
> I know of some arguments for:
>
> 1a) mail servers like it
>
> 1b) anti spam filters believe in the magic of checking forward/reverse match.
>
> 2) traceroute will be nicer
>
> 3) http://ipv6-test.com/ will give me 20/20 instead of 19/20 (yes that was 
> what got me going on this post)
>
> 4) Output from "who" command on Unix will look nicer (maybe).
>
> Regards,
>
> Baldur

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

[Ken Chase]

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 incentive do the ISPs have to enforce any of this though? 

In fact, they're making money sending bits over these prefixes. 

What incentives could be created that the ISPs wont balk at as it
might affect their accidental revenues from "oh, gee, I didnt know it
was being squatted! " prefixes?

/kc   
--   
Ken Chase - m...@sizone.org guelph canada

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

[Ronald F. Guilmette]

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 RIRs can stop someone
>from illegally squatting space?

Oh, don't get me wrong.  I never said that I either could or would
suggest how to convert RiRs into The Internet Police.  Nor did I suggest
that such a conversion would even be either prudent or advisable.
(I am not persuaded that it would be.)

We have a longstanding 20 or 30 year tradition/precedent and a division
of labor that -does not- allocate to RiRs any responsibility for, or
authority over anything to do with what routes people announce, and I
am certainly not even nearly so presumptive as to believe that I either
can or should try to roll back 30 years of history and ask everyone to
start all over again and build governance structures anew, from scratch.
(Doing so would be both silly and the very height of arrogance on my part.)

I nontheless feel free to note, and to bemoan, the current utter lack
of -any- authority which routinely notices apparent routing funny business
and/or which works, on a routine basis, to try to put a stop to it all.

I do not suggest that RiRs should be "minding the store" with respect to
route announcements.  I do think it would be helpful if -somebody- were
doing so.  My own occasional and srictly ad hoc efforts have only succeded
in convincing me of how extensive the problem is, and how dire a need there
is for a more rigorous solution.


Regards,
rfg

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

[Ronald F. Guilmette]

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 missed the fact
>that the supernet was APNIC until I checked the web interface.

Oh!!  Wow!!  I totally missed this also, i.e. that ARIN is showing an
allocation for 103.11.64.0/22 to HostUs.Us in Texas.

That's really weird, but even that doesn't either explain or excuse
what still looks like an illicit squat (by an unrelated Los Angeles
company) on the 103.11.67.0/24 block to me... perhaps one that's been
re-sold to a spammer (which seems possible, given the spam I got).

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".)

This isn't the first time I've wished that the right hand knew (or cared)
what the left hand was doing.  I've asked the folks at IANA about this
sort of thing in the past, i.e. them giving pointers to the apparently
wrong RiR whois server, and they just won't fix it.  They just shrug and
say "Not our problem man!"  And in this case, maybe they're right.  If
APNIC gave two subparts of 103/8 to ARIN, it might have been helpful
if their own whois server was made aware of that fact.

Sigh.  I have to keep reminding myself of what one friend of mine keeps
on telling me... "Ron, there you go again, trying to think about these
things logically."


Regards,
rfg

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

[Nick Hilliard]

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

[Mark Andrews]

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 the RIRs can stop someone
> from illegally squatting space?

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.

> Nick
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

[Nick Hilliard]

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 dfz.

There are some statistics about unallocated space here:

http://www.potaroo.net/tools/ipv4/index.html

summary: this isn't the problem area.

Nick

Re: IPv6 automatic reverse DNS

[Steve Atkins]

> 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 is 
> important to have the forward DNS match the reverse DNS or some mail servers 
> might reject your mails.
> 
> However with IPv6 it is not practical to build such a complete reverse DNS 
> zone. You could do a star entry but that would fail the reverse/forward match 
> test.
> 
> 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.
> 
> Does any DNS server have that feature?

It's easy enough to implement with plugins on some servers.

> Should we have it?

Meh.

> Why not?

Because having an automatically generated reverse DNS is a sign that the IP 
address is not really intended to be offering public services, rather it's a 
malware-infested end user machine.

> 
> I know of some arguments for:
> 
> 1a) mail servers like it

... because it's a sign that the mail is coming from a real mailserver 
configured by a competent admin, rather than being a random compromised 
machine. That's not the case if you're just synthesizing reverse DNS for 
arbitrary IP addresses on your network.

> 
> 1b) anti spam filters believe in the magic of checking forward/reverse match.

For the same reason as above. Spam filters are also often smart enough to 
recognize, and treat as dubious, synthesized reverse DNS.

If you have synthesized reverse DNS on your smarthost you're likely to have a 
bad time, perhaps initially, perhaps the first time someone notices bad mail 
coming from it and doesn't recognize it as a legitimate smarthost.

> 
> 2) traceroute will be nicer

Most of those hosts a traceroute goes through should hopefully have stable IP 
addresses and meaningful, not synthesized, reverse DNS, I'd think. Consumer 
endpoints are the only ones where you might expect that not to be the case and 
synthesized reverse DNS might be an improvement there.

> 
> 3) http://ipv6-test.com/ will give me 20/20 instead of 19/20 (yes that was 
> what got me going on this post)
> 
> 4) Output from "who" command on Unix will look nicer (maybe).
> 
> Regards,
> 
> Baldur

Cheers,
  Steve

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

[Ca By]

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 stop someone
> from illegally squatting space?
>
> Nick
>

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

CB

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

[Nick Hilliard]

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

[Ronald F. Guilmette]

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. 
>
>Makin' phat stacks.
>
>One thing the RIRs could do is put pressure on AS's to not route
>these objects,

Will never happen.  The RiRs have been crystal clear, and also utterly
consistant... "Not our job man!  We am not the Internetz Police."

The thing that really baffles me about this kind of thing is how this
kind of crud can happen in the first place, and also, even more baffling,
how it can persist for months on end without anybody even noticing.

I'm looking at this:

   http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=103.11.67.105

which appears to provide a nice list of the rest of the netwits who are
also to blame for this one particular singular bit of idiocy:

 AS2914 -- NTT America, Inc.
 AS1299 -- Telia Company AB
 AS12798 -- Ace Data Centers, Inc.
 AS174 -- Cogent Communications
 AS6939 -- Hurricane Electric, Inc.
 AS3491 -- PCCW Global
 AS7922 -- Comcast Cable Communications, LLC
 AS6762 -- Telecom Italia Sparkle / Seabone
 AS10026 -- Pacnet Global Ltd
 AS11798 -- Ace Data Centers, Inc.

So, um, is it really the case that -none- of the above companies have even
noticed that anything was amiss here, and that all have failed to do so for
months on end?  (Or did they notice, but then felt is wasn't their place to
say anything about it?)

Sorry if those are stupid or naive questions, but...

   "The more I know, the less I understand."
 -- Don Henley

Is this just another one of these cases where everybody is responsible and
thus, nobody is?

Is it really the case that none of the above companies ever check that what
their peers announce is consistant with any routing registry?

I don't pretend to understand this stuff.  Somebody please 'splain it to
me.  I'll be much obliged.


Regards,
rfg

IPv6 automatic reverse DNS

[Baldur Norddahl]

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 
mail servers might reject your mails.


However with IPv6 it is not practical to build such a complete reverse 
DNS zone. You could do a star entry but that would fail the 
reverse/forward match test.


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.


Does any DNS server have that feature? Should we have it? Why not?

I know of some arguments for:

1a) mail servers like it

1b) anti spam filters believe in the magic of checking forward/reverse 
match.


2) traceroute will be nicer

3) http://ipv6-test.com/ will give me 20/20 instead of 19/20 (yes that 
was what got me going on this post)


4) Output from "who" command on Unix will look nicer (maybe).

Regards,

Baldur

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

[Tom Beecher]

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 rear to catch, even worse when the IX and transit providers
aren't receptive to do anything about it when it's brought to their
attention because the business docs used to instantiate those services are
'good enough', and they have a fiduciary interest in _not_ disconnecting
the IX port or circuit.

This will continue to be the norm until prefix validation is standardized
and in widespread use.




On Fri, Oct 28, 2016 at 5:40 PM, Ronald F. Guilmette 
wrote:

>
>
> 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 to wonder "Has the Internet gone
> mad?"
>
> 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.  But if history is any guide, this is probably going to
> turn out to be another one of these "absentee landlord" kinds of ASes,
> where all they have is an answering machine.
>
> I have to either laugh or cry when I see people posting here about the
> non-functionality of abuse@ email addresses, and then see other people
> saying "Well, this is why all ASes also have phone numbers."
>
> I wish I had a dollar for every AS I had ever tried to contact where
> -neither- the abuse@ address -nor- the phone number got me to any
> actual human being.
>
>
> Regards,
> rfg
>

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

[Doug Clements]

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 APNIC until I checked the web interface.

--Doug


On Fri, Oct 28, 2016 at 5:40 PM, Ronald F. Guilmette 
wrote:

>
>
> 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 to wonder "Has the Internet gone
> mad?"
>
> 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.  But if history is any guide, this is probably going to
> turn out to be another one of these "absentee landlord" kinds of ASes,
> where all they have is an answering machine.
>
> I have to either laugh or cry when I see people posting here about the
> non-functionality of abuse@ email addresses, and then see other people
> saying "Well, this is why all ASes also have phone numbers."
>
> I wish I had a dollar for every AS I had ever tried to contact where
> -neither- the abuse@ address -nor- the phone number got me to any
> actual human being.
>
>
> Regards,
> rfg
>

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

[Ken Chase]

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 to not route
these objects, and start producing daily public output scores
for these orgs, and emailing them -- ultimately threatening them
with de-reg of their assets if they dont stop this nonsense.
Further more, could get the route db's involved in dereg threats.

Is the politcal will there tho?

Right now there's no stigma beyond nanog-l in being a bad actor
from where I sit.

/kc
-- 
Ken Chase - m...@sizone.org guelph canada

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

[Ronald F. Guilmette]

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 to wonder "Has the Internet gone
mad?"

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.  But if history is any guide, this is probably going to
turn out to be another one of these "absentee landlord" kinds of ASes,
where all they have is an answering machine.

I have to either laugh or cry when I see people posting here about the
non-functionality of abuse@ email addresses, and then see other people
saying "Well, this is why all ASes also have phone numbers."

I wish I had a dollar for every AS I had ever tried to contact where
-neither- the abuse@ address -nor- the phone number got me to any
actual human being.


Regards,
rfg

Re: Need to reach someone in Bell Canada

[Alain Hebert]

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 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 racing against several coworkers stuck in the phone tree/tier 1
> customer support
>

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

[Jeff Waddell]

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 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  wrote:
> >>
> >> 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 signed an agreement
> >> with CenturyLink for the sole purpose of fail over.
> >>
> >> -Original Message-
> >> Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
> >> Interweb is doomed
> >> From: Jima 
> >> To: 
> > 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 mutual
> >> customers, and probably a long list of other M I'm not thinking of
> >> off-hand.)
> >>
> >> OK, I lied about it being great anyway.
> >>
> >>  Jima
> >>
> >>
> >>
> >> -Original Message-
> >> Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
> >> Interweb is doomed
> >> From: Jima 
> >> To: 
>
>
>
>

Yet another NTP security bug we fixed before the CVE issued

[Eric S. Raymond]

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 timestamp
handling.

On past performance, there'll be about a 75% chance each that we've
pre-fixed the other new security bugs.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

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

[joel jaeggli]

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  wrote:
>>
>> 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 signed an agreement
>> with CenturyLink for the sole purpose of fail over.
>>
>> -Original Message-
>> Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
>> Interweb is doomed
>> From: Jima 
>> To: 
> 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 mutual
>> customers, and probably a long list of other M I'm not thinking of
>> off-hand.)
>>
>> OK, I lied about it being great anyway.
>>
>>  Jima
>>
>>
>>
>> -Original Message-
>> Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
>> Interweb is doomed
>> From: Jima 
>> To: 





signature.asc
Description: OpenPGP digital signature

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

[Luke Guillory]

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 
> wrote:

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 signed an agreement
with CenturyLink for the sole purpose of fail over.




Luke Guillory
Network Operations Manager


[cid:image9bee0e.JPG@604f5a4c.42a728e5] 

Tel:985.536.1212
Fax:985.536.0300
Email:  lguill...@reservetele.com
Web:www.rtconline.com

Reserve Telecommunications
100 RTC Dr
Reserve, LA 70084





Disclaimer:
The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material which should not disseminate, distribute or be 
copied. Please notify Luke Guillory immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. Luke Guillory therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission.


-Original Message-
Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
Interweb is doomed
From: Jima >
To: >
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 mutual
customers, and probably a long list of other M I'm not thinking of
off-hand.)

OK, I lied about it being great anyway.

 Jima



-Original Message-
Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
Interweb is doomed
From: Jima >
To: >

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

[Mel Beckman]

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 (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 signed an agreement
> with CenturyLink for the sole purpose of fail over.
> 
> -Original Message-
> Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
> Interweb is doomed
> From: Jima 
> To: 
 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 mutual
> customers, and probably a long list of other M I'm not thinking of
> off-hand.)
> 
> OK, I lied about it being great anyway.
> 
>  Jima
> 
> 
> 
> -Original Message-
> Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
> Interweb is doomed
> From: Jima 
> To: 

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

[Timothy Lister]

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 signed an agreement
with CenturyLink for the sole purpose of fail over.

-Original Message-
Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
Interweb is doomed
From: Jima 
To: 
>> 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 mutual
customers, and probably a long list of other M I'm not thinking of
off-hand.)

OK, I lied about it being great anyway.

  Jima



-Original Message-
Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
Interweb is doomed
From: Jima 
To: 

Need to reach someone in Bell Canada

[Jippen]

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 racing against several coworkers stuck in the phone tree/tier 1
customer support

Weekly Routing Table Report

[Routing Analysis Role Account]

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.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 29 Oct, 2016

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  619119
Prefixes after maximum aggregation (per Origin AS):  220712
Deaggregation factor:  2.81
Unique aggregates announced (without unneeded subnets):  300943
Total ASes present in the Internet Routing Table: 55082
Prefixes per ASN: 11.24
Origin-only ASes present in the Internet Routing Table:   36320
Origin ASes announcing only one prefix:   15327
Transit ASes present in the Internet Routing Table:6532
Transit-only ASes present in the Internet Routing Table:167
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  37
Max AS path prepend of ASN ( 55644)  31
Prefixes from unregistered ASNs in the Routing Table:52
Unregistered ASNs in the Routing Table:  16
Number of 32-bit ASNs allocated by the RIRs:  15924
Number of 32-bit ASNs visible in the Routing Table:   12230
Prefixes from 32-bit ASNs in the Routing Table:   49420
Number of bogon 32-bit ASNs visible in the Routing Table:   281
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:352
Number of addresses announced to Internet:   2828482468
Equivalent to 168 /8s, 151 /16s and 55 /24s
Percentage of available address space announced:   76.4
Percentage of allocated address space announced:   76.4
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.3
Total number of prefixes smaller than registry allocations:  203450

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   156739
Total APNIC prefixes after maximum aggregation:   42750
APNIC Deaggregation factor:3.67
Prefixes being announced from the APNIC address blocks:  170488
Unique aggregates announced from the APNIC address blocks:69969
APNIC Region origin ASes present in the Internet Routing Table:5173
APNIC Prefixes per ASN:   32.96
APNIC Region origin ASes announcing only one prefix:   1140
APNIC Region transit ASes present in the Internet Routing Table:947
Average APNIC Region AS path length visible:4.3
Max APNIC Region AS path length visible: 35
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2444
Number of APNIC addresses announced to Internet:  758852036
Equivalent to 45 /8s, 59 /16s and 41 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:187849
Total ARIN prefixes after maximum aggregation:89675
ARIN Deaggregation factor: 2.09
Prefixes being announced from the ARIN address blocks:   193888
Unique aggregates announced from the ARIN address blocks: 89398
ARIN Region origin ASes present in the Internet Routing Table:16158
ARIN Prefixes per ASN:12.00

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

[Jima]

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 mutual 
customers, and probably a long list of other M I'm not thinking of 
off-hand.)


OK, I lied about it being great anyway.

 Jima

Re: Spitballing IoT Security

[Jim Hickstein]

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), rather than just hijacked
them for a while?


A virus that kills its host (too much of the time) is not successful.

Re: Should abuse mailboxes have quotas?

[Rich Kulawiec]

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, and since abuse mailboxes have come up in the context
of the ongoing IoT/DDoS discussion, let me point out that a fair
amount of traffic on this list, on mailop, on dns-operations,
on outages-discussion, on other lists, consists of queries of
the form "how can I contact X about Y?"   The traffic exists because X
either has never read RFC 2142 or has just ignored it.  A *lot*
of our collective time has been wasted asking/answering these queries,
and no doubt they represent the tip of the iceberg, as many folks
don't bother (having found those addresses non-existent) or don't
know where to ask.

So now: A Rant (albeit a considered one, after two (2) cups of coffee):

This is unacceptable.  If you don't maintain the basic role addresses
and pay attention to what shows up there, you're not a professional.
You're not even a competent amateur.  Of all the things we have to do,
from unsnarling switches to diagnosing psychotic web/mail servers to
dealing with WTF-grade announcements, maintaining role addresses is
one of the easiest.  It's also one of the best things to do, because
traffic arriving there is quite often trying to tell you about problems
that you have that you really, REALLY ought to be curious about.

And in a time when we're all facing myriad threats, and relying on
each other to communicate about them and address them in as close
to real time as we can manage, it's inexcusable not to have at least
the basics in place.  (abuse@, hostmaster@, postmaster@, webmaster@,
etc. as applicable to the services you provide)  Other people are often
doing your job for you *for free* and are sharing the results with you:
you should be listening.  Intently.

I've heard all the whining excuses...and I dismiss them:

"We get too much traffic @abuse" -- gosh, stop emitting/facilitating so
much abuse and so many attacks, it'll decrease.

"We can't reply to everything" -- see previous point.  And learn how
to use a real mail client.

"We get too much spam" -- use procmail to bin incoming reports
and triage the most likely non-spam ones first. [1]

"People send us malware" -- to a very good first approximation, there
are no such things as "email viruses".  There are "Outlook viruses".
Learn how to use a real mail client.

"We don't speak language X" -- run it through Google translate, take
your best shot at it.  Most reports will be in your language anyway.
(Note: if you are a multi-mega-million dollar company, then hire abuse
and postmaster and hostmaster  staff fluent in multiple languages.
This is more important than your on-site massage therapist and gourmet chef.)

"We don't have the time/personnel/budget" -- but magically you have
the time, personnel, and budget to run an operation that's causing
problems for other people.  Also you have a market capitalization
of $7.65 gazillion dollars and a gym on the second floor, so please
spare me this one.

"But X isn't doing it either" -- the "we're no worse than anyone else"
excuse and subsequent race to the bottom.

"You can call us on the phone" -- yeah, at 3 AM your local time,
that'll work.  Also I'll be dictating the contents of an email
message, including the full headers.  No, I don't mind trying to
explain a hijacked network problem to your front-line support staff
who will read their from their script and tell me to reboot the Windows
box I've never had.  Good use of my time.

"We have a web form" -- that lets me paste 500 characters into
a tiny box and requires 9 kinds of Javascript and captchas and other
crap and doesn't allow me to keep copy of the message and doesn't
facilitate a conversation and doesn't even work because my network
is on fire (thanks in part to you) while email will at least get
queued and retried at intervals.  I also appreciate having to
figure this out 14 times for 14 different operations rather than
being able to just BCC the same message to all of them and get back
to trying to put the fire out.  Another good use of my time.

"Another tired excuse here" -- if you invested the time you spend
coming up with excuses into just doing it, you wouldn't be reading
this rant.

Mail to your role accounts is often coming either from (a) people your
operation is attacking/abusing and/or (b) people who are graciously
and generously trying to help you, despite (a).

You owe them:

(1) acknowledgement
(2) investigation
(3) action, if indicated
(4) response/explanation
(5) apology, if indicated
(6) a thank-you

You owe yourself:

(7) remedial action to try to forestall a repeat occurrence
and thus the need to keep repeating 1-6 ad infinitum

This isn't hard.  It's not complicated.  We all solve 

Re: Spitballing IoT Security

[Rich Kulawiec]

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 device?"  A cloud controlled networked device, with no cloud, is
> not terribly useful.

1. This has happened already, e.g., Nest.  It will happen again.  Many times.

2. Such a device may not be terribly useful *to you*, but in its
neglected, unremarked, unmaintained state it may become very useful
to attackers.

---rsk

RE: Spitballing IoT Security

[Keith Medcalf]

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 turn it into an agressive DNS destroyer.
> >> 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
> >> that assertion come from the manufacturer, at least you would know that
> >> the device was designed to require that sort of access.**

> > And why would anyone in their right mind trust the manufacturer to make
> > this decision?  

> Because the manufacturer designed the device and knows best as to what
> sort of access it will require.

Manufacturers of devices and Operating Systems (particularly Microsoft WIndows) 
have proven over and over and over again that they cannot be trusted to make 
that decision.  One of the worst offenders, any versions of Windows subsequent 
to Windows XP, insists in dropping its knickers (opening the firewall) so that 
anything that wants to can fuck about with (connect to unrestricted from the 
internet) all the myriad of ever growing piles of shit included by Microsoft.  
Even if you close the firewall, the Manufacturer believes it knows better and 
changes your settings, without your permission.  If you are stupid enough to 
run UPNP on your network, then all the drivel flarn filth is directly 
accessible from the internet (and beyond) without restriction.

Preventing the manufacturer from doing that takes a *LOT* of *DEEP* surgery.

I wish that Ballmer fellow would just up and die, and that damn indian too, 
even more so.  If they got some help along those lines the world would be a lot 
better place.  They are both total asshats and enemies of security and 
functionality everywhere.

However, it is not just a microsoft thing -- ALL of them think they know better 
and they should all fuck off and die.

> Consider that today most devices have
> unfettered outbound access, and many can arrange for unfettered inbound
> access.  That's Not Good®.

Yes, because that is what the device manufacturers have programmed the device 
to do and to have, and to go to inordinate lengths to ignore any directions 
from the OWNER to the contrary.  They should all be strung up by their balls 
and dropped with dull rusty pinking shears!

> That doesn't mean that network
> administrators shouldn't be the kings and queens of their castles, but
> as I'm sure you well know, home users don't really know how to rule, and
> so they need some good defaults.

What is wrong with OFF?  That is a good default.

> Put it another way: you bring home a NEST and the first thing you the
> expert might do is read the net to figure out which ports to open.  Are
> you really going to not open those ports?

First of all, I would NEVER bring home a NEST, nor would I ever allow a NEST or 
anything like it to be connected to my network.  It is an evil device that does 
nothing of any use to me whatsoever.  It is also dangerous and malicious and 
will not permit me to control the damn thing, nor to retrieve data from it.  It 
is a hunk of useless shit.

And no.  Under no circumstances whatsoever do I open ports unless I know what 
they are for.  And inbound port openings require proof of paid up indemnity 
insurance in the millions per incident (trillion in total).  Therefore, no 
inbound ports get opened since no one has ever been able to satisfy this 
requirement.

End of Line.

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

[Exa]

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 cause an operational issue, ExaBGP is not used to route 
packets in anyone's core, but but the current process gave me no choice: it 
takes implementation to find issues with drafts and/or interrop problems, 
unexpected behaviours or simply provide a feature to a crying customer even if 
a draft is never created / never reach RFC status.

I remember reading a draft from John which attempted to allocate some code 
points for experimentation - my memory is fuzzy on the details sorry - but even 
then this would require re numbering which is not ideal.

So perhaps in addition to recognising the squatting issue, "we" should look at 
how the current IETF process works and can be changed to improve 
experimentation.

Thomas

Sent from my iPad

>  On 27 Oct 2016, at 16:47, Owen DeLong  wrote:
> 
> I don’t mind the move to 32, but I hope the vendors are getting appropriately 
> smacked for squatting and that those attributes are not allowed to be 
> misappropriated by the vendors.
> 
> We have a standards process for a reason and vendors simply squatting on 
> numbers is a violation of that process which cannot be allowed to stand 
> unless we wish to establish that as precedent and simply allow vendors to 
> claim numbers as they wish.
> 
> This already happened with the BSD community in their implementation of a 
> pseudo-VRRP like capability and now two different vendors have abused BGP 
> path attributes.
> 
> This is not a good path for us to continue.
> 
> Owen
> 
>> On Oct 26, 2016, at 11:19 PM, Job Snijders  wrote:
>> 
>> Dear Internet,
>> 
>> Through this beacon it was discovered that a vendor was squatting on BGP
>> Path Attribute value 30. And another vendor sat on 31.
>> 
>> So, a twisted turn of events, the Large BGP Communities effort has ended up
>> with BGP Path Attribute value 32 - very befitting if you look at the very
>> problem we're trying to solve :-)
>> 
>> The beacon has been updated to use the new IANA assigned value, nothing
>> else was changed. Hopefully we are in the clear this time around!
>> 
>> Please verify if you can see 192.147.168.0/24 and 2001:67c:208c::/48
>> 
>> Kind regards,
>> 
>> Job
>> 
>>> On Tue, Oct 11, 2016 at 05:01:56PM +0200, Job Snijders wrote:
>>> Large BGP Communities are a novel way to signal information between
>>> networks. An example of a Large BGP Communities is: 2914:4056024901:80.
>>> 
>>> Large BGP Communities are composed of three 4-octet integers, separated
>>> by something like a colon. This is easy to remember and accommodates
>>> advanced routing policies in relation to 4-Byte ASNs. It is the tool that 
>>> has
>>> been missing since 4-octet ASNs were introduced.
>>> 
>>> IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) in
>>> the "BGP Path Attributes" registry under the "Border Gateway Protocol
>>> (BGP) Parameters" group.
>>> 
>>> The draft can be read here: 
>>> https://tools.ietf.org/html/draft-ietf-idr-large-community
>>> 
>>> Additional information about Large BGP Communities can be found here:
>>> http://largebgpcommunities.net/
>>> 
>>> Starting today (2016.10.11), the following two BGP beacons are available
>>> to the general public, with AS_PATH 2914_15562$
>>> 
>>>   Both these prefixes have a Large BGP Community attached:
>>> 
>>>   2001:67c:208c::/48
>>>   192.147.168.0/24
>>> 
>>>   Large BGP Community - 15562:1:1
>>> 
>>> The NLNOG RING BGP Looking Glass is running the latest version of BIRD
>>> which understands the Large BGP Community Path Attribute.
>>> 
>>> IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.147.168.0/24
>>> IPv6 LG: 
>>> http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:67c:208c::/48
>>> 
>>> In theory, since this is an optional transitive BGP Path Attribute, all
>>> the Looking Glass' peers should boomerang the Large Community back to
>>> the LG.  However we currently observe that 50 out of 75 peers propagate
>>> the Large BGP Community to the LG.
>>> 
>>> Relevant Router commands to see if you receive the attribute, or whether
>>> one of intermediate networks has stripped the attribute from the route:
>>> 
>>>   IOS: show ip bgp path-attribute unknown 
>>>   shows all prefixes with unknown path attributes.
>>> 
>>>IOS #2 - like on route views:
>>>route-views>sh ip bgp 192.147.168.0
>>> BGP routing table entry for 192.147.168.0/24, version 98399100
>>> Paths: (39 available, best #30, table default)
>>>   Not advertised to any peer
>>>   Refresh Epoch 1
>>>   701 2914 15562
>>> 137.39.3.55 from 137.39.3.55 (137.39.3.55)
>>>   Origin IGP, localpref 100, valid, external
>>>

Re: Large BGP Communities beacon in the wild

[Randy Bush]

> 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.

luckily we have never seen something like this before. 

Re: Large BGP Communities beacon in the wild

[Christopher Morrow]

On Thu, Oct 27, 2016 at 5:28 PM, James Bensley  wrote:

>
>
> Name and shame, it is not acceptable!
>
>
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.

-chris

1: https://www.ietf.org/mail-archive/web/idr/current/msg16556.html