Re: Notice: Fradulent RIPE ASNs

2013-01-16 Thread Ronald F. Guilmette

In message a5dad1a3-9cc9-4560-93bd-85f9e9128...@steffann.nl, 
Sander Steffann san...@steffann.nl wrote:

Sorry, but you post this information on public mailing lists where it
can be discussed but where no action can be taken...

I think that you mistake formalized centralized action for action
more broadly and generally.

In fact, it is my belief that action has already been taken, within
some networks, to firewall themselves off from the miscreant ASNs and
IP blocks that I reported on.  (And based upon my beliefs regading these
ASNs and IP blocks I would highly recommend that others who have not
yet done so follow suit, along with any and all IP space being announced
in routes from AS2876.)

Nobody else will take your research and submit it to a third party. It's
your research: either you submit it to the RIPE NCC and action will be
taken where appropriate...

As I have already stated, I have no faith whatsoever in the last part of
that assertion, and thus elect not to waste my time.

These kinds of problems have been going on for literally years now,
primarily originating out of Romania.  If RIPE seriously wanted to shut
down all of this fradulent activity, they could have and would have done
so long before now.

In the three years since the following report was written, what has changed?
Anything?

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

   It is impossible at that stage in the process for the RIPE NCC to determine
   that a company is involved in illegal activity. The member in question later
   proved to be a front for RBN, RIPE said in a statement on the case. But the
   allocation was made in 2006 and it wasn't until May 2008 that RIPE was able
   to close down the LIR and get the IP space back.

Excuse me, but really?  Two *^%$#@ years, just to get some space back from
the notorious RBN??

   In most regions, a new organization requesting a large allocation will have
   to go through a fairly rigorous process to show the need for the address
   space...

But not in the RIPE region, apparently.


Regards,
rfg


P.S.  ASNs are not nearly in as short supply as IPv4 addresses are, however
there _are_ only a finite number of them, and they should not be wasted.

As I understand it, generally speaking if you are too small to own even
at least one router, then you most certainly do not need your own ASN.
I have noted however that the last hop on all traceroutes to all of
the domains mentioned in my initial report seems to be 193.226.166.214.
The router at that address is, I believe, the router immediately in front
of the server(s) that are serving up the home pages for these fraudlent
false-front entities.  That IP belongs to AS5606 aka GTS Telecom SRL...
*not* to any one of these bogus fradulent pseudo-entities.

So, within the RIPE region, it appears that one can obtain one's own
ASN... or even perhaps a couple dozen of them... without even owning a
single router.

Somewhow this does not seem to me to be an efficient allocation of finite
number resources.


P.P.S.  Before anyone asks, no, the fact that all routes to all of the
web servers for all of the domains mentioned in my initial report all
pass through 193.226.166.214 (just before the last hop in all cases) is
most certainly *not* the only bit of evidence that indicates that all of
these 18 fradulent false-front entities were created/registered/implemented
by a single hand (which I am confident they all were).  There is plenty
more evidence that supports this view also.  One has only to look just
very slightly below the surface.  The evidence is abundant.

P.P.P.S.  Long before I posted my report here this week, it was already
well and widely known that JUMP.RO has an unfortunate tendency to provide
IP space to fictitious entities engaged primarily in spamming:

  
http://www.spamhaus.org/rokso/evidence/ROK9107/world-company-register-eu-business-register/rogue-ases-as43332-as4

If the good folks at RIPE NCC have not already known about this for some
time then I would suggest that some of them may perhaps be working overtime
to avoid knowing.  On the other hand, if the RIPE folks have in fact known
about what JUMP.RO has been up to, based on earlier published reports of
their quastionable activities, then that begs the obvious question:  What
has RIPE done about this so far?  Anything?

I'm sure that your urging of me to take further action with respect to this
matter is well intentioned, but you have your urging pointed in the wrong
direction, I think.  The primary onus for further action lies elsewhere.



Re: Notice: Fradulent RIPE ASNs

2013-01-16 Thread Ronald F. Guilmette

In message cap-gugvs-kcyosknns+v8r1gdkbpmkuufm1engqvhqh0pr0...@mail.gmail.com
William Herrin b...@herrin.us wrote:

What is your goal here?

Primarily to inform.

Forewarned is forearmed.  Wouldn't you agree?

Is there some action that any particular NANOG
participant should take based on your opinion?

Dropping all route announcements from the 18 fraudlent ASNs I listed,
together with all those from AS2876, and avoiding propagating any of
said routes to any other parties would, I think, be an altogether
prudent step for all concerned.

Unless of couse your are hosting one or more spam research organizations
that are eager to collect as much spam as possible.


Regards,
rfg


P.S.  It is most probably unnecessary to worry about blocking route
announcements relating to any of the separate set of five bogus ASNs
documented here:

   
http://www.spamhaus.org/rokso/evidence/ROK9107/world-company-register-eu-business-register/rogue-ases-as43332-as4441

It is unnecessary to block any such route announcements because owing to
the good work Spamhaus did already in publicising these other five rogue
ASNs... which also got all of their IP space from JUMP.RO... none of them
is even announcing routes anymore.  (Well, at least that's what it looks
like from where I am sitting.)



Re: Notice: Fradulent RIPE ASNs

2013-01-16 Thread Rich Kulawiec
On Tue, Jan 15, 2013 at 11:36:04PM +0100, Sander Steffann wrote:
 Sorry, but you post this information on public mailing lists where it
 can be discussed but where no action can be taken [...]

That's not exactly correct.  Lots of people on this list are perfectly
capable of taking a variety of actions (based on this information)
should they choose to do so.  I have.

I do not understand why you're so adamant about sending this information
to an organization primarily distinguished by its incompetence and
negligence.  If they were actually DOING THEIR JOBS in even minimally
diligent fashion, then Ron wouldn't needed to write that note or do
the research behind it, because this wouldn't be happening.

---rsk



Re: Notice: Fradulent RIPE ASNs

2013-01-16 Thread Todd Underwood
 I do not understand why you're so adamant about sending this information
 to an organization primarily distinguished by its incompetence and
 negligence.  If they were actually DOING THEIR JOBS in even minimally
 diligent fashion, then Ron wouldn't needed to write that note or do
 the research behind it, because this wouldn't be happening.

this kind of mostly unfounded vitriole is silly and damages your credibility.

no one seriously believes that the RIPE NCC (which is managed by all
of its members) is primarily distinguished by their incompetence and
negligence.

i believe this conversation has now gotten to the plonk stage.  can
someone compare them to hitler so that we can move on?

cheers,

t



Re: Notice: Fradulent RIPE ASNs

2013-01-16 Thread Rich Kulawiec
On Wed, Jan 16, 2013 at 10:07:40AM -0500, Todd Underwood wrote:
 no one seriously believes that the RIPE NCC (which is managed by all
 of its members) is primarily distinguished by their incompetence and
 negligence.

Really?  Then why, pray tell, haven't they made it a practice to routinely
(let's say, once a month) ask the people over at Spamhaus: Hey folks, do
you see anything wonky in the space we manage? and then act
immediately and decisively on what they get back for an answer?

I don't want to speak for Spamhaus, but I suspect that they would be
delighted to provide that response, particularly if it led to swift and
effective action to make the problem(s) go away.  And while I don't
always agree with their positions, I've *rarely* found mistakes in
their research: they're thorough.  (So's Ron, by the way.)

This isn't complicated.  This isn't expensive.  This doesn't require
new technology or anything fancy.  It's basic due diligence.  Yet it
clearly hasn't happened.  Why the hell not?

We live in a time when abuse is epidemic.  It's costing us a fortune,
and I don't just mean in financial terms, although certainly that's
bad enough all by itself.  But it doesn't just magically fall out of
the sky and land on our servers or routers, or at port 25 on our
mail servers.   It comes from *somewhere*, and it does so on *somebody's*
watch.  And when it does so on a chronic and systemic basis, surely
it is reasonable to ask questions like Why, if we can so clearly see
it arriving at our operation, can they not see it leaving theirs?
or Why aren't people paying attention to the primary/most useful
sources of information about their own operations?

So it's (well past) time to stop giving people a pass for looking the
other way or failing to look at all.  It's my, your, and everyone's
professional responsibility to do everything we possibly can to prevent
the networks, hosts, and resources we run from being part of the problem.
So yeah: incompetence and negligence are the best words I can find
to describe failure to do that.  What would you call it?

---rsk



RE: looking glass for Level 3

2013-01-16 Thread Siegel, David
Ben,

Our looking glass platform is indeed back online and now supports IPv6 
traceroutes, pings and BGP lookups in the interface (although the web site 
itself is still only available via IPv4).

If you encounter any problems, oddities, or suggestions, please feel free to 
contact me off list and I'll work with engineering to address them.

Again, I apologize for the inconvenience.  Please resume enjoying the use of 
this free tool!  :)

Dave



From: Ben Bartsch [mailto:uwcable...@gmail.com]
Sent: Tuesday, January 15, 2013 8:14 AM
To: Siegel, David
Cc: N. Max Pierson; Cameron Daniel; nanog@nanog.org
Subject: Re: looking glass for Level 3

http://lg.level3.net/ is online from Baton Rouge, LA.  Any official word from 
Level3?

-bb
On Wed, Jan 2, 2013 at 9:27 AM, Siegel, David 
dave.sie...@level3.commailto:dave.sie...@level3.com wrote:
Hi Folks,

The site is offline as a result of some security issues that were discovered.  
As soon as we've got it patched we'll put it back online.

Sorry for any inconvenience this may be causing.

Dave


-Original Message-
From: N. Max Pierson 
[mailto:nmaxpier...@gmail.commailto:nmaxpier...@gmail.com]
Sent: Friday, December 28, 2012 11:06 AM
To: Cameron Daniel
Cc: nanog@nanog.orgmailto:nanog@nanog.org
Subject: Re: looking glass for Level 3

Same here. http://lg.level3.net has been down for over a week for me. I know 
someone in operations I can open a ticket with.

On Fri, Dec 28, 2012 at 5:18 AM, Cameron Daniel 
cdan...@nurve.com.aumailto:cdan...@nurve.com.auwrote:

 I've had issues getting to it for a week or so. Their NOC was
 unresponsive when queried.


 On 2012-12-28 8:23 pm, Peter Ehiwe wrote:

 I normally use the 3rd one you mentioned but they seem to be down at
 the moment.

 Rgds Peter,
 Sent from my Asus  Transformer Pad
 On Dec 28, 2012 1:51 AM, Tassos Chatzithomaoglou 
 ach...@forthnetgroup.grmailto:ach...@forthnetgroup.gr
 wrote:

  Anyone have any looking glass for Level 3?

 The following seem not to be working

 http://www.level3.com/**LookingGlass/http://www.level3.com/LookingG
 lass/ http://lg.level3.net/bgp/bgp.**cgi
 http://lg.level3.net/bgp/bgp.cgi
 http://lookingglass.level3.**net/ http://lookingglass.level3.net/

 --
 Tassos









Re: Notice: Fradulent RIPE ASNs

2013-01-16 Thread Matthew Petach
I'll bet Hitler would have used his real name on the whois entries.

There.  Now I think we're done.

Matt
 On Jan 16, 2013 7:09 AM, Todd Underwood toddun...@gmail.com wrote:

  I do not understand why you're so adamant about sending this information
  to an organization primarily distinguished by its incompetence and
  negligence.  If they were actually DOING THEIR JOBS in even minimally
  diligent fashion, then Ron wouldn't needed to write that note or do
  the research behind it, because this wouldn't be happening.

 this kind of mostly unfounded vitriole is silly and damages your
 credibility.

 no one seriously believes that the RIPE NCC (which is managed by all
 of its members) is primarily distinguished by their incompetence and
 negligence.

 i believe this conversation has now gotten to the plonk stage.  can
 someone compare them to hitler so that we can move on?

 cheers,

 t




Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

2013-01-16 Thread fredrik danerklint

From the article:

Faced with the shortage of IPv4 addresses and the failure of IPv6 to 
take off, British ISP PlusNet is testing carrier-grade network address 
translation CG-NAT, where potentially all the ISP's customers could be 
sharing one IP address, through a gateway. The move is controversial as 
it could make some Internet services fail, but PlusNet says it is 
inevitable, and only a test at this stage.


http://tech.slashdot.org/story/13/01/16/1417244/uk-isp-plusnet-testing-carrier-grade-nat-instead-of-ipv6

I'm only here to bring you the news. So don't complain to me...

--
http://tlmc.fredan.se



Re: Notice: Fradulent RIPE ASNs

2013-01-16 Thread Todd Underwood
it's  nice that we've proceded to insult our colleagues.

many thanks to mr. petach for achieving the end of this thread.  thank
you all for participating.

On Wed, Jan 16, 2013 at 10:54 AM, Rich Kulawiec r...@gsp.org wrote:
 On Wed, Jan 16, 2013 at 10:07:40AM -0500, Todd Underwood wrote:
 no one seriously believes that the RIPE NCC (which is managed by all
 of its members) is primarily distinguished by their incompetence and
 negligence.

 Really?  Then why, pray tell, haven't they made it a practice to routinely
 (let's say, once a month) ask the people over at Spamhaus: Hey folks, do
 you see anything wonky in the space we manage? and then act
 immediately and decisively on what they get back for an answer?

 I don't want to speak for Spamhaus, but I suspect that they would be
 delighted to provide that response, particularly if it led to swift and
 effective action to make the problem(s) go away.  And while I don't
 always agree with their positions, I've *rarely* found mistakes in
 their research: they're thorough.  (So's Ron, by the way.)

 This isn't complicated.  This isn't expensive.  This doesn't require
 new technology or anything fancy.  It's basic due diligence.  Yet it
 clearly hasn't happened.  Why the hell not?

 We live in a time when abuse is epidemic.  It's costing us a fortune,
 and I don't just mean in financial terms, although certainly that's
 bad enough all by itself.  But it doesn't just magically fall out of
 the sky and land on our servers or routers, or at port 25 on our
 mail servers.   It comes from *somewhere*, and it does so on *somebody's*
 watch.  And when it does so on a chronic and systemic basis, surely
 it is reasonable to ask questions like Why, if we can so clearly see
 it arriving at our operation, can they not see it leaving theirs?
 or Why aren't people paying attention to the primary/most useful
 sources of information about their own operations?

 So it's (well past) time to stop giving people a pass for looking the
 other way or failing to look at all.  It's my, your, and everyone's
 professional responsibility to do everything we possibly can to prevent
 the networks, hosts, and resources we run from being part of the problem.
 So yeah: incompetence and negligence are the best words I can find
 to describe failure to do that.  What would you call it?

 ---rsk




Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

2013-01-16 Thread Justin M. Streiner

On Wed, 16 Jan 2013, fredrik danerklint wrote:


From the article:

Faced with the shortage of IPv4 addresses and the failure of IPv6 to take 
off, British ISP PlusNet is testing carrier-grade network address translation 
CG-NAT, where potentially all the ISP's customers could be sharing one IP 
address, through a gateway. The move is controversial as it could make some 
Internet services fail, but PlusNet says it is inevitable, and only a test at 
this stage.


I would hope that PlusNet has valid, well-thought-out reasons for 
deploying CGN instead of IPv6.  Not knowing those, I can only jugde their 
position on its face: foolish and short-sighted.


To quote a NANOG veteran: I encourage my competitors to do this :)

jms



Re: Problem with email to Hawaiilink.net email

2013-01-16 Thread staticsafe
On 1/15/2013 19:19, david peahi wrote:
 Does anyone know of any problems in Hawaii with email or DNS problems?
 Sending from gmail.com and pacbell.net domains, I get:
 
 
 host mail.hawaiilink.net[24.43.223.114] said: 553
 5.1.8 emailaddr...@pacbell.net ... Domain of sender address
 emailaddr...@pacbell.net does not exist (in reply to MAIL FROM command)
 
 Regards,
 
 David
 
See thread on [outages] currently going on regarding outages happening
at the moment in Hawaii,
https://puck.nether.net/pipermail/outages/2013-January/005072.html

-- 
staticsafe
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
Please don't top post - http://goo.gl/YrmAb



Re: Notice: Fradulent RIPE ASNs

2013-01-16 Thread William Herrin
On Wed, Jan 16, 2013 at 10:54 AM, Rich Kulawiec r...@gsp.org wrote:
 On Wed, Jan 16, 2013 at 10:07:40AM -0500, Todd Underwood wrote:
 no one seriously believes that the RIPE NCC (which is managed by all
 of its members) is primarily distinguished by their incompetence and
 negligence.

 Really?  Then why, pray tell, haven't they made it a practice to routinely
 (let's say, once a month) ask the people over at Spamhaus: Hey folks, do
 you see anything wonky in the space we manage? and then act
 immediately and decisively on what they get back for an answer?

 I don't want to speak for Spamhaus, but I suspect that they would be
 delighted to provide that response, particularly if it led to swift and
 effective action to make the problem(s) go away.  And while I don't
 always agree with their positions, I've *rarely* found mistakes in
 their research: they're thorough.  (So's Ron, by the way.)

 This isn't complicated.  This isn't expensive.  This doesn't require
 new technology or anything fancy.  It's basic due diligence.  Yet it
 clearly hasn't happened.  Why the hell not?

Hi Rich,

Since this is NANOG, not a forum which represents Internet activities
on the Continent, perhaps a better set of questions would be:

1. Has SPAMHAUS attempted to feed relevant portions of their knowledge
into ARIN's reporting system for fraudulent registrations and,

2. Understanding that ARIN can only deal with fraudulent
registrations, not any other kind of bad-actor behavior, are there
improvements to ARIN's process which would help SPAMHAUS and similar
organizations feed ARIN actionable knowledge?

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004



Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

2013-01-16 Thread Daniel Ankers
On 16 January 2013 16:31, Justin M. Streiner strei...@cluebyfour.orgwrote:

 On Wed, 16 Jan 2013, fredrik danerklint wrote:

  From the article:

 Faced with the shortage of IPv4 addresses and the failure of IPv6 to
 take off, British ISP PlusNet is testing carrier-grade network address
 translation CG-NAT, where potentially all the ISP's customers could be
 sharing one IP address, through a gateway. The move is controversial as it
 could make some Internet services fail, but PlusNet says it is inevitable,
 and only a test at this stage.


 I would hope that PlusNet has valid, well-thought-out reasons for
 deploying CGN instead of IPv6.  Not knowing those, I can only jugde their
 position on its face: foolish and short-sighted.


A lot of ISPs have customers who are foolish and short-sighted (or
customers unable to move away from suppliers who are foolish and
short-sighted,) and need to support those customers.  I'd be very surprised
if this move isn't in addition to IPv6 support, even though the article
reads as though it is instead of IPv6 support.

In other words, it makes sense to be able to support customers who won't
move to IPv6 in the short-medium term, even though in the long term it's
inevitable.

Dan


Re: Notice: Fradulent RIPE ASNs

2013-01-16 Thread Suresh Ramasubramanian
There have been previous incidents in the ARIN region .. Nothing on the
grand scale of what Ron is describing, and just saying, Arin does liaise
with the Anti spam world rather better than this.

On Wednesday, January 16, 2013, William Herrin wrote:

 Hi Rich,

 Since this is NANOG, not a forum which represents Internet activities
 on the Continent, perhaps a better set of questions would be:

 1. Has SPAMHAUS attempted to feed relevant portions of their knowledge
 into ARIN's reporting system for fraudulent registrations and,

 2. Understanding that ARIN can only deal with fraudulent
 registrations, not any other kind of bad-actor behavior, are there
 improvements to ARIN's process which would help SPAMHAUS and similar
 organizations feed ARIN actionable knowledge?




-- 
--srs (iPad)


Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

2013-01-16 Thread William Herrin
On Wed, Jan 16, 2013 at 11:31 AM, Justin M. Streiner
strei...@cluebyfour.org wrote:
 I would hope that PlusNet has valid, well-thought-out reasons for deploying
 CGN instead of IPv6.  Not knowing those, I can only jugde their position on
 its face: foolish and short-sighted.

Move along, nothing to see here. Barring a few fanatics, everyone here
has known for several years now that CGN would be required for
continuing IPv4 support regardless of the progress of IPv6.

If you spin it right, it's a Free network-based firewall to be
installed next month. Opt out here if you don't want it. And the
fewer than 1 in 10 folks who opt out really aren't a problem.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004



Re: Notice: Fradulent RIPE ASNs

2013-01-16 Thread Carlos M. Martinez
Please, please someone go to http://meemsy.com/videos/add/24 and create
'Hitler reacts to the fraudulent Romanian ASNs'

After that we can move on.

:=)

~C.

On 1/16/13 2:01 PM, Matthew Petach wrote:
 I'll bet Hitler would have used his real name on the whois entries.
 
 There.  Now I think we're done.
 
 Matt
  On Jan 16, 2013 7:09 AM, Todd Underwood toddun...@gmail.com wrote:
 
 I do not understand why you're so adamant about sending this information
 to an organization primarily distinguished by its incompetence and
 negligence.  If they were actually DOING THEIR JOBS in even minimally
 diligent fashion, then Ron wouldn't needed to write that note or do
 the research behind it, because this wouldn't be happening.

 this kind of mostly unfounded vitriole is silly and damages your
 credibility.

 no one seriously believes that the RIPE NCC (which is managed by all
 of its members) is primarily distinguished by their incompetence and
 negligence.

 i believe this conversation has now gotten to the plonk stage.  can
 someone compare them to hitler so that we can move on?

 cheers,

 t





Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

2013-01-16 Thread Mikael Abrahamsson

On Wed, 16 Jan 2013, Daniel Ankers wrote:

In other words, it makes sense to be able to support customers who won't 
move to IPv6 in the short-medium term, even though in the long term it's 
inevitable.


I agree, IPv6 isn't an answer to we're out of IPv4 addresses right now. 
So CGNAT44 i combination with IPv6 rollout makes perfect sense.


--
Mikael Abrahamssonemail: swm...@swm.pp.se



Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

2013-01-16 Thread fredrik danerklint

I would hope that PlusNet has valid, well-thought-out reasons for deploying
CGN instead of IPv6.  Not knowing those, I can only jugde their position on
its face: foolish and short-sighted.


Move along, nothing to see here. Barring a few fanatics, everyone here
has known for several years now that CGN would be required for
continuing IPv4 support regardless of the progress of IPv6.

If you spin it right, it's a Free network-based firewall to be
installed next month. Opt out here if you don't want it. And the
fewer than 1 in 10 folks who opt out really aren't a problem.


Even tough you have very good arguments, my suggestion would be to have 
a class A network (I got that right, right?) for all the users and only 
having 6rd as service on that network.


--
//fredan

http://tlmc.fredan.se



Re: Dreamhost hijacking my prefix...

2013-01-16 Thread john
On 1/11/13 8:28 PM, Scott Weeks wrote:
 
 
 --- andree+na...@toonk.nl wrote:
 From: Andree Toonk andree+na...@toonk.nl
 
 Here's some more data showing an announcement for
 150.182.208.0/20 originated by 26347
 
 http://www.ris.ripe.net/mt/rissearch-result.html?aspref=150.182.208.0%2F20preftype=EMATCHrrc_id=1000peer=ALLstartday=20130111starthour=00startmin=00startsec=00endday=20130111endhour=19endmin=16endsec=26outype=htmlsubmit=Search.submit=type
 -
 
 
 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...
 
 scott
 
 
Hello Scott,

I took a look at this site and unfortunately the use of cookies is very
ingrained into the code.  Removing the requirement breaks all
functionality of www.ris.ripe.net and changing the functionality would
require a rewrite of the site.  Our intention is that
http://stat.ripe.net/ will replace all functionality currently under
www.ris.ripe.net.  If RIPEstat doesn't provide the functionality you are
looking for, please request it by emailing us at s...@ripe.net.

Regards
John




Re: Notice: Fradulent RIPE ASNs

2013-01-16 Thread Steven G. Huter
ni lar has requested to add someone, and so has kanchana, so i think our 
group reservation is full


will try to check this morning to confirm

On Wed, 16 Jan 2013, Matthew Petach wrote:


I'll bet Hitler would have used his real name on the whois entries.

There.  Now I think we're done.

Matt
On Jan 16, 2013 7:09 AM, Todd Underwood toddun...@gmail.com wrote:


I do not understand why you're so adamant about sending this information
to an organization primarily distinguished by its incompetence and
negligence.  If they were actually DOING THEIR JOBS in even minimally
diligent fashion, then Ron wouldn't needed to write that note or do
the research behind it, because this wouldn't be happening.


this kind of mostly unfounded vitriole is silly and damages your
credibility.

no one seriously believes that the RIPE NCC (which is managed by all
of its members) is primarily distinguished by their incompetence and
negligence.

i believe this conversation has now gotten to the plonk stage.  can
someone compare them to hitler so that we can move on?

cheers,

t








Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

2013-01-16 Thread William Herrin
On Wed, Jan 16, 2013 at 12:09 PM, fredrik danerklint
fredan-na...@fredan.se wrote:
 Barring a few fanatics, everyone here
 has known for several years now that CGN would be required for
 continuing IPv4 support regardless of the progress of IPv6.

 If you spin it right, it's a Free network-based firewall to be
 installed next month. Opt out here if you don't want it. And the
 fewer than 1 in 10 folks who opt out really aren't a problem.

 Even tough you have very good arguments, my suggestion would be to have a
 class A network (I got that right, right?) for all the users and only having
 6rd as service on that network.

ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN
use. See RFC 6598. This makes it possible to implement a CGN while
conflicting with neither the user's RFC1918 activity nor the general
Internet's use of assigned addresses. Hijacking a /8 somewhere instead
is probably not a great move.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004



Re: RIPE cookies [was]: Dreamhost hijacking my prefix...

2013-01-16 Thread Scott Weeks
--- jb...@ripe.net wrote:
From: john jb...@ripe.net
- On 1/11/13 8:28 PM, Scott Weeks 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...
-

I took a look at this site and unfortunately the use of cookies is very
ingrained into the code.  Removing the requirement breaks all
functionality of www.ris.ripe.net and changing the functionality would
require a rewrite of the site.  Our intention is that
http://stat.ripe.net/ will replace all functionality currently under
www.ris.ripe.net.  If RIPEstat doesn't provide the functionality you are
looking for, please request it by emailing us at s...@ripe.net.
--


Hi john,

First, thank you for responding.  Second, what a bummer that RIPE's
code was written that way in the first place.  If it's done that 
way in stat.ripe.net as well, I (and others who are security-minded) 
will never get to use your site.  Maybe give brian at merit a holler 
before writing stat.ripe.net in such a way that one MUST allow cookies 
just to look at the site.  Maybe it's too late already. :-(  I haven't 
looked, yet...

scott



Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)

2013-01-16 Thread Shrdlu

On 1/16/2013 9:40 AM, john wrote:


I took a look at this site and unfortunately the use of cookies is very
ingrained into the code.  Removing the requirement breaks all
functionality of www.ris.ripe.net and changing the functionality would
require a rewrite of the site.


Sooner or later, you'll get to a place where you consider a major 
update, and perhaps then you'll consider emulating NANOG's site. However...



Our intention is that http://stat.ripe.net/ will replace all
functionality currently under www.ris.ripe.net. If RIPEstat doesn't
provide the functionality you are looking for, please request it by
emailing us at s...@ripe.net.


I was curious, and I went to look at it. Please consider using some 
other color than lovely amber yellow you've chosen. It's very pretty, 
and exhausting to look at for any length of time. I'm a HUGE fan of gray 
scales, and of text. I see that you want a cookie when I want to look at 
one of the videos, but blocking it doesn't hurt me. Here's where you did 
something right. The video plays on my (pretty old) Firefox, which has 
no Flash (hooray!).


The cookie stays around for a YEAR (if I let it), and has the following 
stuff:


Name: stat-csrftoken
Content: 7f12a95b8e274ab940287407a14fc348
Host: stat.ripe.net
Path: /
Send For: Any type of connection
Expires: Wednesday, January 15, 2014 11:29:34 AM

To your credit, you only ask once, but you ought to ask zero times.

The site's not bad, but please consider changing the yellow to black. 
Less beauty, more utility.


--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
  Brian W. Kernighan



Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

2013-01-16 Thread fredrik danerklint

Even tough you have very good arguments, my suggestion would be to have a
class A network (I got that right, right?) for all the users and only having
6rd as service on that network.


ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN
use. See RFC 6598. This makes it possible to implement a CGN while
conflicting with neither the user's RFC1918 activity nor the general
Internet's use of assigned addresses. Hijacking a /8 somewhere instead
is probably not a great move.


Ok.

If I have calculated the netmasks right that would mean to set aside:

2001:0DB8:6440::/42

for the use of 6rd service:

2001:0DB8:6440:::/64 = 100.64.0.0

2001:0DB8:647F:::/64 = 100.127.255.255

--
//fredan

http://tlmc.fredan.se



Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

2013-01-16 Thread Sander Steffann
Hi,

 If I have calculated the netmasks right that would mean to set aside:
 
 2001:0DB8:6440::/42
 
 for the use of 6rd service:
 
 2001:0DB8:6440:::/64 = 100.64.0.0
 
 2001:0DB8:647F:::/64 = 100.127.255.255

You probably should add a few extra bits for subnetting behind the 6rd CPE. 
Delegating one /64 would be annoying as more and more CPEs have separate 
home/office/guest networks. Giving a /56 to each customer would be good and 
would only take an IPv6 /34 to map from 100.64.0.0/10. That is a quarter of the 
smallest IPv6 allocation an ISP can get.

ISPs can get plenty of IPv6 address space these days if they need it. Smaller 
ISPs don't need to map the whole 100.64.0.0/10, they could just start with 
100.64.0.0/16 for example, which would only take a /40 to give every customer a 
/56. More blocks can always be added to the 6rd setup later.

Cheers,
Sander




Intermittent incorrect DNS resolution?

2013-01-16 Thread Erik Levinson

Hi everyone,

I'm having an unusual DNS problem and would appreciate feedback.

For the zones in question, primary DNS is provided by GoDaddy and
secondary DNS by DNS Made Easy. Over a week ago we made changes to
several A records (including wildcards on two different zones), all
already having a TTL no greater than one hour.

The new IPs on those A records have taken many millions of requests
since the changes. Occasionally, a small amount of traffic appears at
the old IPs that those A records had. This is HTTP traffic. Packet
captures of this traffic show various Host headers.

Attempting to resolve those various Host headers from various networks
in Canada against various random private and public resolvers and
against the authoritative NSs all yield correct results (i.e. new IPs).

However, both GoDaddy and DNS Made Easy use anycast, which makes it less 
likely that I can see the entire picture of what's happening.


I suspect that somewhere, one of their servers has the wrong data, or
some resolver is misbehaving, but based on the 
pattern/traffic/volume/randomization of hostnames, the resolver theory 
is less likely. I haven't analyzed the source IPs yet to see if they're 
in a particular set of countries.


I've opened a ticket with DNS Made Easy and they replied very quickly
suggesting the problem is not with them. I've opened a ticket with
GoDaddy and...well, it's GoDaddy, so I don't expect much (no response yet).

Any ideas? Can folks try resolving eriktest.uberflip.com and post
here with details only if it resolves to an IP starting with 76.9 (old 
IPs)?



Thanks

Erik



Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread George Herbert
On Wed, Jan 16, 2013 at 2:00 PM, Erik Levinson
erik.levin...@uberflip.com wrote:
 Hi everyone,

 I'm having an unusual DNS problem and would appreciate feedback.

 For the zones in question, primary DNS is provided by GoDaddy and
 secondary DNS by DNS Made Easy. Over a week ago we made changes to
 several A records (including wildcards on two different zones), all
 already having a TTL no greater than one hour.

 The new IPs on those A records have taken many millions of requests
 since the changes. Occasionally, a small amount of traffic appears at
 the old IPs that those A records had. This is HTTP traffic. Packet
 captures of this traffic show various Host headers.

 Attempting to resolve those various Host headers from various networks
 in Canada against various random private and public resolvers and
 against the authoritative NSs all yield correct results (i.e. new IPs).

 However, both GoDaddy and DNS Made Easy use anycast, which makes it less
 likely that I can see the entire picture of what's happening.

 I suspect that somewhere, one of their servers has the wrong data, or
 some resolver is misbehaving, but based on the
 pattern/traffic/volume/randomization of hostnames, the resolver theory is
 less likely. I haven't analyzed the source IPs yet to see if they're in a
 particular set of countries.

 I've opened a ticket with DNS Made Easy and they replied very quickly
 suggesting the problem is not with them. I've opened a ticket with
 GoDaddy and...well, it's GoDaddy, so I don't expect much (no response yet).

 Any ideas? Can folks try resolving eriktest.uberflip.com and post
 here with details only if it resolves to an IP starting with 76.9 (old IPs)?


 Thanks

 Erik


The other likely cause of this is local cacheing nameservers somewhere
at some ISP or major site, that do not respect TTL values for some
reason.

This is sadly a common problem - not statistically, most nameservers
do the right thing, but if you run big sites and flip things, there's
always a long tail of people whose nameservers just didn't get it.



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



Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread Christopher Morrow
On Wed, Jan 16, 2013 at 5:00 PM, Erik Levinson
erik.levin...@uberflip.com wrote:
 Any ideas? Can folks try resolving eriktest.uberflip.com and post
 here with details only if it resolves to an IP starting with 76.9 (old IPs)?



 for d in $(seq 1 1000); do dig @pdns01.domaincontrol.com.
eriktest.uberflip.com  /tmp/tst ; dig @pdns02.domaincontrol.com.
eriktest.uberflip.com  /tmp/tst ; dig @ns5.dnsmadeeasy.com.
eriktest.uberflip.com  /tmp/tst ; dig @ns6.dnsmadeeasy.com.
eriktest.uberflip.com  /tmp/tst; dig @ns7.dnsmadeeasy.com.
eriktest.uberflip.com  /tmp/tst ; done

you tried something like this already I assume?



Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread RijilV
Also client programs don't always honor TTLs either.  For example, JAVA
defaults to ignoring TTLs and holding IPs forever.

*networkaddress.cache.ttl (default: -1)*
Indicates the caching policy for successful name lookups from the name
service. The value is specified as as integer to indicate the number of
seconds to cache the successful lookup. A value of -1 indicates cache
forever.

Depending on who your clients are, your milage may vary.

.r'


On 16 January 2013 14:13, George Herbert george.herb...@gmail.com wrote:

 On Wed, Jan 16, 2013 at 2:00 PM, Erik Levinson
 erik.levin...@uberflip.com wrote:
  Hi everyone,
 
  I'm having an unusual DNS problem and would appreciate feedback.
 
  For the zones in question, primary DNS is provided by GoDaddy and
  secondary DNS by DNS Made Easy. Over a week ago we made changes to
  several A records (including wildcards on two different zones), all
  already having a TTL no greater than one hour.
 
  The new IPs on those A records have taken many millions of requests
  since the changes. Occasionally, a small amount of traffic appears at
  the old IPs that those A records had. This is HTTP traffic. Packet
  captures of this traffic show various Host headers.
 
  Attempting to resolve those various Host headers from various networks
  in Canada against various random private and public resolvers and
  against the authoritative NSs all yield correct results (i.e. new IPs).
 
  However, both GoDaddy and DNS Made Easy use anycast, which makes it less
  likely that I can see the entire picture of what's happening.
 
  I suspect that somewhere, one of their servers has the wrong data, or
  some resolver is misbehaving, but based on the
  pattern/traffic/volume/randomization of hostnames, the resolver theory is
  less likely. I haven't analyzed the source IPs yet to see if they're in a
  particular set of countries.
 
  I've opened a ticket with DNS Made Easy and they replied very quickly
  suggesting the problem is not with them. I've opened a ticket with
  GoDaddy and...well, it's GoDaddy, so I don't expect much (no response
 yet).
 
  Any ideas? Can folks try resolving eriktest.uberflip.com and post
  here with details only if it resolves to an IP starting with 76.9 (old
 IPs)?
 
 
  Thanks
 
  Erik


 The other likely cause of this is local cacheing nameservers somewhere
 at some ISP or major site, that do not respect TTL values for some
 reason.

 This is sadly a common problem - not statistically, most nameservers
 do the right thing, but if you run big sites and flip things, there's
 always a long tail of people whose nameservers just didn't get it.



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




Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

2013-01-16 Thread William Herrin
On Wed, Jan 16, 2013 at 2:53 PM, fredrik danerklint
fredan-na...@fredan.se wrote:
 ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN
 use. See RFC 6598. This makes it possible to implement a CGN while
 conflicting with neither the user's RFC1918 activity nor the general
 Internet's use of assigned addresses. Hijacking a /8 somewhere instead
 is probably not a great move.

 If I have calculated the netmasks right that would mean to set aside:

 2001:0DB8:6440::/42

 for the use of 6rd service:

 2001:0DB8:6440:::/64 = 100.64.0.0
 
 2001:0DB8:647F:::/64 = 100.127.255.255

Sander already touched on this, but when implementing 6rd you'll want
*at least* 4 bits on the subnetting side of the IPv6 block associated
with each IPv4 address and you'll want that netmask to be evenly
divisible by 4. A /60 or a /56, not a /64.

In IPv4 your customer has a DSL router, potentially with distinct
wired and wireless LANs running different RFC1918 address blocks. In
IPv6 each of those LANs will consume a /64, so he'll need more than
one.

Selecting a netmask evenly divisible by 4 has two major benefits.
First, it exactly matches one character in the written address. The
customer doesn't have ...:ABC4:* through ...:ABC7:*, he has
...:ABC*::. Second, each delegable RDNS zone takes up the same 4 bits
so the assignment will be right on an RNDS zone boundary.


 Even tough you have very good arguments, my suggestion would be to have a
 class A network (I got that right, right?) for all the users and only having
 6rd as service on that network.

I assume you meant this a little differently than what you wrote here.
It wouldn't make any kind of sense to stand up a private IPv4 network
with no IPv4 Internet connection in order to facilitate IPv6 via a 6rd
deployment. For one thing it'd be a Rube Goldberg machine. For
another, I suspect you'd find it very challenging to acquire a
threshold number of paying customers for an IPv6-only network at the
moment.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004



Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread Christopher Morrow
On Wed, Jan 16, 2013 at 5:24 PM, Erik Levinson
erik.levin...@uberflip.com wrote:
 Yes, though I tried way less than 1000 in the loop.


:)

given a large list of recursives you could even test resolution
through a bunch of recursive servers...



Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread Erik Levinson

Yes, though I tried way less than 1000 in the loop.

On 16/01/13 05:13 PM, Christopher Morrow wrote:

On Wed, Jan 16, 2013 at 5:00 PM, Erik Levinson
erik.levin...@uberflip.com  wrote:

Any ideas? Can folks try resolving eriktest.uberflip.com and post
here with details only if it resolves to an IP starting with 76.9 (old IPs)?




  for d in $(seq 1 1000); do dig @pdns01.domaincontrol.com.
eriktest.uberflip.com  /tmp/tst ; dig @pdns02.domaincontrol.com.
eriktest.uberflip.com  /tmp/tst ; dig @ns5.dnsmadeeasy.com.
eriktest.uberflip.com  /tmp/tst ; dig @ns6.dnsmadeeasy.com.
eriktest.uberflip.com  /tmp/tst; dig @ns7.dnsmadeeasy.com.
eriktest.uberflip.com  /tmp/tst ; done

you tried something like this already I assume?






Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread Erik Levinson

Good point.

While I haven't checked the distribution of source IPs yet, I briefly 
grepped for the User-Agent headers in the tcpdump output, and there's a 
higher than expected bot presence, particularly Baidu.


That said, there are also normal UAs (whatever that means, with every 
device/software pretending to be something else these days).


On 16/01/13 05:20 PM, RijilV wrote:

Also client programs don't always honor TTLs either.  For example, JAVA
defaults to ignoring TTLs and holding IPs forever.

*networkaddress.cache.ttl (default: -1)*
Indicates the caching policy for successful name lookups from the name
service. The value is specified as as integer to indicate the number of
seconds to cache the successful lookup. A value of -1 indicates cache
forever.

Depending on who your clients are, your milage may vary.

.r'






Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread Erik Levinson
True...I did try 4.2.2.2 / 8.8.8.8 and some local ones here. All looked 
fine.


With anycast / DB and other backend clusters / load balancing / whatever 
else behind the scenes, it's hard to get a good idea of what's actually 
happening.


Might be stuck with running this infra for a while longer and seeing if 
the traffic disappears eventually.


On 16/01/13 05:25 PM, Christopher Morrow wrote:

On Wed, Jan 16, 2013 at 5:24 PM, Erik Levinson
erik.levin...@uberflip.com  wrote:

Yes, though I tried way less than 1000 in the loop.



:)

given a large list of recursives you could even test resolution
through a bunch of recursive servers...




Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread William Herrin
On Wed, Jan 16, 2013 at 5:00 PM, Erik Levinson
erik.levin...@uberflip.com wrote:
 I suspect that somewhere, one of their servers has the wrong data, or
 some resolver is misbehaving, but based on the
 pattern/traffic/volume/randomization of hostnames, the resolver theory is
 less likely. I haven't analyzed the source IPs yet to see if they're in a
 particular set of countries.

Hi Erik,

Look up DNS pinning. I can't rule out the possibility of a faulty
DNS server but it's far more likely your customers' web browsers are
simply ignoring the DNS TTL. Malfunctioning as designed. If you keep
it live, you'll notice a falling trickle of traffic to the old address
for the next year or so.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004



Anyone from google networking on this list?

2013-01-16 Thread tglassey
If there is anyone from Google Networking here on the list can you 
contact me offlist please.  I want to talk about 60 Hudson.


Todd Glassey

--
Regards TSG
Ex-Cruce-Leo

//Confidential Mailing - Please destroy this if you are not the intended 
recipient.




Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread Jean-Francois Mezei
Consider the possibility that some end users (or even corp networks) may
have hardcoded your hosts' translation into their hosts files or perhaps
corporate proxy firewalls that allow access onto to whitelisted web sites.

They will continue to point to the old IP addresses until you shutdown
the service and they call you to inquire why *you* broke your system :-)

If this HTTP service has a GUI (aka: web page versus credit card
transactions), you should put up a warning on the web page whenever it
is being accessed via the old IP address.



Netflow Nfsen Server Hardware

2013-01-16 Thread Tim Calvin
We are looking to purchase a new server for Netflow exports. This will mainly 
be used to evaluate our transit bandwidth for potential peering opportunities. 
A long data retention is not a high priority.

Our combined transit bandwidth is around 6 Gbps and increasing all the time.

Looking to get a sanity check on the server hardware required. We will be using 
Nfsen as the collector.

Would one of the below configurations be okay to handle such as task? If not, 
does anyone have any other recommendations.

Thanks in advance.

Tim

PowerEdge R610 -

2x Intel E5540, 2.53GHz Quad Core Processor

32GB RAM

2x 300gb 10k 2.5 SAS HDD

PERC6i RAID Controller

iDRAC6 Enterprise

Redundant Power Supply

ReadyRails


PowerEdge R610 -

2x Intel E5540, 2.53GHz Quad Core Processor

64GB RAM

6x 300gb 10k 2.5 SAS HDD

PERC6i RAID Controller

iDRAC6 Enterprise

Redundant Power Supply

ReadyRails






Symantec / Message Labs contact?

2013-01-16 Thread Robert Glover

Hello,

We are having a really hard time getting a hold of Symantec / Message 
Labs regarding one of our mail servers getting a Connection Refused 
when trying to send to any domains hosted with Symantec / Message Labs.


Can someone please contact me?

Sincerely,
Bobby Glover
Director of Information Services
SVI Incorporated



DNS resolver addresses for Sprint PCS/3G/4G

2013-01-16 Thread Jay Ashworth
I've noticed, for quite some time, that there seems to be a specific category
of slow that I see in using apps on my HTC Supersonic/Sprint EVO, on both
their 3G and 4G networks, and I wonder if it isn't because the defined
resolvers are 8.8.4.4 and 8.8.8.8, which aren't *on* Sprint's networks.

Does anyone have, in their magic bag of tricks, IP addresses for resolvers
that *are* native to that network, that they wouldn't mind whispering in my
ear?

I don't suppose Android's smart enough to swap that file around when the
IP core notices the uplink has changed? (Yes, I know, that's properly a 
question for XDA-Devel...)

Offlist is fine.  Yes, I owe the list summaries on a couple earlier 
questions; I still have the details to write from.  :-}

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth  Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274



Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread Jay Ashworth
- Original Message -
 From: Erik Levinson erik.levin...@uberflip.com

 I'm having an unusual DNS problem and would appreciate feedback.
 
 For the zones in question, primary DNS is provided by GoDaddy and
 secondary DNS by DNS Made Easy. Over a week ago we made changes to
 several A records (including wildcards on two different zones), all
 already having a TTL no greater than one hour.
 
 The new IPs on those A records have taken many millions of requests
 since the changes. Occasionally, a small amount of traffic appears at
 the old IPs that those A records had. This is HTTP traffic. Packet
 captures of this traffic show various Host headers.

I'm a touch surprised to find that no one has mentioned the facet of
Windows OSs that requires ipconfig /flushdns in some such circumstances...

Not only may *browsers* be caching DNS lookups without regard to TTLs,
the *OS* might be doing it to you too, in circumstances I was never quite
able to get a handle on.

XP was known to do this, as late as SP3; I'm not sure about V or 7.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth  Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274



Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

2013-01-16 Thread Stephen D. Strowes

On 16/01/2013 08:31, Justin M. Streiner wrote:

On Wed, 16 Jan 2013, fredrik danerklint wrote:


From the article:

Faced with the shortage of IPv4 addresses and the failure of IPv6 to
take off, British ISP PlusNet is testing carrier-grade network address
translation CG-NAT, where potentially all the ISP's customers could be
sharing one IP address, through a gateway. The move is controversial
as it could make some Internet services fail, but PlusNet says it is
inevitable, and only a test at this stage.


I would hope that PlusNet has valid, well-thought-out reasons for
deploying CGN instead of IPv6.  Not knowing those, I can only jugde
their position on its face: foolish and short-sighted.


Apparently they aren't _totally_ blind to v6, but it sounds like it's 
been put in the mystery when we have a spare moment! bin:


http://community.plus.net/forum/index.php/topic,106125.0.html



S.



How are operators using IRR?

2013-01-16 Thread ML

How are operators using the data available in the various IRRs?

Using an example:

AS1 is your customer
AS1 has AS2, AS3 and AS4 described as customers in an IRR
Also assume AS2 has IRR data describing AS1000 and AS2000 as it's customers.

Are operators building AS path regexes such as the following 
automatically from IRR and applying that to your BGP sessions?



AS1{1,}
AS1{1,} AS2{1,}
AS1{1,} AS3{1,}
AS1{1,} AS2{1,} AS1000{1,}
AS1{1,} AS2{1,} AS2000{1,}



I would imagine most operators that are building policy from IRR are 
building prefix lists to limit what they are accepting.  Is this being 
paired with some AS path filtering?



Are operators just traversing an AS-SET as far as it will go and 
building prefix lists to represent all intended prefixes to be heard on 
a session regardless of who originates them? Is the possibility of 
AS1000 hijacking AS2000 prefixes towards AS2 a problem you as the 
upstream to AS1 need to consider? (Last question assumes AS2 made a 
mistake and wasn't filtering properly on it's own customers and AS1 is 
just accepting all prefixes under the cone of AS2)


Thanks



GPS attack vector

2013-01-16 Thread Jay Ashworth
Do you use GPS to provide any mission critical services (like time of day)
in your network?

Have you already see this? (I hadn't)
  
  
http://arstechnica.com/security/2012/12/how-to-bring-down-mission-critical-gps-networks-with-2500/

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth  Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274



Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread Robert Bonomi
 From nanog-bounces+bonomi=mail.r-bonomi@nanog.org  Wed Jan 16 18:21:21 
 2013
 Date: Wed, 16 Jan 2013 19:16:57 -0500 (EST)
 From: Jay Ashworth j...@baylink.com
 To: NANOG nanog@nanog.org
 Subject: Re: Intermittent incorrect DNS resolution?

 I'm a touch surprised to find that no one has mentioned the facet of 
 Windows OSs that requires ipconfig /flushdns in some such 
 circumstances...

Winbloze has to be rebooted frequently enough that this is rarely an issue.
wry grin






Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread Joe Abley

On 2013-01-16, at 14:33, Erik Levinson erik.levin...@uberflip.com wrote:

 True...I did try 4.2.2.2 / 8.8.8.8 and some local ones here. All looked fine.

I sent queries from 270+ different locations for the domains you mentioned 
off-list and I didn't see any inconsistencies. The persistent 
host-caching/browser-caching theories seem like your best bet (or my 270+ 
locations weren't sufficiently diverse to catch a stale zone being served by an 
anycast authority server).


Joe




Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

2013-01-16 Thread Mark Andrews

In message 50f70524.4020...@fredan.se, fredrik danerklint writes:
  Even tough you have very good arguments, my suggestion would be to have a
  class A network (I got that right, right?) for all the users and only havi
 ng
  6rd as service on that network.
 
  ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN
  use. See RFC 6598. This makes it possible to implement a CGN while
  conflicting with neither the user's RFC1918 activity nor the general
  Internet's use of assigned addresses. Hijacking a /8 somewhere instead
  is probably not a great move.
 
 Ok.
 
 If I have calculated the netmasks right that would mean to set aside:
 
 2001:0DB8:6440::/42
 
 for the use of 6rd service:
 
 2001:0DB8:6440:::/64 = 100.64.0.0
 
 2001:0DB8:647F:::/64 = 100.127.255.255

No.  With 6rd you DROP the top 10 bits and you give every customer
a /56. And you can repeat the exercise 4 times within a /32.

/etc/dhcpd.conf:
subnet 100.64.0.0 netmask 255.240.0.0 {
range 100.64.0.2 100.64.255.254;
router 100.64.0.1;
option 6rd 10 34 2001:DB8:: 2001:DB8::1;
}
subnet 100.64.0.0 netmask 255.240.0.0 {
range 100.64.0.2 100.64.255.254;
router 100.64.0.1;
option 6rd 10 34 2001:DB8:4000: 2001:DB8:4000:1;
}
subnet 100.64.0.0 netmask 255.240.0.0 {
range 100.64.0.2 100.64.255.254;
router 100.64.0.1;
option 6rd 10 34 2001:DB8:8000: 2001:DB8:8000:1;
}
subnet 100.64.0.0 netmask 255.240.0.0 {
range 100.64.0.2 100.64.255.254;
router 100.64.0.1;
option 6rd 10 34 2001:DB8:c000: 2001:DB8:C000:1;
}

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



Re: DNS resolver addresses for Sprint PCS/3G/4G

2013-01-16 Thread Christopher Morrow
On Wed, Jan 16, 2013 at 7:13 PM, Jay Ashworth j...@baylink.com wrote:
 I've noticed, for quite some time, that there seems to be a specific category
 of slow that I see in using apps on my HTC Supersonic/Sprint EVO, on both
 their 3G and 4G networks, and I wonder if it isn't because the defined
 resolvers are 8.8.4.4 and 8.8.8.8, which aren't *on* Sprint's networks.


doesn't sprint intercept all udp/53 on their cellular network?



Re: Intermittent incorrect DNS resolution?

2013-01-16 Thread Erik Levinson
Thanks Joe and thanks everyone else for the on and off-list replies. Quite 
insightful.

I think we've reached the consensus that the problem is the ignoring of TTLs as 
opposed to misbehaving/stale authoritative servers. So for now I shall wait.

To give an idea of the scale of the problem right now, I'm getting thousands of 
requests per minute to a new IP vs. about two requests per minute on the 
equivalent old IP, with over 60% of the latter being Baidu, but also a bit of 
Googlebot and other random bot and non-bot UAs. 

Perhaps next week I'll unbind some old IPs for a few minutes to see what 
happens.

-Original Message-
From: Joe Abley jab...@hopcount.ca
Sent: Wednesday, January 16, 2013 8:57pm
To: Erik Levinson erik.levin...@uberflip.com
Cc: Christopher Morrow morrowc.li...@gmail.com, nanog@nanog.org
Subject: Re: Intermittent incorrect DNS resolution?


On 2013-01-16, at 14:33, Erik Levinson erik.levin...@uberflip.com wrote:

 True...I did try 4.2.2.2 / 8.8.8.8 and some local ones here. All looked fine.

I sent queries from 270+ different locations for the domains you mentioned 
off-list and I didn't see any inconsistencies. The persistent 
host-caching/browser-caching theories seem like your best bet (or my 270+ 
locations weren't sufficiently diverse to catch a stale zone being served by an 
anycast authority server).


Joe






Re: GPS attack vector

2013-01-16 Thread Tom Morris
This could also be a big show stopper for cellular and radio networks. Many
use a 10.000 MHz timebase distributed from a GPS disciplined local
oscillator for precise time and frequency synchronization. Without this
tight frequency stabilization from a GPS receiver, major drama will occur
on the borders between simulcasting repeater coverage areas, cell sites,
etc. Can anyone say Spaghetti mess? Ow my brain hurts.

Tom Morris, KG4CYX
Chairman, South Florida Tropical Hamboree
Mad Scientist, Miami Children's Museum

This message sent from a mobile device. Silly typos provided free of charge.
On Jan 16, 2013 8:08 PM, Jay Ashworth j...@baylink.com wrote:

 Do you use GPS to provide any mission critical services (like time of day)
 in your network?

 Have you already see this? (I hadn't)


 http://arstechnica.com/security/2012/12/how-to-bring-down-mission-critical-gps-networks-with-2500/

 Cheers,
 -- jra
 --
 Jay R. Ashworth  Baylink
 j...@baylink.com
 Designer The Things I Think   RFC
 2100
 Ashworth  Associates http://baylink.pitas.com 2000 Land
 Rover DII
 St Petersburg FL USA   #natog  +1 727 647
 1274




Re: DNS resolver addresses for Sprint PCS/3G/4G

2013-01-16 Thread Jay Ashworth
- Original Message -
 From: Christopher Morrow morrowc.li...@gmail.com

 On Wed, Jan 16, 2013 at 7:13 PM, Jay Ashworth j...@baylink.com wrote:
  I've noticed, for quite some time, that there seems to be a specific
  category
  of slow that I see in using apps on my HTC Supersonic/Sprint EVO, on
  both
  their 3G and 4G networks, and I wonder if it isn't because the
  defined
  resolvers are 8.8.4.4 and 8.8.8.8, which aren't *on* Sprint's
  networks.
 
 doesn't sprint intercept all udp/53 on their cellular network?

I don't know.  If they do, and said boxes are slow, that could explain it, 
too.  On the gripping hand, I am running Cyanogen, which isn't Sprint
specific, and that could explain it too.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth  Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274



Re: How are operators using IRR?

2013-01-16 Thread Dan Luedtke
Hi,

On Wed, 16 Jan 2013 19:55:44 -0500
ML m...@kenweb.org wrote:
 Is this
 being paired with some AS path filtering?

I am a huge fan of path filtering, but I have so very little paths to
maintain that I can say so. I guess most operators to not filter paths,
and building prefix lists is more or less current practice. Just from
what I have seen so far.

I asked about best practice about building filteers from IRR data a
while ago on NANOG, but there were not really an answer.

Cheers

Dan