Re: ripe/ncc likes cookies

2013-01-14 Thread Owen DeLong

On Jan 12, 2013, at 8:50 PM, Andrew Latham lath...@gmail.com wrote:

 On Sat, Jan 12, 2013 at 11:06 PM, Randy Bush ra...@psg.com wrote:
 RIPE needs to fix on their web site:
 
 Please turn on the cookies on your browser to view this site.
 
 It doesn't have to be this way...
 
 it should not be this way
 
 randy
 
 
 Local law in EU which I assumed that most knew about
 http://www.cookielaw.org/about-this-message.aspx
 

The law requires notification _IF_ you use cookies.

It does _NOT_ require use of cookies which is what I believe the original 
objections were.

Owen




Re: De-funding the ITU

2013-01-14 Thread Owen DeLong
The regulatory side of ITU-T is responsible for much of the damaging legacy 
Telecom attitude of revenue entitlement.

I think defunding that and seeing what is developed in its place might well be 
a good thing.

Owen

On Jan 12, 2013, at 9:04 PM, Fred Baker (fred) f...@cisco.com wrote:

 
 On Jan 12, 2013, at 8:17 PM, John Levine jo...@iecc.com wrote:
 
 Please learn a little more about the ITU before doing so.  There is
 more to the ITU than the dysfunctional ITU-T, and the political
 fallout from the US being seen as a big rich bully taking its wallet
 and going home is likely not worth the trivial amount of money
 involved.
 
 On that I would agree. ITU-D and ITU-R do a lot of good work. ITU-T does 
 reasonable work, for the most part, in regulatory matters, which neither the 
 IGF nor the IETF address. Frankly, if the ITU gets shut down, ITU-R, ITU-D, 
 and the regulatory component of ITU-T will have to be re-created to 
 accomplish those roles. Where we have travelled in circles with the ITU is in 
 conflicting technical standardization and in the desire of ITU-T staff to 
 take over certain functions from ICANN and the NRO. Shutting down the ITU 
 would be in effect discarding the baby with the bathwater.
 
 http://www.itu.int/en/ITU-R/pages/default.aspx
 http://www.itu.int/en/ITU-D/Pages/default.aspx




Re: De-funding the ITU

2013-01-14 Thread Owen DeLong

On Jan 13, 2013, at 1:47 PM, Barry Shein b...@world.std.com wrote:

 
 Even if there were no ITU we'd have to invent one, to paraphrase
 Voltaire's quip about God.
 
 There'd have to be some organization to negotiate and oversee
 international settlements and other, similar, regulations.
 

Why? The internet has operated just fine without such for quite some time
now.

 And it would probably end up being about the same because who'd be
 involved but about the same people and organizations (particularly the
 PTTs et al)?

Which is a good argument that such an organization has, in fact, become
an anachronism.

 If you sincerely wanted to get rid of the ITU or pieces thereof the
 only way would be to form some alternative organization, perhaps with
 different policy and process rules, and use it to supplant them.

If you don't believe that the internet is in the process of supplanting
traditional telephony, you aren't paying attention.

The internet has had such organizations for some time now.

The petition specifically focuses on moving US funding from the ITU to
those organizations (which does give me pause… I think I prefer the
organizations in question not being purchased by the USG).

 
 Actually, no matter how you got rid of the ITU that's what you'd end
 up with because much of what they do would happen somehow, but without
 a real plan probably by even worse means like shadowy inter-PTT
 organizations arising without any accountability or transparency.

Such organizations would be scattered and far less effective. I would
rather take my chances against them than the current ITU structure.

Owen




RE: OOB core router connectivity wish list

2013-01-14 Thread Jamie Bowden
 From: Mikael Abrahamsson [mailto:swm...@swm.pp.se]
 On Sat, 12 Jan 2013, Matthew Petach wrote:
 
  Thank goodness ethernet never has problems with negotiation going
 awry,
  and coming up with mismatched duplexes, and vendors never had to
  implement no negotiation-auto in their configs because you couldn't
  count on everyone's implementations working together just absolutely
  perfectly the first time on bootup.  Yes, it sure is a good thing
  ethernet never has issues like that which would cripple your ability
 to
  get a box up and running at 2am.
 
 Has this happened to you with equipment designed and manufactured the
 past
 5 years?

This happened to me just last month.

Jamie



Brocade XMR/MLX VLAN bit counters (Cacti graphs for brocade VLANS) (95% billing).

2013-01-14 Thread James Wininger
All,

We are running into an issue with Brocade where we are finding it difficult to 
to graph VLAN interfaces for bits (in/out) across a tagged (trunk) interface. 
On Cisco this is not an issue. So what we end up with in Cacti is a blank (no 
data) graph.

I have been all over these devices with snmpwalk etc (typical tool set). Has 
anyone found a fix or work around for this? Or perhaps I should be asking a 
different question….Is there a better tool/mindset for 95% billing since this 
is what we are doing with this info.
--

Jim Wininger

Don't find fault, find a remedy. - Henry Ford



Re: Brocade XMR/MLX VLAN bit counters (Cacti graphs for brocade VLANS) (95% billing).

2013-01-14 Thread Pui Edylie

Hi James,

We have been using Observium and never look back

http://www.observium.org/wiki/Main_Page

Cheers,
Edy

On 1/14/2013 10:00 PM, James Wininger wrote:

All,

We are running into an issue with Brocade where we are finding it difficult to 
to graph VLAN interfaces for bits (in/out) across a tagged (trunk) interface. 
On Cisco this is not an issue. So what we end up with in Cacti is a blank (no 
data) graph.

I have been all over these devices with snmpwalk etc (typical tool set). Has anyone found 
a fix or work around for this? Or perhaps I should be asking a different 
question….Is there a better tool/mindset for 95% billing since this is what we are doing 
with this info.
--

Jim Wininger

Don't find fault, find a remedy. - Henry Ford






Re: Brocade XMR/MLX VLAN bit counters (Cacti graphs for brocade VLANS) (95% billing).

2013-01-14 Thread JP Viljoen
On 14 Jan 2013, at 4:00 PM, James Wininger jwinin...@ifncom.net wrote:
 All,
 
 We are running into an issue with Brocade where we are finding it difficult 
 to to graph VLAN interfaces for bits (in/out) across a tagged (trunk) 
 interface. On Cisco this is not an issue. So what we end up with in Cacti is 
 a blank (no data) graph.
 
 I have been all over these devices with snmpwalk etc (typical tool set). Has 
 anyone found a fix or work around for this? Or perhaps I should be asking a 
 different question….Is there a better tool/mindset for 95% billing since this 
 is what we are doing with this info.

I second Pui's suggestion for taking a look at Observium, it's got a vastly 
more NOC-friendly build than what Cacti's reigning philosophy appears to be. 
Might not be perfect for everyone, but certainly worth a bit of time to check 
out.

As for your Cacti problem, it's likely the 64-bit counters thing. Cacti's 
templates don't default to 64-bit counters.

-J


Re: De-funding the ITU

2013-01-14 Thread John Levine
 There'd have to be some organization to negotiate and oversee
 international settlements and other, similar, regulations.

Why? The internet has operated just fine without such for quite some time
now.

The Internet is held together with spit and duct tape, and sucks for
connections that need a stable low-jitter channel, we've all noticed.
It has no principle of universal service.

The Internet does what it does surprisingly well, but it's not the
same kind of network as the phone system.  We all know of the abuses
that can come with mandatory interconnection and settlements, but the
solution is not to cut off the poor countries.








Re: De-funding the ITU

2013-01-14 Thread Nick Hilliard
On 14/01/2013 15:27, John Levine wrote:
 The Internet does what it does surprisingly well, but it's not the
 same kind of network as the phone system.  We all know of the abuses
 that can come with mandatory interconnection and settlements, but the
 solution is not to cut off the poor countries.

less well developed countries often have their telecoms requirements
serviced by an incumbent monopoly, often involving government ownership and
usually involving little or no functional regulation.  20 years ago, the
ISP that I worked for was paying about $20,000/meg/month for IP transit.
It didn't drop to where it is now because of ITU regulations,
interconnection settlements or by maintaining the government-owned monopoly
of the time.  I'm struggling to understand why people view these things as
solutions to a problem, rather than the root cause.

Nick




Re: Brocade XMR/MLX VLAN bit counters (Cacti graphs for brocade VLANS) (95% billing).

2013-01-14 Thread Erik Muller

On 1/14/13 9:00 , James Wininger wrote:

All,

We are running into an issue with Brocade where we are finding it difficult to 
to graph VLAN interfaces for bits (in/out) across a tagged (trunk) interface. 
On Cisco this is not an issue. So what we end up with in Cacti is a blank (no 
data) graph.


Depending on the specific hardware you're using, you may be out of luck - 
early generations of MLX/XMR line cards don't support per-vlan statistics; 
you need to have the new 8x10GE cards (or a few others of the current 
generation) to have those counters available.


-e



Re: Brocade XMR/MLX VLAN bit counters (Cacti graphs for brocade VLANS) (95% billing).

2013-01-14 Thread Jeroen Wunnink | Atrato IP Networks
Sneaky hack: Slap an in+out rate limit on the vlan with high settings 
(i.e. same as port/lag speed) and just graph the OID of the rate limit 
counter :-)
Might need to take a multiplier calculation/CDEF into account based on 
the number of ports you have in the lag.


The new 8x10 cards have built in ve counters indeed which makes it a lot 
easier




On 1/14/13 5:37 PM, Erik Muller wrote:

On 1/14/13 9:00 , James Wininger wrote:

All,

We are running into an issue with Brocade where we are finding it 
difficult to to graph VLAN interfaces for bits (in/out) across a 
tagged (trunk) interface. On Cisco this is not an issue. So what we 
end up with in Cacti is a blank (no data) graph.


Depending on the specific hardware you're using, you may be out of 
luck - early generations of MLX/XMR line cards don't support per-vlan 
statistics; you need to have the new 8x10GE cards (or a few others of 
the current generation) to have those counters available.


-e




--

Jeroen Wunnink
Network Engineer
Atrato IP Networks
jeroen.wunn...@atrato-ip.com
Phone: +31 20 82 00 623




Re: Brocade XMR/MLX VLAN bit counters (Cacti graphs for brocade VLANS) (95% billing).

2013-01-14 Thread Steven Noble
I saw the same issue for getting OpenFlow stats, you need the new 8x10 or 100GE 
cards afaict.

On Jan 14, 2013, at 9:38 AM, Jeroen Wunnink | Atrato IP Networks 
jeroen.wunn...@atrato-ip.com wrote:

 Sneaky hack: Slap an in+out rate limit on the vlan with high settings (i.e. 
 same as port/lag speed) and just graph the OID of the rate limit counter :-)
 Might need to take a multiplier calculation/CDEF into account based on the 
 number of ports you have in the lag.
 
 The new 8x10 cards have built in ve counters indeed which makes it a lot 
 easier
 
 
 
 On 1/14/13 5:37 PM, Erik Muller wrote:
 On 1/14/13 9:00 , James Wininger wrote:
 All,
 
 We are running into an issue with Brocade where we are finding it difficult 
 to to graph VLAN interfaces for bits (in/out) across a tagged (trunk) 
 interface. On Cisco this is not an issue. So what we end up with in Cacti 
 is a blank (no data) graph.
 
 Depending on the specific hardware you're using, you may be out of luck - 
 early generations of MLX/XMR line cards don't support per-vlan statistics; 
 you need to have the new 8x10GE cards (or a few others of the current 
 generation) to have those counters available.
 
 -e
 
 
 
 -- 
 
 Jeroen Wunnink
 Network Engineer
 Atrato IP Networks
 jeroen.wunn...@atrato-ip.com
 Phone: +31 20 82 00 623
 
 




Re: De-funding the ITU

2013-01-14 Thread Wayne E Bouchard
I'm of the camp that says that, in large measure, the only beneficial
elements of international telecommunications agreements have been to
define an international band plan for the radio spectrum. That was,
afterall, the principal reason these treaties were signed, to prevent
chaos within the spectrum. (That was also the genesis of the FCC. Too
bad it didn't confine itself to that.)

I'm sure there have been other useful things to come about but the
have been abd continue to be considerably overshadowed by the
detrimental effects of excessive meddling.

-Wayne

On Mon, Jan 14, 2013 at 04:14:56PM +, Nick Hilliard wrote:
 On 14/01/2013 15:27, John Levine wrote:
  The Internet does what it does surprisingly well, but it's not the
  same kind of network as the phone system.  We all know of the abuses
  that can come with mandatory interconnection and settlements, but the
  solution is not to cut off the poor countries.
 
 less well developed countries often have their telecoms requirements
 serviced by an incumbent monopoly, often involving government ownership and
 usually involving little or no functional regulation.  20 years ago, the
 ISP that I worked for was paying about $20,000/meg/month for IP transit.
 It didn't drop to where it is now because of ITU regulations,
 interconnection settlements or by maintaining the government-owned monopoly
 of the time.  I'm struggling to understand why people view these things as
 solutions to a problem, rather than the root cause.
 
 Nick
 

---
Wayne Bouchard
w...@typo.org
Network Dude
http://www.typo.org/~web/



Re: De-funding the ITU

2013-01-14 Thread Eliot Lear
A point of clarification:

On 1/14/13 7:46 PM, Wayne E Bouchard wrote:
 I'm of the camp that says that, in large measure, the only beneficial
 elements of international telecommunications agreements have been to
 define an international band plan for the radio spectrum. That was,
 afterall, the principal reason these treaties were signed, to prevent
 chaos within the spectrum. (That was also the genesis of the FCC. Too
 bad it didn't confine itself to that.)

There are at least three sets of treaty texts.  The first is the output
of the ITU Plenipotentiary conference, which consists of its
Constitution and Convention and a number of resolutions, the second are
the ITRs (over which we just had the fractious affair in Dubai), and the
third are the Radio Regulations.  You refer to the 3rd set of text and
you clearly are not alone in terms of your thoughts about the ITRs since
55 countries did not sign them.

Eliot



Re: De-funding the ITU

2013-01-14 Thread Owen DeLong

On Jan 14, 2013, at 7:27 AM, John Levine jo...@iecc.com wrote:

 There'd have to be some organization to negotiate and oversee
 international settlements and other, similar, regulations.
 
 Why? The internet has operated just fine without such for quite some time
 now.
 
 The Internet is held together with spit and duct tape, and sucks for
 connections that need a stable low-jitter channel, we've all noticed.
 It has no principle of universal service.
 
 The Internet does what it does surprisingly well, but it's not the
 same kind of network as the phone system.  We all know of the abuses
 that can come with mandatory interconnection and settlements, but the
 solution is not to cut off the poor countries.

I have no reason whatsoever to believe that defunding the ITU would
cut off the poor countries.

Quite the contrary, actually. I believe that the combination of the ITU
and the back-pocket distribution of settlement checks has held back the
improvement of digital connections to poorer countries.

Owen




Re: De-funding the ITU

2013-01-14 Thread Bill Woodcock

On Jan 14, 2013, at 11:12 AM, Owen DeLong o...@delong.com wrote:
 On Jan 14, 2013, at 7:27 AM, John Levine jo...@iecc.com wrote:
 The solution is not to cut off the poor countries.
 
 I have no reason whatsoever to believe that defunding the ITU would
 cut off the poor countries.
 
 Quite the contrary, actually. I believe that the combination of the ITU
 and the back-pocket distribution of settlement checks has held back the
 improvement of digital connections to poorer countries.

Exactly.  The ITU bleeds poor countries dry, by keeping communications costs 
exorbitantly high, while appeasing them with settlements.  The Internet doesn't 
need to bribe destitute people with settlements, because it's five orders of 
magnitude less expensive: affordable enough that they can get online in the 
first place.

http://oecdinsights.org/2012/10/22/internet-traffic-exchange-2-billion-users-and-its-done-on-a-handshake/

The ITU has $181M/year.  It'll do just fine without our money.  No sense in 
throwing good money after bad.

-Bill








Re: De-funding the ITU

2013-01-14 Thread Nick Hilliard
On 14/01/2013 19:23, Bill Woodcock wrote:
 The ITU bleeds poor countries dry, by keeping communications costs
 exorbitantly high,

Whoa.  What bleeds poor countries dry is bad management of national
resources, coupled with inherent kleptocracy, massive corruption and
stifling regulation.  In short: endemic mismanagement - and this extends
way beyond the reach of just the telecoms infrastructure within the country.

The ITU's impact in this serves only to provide some post-facto
justification for preserving the status quo, nothing more.  If any country
wants to ditch the dinosaur model, they are free to do so and the ITU has
no say in this whatever.  And the countries which have done so have ended
up with vastly improved infrastructure as a result, despite the efforts of
those dinosaurs to convince the politicians with scary horror stories of
what bad and evil things will happen if they lose their monopoly in the
marketplace and are exposed to actual competition!

 The Internet doesn't need to bribe destitute people with settlements,
 because it's five orders of magnitude less expensive

Exactly - and the fix for this is to deal with national policy
mismanagement rather than international.  Once you have enough fibre into a
country to allow competitive access to the market, the international
pricing issues become line noise.

Nick




Re: Postini Exiting ISP Business?

2013-01-14 Thread JC Dill

On 08/01/13 9:06 AM, Ray Wong wrote:

The lack of customer service is, somewhat sadly, fairly
typical of Google's offerings. Once you get into dealings with
Google's actual business units it's a little better, but still always
a challenge to reach a human being who can actually give you straight
answers and simplify things. Actually, pretty typical IME of almost
every company that's run by the Tech people (top execs not
withstanding, they've always favored promoting/hiring techier people
to oversee pretty much everything... even sales types get the tech
screen interviews, just with lower grading standards) to forget how to
actually treat customers.


+1

(Yes, I see the irony in that.)

I've been saying this about Google for years.  This problem first became 
evident when gmail was still in beta, when major problems went unfixed 
for over a year, when gmail itself was still in beta almost 5 years 
after they went public with it.  While Google is good at a lot of 
things, and very good at some things, they are horrible at customer 
service.  I use Google for many things, but I don't RELY on them for 
much.  I would be very cautious about relying on them as your sole 
source for a critical enterprise service like email spam filtering.


jc




Re: De-funding the ITU

2013-01-14 Thread Owen DeLong


Sent from my iPad

On Jan 14, 2013, at 11:03 AM, Nick Hilliard n...@foobar.org wrote:

 On 14/01/2013 19:23, Bill Woodcock wrote:
 The ITU bleeds poor countries dry, by keeping communications costs
 exorbitantly high,
 
 Whoa.  What bleeds poor countries dry is bad management of national
 resources, coupled with inherent kleptocracy, massive corruption and
 stifling regulation.  In short: endemic mismanagement - and this extends
 way beyond the reach of just the telecoms infrastructure within the country.
 
 The ITU's impact in this serves only to provide some post-facto
 justification for preserving the status quo, nothing more.  If any country
 wants to ditch the dinosaur model, they are free to do so and the ITU has
 no say in this whatever.  And the countries which have done so have ended
 up with vastly improved infrastructure as a result, despite the efforts of
 those dinosaurs to convince the politicians with scary horror stories of
 what bad and evil things will happen if they lose their monopoly in the
 marketplace and are exposed to actual competition!

I don't agree. The ITU's impact in part is to provide a continuing source
of revenue to motivate, promote, and preserve this status quo.

While the ITU has no legitimate say in it, the ITU provides significant
economic incentives against ditching the dinosaur as you called it.
There's a reason that ITU representatives hand-deliver settlement
checks to many of these countries.

Those countries that have done so have largely done so because they
got lucky with visionary regulators that were motivated more by doing
right by the country and its citizens rather than maximizing personal
immediate gains. In many cases, this was the result of a higher level
official overriding the telecom minister (or equivalent) and opening
competition over the objections of said telecom minister (or equiv.).

 
 The Internet doesn't need to bribe destitute people with settlements,
 because it's five orders of magnitude less expensive
 
 Exactly - and the fix for this is to deal with national policy
 mismanagement rather than international.  Once you have enough fibre into a
 country to allow competitive access to the market, the international
 pricing issues become line noise.

Even in trying to be pro-ITU, you have admitted that they are a proximate
preserver of this problem. As such, defunding them seems a rational step
in the direction of solution. It's not a panacea, but it's one step in the right
direction.

Owen




Notice: Fradulent RIPE ASNs

2013-01-14 Thread Ronald F. Guilmette

After a careful investigation, I am of the opinion that each of the
following 18 ASNs was registered (via RIPE) with fradulent information
purporting to represent the identity of the true registrant, and that
in fact, all 18 of these ASNs were registered by a single party,
apparently as part of a larger scheme to provide IP space to various
snowshoe spammers.

Evidence I have in hand strongly links this scheme and these ASNs and
their associated IPv4 route announcements to Jump Network Services,
aka JUMP.RO.  Furthermore, all of these ASNs are apparently peering
with exactly and only the same two other ASNs in all cases, i.e.
GTS Telecom SRL (AS5606) and Net Vision Telecom SRL (AS39737).  These
peers and the fradulent ASNs listed below are all apparently originated
out of Romania.

AS16011 (fiberwelders.ro)
AS28822 (creativitaterpm.ro)
AS48118 (telecomhosting.ro)
AS49210 (rom-access.ro)
AS50659 (grandnethost.com)
AS57131 (speedconnecting.ro)
AS57133 (nordhost.ro)
AS57135 (fastcable.ro)
AS57176 (bucovinanetwork.ro)
AS57184 (kaboomhost.ro)
AS57415 (highwayinternet.ro)
AS57695 (effidata.ro)
AS57724 (id-trafic.ro)
AS57738 (mclick.ro)
AS57786 (hosting-www.ro)
AS57837 (romtechinnovation.ro)
AS57906 (momy.ro)
AS57917 (nature-design.ro)

At present, the above 18 ASNs are currently announcing routes for a total
amount of IP space equal to 1,022 /24s, which is the rough equivalent of
an entire /14 block.  These IPv4 route announcements are listed below,
sorted by IPv4 (32-bit) start address.

Additional potentially relevant background information:


http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-spam-122109

http://www.spamhaus.org/rokso/evidence/ROK9107/world-company-register-eu-business-register/rogue-ases-as43332-as44414-as44520-as49173-as49643
http://www.spamhaus.org/sbl/listings/jump.ro


Current route announcements:

31.14.30.0/24
31.14.32.0/24
31.14.33.0/24
31.14.34.0/23
31.14.36.0/22
31.14.40.0/22
31.14.44.0/24
31.14.45.0/24
31.14.46.0/23
31.14.48.0/24
31.14.49.0/24
31.14.50.0/23
31.14.52.0/22
31.14.56.0/21
31.14.64.0/24
31.14.65.0/24
31.14.66.0/23
31.14.68.0/22
31.14.72.0/21
31.14.80.0/20
31.14.112.0/20
31.14.144.0/20
37.153.128.0/22
37.153.132.0/22
37.153.140.0/22
37.153.144.0/21
37.153.152.0/22
37.153.160.0/21
37.153.168.0/22
37.153.172.0/23
37.153.174.0/23
37.153.176.0/20
37.156.0.0/22
37.156.4.0/22
37.156.8.0/21
37.156.16.0/23
37.156.18.0/23
37.156.20.0/23
37.156.22.0/23
37.156.24.0/23
37.156.26.0/23
37.156.28.0/23
37.156.30.0/23
37.156.36.0/24
37.156.37.0/24
37.156.38.0/23
37.156.48.0/21
37.156.56.0/22
37.156.100.0/22
37.156.104.0/22
37.156.108.0/22
37.156.112.0/20
37.156.128.0/20
37.156.144.0/22
37.156.148.0/22
37.156.152.0/21
37.156.160.0/21
37.156.168.0/22
37.156.172.0/23
37.156.180.0/23
37.156.184.0/22
37.156.188.0/22
37.156.208.0/22
37.156.216.0/22
37.156.224.0/24
37.156.225.0/24
37.156.226.0/23
37.156.228.0/23
37.156.230.0/23
37.156.232.0/23
37.156.234.0/23
37.156.236.0/23
37.156.238.0/23
37.156.240.0/21
37.156.248.0/22
37.156.252.0/22
46.102.128.0/20
46.102.144.0/20
46.102.160.0/21
77.81.120.0/23
77.81.126.0/24
77.81.160.0/22
84.247.4.0/22
84.247.18.0/23
84.247.40.0/22
85.204.18.0/24
85.204.20.0/23
85.204.30.0/23
85.204.36.0/22
85.204.54.0/23
85.204.64.0/23
85.204.66.0/24
85.204.76.0/23
85.204.96.0/23
85.204.104.0/23
85.204.120.0/24
85.204.121.0/24
85.204.124.0/24
85.204.132.0/23
85.204.152.0/23
85.204.176.0/21
85.204.194.0/23
86.104.0.0/23
86.104.2.0/24
86.104.4.0/24
86.104.9.0/24
86.104.10.0/24
86.104.96.0/21
86.104.115.0/24
86.104.116.0/24
86.104.118.0/23
86.104.121.0/24
86.104.122.0/23
86.104.132.0/23
86.104.192.0/24
86.104.195.0/24
86.104.212.0/23
86.104.215.0/24
86.104.240.0/22
86.104.245.0/24
86.104.248.0/23
86.105.178.0/24
86.105.195.0/24
86.105.196.0/24
86.105.200.0/22
86.105.225.0/24
86.105.227.0/24
86.105.230.0/24
86.105.242.0/23
86.105.248.0/22
86.106.0.0/21
86.106.8.0/23
86.106.10.0/24
86.106.11.0/24
86.106.12.0/24
86.106.24.0/24
86.106.25.0/24
86.106.90.0/24
86.106.95.0/24
86.106.169.0/24
86.107.8.0/21
86.107.28.0/23
86.107.74.0/23
86.107.104.0/24
86.107.195.0/24
86.107.216.0/21
86.107.242.0/23
89.32.122.0/23
89.32.176.0/23
89.32.192.0/23
89.32.196.0/23
89.32.204.0/24
89.33.46.0/23
89.33.108.0/23
89.33.117.0/24
89.33.168.0/21
89.33.233.0/24
89.33.246.0/24
89.33.255.0/24
89.34.16.0/22
89.34.94.0/23
89.34.102.0/23
89.34.112.0/21
89.34.128.0/20
89.34.148.0/23
89.34.200.0/23
89.34.216.0/23
89.34.236.0/22
89.35.32.0/24
89.35.56.0/24
89.35.77.0/24
89.35.133.0/24
89.35.156.0/23
89.35.176.0/23
89.35.196.0/24
89.35.240.0/21
89.36.16.0/23
89.36.32.0/23
89.36.34.0/24
89.36.35.0/24
89.36.96.0/21
89.36.104.0/21
89.36.178.0/23
89.36.182.0/23
89.36.184.0/21
89.36.226.0/23
89.36.236.0/22
89.37.48.0/21
89.37.64.0/22
89.37.76.0/22
89.37.102.0/23
89.37.107.0/24
89.37.129.0/24
89.37.133.0/24
89.37.143.0/24
89.37.240.0/21
89.38.26.0/24
89.38.216.0/22
89.38.220.0/22
89.39.76.0/22
89.39.168.0/22
89.39.180.0/23
89.39.216.0/22
89.40.40.0/24
89.40.66.0/24

Re: De-funding the ITU

2013-01-14 Thread George Herbert
On Mon, Jan 14, 2013 at 7:27 AM, John Levine jo...@iecc.com wrote:
 There'd have to be some organization to negotiate and oversee
 international settlements and other, similar, regulations.

Why? The internet has operated just fine without such for quite some time
now.

 The Internet is held together with spit and duct tape, and sucks for
 connections that need a stable low-jitter channel, we've all noticed.
 It has no principle of universal service.

 The Internet does what it does surprisingly well, but it's not the
 same kind of network as the phone system.  We all know of the abuses
 that can come with mandatory interconnection and settlements, but the
 solution is not to cut off the poor countries.

I'm not sure that this mythical kind of network as the phone system
allegedly is describes the reality of the phone network...

That said, two comments:

1. I generally agree that the Internet has too much spit and duct tape, however;

2. Siccing the ITU on that problem - or allowing them near it - would
be a disaster of a magnitude not often seen in human affairs.


-- 
-george william herbert
george.herb...@gmail.com



Re: De-funding the ITU

2013-01-14 Thread John R. Levine

1. I generally agree that the Internet has too much spit and duct tape, however;

2. Siccing the ITU on that problem - or allowing them near it - would
be a disaster of a magnitude not often seen in human affairs.


No disagreement there.  The Internet isn't designed to be a phone network.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,
Please consider the environment before reading this e-mail. http://jl.ly

smime.p7s
Description: S/MIME Cryptographic Signature


Re: De-funding the ITU

2013-01-14 Thread Eric Brunner-Williams
On 1/14/13 11:23 AM, Bill Woodcock wrote:
 ... The ITU ...

How shall states determine what harms are lawfully attempted, and what
harms are not lawfully attempted? Shall there be a treaty concerning
cyber strife between states, or shall cyber strife between states
be without treaty based limits?

If one answers that without is less attractive than with, what is the
means by which states arrive at treaties, without the ITU, or treaty
bodies similar to the ITU, whether regional, or global, in membership
and form?

Shall all predatory or intentionally injurious uses of
trans-jurisdictionally routed communications be {managed, reduced,
mitigated, ...} by private parties, which are, inter alia, for the
most part, for-profit corporations, with no, or negative, fiduciary
duty to police the net?

Flawed as the current institution is, and has been, for the duration
of the the connectionist vs connectionless struggle, proposing to
remove the state member organization without a proposal for an
alternative public purposed organization, not all of which are state
actors, means not have very useful starting points for the big
questions -- shall there be any limit on state actions? shall there be
any limit on non-state actions?

Eric




Re: Notice: Fradulent RIPE ASNs

2013-01-14 Thread Eugeniu Patrascu
On Tue, Jan 15, 2013 at 12:49 AM, Ronald F. Guilmette
r...@tristatelogic.com wrote:

 After a careful investigation, I am of the opinion that each of the
 following 18 ASNs was registered (via RIPE) with fradulent information
 purporting to represent the identity of the true registrant, and that
 in fact, all 18 of these ASNs were registered by a single party,
 apparently as part of a larger scheme to provide IP space to various
 snowshoe spammers.

 Evidence I have in hand strongly links this scheme and these ASNs and
 their associated IPv4 route announcements to Jump Network Services,
 aka JUMP.RO.  Furthermore, all of these ASNs are apparently peering
 with exactly and only the same two other ASNs in all cases, i.e.
 GTS Telecom SRL (AS5606) and Net Vision Telecom SRL (AS39737).  These
 peers and the fradulent ASNs listed below are all apparently originated
 out of Romania.

Jump.ro is a very active LIR and domain registry on the Romanian
market and is selling ASNs to whomever is interested and facilitates
allocations of PI netblocks to those who can justify them. It might
come as a surprise to you, but in Romania there are a lot of companies
(even very small ones) with their own ASN and PI netblocks. This setup
makes it extremely easy to switch ISPs with virtually no impact on
network operations.

If I'm not mistaken, companies use Netvision for cheap internet
access. GTS is more expensive, but theoretically is providing high
quality internet access with good SLAs.


 AS16011 (fiberwelders.ro)
 AS28822 (creativitaterpm.ro)
 AS48118 (telecomhosting.ro)
 AS49210 (rom-access.ro)
 AS50659 (grandnethost.com)
 AS57131 (speedconnecting.ro)
 AS57133 (nordhost.ro)
 AS57135 (fastcable.ro)
 AS57176 (bucovinanetwork.ro)
 AS57184 (kaboomhost.ro)
 AS57415 (highwayinternet.ro)
 AS57695 (effidata.ro)
 AS57724 (id-trafic.ro)
 AS57738 (mclick.ro)
 AS57786 (hosting-www.ro)
 AS57837 (romtechinnovation.ro)
 AS57906 (momy.ro)
 AS57917 (nature-design.ro)

from all those websites it looks like they are all hosting companies.
have you tried calling the numbers listed on the WHOIS registrant
information on the ASN and you couldn't get to any one ?


 At present, the above 18 ASNs are currently announcing routes for a total
 amount of IP space equal to 1,022 /24s, which is the rough equivalent of
 an entire /14 block.  These IPv4 route announcements are listed below,
 sorted by IPv4 (32-bit) start address.

If you really believe that all those ASNs listed by you above are only
used to host spammers, then by all means please contact
ale...@cert-ro.eu - that is the Romanian CERT as they are active and
will investigate the allegations you make.


 Additional potentially relevant background information:

 
 http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-spam-122109
 
 http://www.spamhaus.org/rokso/evidence/ROK9107/world-company-register-eu-business-register/rogue-ases-as43332-as44414-as44520-as49173-as49643
 http://www.spamhaus.org/sbl/listings/jump.ro


So far I do not know a single web hosting company that it's customers
never spammed anyone :)