Re: Aid in bypassing DNS issue

[William Warren]

Steve Bertrand wrote:
With the time I've had, I've tried my best to keep up with every 
message related to the current issue upon us related to DNS.


I am a small op, amongst many that I've met the last few days that may 
need assistance. I would like at least someone from a large operation 
to read what I've done, what my concerns are and what help might be 
provided for a scenario. If this is as big an issue as I feel it is, 
then perhaps those with resources can offer advice. If you will:


I've:

- exploited a legacy machine and hijacked the NS records
- set up an NS under the phony domain
- configured A,  and MX records for the hijacked domain (example.com)
- put in place a simple index.html file for a website
- configured email accounts
- you get the point...it all works

Then:

- made some slight changes to the latest (as of 1000hrs 080725) to the 
bailiwicked_domain.rb file to accept a new parameter 'RECURSCHK', that 
'fixes' the problem of a consistent domain showing up in the initial 
TXT check that from what I can tell tests for recursion: (#set 
recurschk wwNN.myDdomain.com).


It allows an attacker to set a lookup against a name/record that (s)he 
knows exists to get the ball rolling initially.


This generally ensures that the first check of the exploit will always 
pass (at least get an affirmative response, recursive or not), but 
come under the radar of an expecting IDS filter.


Once one host is exploited, then the rest of the names can be 
built/run against, well, anything of course ...unfinished, but in 
progress (I know Perl, never dealt with Ruby... a if/for/while would 
be handy).


I'd like to change the initial TXT to an A, but I don't think I quite 
understand the ramifications on the grand scheme of things within the 
scope of the exploit code, unless I were to focus more time on this. 
Technically, I'm now on holidays...


Anyway, if you've read this far,

- my true, core name servers are as vulnerable as any name server that 
has been patched


- I have clients connected to my 'upstream' (if you please)

- I configured a DNS server (implementation regardless) to "FORWARD 
ONLY" to the 'upstream' DNS servers


- We found that we are vulnerable, due to the fact that our 'upstream' 
DNS servers are vulnerable because they don't use port randomization


- we have wholesale business clients who are directly connected to 
this 'upstream', and retrieve DNS server addresses via DHCP from 
somewhere within their access layer


- the 'upstream' has made no confirmation regarding fixes after 
discussion


My question:

How to deal with this? It appears as though there are many that state 
"...the patching has gone down hill", but what to do when your hands 
are tied?




Is there a network operations centre capable, able and willing to 
publicly claim:


"if you've tried your best to tell your 'upstreams' (ISP) to fix the 
issue but they haven't, tell them to forget patching, ignore the work 
until the problem goes away, turn off recursion and forward to us, 
then patch later when you can afford some downtime"?


Thank you to everyone who has already put so much time and 
determination into this issue.


Steve

if your upstream has not fixed their issues yet..try forwarding to 
opendns which IS secured against this issue until your upstream fixes 
their servers.

Re: So why don't US citizens get this?

[Jorge Amodio]

Lets put aside for a moment the conspiracy theories of government
intervention and
the telcos evil doing, IMHO there is a simple reason why I don't have fiber
going
to my house: geography & economics.

Japan:
- area = 377,873 Km^2
- density = 337/Km^2
- pop = 127.5 mill

USA::
- area = 9,826,630 Km^2
- density = 31/Km^2
- pop = 304.7 mill

I belive there are just few major cities in the US that have a comparable or
higher
concentration of people like other large cities around the world.

I'd bet that if you deploy fiber in a given radious in a suburban area in
Japan you
may reach hundreds or thousands of potential customers, do the same a little
bit
north from where I live and you will reach a dozen guys, 50 cows and a
couple of
hundred chickens.

The US is so spread out that anything to do with transportation, being
people,
packages, or ip packets becomes quite costly.

Still I beleve is interesting to analyze why the US is lagging behind on
high speed
services.

My .02

Re: So why don't US citizens get this?

[Tom Vest]

Sort of makes one wonder how the US came to have ubiquitous roads, or  
power, or water distribution...


TV

On Jul 28, 2008, at 1:06 PM, Jorge Amodio wrote:


Lets put aside for a moment the conspiracy theories of government
intervention and
the telcos evil doing, IMHO there is a simple reason why I don't  
have fiber

going
to my house: geography & economics.

Japan:
- area = 377,873 Km^2
- density = 337/Km^2
- pop = 127.5 mill

USA::
- area = 9,826,630 Km^2
- density = 31/Km^2
- pop = 304.7 mill

I belive there are just few major cities in the US that have a  
comparable or

higher
concentration of people like other large cities around the world.

I'd bet that if you deploy fiber in a given radious in a suburban  
area in

Japan you
may reach hundreds or thousands of potential customers, do the same  
a little

bit
north from where I live and you will reach a dozen guys, 50 cows and a
couple of
hundred chickens.

The US is so spread out that anything to do with transportation, being
people,
packages, or ip packets becomes quite costly.

Still I beleve is interesting to analyze why the US is lagging  
behind on

high speed
services.

My .02

RE: Software router state of the art

[Darden, Patrick S.]

I have one of these (Imagestream T3 WAN adapter on an Imagestream router) for 
5+ years to back up my Cisco 7204 with a channelized T3 card.  I like the 
system, I like the card.

The other engineers in my office call it the "bling router".  Lots of gold 
chrome.  Pimped out.
--Patrick Darden


-Original Message-
From: Chris Adams [mailto:[EMAIL PROTECTED]

Once upon a time, Andrew D Kirch <[EMAIL PROTECTED]> said:
> there 
> are no Channelized T3/OC3 cards available for a PeeCee, which means you 
> still need to buy something from Cisco or Juniper.

First hit on a Google search:

http://www.imagestream.com/PCI_921-CDS.html

-- 
Chris Adams <[EMAIL PROTECTED]>

RE: [SPAM] Re: So why don't US citizens get this?

[Ray Plzak]

Government intervention - see Federal-Aid Highway Act, Rural Electrification 
Act, etc.

Ray

> -Original Message-
> From: Tom Vest [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 28, 2008 08:12
> To: Jorge Amodio
> Cc: nanog@nanog.org; [EMAIL PROTECTED]
> Subject: [SPAM] Re: So why don't US citizens get this?
>
> Sort of makes one wonder how the US came to have ubiquitous roads, or
> power, or water distribution...
>
> TV
>
> On Jul 28, 2008, at 1:06 PM, Jorge Amodio wrote:
>
> > Lets put aside for a moment the conspiracy theories of government
> > intervention and
> > the telcos evil doing, IMHO there is a simple reason why I don't
> > have fiber
> > going
> > to my house: geography & economics.
> >
> > Japan:
> > - area = 377,873 Km^2
> > - density = 337/Km^2
> > - pop = 127.5 mill
> >
> > USA::
> > - area = 9,826,630 Km^2
> > - density = 31/Km^2
> > - pop = 304.7 mill
> >
> > I belive there are just few major cities in the US that have a
> > comparable or
> > higher
> > concentration of people like other large cities around the world.
> >
> > I'd bet that if you deploy fiber in a given radious in a suburban
> > area in
> > Japan you
> > may reach hundreds or thousands of potential customers, do the same
> > a little
> > bit
> > north from where I live and you will reach a dozen guys, 50 cows and
> a
> > couple of
> > hundred chickens.
> >
> > The US is so spread out that anything to do with transportation,
> being
> > people,
> > packages, or ip packets becomes quite costly.
> >
> > Still I beleve is interesting to analyze why the US is lagging
> > behind on
> > high speed
> > services.
> >
> > My .02
>
>

Re: So why don't US citizens get this?

[Mikael Abrahamsson]

On Mon, 28 Jul 2008, Jorge Amodio wrote:

The US is so spread out that anything to do with transportation, being 
people, packages, or ip packets becomes quite costly.


Well then, let's take Sweden:

total: 449,964 sq km

This is slightly larger than california. We're 9 million.

I think at least 90% of Swedish households have access to at least ADSL 
2M/1M, and 95% of households have access to 384kbit/s UMTS mobile 
wireless.


ADSL 24M/1M is around USD50 per month, and should be available to a 
majority of households that live within technical range of COs. 100/10M 
ETTH is cheaper than ADSL 24M/1M and is available to somewhere around 
10-15% of households. Wierdly 100/10M ETTH is more common in the smaller 
cities because of need of competitive advantage, so more money is spent my 
real estate owners there to make sure broadband is available.


So, we're 9 million, Californa is what, 60million, on the same surface 
area. Is there any reason why california, in itself one of the largest 
economies in the world, seems to have problems delivering anything close 
to broadband to its inhabitants? So yes, the US must have structural 
problems here...


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

RE: So why don't US citizens get this?

[michael.dillon]

> I belive there are just few major cities in the US that have 
> a comparable or higher concentration of people like other 
> large cities around the world.

So then...
Why do major US cities not have fiber to the home yet?
Of course, here in the UK, FTTH won't go to London first:



There are already plans afoot to roll out FTT? darn near everywhere
here.

FTTC is far more interesting that FTTH, because it is not just a
technology buzzword driven idea, but one based on economics. It is
cheaper to rollout a nice high bandwidth fiber link to most
neighborhoods than to use that fat bundle of copper pairs. But, on the
other hand, it is cheaper to leave that last quarter-mile intact and
only build out fiber where new development is being done. 

So the real question that is much more interesting is as follows:
Does the US lag the world in high-speed fiber to the cabinet (FTTC)?

> I'd bet that if you deploy fiber in a given radious in a 
> suburban area in Japan you may reach hundreds or thousands of 
> potential customers, do the same a little bit north from 
> where I live and you will reach a dozen guys, 50 cows and a 
> couple of hundred chickens.

Don't let the copper thieves know where you live. They might show up one
nice Sunday morning bright and early to clean out the county's copper
wire. When I lived in British Columbia, Canada in teh 90's, I noticed
that our incumbent telco was well ahead of the game. They were putting
up fiber everywhere and then following up by cutting the fat copper
cables into sections for recovery of the metal. They even ran fibre into
remote valleys were there were only a few dozen families and it was
probably economically worthwhile because they recovered a higher dollar
value of copper from those remote locations.

> Still I beleve is interesting to analyze why the US is 
> lagging behind on high speed services.

Analysis paralysis perhaps? AKA bipartisan politics.

--Michael Dillon

Re: So why don't US citizens get this?

[Michal Krsek]

The US is so spread out that anything to do with transportation, being 
people, packages, or ip packets becomes quite costly.


Well then, let's take Sweden:

total: 449,964 sq km

This is slightly larger than california. We're 9 million.

I think at least 90% of Swedish households have access to at least ADSL 
2M/1M, and 95% of households have access to 384kbit/s UMTS mobile 
wireless.


So, we're 9 million, Californa is what, 60million, on the same surface 
area. Is there any reason why california, in itself one of the largest 
economies in the world, seems to have problems delivering anything close 
to broadband to its inhabitants? So yes, the US must have structural 
problems here...


Have you tried to use any "distribution of people" function on your numbers?

Here in CZ we have more railroads than you in SE or California in US have. 
But I'm very far away to argue that Sweden or California have structural 
problems ...


   Regards
   Michal

Re: So why don't US citizens get this?

[John Levine]

In article <[EMAIL PROTECTED]> you write:
>Sort of makes one wonder how the US came to have ubiquitous roads, or  
>power, or water distribution...

Oh, but that's different.  They were important.

Re: So why don't US citizens get this?

[Laird Popkin]

On Jul 28, 2008, at 9:54 AM, John Levine wrote:

In article <[EMAIL PROTECTED]>  
you write:

Sort of makes one wonder how the US came to have ubiquitous roads, or
power, or water distribution...


Oh, but that's different.  They were important.


Or, to be more specific, people everywhere need power and water and  
were willing to pay for them, so other people started companies to  
provide them everywhere. Roads are a little more complicated - the  
basic roads were there due to demand, but the highways got built  
because the Army argued that without highways they couldn't move  
troops and supplies to defend the country in case of an invasion. The  
same trick got science funded for a while... :-)

Re: So why don't US citizens get this?

[Laurence F. Sheldon, Jr.]

Oh, but that's different.  They were important.


What is the key criterion here for identifying odious off topic 
correspondents and the public naming thereof?

RE: So why don't US citizens get this?

[Rod Beck]

Well, to be exact, there was the political will to get the job done and a more 
pragmatic approach than we see today in the States. 

The interstate highway was created by the Federal goverment, not the private 
sector. And although the difficulties in moving troops in WWII was an issue, 
everyone recognized that a great nation requires a modern transportation. 
Similarly, one does not need a car in France - there is a seamless tram, metro, 
regional railroad, intercity and international train system. Political will, 
not private enterprise. 

The Europeans took a more pragmatic to broadband whereas the Yanks (and I am 
one) got bogged down into ideological battles over private property, etc.

The Asians were also pragmatic. Asian governments told the private sector 
(incumbents) that they had moral obligation to provide broadband and they did 
it. 

Regards, 

Roderick S. Beck
Director of European Sales
Hibernia Atlantic
13-15, rue Sedaine, 75011 Paris
http://www.hiberniaatlantic.com
Wireless: 1-212-444-8829. 
French Wireless: 33-6-14-33-48-97.
AOL Messenger: GlobalBandwidth
[EMAIL PROTECTED]
[EMAIL PROTECTED]
``Unthinking respect for authority is the greatest enemy of truth.'' Albert 
Einstein. 

Re: So why don't US citizens get this?

[Scott McGrath]

Actually ubiquitous power came from a government mandate and funding 
known as the Rural Electrification Act.The former Bell system left 
many areas of the country without telephone service and the same act set 
up the "Rural Telco's" to this day I am served by "Kearsarge Telephone 
Co" at home which serves a large chunk of Central NH.


Ultimately the 'Market' always fails in corner cases and Government in 
the form of regulation and sometimes funding needs to step in as human 
nature never changes and greed still dominates in the end not so much 
that these areas are unprofitable to service it's just that with the 
same investment more money can be made elsewhere.   From a accounting 
standpoint this is rational behavior from a societal standpoint this 
behavior is counterproductive.  Government is not 'The Answer" as many 
people feel but it does have a valuable role in balancing financial and 
societal needs.   

One of the societal needs today is reasonably priced high speed internet 
otherwise the US will fall behind in developing next generation network 
services as low speed DSL simply does not get the job done reasonably 
priced does not mean $100US for a 384/768 "Business DSL" which is the 
only thing I can run VPN over.This infrastructure is important today 
as electricity was in the 20's and 30's






Laird Popkin wrote:


On Jul 28, 2008, at 9:54 AM, John Levine wrote:

In article <[EMAIL PROTECTED]> you 
write:

Sort of makes one wonder how the US came to have ubiquitous roads, or
power, or water distribution...


Oh, but that's different.  They were important.


Or, to be more specific, people everywhere need power and water and 
were willing to pay for them, so other people started companies to 
provide them everywhere. Roads are a little more complicated - the 
basic roads were there due to demand, but the highways got built 
because the Army argued that without highways they couldn't move 
troops and supplies to defend the country in case of an invasion. The 
same trick got science funded for a while... :-)

Re: So why don't US citizens get this?

[Jack Bates]

[EMAIL PROTECTED] wrote:

FTTC is far more interesting that FTTH, because it is not just a
technology buzzword driven idea, but one based on economics. It is
cheaper to rollout a nice high bandwidth fiber link to most
neighborhoods than to use that fat bundle of copper pairs. But, on the
other hand, it is cheaper to leave that last quarter-mile intact and
only build out fiber where new development is being done. 

It is cheaper to bore fiber and attach more remote systems than to use the 
already existing copper? I'm curious how you come up with those economics. 
(seriously, that wasn't sarcasm)



So the real question that is much more interesting is as follows:
Does the US lag the world in high-speed fiber to the cabinet (FTTC)?


Good question. I'd say my little backwoods part of the world is roughly 10% 
FTTC, probably less.



Don't let the copper thieves know where you live. They might show up one
nice Sunday morning bright and early to clean out the county's copper
wire. When I lived in British Columbia, Canada in teh 90's, I noticed
that our incumbent telco was well ahead of the game. They were putting
up fiber everywhere and then following up by cutting the fat copper
cables into sections for recovery of the metal. They even ran fibre into
remote valleys were there were only a few dozen families and it was
probably economically worthwhile because they recovered a higher dollar
value of copper from those remote locations.


Yeah, mom was a little aggravated that she lost her connectivity in the valley 
out in El Salvador because one weekend thieves stole the entire stretch of 
copper down the mountain off the poles.


Still I beleve is interesting to analyze why the US is 
lagging behind on high speed services.


Analysis paralysis perhaps? AKA bipartisan politics.


I have a high speed cable competitor here in town. They love sucking up the 
competitive profits in town. Of course, our plant footprint by law is about 20 
times theirs. They weren't required to service pop and his cows 20 miles out 
where you'll never catch up on costs. Estimated population is roughly 5-6k. I've 
heard similar issues with CLEC's in small population areas. They suck up the 
profitable areas, and stay out of the areas where you will *never* recover your 
money. This was the whole point of regulation to begin with in my opinion; to 
ensure that every household had a phone line, even if it lost money.


Of course, who cares about the rural areas. They always get the fallout from 
regulation changes made with the big cities in mind. If the want fiber to every 
home, they'll either have to up their incentives or remove the competition to 
average out profits. Forcing competition to the same requirements as the 
incumbent should effectively kill them off in the rural exchanges and keep them 
in the big cities. The last I checked, NTT didn't have to compete for their high 
profit areas while losing money on the fringes (I presume Japan still has SOME 
rural areas?).


Jack

[Fwd: Admin: Offtopic Political Threads]

[S. Ryan]

Did you all forget this?

 Original Message 
Subject: Admin: Offtopic Political Threads
Date: Mon, 28 Jul 2008 09:29:24 +1200 (NZST)
From: Simon Lyall <[EMAIL PROTECTED]>
To: nanog@nanog.org


List members are reminder that the NANOG List Acceptable Use Policy
states that:

6.  Postings of political, philosophical, and legal nature are prohibited.

The current thread on the "Free Market" and "So why don't US citizens get
this?" appears to be solely political and should be moved elsewhere.

Simon Lyall
NANOG Mailing List Committee


The above is a "reminder" regarding desired emails to the NANOG mailing
list from the Mailing List Committee (MLC). While it does not constitute
a "Formal Warning" it is an official correspondence from the MLC after
internal consultation.

Please contact [EMAIL PROTECTED] if you have any feedback

Re: [Fwd: Admin: Offtopic Political Threads]

[Scott McGrath]

To a degree yes -

This issue revolves around the inability to provide end-to-end network 
services due to artificial constraints in the last mile.  At our shop we 
call it "Troubleshooting the Internet" when one of our customers cannot 
use a service which we provide and in too many cases it involves the 
last mile and the only fix is to upgrade to Frac T1 or "Business Class" 
services.


- Scott

S. Ryan wrote:

Did you all forget this?

 Original Message 
Subject: Admin: Offtopic Political Threads
Date: Mon, 28 Jul 2008 09:29:24 +1200 (NZST)
From: Simon Lyall <[EMAIL PROTECTED]>
To: nanog@nanog.org


List members are reminder that the NANOG List Acceptable Use Policy
states that:

6.  Postings of political, philosophical, and legal nature are 
prohibited.


The current thread on the "Free Market" and "So why don't US citizens get
this?" appears to be solely political and should be moved elsewhere.

Simon Lyall
NANOG Mailing List Committee


The above is a "reminder" regarding desired emails to the NANOG mailing
list from the Mailing List Committee (MLC). While it does not constitute
a "Formal Warning" it is an official correspondence from the MLC after
internal consultation.

Please contact [EMAIL PROTECTED] if you have any feedback

Re: So why don't US citizens get this?

[Hyunseog Ryu]

I think it is simply the matter of ROI - Return on Investment - issue.
I'm still living in the area without city water, and when there is power
outage, I don't have water at all since my water pump still needs
electricity.
But some rural area has FTTH because of government funding RUS
(http://www.usda.gov/rus/) project.
And most of urban area, people are still happy with cable modem service.

People in Japan and South Korea are more of tendency to become
early-adapters.
So when they have new products, they wants to try it by majority.
But in U.S., we are still cost oriented, and if we don't need it, we
don't buy it. ^^

That's my 2 cents.


Hyun



Tom Vest wrote:
> Sort of makes one wonder how the US came to have ubiquitous roads, or
> power, or water distribution...
>
> TV
>
> On Jul 28, 2008, at 1:06 PM, Jorge Amodio wrote:
>
>> Lets put aside for a moment the conspiracy theories of government
>> intervention and
>> the telcos evil doing, IMHO there is a simple reason why I don't have
>> fiber
>> going
>> to my house: geography & economics.
>>
>> Japan:
>> - area = 377,873 Km^2
>> - density = 337/Km^2
>> - pop = 127.5 mill
>>
>> USA::
>> - area = 9,826,630 Km^2
>> - density = 31/Km^2
>> - pop = 304.7 mill
>>
>> I belive there are just few major cities in the US that have a
>> comparable or
>> higher
>> concentration of people like other large cities around the world.
>>
>> I'd bet that if you deploy fiber in a given radious in a suburban
>> area in
>> Japan you
>> may reach hundreds or thousands of potential customers, do the same a
>> little
>> bit
>> north from where I live and you will reach a dozen guys, 50 cows and a
>> couple of
>> hundred chickens.
>>
>> The US is so spread out that anything to do with transportation, being
>> people,
>> packages, or ip packets becomes quite costly.
>>
>> Still I beleve is interesting to analyze why the US is lagging behind on
>> high speed
>> services.
>>
>> My .02
>
>
>
>

Off topic - RE: So why don't US citizens get this?

[nancyp]

Grad Student thesis rsrch one page: comments welcome ;)
however I have my good comments filter on...

Is Internet Reachability a Net Neutrality Issue?
CRTC Chairperson Konrad von Finckenstein introduced Net Neutrality in his
speech to the 2007 Broadcasting Invitational Summit and again at the 2008
Canadian Telecom Summit mentioning that the CRTC's New Media Initiative will
include "striking a social, cultural and economic balance to deal with Internet
traffic prioritization".

Traffic prioritization or traffic shaping is a small part of the entire
concept of a neutral network.

The internet has no minimum standard of acceptable performance for
reachability of websites and data. As an information tool it becomes useless
without this reachability addressed as far as possible.

The most famous example of non-neutrality in Canada occurred during the
Telus labour dispute (2005). Telus blocked access to a pro-union site by
blocking the server on which it was hosted. Researchers at Harvard, Cambridge
and the University of Toronto (OpenNet Initiative) found that Telus’s actions
resulted in an additional 766 unrelated sites also being blocked for
subscribers. Dealing with blocking access to servers and blocking access to
other networks are very important aims of a neutral internet.

Example: A York University professor was sitting at his desk at work in
March 2008 trying to reach an internet website located somewhere in Europe. It
was important to his research so when he repeatedly could not reach the site he
contacted his IT department at the University. They were mystified why this
would be the case. The Professor went home after work and found that he could
reach the website from home consistently, for many days and was not ever able
to reach the website from the University campus network.York’s bandwidth
supplier is Cogent which had severed a peering relationship with a bandwidth
provider in Europe called Telia, which was the bandwidth network provider for
the website that the Professor was trying to reach. However at home, the
Professor purchased bandwidth from Rogers (and its upstream providers) who did
not sever their peering relationship with Telia. Cogent did not proactively
inform the University of the issue and the loss of connectivity. Unreachability
due to arbitrariness in network peering is unacceptable.

Parts of the internet become unreachable for a great many reasons such as
line failure, cable cuts, misconfiguration of equipment and human error but to
add significantly and deliberately to this unreachability due to arbitrariness
in peering is unacceptable. End users whether award winning scholars, backyard
astronomers or teenage scientists require as much reachability of data as the
technology will allow. Political and economic persuasions should not be
permitted to condition and alter the media or the content.

Recommendation: Bandwidth purchase agreements (Service Level Agreements)
that specify bandwidth, uptime and cost actually define connectivity thus they
should contain a list of peers or network interconnections that will be
maintained for the length of the agreement.
Prepared by Nancy Paterson, York University July 23, 2008 [EMAIL PROTECTED]

PS anyone willing to proof read a few technical pages of thesis paper? pls
contact off list

Re: Arbitrary de-peering

[William Waites]

Le 08-07-28 à 17:12, [EMAIL PROTECTED] a écrit :

Example: A York University professor was sitting at his desk at  
work in
March 2008 trying to reach an internet website located somewhere in  
Europe.
[...] York’s bandwidth supplier is Cogent which had severed a  
peering relationship
with a bandwidth provider in Europe called Telia [...] which was the  
bandwidth
network provider for the website that the Professor was trying to  
reach. [...]
Cogent did not proactively inform the University of the issue and  
the loss of
connectivity. Unreachability due to arbitrariness in network peering  
is unacceptable.


There must be more to this story. If Cogent de-peered from Telia the  
traffic would
normally just have taken another path. Either there was a  
configuration error of some
sort or else some sort of proactive black-holing on one side or the  
other. As the
latter would be surprising and very heavy handed, I would tend to  
suspect the former.


Peering relationships are made and severed all the time with no  
particular ill-effects,
unless you can point to examples of outright malice (i.e. of the black- 
holing kind) I
don't think there is much basis for any public policy decisions in  
this example.


Unreachability due to configuation error is of course relatively  
common; perhaps I am
wrong, but I don't think the CRTC would really have much to say about  
that.


Cheers,
-w

Re: Arbitrary de-peering

[Patrick W. Gilmore]

On Jul 28, 2008, at 11:24 AM, William Waites wrote:

Le 08-07-28 à 17:12, [EMAIL PROTECTED] a écrit :

Example: A York University professor was sitting at his desk at  
work in
March 2008 trying to reach an internet website located somewhere in  
Europe.
[...] York’s bandwidth supplier is Cogent which had severed a  
peering relationship
with a bandwidth provider in Europe called Telia [...] which was  
the bandwidth
network provider for the website that the Professor was trying to  
reach. [...]
Cogent did not proactively inform the University of the issue and  
the loss of
connectivity. Unreachability due to arbitrariness in network  
peering is unacceptable.


There must be more to this story. If Cogent de-peered from Telia the  
traffic would

normally just have taken another path.


One should check one's assumptions before posting to 10K+ of their not- 
so-close friends.


Neither network has transit.  What other path is there to take?

Once you answer that, I'll read the rest of your e-mail.

--
TTFN,
patrick



Either there was a configuration error of some
sort or else some sort of proactive black-holing on one side or the  
other. As the
latter would be surprising and very heavy handed, I would tend to  
suspect the former.


Peering relationships are made and severed all the time with no  
particular ill-effects,
unless you can point to examples of outright malice (i.e. of the  
black-holing kind) I
don't think there is much basis for any public policy decisions in  
this example.


Unreachability due to configuation error is of course relatively  
common; perhaps I am
wrong, but I don't think the CRTC would really have much to say  
about that.


Cheers,
-w

Re: Arbitrary de-peering

[Christian Koch]

http://www.renesys.com/blog/2008/03/you_cant_get_there_from_here_1.shtml

http://www.renesys.com/blog/2008/03/he_said_she_said_cogent_vs_tel.shtml

http://www.renesys.com/blog/2008/03/telia_and_cogent_kiss_and_make_1.shtml


On Mon, Jul 28, 2008 at 11:24 AM, William Waites <[EMAIL PROTECTED]> wrote:

> Le 08-07-28 à 17:12, [EMAIL PROTECTED] a écrit :
>
>  Example: A York University professor was sitting at his desk at work
>> in
>> March 2008 trying to reach an internet website located somewhere in
>> Europe.
>> [...] York's bandwidth supplier is Cogent which had severed a peering
>> relationship
>> with a bandwidth provider in Europe called Telia [...] which was the
>> bandwidth
>> network provider for the website that the Professor was trying to reach.
>> [...]
>> Cogent did not proactively inform the University of the issue and the loss
>> of
>> connectivity. Unreachability due to arbitrariness in network peering is
>> unacceptable.
>>
>
> There must be more to this story. If Cogent de-peered from Telia the
> traffic would
> normally just have taken another path. Either there was a configuration
> error of some
> sort or else some sort of proactive black-holing on one side or the other.
> As the
> latter would be surprising and very heavy handed, I would tend to suspect
> the former.
>
> Peering relationships are made and severed all the time with no particular
> ill-effects,
> unless you can point to examples of outright malice (i.e. of the
> black-holing kind) I
> don't think there is much basis for any public policy decisions in this
> example.
>
> Unreachability due to configuation error is of course relatively common;
> perhaps I am
> wrong, but I don't think the CRTC would really have much to say about that.
>
> Cheers,
> -w
>

One Communications (Choice One)

[Brendan Mannella]

Just wondering if anyone from the One Communications Network Group is part of 
this list. Please contact me offlist if so. 

Brendan Mannella 
TeraSwitch Networks Inc. 

Anyone from Charter Communications?

[Justin Ream]

Hi -

I thought I'd ask here as it seems I'm not really going to get anywhere through 
the abuse desk.  It involves a stolen laptop (company's) and certain dns 
requests that this certain stolen laptop would be making.

-Justin

Re: Software router state of the art

[Sargun Dhillon]

This is not exactly true. The modern Linux kernel (2.6) uses some amount 
of flow tracking in order to do route caching. You can check this out on 
your system by:

"ip route show cache"

It keeps track of Src/Dst/QoS/Ethernet adapters/etc.. Additionally most 
systems have the iptables modules loaded in kernel and the conntrack 
module in kernel. This immediately activates connection tracking, 
therefore considerably slowing down software routing. The most optimal 
way of speeding this up would be sticking the route cache into somewhat 
faster memory. Though it would be fairly nice to get rid of the route 
cache as that can cause problem with eccentric setups. Also, as cache 
entries take a moment to be deleted, or degrade leading to convergence 
times being higher.






Joe Greco wrote:

On Sat, Jul 26, 2008, Florian Weimer wrote:


Was this with one packet flow, or with millions of them?
  

I believe it was >1 flow. The guy is using an Ixia; I don't know how
he has it configured.



Traditionally, software routing performance on hosts systems has been
optimized for few and rather long flows.
  

Yup.

And I always ask that question when people claim really high(!) throughput on
software forwarding. It turns out their throughput was single source/single
dest, and/or large packets (so high throughput, but low pps.)



I'm not sure where the claims about "{one, few} flow{s}" are coming from.
Certainly the number of flows on a typical UNIX box acting as a router is
not that relevant unless you specifically configure something like 
stateful firewalling, because the typical UNIX box simply doesn't have a

*concept* of "flows."  It deals with packets.  This has its own problems,
of course, but handling high levels of traffic in many flows is not one of
them.

There are other software routing platforms that DO flows, but the above
mentions "host[s] systems", so I'm reading that as "UNIX router."

On the flip side, packet size is definitely a consideration.  This topic
has been beaten to death on the Zebra mailing lists by myself and others
in the past.  


With yesterday's technology (P4 3.0G, 512MB RAM, PCI-X, FreeBSD 4) we were
successfully dealing with >300Kpps about 3 years ago, without substantial
work.  That was single source/single dest, but with a full routing table.
There's no real optimization for that within the FreeBSD framework, so it
is about the same performance you'd have gotten with multi source/multi
dest.

... JG
  




--
+1.925.202.9485
Sargun Dhillon
deCarta
[EMAIL PROTECTED]
www.decarta.com

Re: Arbitrary de-peering

[William Waites]

Le 08-07-28 à 17:29, Patrick W. Gilmore a écrit :


One should check one's assumptions before posting to 10K+ of their  
not-so-close friends.


Firstly I missed the actual incident since I was off the 'net for an  
extended period about that

time, so apologies for any rehash.


Neither network has transit.  What other path is there to take?


http://www.renesys.com/blog/2008/03/he_said_she_said_cogent_vs_tel.shtml

"Then Cogent de-peered Telia and suddenly Verizon and others started  
providing a path

between the two and their respective customers."

Which is as it should be. Then somebody (not clear who) apparently  
took explicit steps
to stop the traffic from taking these other paths. Surprising.  
Severing a peering relationship
is one thing, purposely filtering large swathes of the Internet over  
other all links is quite

another.

As I said, this is surprising behaviour, but not simple de-peering.  
And I'm sure that any
Tier 1 has enough peering relationships with enough other Tier 1  
networks that they can

always buy temporary transit privileges over an existing link.

-w

Re: Level3 newyork - london, anyone else seeing issues?

[up]

We saw an outage from 7:35am to 8:14am (partially back up) 8:20 (fully up) 
on 7/24.  I was on the phone with Level 3 at the time.  A tech was 
supposed to get back to me with an explanation so I could pass that on to 
my customers, but it never happened.


On Sat, 26 Jul 2008, John Menerick wrote:

I was seeing the same thing around the same time.  However, the "issue" 
corrected itself after 10 minutes.  Not quite long enough to get Level3 
support on the phone.  Support's answer: "OOps, our bad."



John Menerick
http://www.icehax.us
twitter: aeonice
aim: glacilwing


On Jul 25, 2008, at 6:13 AM, Drew Weaver wrote:


C:\Users\aweaver>tracert 123.237.32.1

Tracing route to 123.237.32.1 over a maximum of 30 hops

5 5 ms 5 ms 5 ms  ae-2-6.bar2.Cleveland1.Level3.net 
[4.69.132.202]
6 5 ms 4 ms 4 ms  ae-0-11.bar1.Cleveland1.Level3.net 
[4.69.136.185]
713 ms17 ms17 ms  ae-6-6.ebr1.Washington1.Level3.net 
[4.69.136.190]
816 ms16 ms17 ms  ae-91-91.csw4.Washington1.Level3.net 
[4.69.134.142]
915 ms17 ms17 ms  ae-93-93.ebr3.Washington1.Level3.net 
[4.69.134.173]

1022 ms18 ms18 ms  ae-3.ebr3.NewYork1.Level3.net [4.69.132.90]
1130 ms18 ms18 ms  ae-63-63.csw1.NewYork1.Level3.net 
[4.69.134.98]
1218 ms19 ms19 ms  ae-13-69.car3.NewYork1.Level3.net 
[4.68.16.5]

13 *** Request timed out.
14 *** Request timed out.
15 *** Request timed out.
16 *** Request timed out.
17 *** Request timed out.
18 *** Request timed out.
19 *** Request timed out.
20 *** Request timed out.
21 *** Request timed out.
22 *** Request timed out.
23 *** Request timed out.
24 *** Request timed out.
25 *** Request timed out.
26 *** Request timed out.
27 *** Request timed out.
28 *** Request timed out.
29 *** Request timed out.
30 *** Request timed out.

Looks like it began occurring around 4am. We're getting reports from some 
international users that they are unable to reach destinations within our 
network.


-Drew






James Smallacombe PlantageNet, Inc. CEO and Janitor
[EMAIL PROTECTED]   
http://3.am
=

Re: Software router state of the art

[Joe Greco]

> This is not exactly true. The modern Linux kernel (2.6) uses some amount 
> of flow tracking in order to do route caching. You can check this out on 
> your system by:
> "ip route show cache"

Okay...

# ip route show cache
ip: Command not found.
#

So I guess that's all well and good for me.

> It keeps track of Src/Dst/QoS/Ethernet adapters/etc.. Additionally most 
> systems have the iptables modules loaded in kernel and the conntrack 
> module in kernel. This immediately activates connection tracking, 
> therefore considerably slowing down software routing. The most optimal 
> way of speeding this up would be sticking the route cache into somewhat 
> faster memory. Though it would be fairly nice to get rid of the route 
> cache as that can cause problem with eccentric setups. Also, as cache 
> entries take a moment to be deleted, or degrade leading to convergence 
> times being higher.

Note .. to .. self ..  Linux .. makes .. crappy .. router.  Got it.

Guess we'll continue to use FreeBSD, and the lesson to come away with
is that it probably pays to avoid technologies that are suboptimal 
for the task at hand.  Not everything is created equal.  It also pays
to tune things.  If "conntrack" hurts, then remove it.

With the emergence of computers with many cores, it will be very
interesting to see how this develops.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

RE: So why don't US citizens get this?

[michael.dillon]

> It is cheaper to bore fiber and attach more remote systems 
> than to use the already existing copper? I'm curious how you 
> come up with those economics. 
> (seriously, that wasn't sarcasm)

First point is that you can sell the copper. Second is that you can
reduce the number of local loop faults because the local loop is digital
to the fiber cabinets. Local loop faults seem to be a major cause of
overtime work in telcos. The cause of the faults is numerous including
stretched copper, cracked insulation, moisture in the bundles, rodents,
etc. Have you ever seen the huge bundles of copper wires that come into
a telephone exchange? Once you have seen this in person and you
understand the complexity of cutting those loops, and splicing, and
recutting, and resplicing over many decades, then you will see where it
might be cheaper overall to just replace them with OC48 over fiber. Or
GigE or whatever, but make it digital and make it go on glass fiber
cables.

> Yeah, mom was a little aggravated that she lost her 
> connectivity in the valley out in El Salvador because one 
> weekend thieves stole the entire stretch of copper down the 
> mountain off the poles.

Here in London they even steel bronze statues or brass railings in a
park to get the copper content. Here is one account of the risks that
copper thieves will go to. Don't read it if you have a queasy stomach.

> > Analysis paralysis perhaps? AKA bipartisan politics.

> This was the whole point of regulation to begin with in my 
> opinion; to ensure that every household had a phone line, 
> even if it lost money.

And the day will dawn when governments realize that the technology used
to supply service is irrelevant, but everyone needs to have a reliable
connection to the Internet. They may even mandate that every connection
has to include an emergency voice service that is the old -48VDC POTS in
disguise. Today the USA and the rest of the world is still in the
pioneering experimental stage of figuring out what works. If Russia
forges ahead with FTTH broadband everywhere, just watch how quickly you
see bipartisan agreement in the USA.

> Of course, who cares about the rural areas.

Do you eat? 

Anyway there is history in the USA of treating rural areas as a apecial
case such as the Rural Electrification programs. The rural people didn't
need electricity and could have gotten on just fine without it as they
had for centuries before. Even industrialised countries like Russia and
Ukraine still have rural areas where there is essentially no
electricity, or very occasional and unreliable electricity. Different
countries choose different priorities, but over time there seems to be
general convergence of all countries onto a basic set of modern services
that they want to deliver to their entire population.

Some things can be done with competitive markets, and other things
cannot. It's all about figuring out which measures to apply to which
problems, not about taking a political ideology like communism and
forcing it upon every aspect of people's lives. That has been proven to
not work and people who call for free-market everything need to realize
that they are trodding the same wellworn path that communists travelled
in the last century.

Furthermore, most Americans alive today do not really remember what a
free market was like. When was the last time you travelled in an
unregulated cab, ate in an unregulated restaurant, etc.?

Even this mailing list is attempting to impose constraints on the free
market of network design and operations. Best practices become embodied
in vendor products and even people who don't necessarily want to follow
the best practices for good technical reasons, can't find the equipment
to do it or the people who will build it differently.

--Michael Dillon

RE: Arbitrary de-peering

[Randy Epstein]

> Which is as it should be. Then somebody (not clear who) apparently  
> took explicit steps to stop the traffic from taking these other paths.

> Surprising.  Severing a peering relationship is one thing, purposely
> filtering large swathes of the Internet over other all links is quite
> another.
> As I said, this is surprising behaviour, but not simple de-peering.  
> And I'm sure that any Tier 1 has enough peering relationships with enough
> other Tier 1 networks that they can always buy temporary transit
> privileges over an existing link.

This is not surprising at all.  One of the networks making arrangements to
purchase transit immediately may help the customers of both networks in the
short term, but the reality is that peering problem still exists and it
immediately shows a weakness on one side.  If they're willing to pay, they
may agree to peering with settlements as well or just continue to buy
transit.  No transit free network is going to allow this to happen.  It is
in their best interest to make the de-peering as painful as possible to get
a quicker resolution that satisfies both parties.

Maybe not the greatest analogy, but think labor strikes and scabs (temporary
workers willing to cross the picket line).  If there were no repercussions
to allowing scab workers to cross a picket line (lack of training leading to
mistakes/accidents, pressure placed by the unions, negative publicity
causing customers to boycott the company, etc), then unions wouldn't exist,
or at least wouldn't have the strength needed to put the issue to rest as
quickly as possible.

When your customers (and the other networks customers) are complaining, the
issue gets resolved much quicker.  The Telia/Cogent depeering went longer
than most, but it usually gets the job done.

>-w

Randy

Re: Arbitrary de-peering

[Jon Lewis]

On Mon, 28 Jul 2008, William Waites wrote:


Neither network has transit.  What other path is there to take?


Bit bucket path.


http://www.renesys.com/blog/2008/03/he_said_she_said_cogent_vs_tel.shtml

"Then Cogent de-peered Telia and suddenly Verizon and others started 
providing a path

between the two and their respective customers."

Which is as it should be. Then somebody (not clear who) apparently took 
explicit steps to stop the traffic from taking these other paths. 
Surprising. Severing a peering relationship is one thing, purposely 
filtering large swathes of the Internet over other all links is quite 
another.


As I said, this is surprising behaviour, but not simple de-peering. And I'm


Why is it surprising?  Sounds more like a repeat performance to me.

Back when Level3 depeered Cogent, it was said that Cogent was already 
buying transit from Verio to reach at least some networks they weren't 
peering with.  After the depeering, why didn't Cogent get to Level3 (and 
vice versa) via Verio?


Was the reason ever made public?

Tier 1 has enough peering relationships with enough other Tier 1 
networks that they can always buy temporary transit privileges over an 
existing link.


Tier 1 means you don't buy transit, no?

--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

RE: So why don't US citizens get this?

[Rod Beck]

As if you believe in network externalities (each additional network node 
increases the value of the entire network) and I certainly do, then there is 
reason to believe a purely private market will not serve enough customers. :)

Each customer decides to join the network based on their private calculus of 
cost and benefit and disregards the benefit everyone else gains from their 
joining the network. 

Similarly, I pay for my mother's phone so I can reach her. :) 

Roderick S. Beck
Director of European Sales
Hibernia Atlantic
13-15, rue Sedaine, 75011 Paris
http://www.hiberniaatlantic.com
Wireless: 1-212-444-8829. 
French Wireless: 33-6-14-33-48-97.
AOL Messenger: GlobalBandwidth
[EMAIL PROTECTED]
[EMAIL PROTECTED]
``Unthinking respect for authority is the greatest enemy of truth.'' Albert 
Einstein. 

RE: Arbitrary de-peering

[michael.dillon]

> Tier 1 means you don't buy transit, no?

Presumably it follows that tier 2 networks do buy transit. Therefore,
why would anyone buy service from a Tier 1 network except for other
network operators?

This doesn't match with the reality that providers who are Tier 1 seem
to get some very big companies as customers. Why would they do that if
Tier 1 networks offer a substandard service? Is this a scandal in the
making?

--Michael Dillon

RE: So why don't US citizens get this?

[Rod Beck]

Her cell phone. 

Roderick S. Beck
Director of European Sales
Hibernia Atlantic
13-15, rue Sedaine, 75011 Paris
http://www.hiberniaatlantic.com
Wireless: 1-212-444-8829. 
French Wireless: 33-6-14-33-48-97.
AOL Messenger: GlobalBandwidth
[EMAIL PROTECTED]
[EMAIL PROTECTED]
``Unthinking respect for authority is the greatest enemy of truth.'' Albert 
Einstein. 



-Original Message-
From: Rod Beck [mailto:[EMAIL PROTECTED]
Sent: Mon 7/28/2008 5:29 PM
To: Scott McGrath; Laird Popkin
Cc: nanog@nanog.org
Subject: RE: So why don't US citizens get this?
 
As if you believe in network externalities (each additional network node 
increases the value of the entire network) and I certainly do, then there is 
reason to believe a purely private market will not serve enough customers. :)

Each customer decides to join the network based on their private calculus of 
cost and benefit and disregards the benefit everyone else gains from their 
joining the network. 

Similarly, I pay for my mother's phone so I can reach her. :) 

Roderick S. Beck
Director of European Sales
Hibernia Atlantic
13-15, rue Sedaine, 75011 Paris
http://www.hiberniaatlantic.com
Wireless: 1-212-444-8829. 
French Wireless: 33-6-14-33-48-97.
AOL Messenger: GlobalBandwidth
[EMAIL PROTECTED]
[EMAIL PROTECTED]
``Unthinking respect for authority is the greatest enemy of truth.'' Albert 
Einstein. 

Re: Arbitrary de-peering

[William Waites]

Le 08-07-28 à 18:27, Jon Lewis a écrit :


Bit bucket path.


Evidently.

As I said, this is surprising behaviour, but not simple de-peering.  
And I'm


Why is it surprising?  Sounds more like a repeat performance to me.

Back when Level3 depeered Cogent, it was said that Cogent was  
already buying transit from Verio to reach at least some networks  
they weren't peering with.  After the depeering, why didn't Cogent  
get to Level3 (and vice versa) via Verio?


Surprising because, Cogent (or Telia, but from what you say here,  
looks like Cogent),
presumably put themselves in a breach of contract position with their  
(end-user or stub
AS) customers who one would imagine have bought "Internet service"  
from them. Given
that they have some reasonably big/important customers it is  
surprising that they would
take that risk, and even more surprising that it didn't bite them too  
hard. By maybe I am

just easily surprised.

Tier 1 has enough peering relationships with enough other Tier 1  
networks that they can always buy temporary transit privileges over  
an existing link.


Tier 1 means you don't buy transit, no?


Maybe a slightly revised definition of Tier 1 is in order -- a  
provider that doesn't buy transit
and doesn't sell to end-users or stub systems. Doing either of these  
things would degrade
them in the nomenclature by 0.5. Doing both of these things makes a  
Tier 2 provider which
had better have transit from more than one upstream. This way  
innocents don't suffer the
collateral damage from games of chicken among the titans (unless they  
were silly enough
to get their only Internet connection from a Tier 1.5 provider). Oh  
well.


Cheers,
-w

Re: Arbitrary de-peering

[Jon Lewis]

On Mon, 28 Jul 2008, William Waites wrote:

Surprising because, Cogent (or Telia, but from what you say here, looks 
like Cogent), presumably put themselves in a breach of contract position 
with their (end-user or stub AS) customers who one would imagine have 
bought "Internet service" from them. Given that they have some 
reasonably big/important customers it is surprising that they would take 
that risk, and even more surprising that it didn't bite them too hard. 
By maybe I am just easily surprised.


But, AFAICT, Cogent has done this before and even combined it with the 
publicity stunt of offering free peering to any single-homed Level3 
customer for a year.



Tier 1 means you don't buy transit, no?


Maybe a slightly revised definition of Tier 1 is in order -- a provider 
that doesn't buy transit and doesn't sell to end-users or stub systems.


I don't know that you'll find a Tier 1 that doesn't sell to end-user 
networks.  It's kind of what they do.  Once you start buying transit, all 
the bigger networks probably figure they can get you to "pay us too."


--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Software router state of the art

[Seth Mattinen]

Sargun Dhillon wrote:
This is not exactly true. The modern Linux kernel (2.6) uses some amount 
of flow tracking in order to do route caching. You can check this out on 
your system by:

"ip route show cache"



Did you mean "route -C" ?

I like the idea and price point of the ImageStream products, but knowing 
how bad Linux is at being a router and that their products are 
Linux-based, I'm afraid to give one a try. J products are based on a 
competing non-Linux platform that has a better reputation for routing.


~Seth

RE: Software router state of the art

[michael.dillon]

> but knowing how bad Linux is at being a router and that their 
> products are Linux-based, I'm afraid to give one a try. J 
> products are based on a competing non-Linux platform that has 
> a better reputation for routing.

Enough with the bipartisan politics. There are more choices than 
just Linux and FreeBSD for software routing.

Click for instance 

--Michael Dillon

Re: So why don't US citizens get this?

[Jean-François Mezei]

Jorge Amodio wrote:

> I belive there are just few major cities in the US that have a comparable or
> higher
> concentration of people like other large cities around the world.


Does population density still REALLY matter ? Considering that fibre
optic cables have a far longer reach than  copper, and considering that
the utility poles already exist in less densely populated areas, it
would seem to me that fibre would be a superior alternative to copper,
especially when you consider the costs of setting up remotes all over
the place for copper.


And I would reckon that laying fibre along existing utility poles to
reach 200 homes would cost far less than laying fibre in a concrete high
rise appartment building to reach 200 appartments.

The way I view it, telco accountants have build *excuses* to not lay
fibre instead of finding ways to justify laying it.

Re: So why don't US citizens get this?

[Josh Cheney]

Jean-François Mezei wrote:

Does population density still REALLY matter ? Considering that fibre
optic cables have a far longer reach than  copper, and considering that
the utility poles already exist in less densely populated areas, it
would seem to me that fibre would be a superior alternative to copper,
especially when you consider the costs of setting up remotes all over
the place for copper.


And I would reckon that laying fibre along existing utility poles to
reach 200 homes would cost far less than laying fibre in a concrete high
rise appartment building to reach 200 appartments.


My understanding is that for a rural area, in a completely new rollout 
or a forklift upgrade, fiber is cheaper than copper. However, because 
the majority of the copper that is currently deployed is still highly 
serviceable, it is very difficult to justify tearing out perfectly good 
copper and laying out fiber in it's place.



--
Josh Cheney
[EMAIL PROTECTED]
http://www.joshcheney.com

Re: So why don't US citizens get this?

[Jorge Amodio]

> And I would reckon that laying fibre along existing utility poles to
> reach 200 homes would cost far less than laying fibre in a concrete high
> rise appartment building to reach 200 appartments.
>
> Problem is not laying fiber between poles, the last mile has been always
the show killer.

200 local loops + terminating equipment surely will cost more than 1 local
loop + terminating equipment.

My .02

Re: Software router state of the art

[Justin Sharp]

[EMAIL PROTECTED] wrote:
but knowing how bad Linux is at being a router and that their 
products are Linux-based, I'm afraid to give one a try. J 
products are based on a competing non-Linux platform that has 
a better reputation for routing.



Enough with the bipartisan politics. There are more choices than 
just Linux and FreeBSD for software routing.


Click for instance 

--Michael Dillon

  
Anyone have experience with RouterOS (http://www.mikrotik.com/)? Created 
mostly to run on these guys I think 
(http://www.routerboard.com/comparison.html) which generally don't get 
above 200k pps on the higher models.. But will RouterOS run on bigger boxen?

Re: Software router state of the art

[Seth Mattinen]

[EMAIL PROTECTED] wrote:
but knowing how bad Linux is at being a router and that their 
products are Linux-based, I'm afraid to give one a try. J 
products are based on a competing non-Linux platform that has 
a better reputation for routing.


Enough with the bipartisan politics. There are more choices than 
just Linux and FreeBSD for software routing.


Click for instance 

--Michael Dillon




Thanks for being oh-so-helpful with a serious question. Got any useful 
answers for me? Give me a vendor that offers your suggestion. I don't 
have time for a make-it-myself solution.


~Seth

Re: Software router state of the art

[Charles Wyble]

Seth Mattinen wrote:

[EMAIL PROTECTED] wrote:
but knowing how bad Linux is at being a router and that their 
products are Linux-based, I'm afraid to give one a try. J products 
are based on a competing non-Linux platform that has a better 
reputation for routing.





Thanks for being oh-so-helpful with a serious question. Got any useful 
answers for me? Give me a vendor that offers your suggestion. I don't 
have time for a make-it-myself solution.


H. Well then you probably don't want to use Linux/BSD as a router, 
as a substantial amount of DIY is required for anything beyond 
relatively simple routing. MPLS support (on Linux) for example is in 
early phases and requires integrating separate pieces and is best 
supported on Fedora9. Needless to say, Fedora isn't designed for 
reliable/stable operation and long term deployment.


I have yet to look into *BSD based solutions, but hear very good things 
about firewall performance. I don't know about BGP/OSPF/MPLS etc support 
on FreeBSD but am going to wager a guess its on par with Linux if not 
better.


To address another point made in this thread, see 
http://ols.fedoraproject.org/OLS/Reprints-2007/zhu-Reprint.pdf which 
addresses hardware multiqueue device support under Linux. Its from 
2007.  I think there was a question about Linux/multiqueue support in 
this thread, but I am not 100% sure. :)


I think there was mention of Vyatta earlier in the thread and some talk 
about it switching from Xorp to Quagga, and a supposition that should 
improve it.



--
Charles Wyble (818) 280 - 7059
http://charlesnw.blogspot.com
CTO Known Element Enterprises / SoCal WiFI project

Re: So why don't US citizens get this?

[Chris Stebner]

   Jean-François Mezei wrote:

Jorge Amodio wrote:



I belive there are just few major cities in the US that have a comparable or
higher
concentration of people like other large cities around the world.



Does population density still REALLY matter ? Considering that fibre
optic cables have a far longer reach than  copper, and considering that
the utility poles already exist in less densely populated areas, it
would seem to me that fibre would be a superior alternative to copper,
especially when you consider the costs of setting up remotes all over
the place for copper.


And I would reckon that laying fibre along existing utility poles to
reach 200 homes would cost far less than laying fibre in a concrete high
rise appartment building to reach 200 appartments.

The way I view it, telco accountants have build *excuses* to not lay
fibre instead of finding ways to justify laying it.



   That brings up another instance of CLEC to ILEC inequality. We have
   repeatedly tried to ascertain 'pole rights' from local/regional power
   companies but have been brushed off with "agreements "of 15-20k per
   pole! We would love to run fiber to our rural remotes and offer triple
   play services, but at 15k per pole! Currently, the best we can do for
   very remote locations is to mux a couple of T1's together or if we're
   lucky get a couple of unbundled loops and run Ethernet over copper. I
   wanted to chime in earlier when people where mentioning what they paid
   for what kind of connectivity and this seems as apropos time as any. We
   charge a FLAT $70 bux for 3m/1m and unlimited local/LD to these remote
   locations, if served from a CO, that price drops to $50 US and the
   speed climbs to whatever the line is capable of. The company is based
   in the southwest US. I suppose I could de-politicize this comment by
   posing the question, has anybody had luck attaining pole rights in such
   an instance for a reasonable rate?
   -chris

Re: Software router state of the art

[Joe Greco]

> H. Well then you probably don't want to use Linux/BSD as a router, 
> as a substantial amount of DIY is required for anything beyond 
> relatively simple routing. MPLS support (on Linux) for example is in 
> early phases and requires integrating separate pieces and is best 
> supported on Fedora9. Needless to say, Fedora isn't designed for 
> reliable/stable operation and long term deployment.
> 
> I have yet to look into *BSD based solutions, but hear very good things 
> about firewall performance. I don't know about BGP/OSPF/MPLS etc support 
> on FreeBSD but am going to wager a guess its on par with Linux if not 
> better.

The underlying OS is responsible for packet forwarding, but none of them
do any significant routing protocols natively.  Adding on a package
such as Quagga or OpenBGPD is required for that, and the results of
each should be relatively similar across platforms.

The only major caveat is that Quagga OSPF is currently a disaster on 
FreeBSD 7.  Don't try it.  We added a server that was advertising some
stuff, with multiple interfaces, using a config identical to what we
do under FreeBSD 6.  Not only did it randomly not work, but it also
randomly killed OTHER OSPF speakers elsewhere in the network, including
on non-directly attached networks in another OSPF area (we'd log in and
see no neighbors).

OpenOSPFD appears to be the fix for that.  Simpler, smaller, but dumb
enough that it advertised 127.0.0.1 into our OSPF environment when we
were trying to get some aliases on lo0 advertised, which caused 
freaking out of pretty much every OSPF-speaking UNIX server we have 
(sigh).

BGP is straightforward, except for things like MD5, which can be a bit
dicey.  Quagga is very good, and much less expensive than, something
like Cisco for a route server, from what I've heard over the years.
You'll notice some of the Route-views boxes are Quagga or Zebra (its
predecessor).

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Software router state of the art

[Andrew D Kirch]

Justin Sharp wrote:

[EMAIL PROTECTED] wrote:
but knowing how bad Linux is at being a router and that their 
products are Linux-based, I'm afraid to give one a try. J products 
are based on a competing non-Linux platform that has a better 
reputation for routing.



Enough with the bipartisan politics. There are more choices than just 
Linux and FreeBSD for software routing.


Click for instance 

--Michael Dillon

  
Anyone have experience with RouterOS (http://www.mikrotik.com/)? 
Created mostly to run on these guys I think 
(http://www.routerboard.com/comparison.html) which generally don't get 
above 200k pps on the higher models.. But will RouterOS run on bigger 
boxen?


Yes I do, and I'm still in therapy.  I was pushing 30mbit, and I can't 
remember how many PPS through one, and it crashed about once a month 
requiring onsite intervention (usually at midnight).  This was running 
on a Compaq Deskpro I think.  It doesn't have much support for good 
network cards.  I suspect the Realtek's were behind the crashes.


Andrew

Re: Software router state of the art

[Charles Wyble]

Andrew D Kirch wrote:

Justin Sharp wrote:

[EMAIL PROTECTED] wrote:


  


Yes I do, and I'm still in therapy.  I was pushing 30mbit, and I can't 
remember how many PPS through one, and it crashed about once a month 
requiring onsite intervention (usually at midnight).  This was running 
on a Compaq Deskpro I think.  It doesn't have much support for good 
network cards.  I suspect the Realtek's were behind the crashes.


Yeah or any number of cheap consumer parts in the Deskpro.  I would 
love to see RouterOS running on an HP or Dell mid range server and how 
that performs. I'm guessing it would be quite nice.




--
Charles Wyble (818) 280 - 7059
http://charlesnw.blogspot.com
CTO Known Element Enterprises / SoCal WiFI project

Re: Software router state of the art

[Seth Mattinen]

Michael 'Moose' Dinn wrote:
 Thanks for being oh-so-helpful with a serious question. Got any useful 
 answers for me? Give me a vendor that offers your suggestion. I don't have 
 time for a make-it-myself solution.




What are your requirements?



The problem I'm facing is that if I want something from Cisco that can 
do at least line-rate T3, I'm looking at least $20k per router. I don't 
have a uber-budget, so for me, that's kind of painful when I start to 
need more than one plus spare parts. But, I have a high level of 
confidence that I can put cards in, some memory, power it up, configure 
it and I'm good to go.


Junpier's J-series is a BSD based platform as far as I understand it. 
ImageStream is *much* more affordable for me, but is Linux-based, and I 
fear Linux as a router and I don't know what they've done to fix the 
common gripes with Linux-as-router. I have no idea if either of the two 
have hardware assist in the cards, but my impression is that they are 
essentially software platforms with custom interface cards. Interface 
cards are important to me because I'm operating in an environment where 
my link to the outside world is probably going to be T1/T3.


I'm aware of Cisco IOS, then BSD-based and Linux-based platforms that 
are actually sold as routing products. I also know there are a billion 
"yay, router!" things out there. T1 cards are easy to find. The only 
other place I know I could buy a T3 card from is Sangoma. Maybe someone 
has even used it* T3 card before. Rather than reinvent the wheel alone, 
nanog has to contain the highest concentration of people that have tried 
various things and already know what will work and what won't work. I'm 
not looking for OS politics, just operational experience from people who 
have access to more money and more hardware than I do to have tried more 
stuff.


If my best option is still from the big players, so be it. If there's 
something else that's just as stable, I want to hear about it. I'm not 
adverse to some dirty work, but I just don't have the time right now to 
jump in over my head into a software router project and then fight my 
way back to the surface. I'm not trying to create something for 
educational purposes, I need something suitable for a production 
environment.


~Seth


* http://www.sangoma.com/products_and_solutions/hardware/data_only/a301.html

Great Suggestion for the DNS problem...?

[Jay R. Ashworth]

[ unthreaded to encourage discussion ]

On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote:
> Nameservers could incorporate poison detection...
>
> Listen on 200 random fake ports (in addition to the true query ports);
> if a response ever arrives at a fake port, then it must be an attack,
> read the "identified" attack packet, log the attack event, mark the
> RRs mentioned in the packet as "poison being attempted" for 6 hours;
> for such domains always request and collect _two_ good responses
> (instead of one), with a 60 second timeout, before caching a lookup.
>
> The attacker must now guess nearly 64-bits in a short amount of time,
> to be successful. Once a good lookup is received, discard the normal
> TTL and hold the good answer cached and immutable, for 6 hours (_then_
> start decreasing the TTL normally).

Is there any reason which I'm too far down the food chain to see why
that's not a fantastic idea?  Or at least, something inspired by it?

Cheers,
-- jr 'IANAIE' a
-- 
Jay R. Ashworth   Baylink  [EMAIL PROTECTED]
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

 Those who cast the vote decide nothing.
 Those who count the vote decide everything.
   -- (Josef Stalin)

Re: So why don't US citizens get this?

[Jay R. Ashworth]

On Sat, Jul 26, 2008 at 11:11:39PM +, [EMAIL PROTECTED] wrote:
>   that said, can I get FIOS w/o any other 
>   Verizon crap?  I just want the fiber transport
>   to an exchange... want my own ISP/peering, not
>   theirs.  They wont sell it.

I gather that the company providing FIOS is an unreg subsidiary, and a
CLEC, and therefore doesn't have to *sell* you transport, voice or
data.  How they get to be in the wire centers, I'm not clear, though i
understand they are.

I *do* have the FIOS Tampa and National NOC phone numbers, if anyone
needs them; the St Pete Times did a piece on them when they first
rolled out, and were indelicate enough to use a high-res pic of their
warroom as the lede, with the numbers clearly readable.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth   Baylink  [EMAIL PROTECTED]
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

 Those who cast the vote decide nothing.
 Those who count the vote decide everything.
   -- (Josef Stalin)

Re: So why don't US citizens get this?

[WWWhatsup]

In http://punkcast.com/933/ (2006) Gale Brewer, chair of the NYC Council Tech 
Cttee talks
about Verizon's initial plans for FTTH in NYC. In the city the problem was that 
they would have
to negotiate with apartment building owners who would habg them out to dry for 
access to
their tenants. As a result Verizon went for the suburbs. Just recently, after 
having gained
approval to deliver cable tv like services, and thus one might imagine 
sufficient revenue to
meet such demands, have they started in on the city.

joly



Jorge Amodio wrote:

>I belive there are just few major cities in the US that have a comparable or
>higher
>concentration of people like other large cities around the world.

---
 WWWhatsup NYC
http://pinstand.com - http://punkcast.com
--- 

Re: Great Suggestion for the DNS problem...?

[Colin Alston]

On 2008/07/28 09:05 PM Jay R. Ashworth wrote:

Is there any reason which I'm too far down the food chain to see why
that's not a fantastic idea?  Or at least, something inspired by it?


If NS records pointed to IP's instead of names then this problem might 
not exist.
The root holds glue going up the chain, and you could reject 
authoritative responses from IP's not listed as authoritative NS for 
that zone.


Ie for karnaugh.za.net, net is looked up from root. Root IP addresses 
are queried directly, so you know to ignore responses coming from 
someone else. That gives you net (the same gtld, how convenient) and 
authoritative IP response for its NS. So you look up za.net and get 
correct glue and so on.


Actually, if glue were always served up the resolution chain then then 
only crummy glueless delegations would be vulnerable.


Anyone feel like redesigning the DNS protocol? Anyone? No? :(

Re: Great Suggestion for the DNS problem...?

[Joe Greco]

> [ unthreaded to encourage discussion ]
> 
> On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote:
> > Nameservers could incorporate poison detection...
> >
> > Listen on 200 random fake ports (in addition to the true query ports);
> > if a response ever arrives at a fake port, then it must be an attack,
> > read the "identified" attack packet, log the attack event, mark the
> > RRs mentioned in the packet as "poison being attempted" for 6 hours;
> > for such domains always request and collect _two_ good responses
> > (instead of one), with a 60 second timeout, before caching a lookup.
> >
> > The attacker must now guess nearly 64-bits in a short amount of time,
> > to be successful. Once a good lookup is received, discard the normal
> > TTL and hold the good answer cached and immutable, for 6 hours (_then_
> > start decreasing the TTL normally).
> 
> Is there any reason which I'm too far down the food chain to see why
> that's not a fantastic idea?  Or at least, something inspired by it?

There's a ton of stuff that you can do, I talked a bit about this kind of
solution several days ago, see <[EMAIL PROTECTED]>. 
The problem is mainly that this is reactive, and primarily applicable to 
this attack because it's a brute-force.  The next attack might be more
elegant.  Designing in this sort of "protection" is good AND bad, because
on one hand, you do mostly solve the problem, and that's good, but you
also encourage people to think of the problem as "fixed" or "my server
is not vulnerable," when the only real way to protect against the *next*
attack is to make sure that the data is valid, so that's DNSSEC.

There are actually more specifically useful things that you can do to
mitigate particular aspects of this attack, except that talking about
them will also point to some risks that I don't believe have been made
public, and I'm going to do my part to keep it that way, at least for a
bit longer.

The short form, though, is that if you sit there and try to manufacture
artificial protection against each new attack as it develops, you will
end up with this Rube Goldberg contraption to protect your nameserver
from various attacks, and who knows what will break it.  View these as
very short-term fixes, rather than a correction of the underlying issue.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Software router state of the art

[Deepak Jain]

The problem I'm facing is that if I want something from Cisco that can 
do at least line-rate T3, I'm looking at least $20k per router. I don't 
have a uber-budget, so for me, that's kind of painful when I start to 
need more than one plus spare parts. But, I have a high level of 
confidence that I can put cards in, some memory, power it up, configure 
it and I'm good to go.


Junpier's J-series is a BSD based platform as far as I understand it. 
ImageStream is *much* more affordable for me, but is Linux-based, and I 
fear Linux as a router and I don't know what they've done to fix the 
common gripes with Linux-as-router. I have no idea if either of the two 
have hardware assist in the cards, but my impression is that they are 
essentially software platforms with custom interface cards. Interface 
cards are important to me because I'm operating in an environment where 
my link to the outside world is probably going to be T1/T3.


I'm aware of Cisco IOS, then BSD-based and Linux-based platforms that 
are actually sold as routing products. I also know there are a billion 
"yay, router!" things out there. T1 cards are easy to find. The only 
other place I know I could buy a T3 card from is Sangoma. Maybe someone 
has even used it* T3 card before. Rather than reinvent the wheel alone, 
nanog has to contain the highest concentration of people that have tried 
various things and already know what will work and what won't work. I'm 
not looking for OS politics, just operational experience from people who 
have access to more money and more hardware than I do to have tried more 
stuff.


If my best option is still from the big players, so be it. If there's 
something else that's just as stable, I want to hear about it. I'm not 
adverse to some dirty work, but I just don't have the time right now to 
jump in over my head into a software router project and then fight my 
way back to the surface. I'm not trying to create something for 
educational purposes, I need something suitable for a production 
environment.




[I didn't know what to cut from above, so I left it].

What I've used and seen used before that plays both to the strengths of 
the PC as a router and addresses some of the T3 related issues -- 
especially if you control both ends of the T3.


Using an FE to T3 bridge or FE to T1 bridge as the case may be. With a 
little tuning you can put a rate shaper on the PC (prior art, very 
stable) to not run into off-PC buffering issues. Your PC has plenty of 
cheap buffer. The interface to the comms network is done through a 
dedicated, telco or computer center grade piece of gear.


Everyone here (NANOG) can agree that a 10 or 100Mb/s PC router is a no 
brainer and as long as you aren't using irresponsible gear, this thing 
will route packets forever.


Putting telco interfaces into PCs has always been a little more odd, but 
telco to ethernet bridges are fairly standard and fairly dumb. Depending 
on how many of these you have etc, you can do creative things with 
switches, FR, etc. And cost can be all over the map. I know Pairgain 
used to make good ethernet to T1 bridges, and that's probably the last 
time I remember playing with this stuff.


YMMV.

Deepak Jain
AiNET

RE: Great Suggestion for the DNS problem...?

[Tomas L. Byrnes]

As you pointed out, the protocol, if properly implemented, addresses
this. 

There should always be Glue (A records for the NS) in a delegation. RFC
1034 even specifies this:

4.2.2 
As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.




> -Original Message-
> From: Colin Alston [mailto:[EMAIL PROTECTED] 
> Sent: Monday, July 28, 2008 12:20 PM
> To: Jay R. Ashworth
> Cc: nanog@nanog.org
> Subject: Re: Great Suggestion for the DNS problem...?
> 
> On 2008/07/28 09:05 PM Jay R. Ashworth wrote:
> > Is there any reason which I'm too far down the food chain 
> to see why 
> > that's not a fantastic idea?  Or at least, something inspired by it?
> 
> If NS records pointed to IP's instead of names then this 
> problem might not exist.
> The root holds glue going up the chain, and you could reject 
> authoritative responses from IP's not listed as authoritative 
> NS for that zone.
> 
> Ie for karnaugh.za.net, net is looked up from root. Root IP 
> addresses are queried directly, so you know to ignore 
> responses coming from someone else. That gives you net (the 
> same gtld, how convenient) and authoritative IP response for 
> its NS. So you look up za.net and get correct glue and so on.
> 
> Actually, if glue were always served up the resolution chain 
> then then only crummy glueless delegations would be vulnerable.
> 
> Anyone feel like redesigning the DNS protocol? Anyone? No? :(
> 
> 

Re: Software router state of the art

[Deepak Jain]

Another option (if you want a pure Cisco platform) would be to buy a 
used Cisco 7500 or 7200 and put a T3 card in there. Those are probably 
super cheap through reseller channels. (<<$20K for a 1+1).


A quick scan of Ebay shows a PA-MC-T3 for <$3K, a 7505 +RSP4+PS for $300 
and a fast ethernet blade for $30.00.


Excluding software licenses (assuming its not running something that its 
not perpetually licensed to something that will run the T3 card) you are 
looking at about $3K per T3 in HW.


Deepak  

Re: Great Suggestion for the DNS problem...?

[Jay R. Ashworth]

On Mon, Jul 28, 2008 at 12:35:30PM -0700, Tomas L. Byrnes wrote:
> As you pointed out, the protocol, if properly implemented, addresses
> this. 
> 
> There should always be Glue (A records for the NS) in a delegation. RFC
> 1034 even specifies this:
> 
> 4.2.2 
> As the last installation step, the delegation NS RRs and glue RRs
> necessary to make the delegation effective should be added to the parent
> zone.  The administrators of both zones should insure that the NS and
> glue RRs which mark both sides of the cut are consistent and remain so.
> 

A probably important distinction:

That's not the protocol, that's the specified implementation framework
of the protocol.  In general, DNS still works if you screw that up,
which is why it's so often screwed up.

Cheers,
-- jra
-- 
Jay R. Ashworth   Baylink  [EMAIL PROTECTED]
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

 Those who cast the vote decide nothing.
 Those who count the vote decide everything.
   -- (Josef Stalin)

Re: Software router state of the art

[Rubens Kuhl Jr.]

>> It keeps track of Src/Dst/QoS/Ethernet adapters/etc.. Additionally most
>> systems have the iptables modules loaded in kernel and the conntrack
>> module in kernel. This immediately activates connection tracking,
>> therefore considerably slowing down software routing. The most optimal
>> way of speeding this up would be sticking the route cache into somewhat
>> faster memory. Though it would be fairly nice to get rid of the route
>> cache as that can cause problem with eccentric setups. Also, as cache
>> entries take a moment to be deleted, or degrade leading to convergence
>> times being higher.
>
> Note .. to .. self ..  Linux .. makes .. crappy .. router.  Got it.
>
> Guess we'll continue to use FreeBSD, and the lesson to come away with
> is that it probably pays to avoid technologies that are suboptimal
> for the task at hand.  Not everything is created equal.  It also pays
> to tune things.  If "conntrack" hurts, then remove it.

You can use Linux without conntrack. You can either do "rmmod
ip_conntrack" (unload the module), rm /var/lib/modules/ip_conntrack
(or something like that to erase the file) or use the RAW queue to
forward some packets without connection tracking (-j NOTRACK) and some
others with conntrack (proxy redirection, captive portal and thinks
like that requires stateful forwarding in any platform).

I would be more worried about the prefix match and route cache done by
the operating system you are considering for use as a router. That
cannot be circunverted by turning off conntrack, pf or anything that
might do more with the packet that plain simple routing.


Rubens

Re: Software router state of the art

[Chris Stebner]

Deepak Jain wrote:


The problem I'm facing is that if I want something from Cisco that 
can do at least line-rate T3, I'm looking at least $20k per router. I 
don't have a uber-budget, so for me, that's kind of painful when I 
start to need more than one plus spare parts. But, I have a high 
level of confidence that I can put cards in, some memory, power it 
up, configure it and I'm good to go.


Junpier's J-series is a BSD based platform as far as I understand it. 
ImageStream is *much* more affordable for me, but is Linux-based, and 
I fear Linux as a router and I don't know what they've done to fix 
the common gripes with Linux-as-router. I have no idea if either of 
the two have hardware assist in the cards, but my impression is that 
they are essentially software platforms with custom interface cards. 
Interface cards are important to me because I'm operating in an 
environment where my link to the outside world is probably going to 
be T1/T3.


I'm aware of Cisco IOS, then BSD-based and Linux-based platforms that 
are actually sold as routing products. I also know there are a 
billion "yay, router!" things out there. T1 cards are easy to find. 
The only other place I know I could buy a T3 card from is Sangoma. 
Maybe someone has even used it* T3 card before. Rather than reinvent 
the wheel alone, nanog has to contain the highest concentration of 
people that have tried various things and already know what will work 
and what won't work. I'm not looking for OS politics, just 
operational experience from people who have access to more money and 
more hardware than I do to have tried more stuff.


If my best option is still from the big players, so be it. If there's 
something else that's just as stable, I want to hear about it. I'm 
not adverse to some dirty work, but I just don't have the time right 
now to jump in over my head into a software router project and then 
fight my way back to the surface. I'm not trying to create something 
for educational purposes, I need something suitable for a production 
environment.




[I didn't know what to cut from above, so I left it].

What I've used and seen used before that plays both to the strengths 
of the PC as a router and addresses some of the T3 related issues -- 
especially if you control both ends of the T3.


Using an FE to T3 bridge or FE to T1 bridge as the case may be. With a 
little tuning you can put a rate shaper on the PC (prior art, very 
stable) to not run into off-PC buffering issues. Your PC has plenty of 
cheap buffer. The interface to the comms network is done through a 
dedicated, telco or computer center grade piece of gear.


Everyone here (NANOG) can agree that a 10 or 100Mb/s PC router is a no 
brainer and as long as you aren't using irresponsible gear, this thing 
will route packets forever.


Putting telco interfaces into PCs has always been a little more odd, 
but telco to ethernet bridges are fairly standard and fairly dumb. 
Depending on how many of these you have etc, you can do creative 
things with switches, FR, etc. And cost can be all over the map. I 
know Pairgain used to make good ethernet to T1 bridges, and that's 
probably the last time I remember playing with this stuff.


YMMV.

Deepak Jain
AiNET

To echo Deepak's suggestion and draw attention to the original statement 
"because I'm operating in an environment where my link to the outside 
world is probably going to be T1/T3." Would lead one to question the 
PA-MC-T3 even. Could be even cheaper if you don't need the multi-channel 
component (of course the monthly cost of the DS3 pales here in 
comparison w/ the h/w setup, but thought Id mention it regardless as it 
could save you 2 grand.) If all you need is a few t1's just pick up the 
VIP 2-50 interface card and a 4 x T1 adapter.


This solution can most be definitely be had for under 5 grand. with the 
RSP4+'s (ECC mem) youd be looking at greater than 99.99 percent uptime 
if configured with SSO.


-chris

Re: Software router state of the art

[Jack Bates]

Chris Stebner wrote:
This solution can most be definitely be had for under 5 grand. with the 
RSP4+'s (ECC mem) youd be looking at greater than 99.99 percent uptime 
if configured with SSO.


But if you end up needing BGP with full routes, throw that out the window. The 
RSP16's are expensive (even used relative to the RSP4) and usually necessarily 
for memory due to the current global routing table size. They are still cheap on 
the used market compared to list of most vendors, though.


Jack

Re: Great Suggestion for the DNS problem...?

[Colin Alston]

On 2008/07/28 09:52 PM Jay R. Ashworth wrote:

On Mon, Jul 28, 2008 at 12:35:30PM -0700, Tomas L. Byrnes wrote:

As you pointed out, the protocol, if properly implemented, addresses
this. 


There should always be Glue (A records for the NS) in a delegation. RFC
1034 even specifies this:

4.2.2 
As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.



A probably important distinction:

That's not the protocol, that's the specified implementation framework
of the protocol.  In general, DNS still works if you screw that up,
which is why it's so often screwed up.


Yes it should work. In fact, why *don't* implementations discard 
authoritative responses from non-authoritative hosts? Or do we? Or am 
I horribly wrong?


There's an argument that IP spoofing can easily derail this, but I'd 
shift that argument higher up the OSI, blame TCP, and move on to 
recommending SYN cookies. Even if forged though, if the forged IP 
returns NS authority glue that doesn't match the source, the lookup 
still fails.


DNSSEC kinda does this verification though, just more complicatedly 
and more reliant on administrative cooperation, and I've never met a 
DNS person who is cooperative ;)


My suggestion though was more of replacing
NS -> A -> IP
with
NS -> IP

That is just a brain fart though.

My 0.00264050803375 cents (at current exchange rates).

Re: Arbitrary de-peering

[Jay Hennigan]

Jon Lewis wrote:

On Mon, 28 Jul 2008, William Waites wrote:


Tier 1 has enough peering relationships with enough other Tier 1 
networks that they can always buy temporary transit privileges over an 
existing link.


Every peering agreement I've seen has language to the effect that an 
entity can't both be a transit customer and a peer.  Even if allowed, 
the temporary transit privileges would need to be provisioned and turned 
up which isn't going to happen instantaneously.



Tier 1 means you don't buy transit, no?


"We are a Tier 1 provider" tends to mean "I am a salesperson".

--
Jay Hennigan - CCIE #7880 - Network Engineering - [EMAIL PROTECTED]
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

RE: So why don't US citizens get this?

[Frank Bulk]

That's right on the moneynow, when significant portions of the plant
needs to be replaced, fiber is almost the de facto approach.

Frank

-Original Message-
From: Josh Cheney [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 28, 2008 12:39 PM
To: Jean-François Mezei; nanog@nanog.org
Subject: Re: So why don't US citizens get this?

Jean-François Mezei wrote:
> Does population density still REALLY matter ? Considering that fibre
> optic cables have a far longer reach than  copper, and considering that
> the utility poles already exist in less densely populated areas, it
> would seem to me that fibre would be a superior alternative to copper,
> especially when you consider the costs of setting up remotes all over
> the place for copper.
>
>
> And I would reckon that laying fibre along existing utility poles to
> reach 200 homes would cost far less than laying fibre in a concrete high
> rise appartment building to reach 200 appartments.

My understanding is that for a rural area, in a completely new rollout
or a forklift upgrade, fiber is cheaper than copper. However, because
the majority of the copper that is currently deployed is still highly
serviceable, it is very difficult to justify tearing out perfectly good
copper and laying out fiber in it's place.


--
Josh Cheney
[EMAIL PROTECTED]
http://www.joshcheney.com

Re: Software router state of the art

[Florian Weimer]

* Joe Greco:

> I'm not sure where the claims about "{one, few} flow{s}" are coming from.
> Certainly the number of flows on a typical UNIX box acting as a router is
> not that relevant unless you specifically configure something like 
> stateful firewalling, because the typical UNIX box simply doesn't have a
> *concept* of "flows."  It deals with packets.

You are mistaken.  Linux routing is flow-based.  Ever wondered what
those "dst cache overflow" messages mean you see during a DoS attack?
It's the flow cache complaining that it can't expire records in an
organic manner.

I don't know much about FreeBSD.  I think it got a route cache after
FreeBSD 4, too.  That's the reason why the FreeBSD 4 IP stack is still
so popular.

Re: So why don't US citizens get this?

[Charles Wyble]

Frank Bulk wrote:

That's right on the moneynow, when significant portions of the plant
needs to be replaced, fiber is almost the de facto approach.
  


Almost? What else is there? I mean besides copper/coax of course?

Why would you want to continue upgrading an outside plant based on that? 
I mean unless of course your a US telco. :)



--
Charles Wyble (818) 280 - 7059
http://charlesnw.blogspot.com
CTO Known Element Enterprises / SoCal WiFI project

Missing URL is here (was: So why don't US citizens get this?)

[michael.dillon]

As I was saying...

> Here in London they even steal bronze statues or brass 
> railings in a park to get the copper content. Here is one 
> account of the risks that copper thieves will go to. Don't 
> read it if you have a queasy stomach.



--Michael Dillon

RE: Software router state of the art

[michael.dillon]

> > Click for instance 

> Thanks for being oh-so-helpful with a serious question. Got 
> any useful answers for me? Give me a vendor that offers your 
> suggestion. I don't have time for a make-it-myself solution.

Sorry, but you're in the wrong place. The IP networking consultants
are over thataway, and if you pay them a nice daily fee they will
sort out your problem for you.

But if you want free suggestions, then you'll have to put up with
half answers, vendor fanboys, and the usual ruckus of NANOG.

--Michael Dillon

P.S. that was a serious suggestion up above. If you have an interest
in software routers, then you should look at it. If you just want to
buy products then all routers are software routers, most especially 
the ones that depend on something called IOS or Junos. Focus on the
capabilities that you need and the prices. Don't try to be pretend to
be a router designer.

Re: Software router state of the art

[Eugeniu Patrascu]

Rubens Kuhl Jr. wrote:

You can use Linux without conntrack. You can either do "rmmod
ip_conntrack" (unload the module), rm /var/lib/modules/ip_conntrack
(or something like that to erase the file) or use the RAW queue to
forward some packets without connection tracking (-j NOTRACK) and some
others with conntrack (proxy redirection, captive portal and thinks
like that requires stateful forwarding in any platform).

I would be more worried about the prefix match and route cache done by
the operating system you are considering for use as a router. That
cannot be circunverted by turning off conntrack, pf or anything that
might do more with the packet that plain simple routing.
  

Hi,

As of 2.6.x kernel version (at least on 2.6.17) there is a FIB 
implementation called LC_Trie which supposedly does an O(1) route lookup 
which is very fast.
Where I live there are a lot of linux boxes deployed as routers pushing 
line rate GE for hundreds to thousand nodes computer networks while also 
deliverying QoS for each and every node.
From what I see in this thread you're more worried about T3/E3 
linecards than the actual Linux performance as a router.


As a personal example, I use a celeron 2.53Ghz with 512Mb of ram to push 
line rate 3 x 100Mbps cards wihout any discernable load reported either 
by top or uptime and that on top of Quagga with about ~ 5k prefixes.
Also, as an experiment I loaded a full routing table from one of my 
peers and besides of the increased RAM usage by Quagga to about 50MB the 
machine forwarded at the same rate, _maybe_ 1% incresed load.

Re: Software router state of the art

[Chris Stebner]

Jack Bates wrote:

Chris Stebner wrote:
This solution can most be definitely be had for under 5 grand. with 
the RSP4+'s (ECC mem) youd be looking at greater than 99.99 percent 
uptime if configured with SSO.


But if you end up needing BGP with full routes, throw that out the 
window. The RSP16's are expensive (even used relative to the RSP4) and 
usually necessarily for memory due to the current global routing table 
size. They are still cheap on the used market compared to list of most 
vendors, though.


Jack
I was "assuming" some level of route filtering/summarization as he did 
mention a single t1/t3 (at least used the word "link" - singular). Good 
point though, if you need more than 512mb mem, your gonna have to shell 
out the extra $10k for the pair of RSP16's


-chris

Re: Software router state of the art

[Seth Mattinen]

[EMAIL PROTECTED] wrote:

Click for instance 


Thanks for being oh-so-helpful with a serious question. Got 
any useful answers for me? Give me a vendor that offers your 
suggestion. I don't have time for a make-it-myself solution.


Sorry, but you're in the wrong place. The IP networking consultants
are over thataway, and if you pay them a nice daily fee they will
sort out your problem for you.

But if you want free suggestions, then you'll have to put up with
half answers, vendor fanboys, and the usual ruckus of NANOG.

--Michael Dillon

P.S. that was a serious suggestion up above. If you have an interest
in software routers, then you should look at it. If you just want to
buy products then all routers are software routers, most especially 
the ones that depend on something called IOS or Junos. Focus on the

capabilities that you need and the prices. Don't try to be pretend to
be a router designer.




I'm aware of Cisco IOS, then BSD-based and Linux-based platforms that 
are actually sold as routing products. I also know there are a billion 
"yay, router!" things out there. Rather than reinvent the wheel alone, 
nanog has to contain the highest concentration of people that have tried 
various things and already know what will work and what won't work. I'm 
not looking for OS politics, just operational experience from people who 
have access to more money and more hardware than I do to have tried more 
stuff.


~Seth

Re: Software router state of the art

[Rev. Jeffrey Paul]

On Mon, Jul 28, 2008 at 10:08:32PM +0100, [EMAIL PROTECTED] wrote:
> 
> But if you want free suggestions, then you'll have to put up with
> half answers, vendor fanboys, and the usual ruckus of NANOG.
> 

As much as I hate to contribute to the problem, I'd like to point out
that the barrage of useless, off-topic, empty traffic on this list in
the last week is, in my estimation, quite a bit above the "usual" ruckus
of NANOG.

While I'm not one to thunk down the rulebook, can you all collectively
knock it off?

Cheers,
-jp

-- 

 Rev. Jeffrey Paul-datavibe- [EMAIL PROTECTED]
  aim:x736e65616b   pgp:0xD9B3C17D  phone:1-800-403-1126
   9440 0C7F C598 01CA 2F17  D098 0A3A 4B8F D9B3 C17D
"Virtue is its own punishment."

Re: So why don't US citizens get this?

[Jay R. Ashworth]

On Mon, Jul 28, 2008 at 12:48:49PM -0500, Jorge Amodio wrote:
> > And I would reckon that laying fibre along existing utility poles to
> > reach 200 homes would cost far less than laying fibre in a concrete high
> > rise appartment building to reach 200 appartments.
> >
> > Problem is not laying fiber between poles, the last mile has been always
> the show killer.
> 
> 200 local loops + terminating equipment surely will cost more than 1 local
> loop + terminating equipment.

As it happens, we're looking into replacing about 30 HDSL4 T-1s with
fiber.  The copper loop charge, per T1, is about $180 a month or so.

The fiber loop charge, *per T1* is about $150.

Plus a $30 a month cross-connect charge.

I love tariffs, don't you?

Cheers,
-- jra
-- 
Jay R. Ashworth   Baylink  [EMAIL PROTECTED]
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

 Those who cast the vote decide nothing.
 Those who count the vote decide everything.
   -- (Josef Stalin)

Re: Software router state of the art

[Andrew D Kirch]

Rev. Jeffrey Paul wrote:

On Mon, Jul 28, 2008 at 10:08:32PM +0100, [EMAIL PROTECTED] wrote:
  

But if you want free suggestions, then you'll have to put up with
half answers, vendor fanboys, and the usual ruckus of NANOG.




As much as I hate to contribute to the problem, I'd like to point out
that the barrage of useless, off-topic, empty traffic on this list in
the last week is, in my estimation, quite a bit above the "usual" ruckus
of NANOG.

While I'm not one to thunk down the rulebook, can you all collectively
knock it off?

Cheers,
-jp
I haven't followed the other threads in the last week, but I don't think 
that a discussion of routers is off topic.  While Michael's opinion was 
expressed in a fairly tongue-in-cheek method as would be required by his 
response, I don't see anything offtopic, perhaps just hotly worded.


Anderw

Re: Software router state of the art

[Christopher Morrow]

On Mon, Jul 28, 2008 at 2:55 PM, Seth Mattinen <[EMAIL PROTECTED]> wrote:

> The problem I'm facing is that if I want something from Cisco that can do at
> least line-rate T3, I'm looking at least $20k per router. I don't have a
> uber-budget, so for me, that's kind of painful when I start to need more
> than one plus spare parts. But, I have a high level of confidence that I can
> put cards in, some memory, power it up, configure it and I'm good to go.
>

it's interesting that no one has mentioned the Nokia platform in this
discussion... they have a pc-based rackable server platform (in the
ip530/ip560 sized box) which would do T3 interfaces (from nokia I
believe even). Looking at the nokia website now I don't see WAN
capabilities below the 1220 though :( so you'd have to be in for that
at least.

-Chris

Re: Software router state of the art

[Seth Mattinen]

Andrew D Kirch wrote:

Rev. Jeffrey Paul wrote:

On Mon, Jul 28, 2008 at 10:08:32PM +0100, [EMAIL PROTECTED] wrote:
 

But if you want free suggestions, then you'll have to put up with
half answers, vendor fanboys, and the usual ruckus of NANOG.




As much as I hate to contribute to the problem, I'd like to point out
that the barrage of useless, off-topic, empty traffic on this list in
the last week is, in my estimation, quite a bit above the "usual" ruckus
of NANOG.

While I'm not one to thunk down the rulebook, can you all collectively
knock it off?

Cheers,
-jp
I haven't followed the other threads in the last week, but I don't think 
that a discussion of routers is off topic.  While Michael's opinion was 
expressed in a fairly tongue-in-cheek method as would be required by his 
response, I don't see anything offtopic, perhaps just hotly worded.




I wasn't too thrilled about being accused of OS politics when I was 
genuinely concerned about deploying a software router based on things 
I've heard in passing or read about here previously. It *is* nice to 
know that someone found out that FreeBSD 7 hates OSPF - since I actually 
use OSPF - and that would have tormented me for a while had I gone that 
route.


Back to the topic at hand, unfortunately I wouldn't have the luxury of 
converting T1/T3 to Ethernet. I've used cards from Digium and Sangoma in 
the past for T1 and been relatively pleased, although older Digium cards 
hated sharing an IRQ with anything.


~Seth

Re: Software router state of the art

[Kevin Day]

On Jul 28, 2008, at 1:55 PM, Seth Mattinen wrote:
I'm aware of Cisco IOS, then BSD-based and Linux-based platforms  
that are actually sold as routing products. I also know there are a  
billion "yay, router!" things out there. T1 cards are easy to find.  
The only other place I know I could buy a T3 card from is Sangoma.  
Maybe someone has even used it* T3 card before. Rather than reinvent  
the wheel alone, nanog has to contain the highest concentration of  
people that have tried various things and already know what will  
work and what won't work. I'm not looking for OS politics, just  
operational experience from people who have access to more money and  
more hardware than I do to have tried more stuff.


If my best option is still from the big players, so be it. If  
there's something else that's just as stable, I want to hear about  
it. I'm not adverse to some dirty work, but I just don't have the  
time right now to jump in over my head into a software router  
project and then fight my way back to the surface. I'm not trying to  
create something for educational purposes, I need something suitable  
for a production environment.


~Seth



We use a lot of Sangoma's stuff ourselves, both for data and TDM voice  
applications. For the most part, it's worked flawlessly. The few  
problems we've had were dealt with amazingly quickly on their end -  
one of their developers stayed well after midnight and gave me a  
custom fix for a problem that was pretty insignificant to us.


They support Linux a bit more strongly than FreeBSD, but both should  
work for what you need. Unless you're trying to install it on a 486,  
you'll have no problem handling 45mbps of traffic, bgp, nat,  
firewalls, etc. no matter what the PPS rate is.


You get the full source to their drivers, the only exception is the  
firmware loaded onto the echo canceler DSP for voice applications.


That said, they are a small company. Don't buy if you're expecting TAC  
level support contracts, glossy manuals or a GUI web interface to set  
the card up.


T3 levels of bandwidth are well inside the "no longer a problem" scale  
of software routing. Quagga or Xorp, combined with your favorite  
software firewall, nat, or other goodies and you're up. If I remember  
right, someone made a Xorp bootable CD that had Sangoma's drivers  
included, so you were up and running pretty fast.


If you want more specific info about anything, ask off list.

-- Kevin

Re: Software router state of the art

[Joe Greco]

> I wasn't too thrilled about being accused of OS politics when I was 
> genuinely concerned about deploying a software router based on things 
> I've heard in passing or read about here previously. It *is* nice to 
> know that someone found out that FreeBSD 7 hates OSPF - since I actually 
> use OSPF - and that would have tormented me for a while had I gone that 
> route.

Nonononono ... QUAGGA hates FreeBSD 7, and therefore Quagga OSPF does 
not work on FreeBSD 7.  OpenOSPFD has worked like a CHAMP.  Any issues
I have with OpenOSPFD are related to it not being Quagga, or as flexible
as Quagga, but I have had >0< issues with OpenOSPFD's reliability.  With
only a relatively short period to judge it, I'll note, but still, easy
to install, easy to deploy...

Easily enough that I'm having semi-serious thoughts ...

The problem appears to be related to FreeBSD having made changes to the
multicast API to become RFC-compliant.  Quagga has a bunch of workarounds
for various forms of brokenness present in Linux, etc., and my reading
suggests that Quagga is doing the wrong thing.

Quite frankly, this, and the loopback implosion OpenOSPFD caused when we
misconfigured it, are the worst things I've heard about software routing
this year.  Unlike most Cisco or Juniper issues, it's not a "reboot the
router" or "that'll be fixed 'soon'" type of thing.  You're free to open
up the hood and experiment yourself.

If your Cisco OSPF wasn't working, and Cisco didn't show any signs of
fixing it, it's a little more difficult to just pop the top and drop a
different routing protocol engine in.

Sorry for any misinterpretation.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Software router state of the art

[Bill Nash]

On Mon, 28 Jul 2008, Rev. Jeffrey Paul wrote:


As much as I hate to contribute to the problem, I'd like to point out
that the barrage of useless, off-topic, empty traffic on this list in
the last week is, in my estimation, quite a bit above the "usual" ruckus
of NANOG.

While I'm not one to thunk down the rulebook, can you all collectively
knock it off?


I gotta disagree with you, especially with regard to this thread. Much of 
the conversations on this topic have ancillary benefits, specifically for 
folks who need to populate networks with things like 10g forensic sensors 
or similiar. I don't see commodity hardware router discussions being any 
different from a foundry vs juniper vs crisco discussion, be it typical 
fanboy nonsense or otherwise. As far as active threads on nanog go, the 
signal to noise ratio on this one has already far exceeded more 
'operational' ones. Even anecdotal experiences noted thus far have been 
pretty insightful, and useful.


I even totally resisted the urge of bombing the thread by extolling the 
virtues of the Killer NIC as a solution to all the throughput problems 
people have, because I felt it would really derail what has thus far been 
a fairly educational thread.


That said though, the more I thought about it (the killer nic joke), the 
more I looked at it. What's the state of NPU offloading amongst software 
routers? Is the notion even viable? I've seen a couple remarks about 
various brands of network cards having various buffer and interrupt driven 
issues as serious limiters to pps throughput, which is what prompted me to 
think of it in the first place.


- billn

Re: Great Suggestion for the DNS problem...?

[Paul Vixie]

[EMAIL PROTECTED] ("Jay R. Ashworth") writes:

> [ unthreaded to encourage discussion ]
>
> On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote:
>> Nameservers could incorporate poison detection...
>>
>> Listen on 200 random fake ports (in addition to the true query ports);
>> if a response ever arrives at a fake port, then it must be an attack,
>> read the "identified" attack packet, log the attack event, mark the
>> RRs mentioned in the packet as "poison being attempted" for 6 hours;
>> for such domains always request and collect _two_ good responses
>> (instead of one), with a 60 second timeout, before caching a lookup.
>>
>> The attacker must now guess nearly 64-bits in a short amount of time,
>> to be successful. Once a good lookup is received, discard the normal
>> TTL and hold the good answer cached and immutable, for 6 hours (_then_
>> start decreasing the TTL normally).
>
> Is there any reason which I'm too far down the food chain to see why
> that's not a fantastic idea?  Or at least, something inspired by it?

at first glance, this is brilliant, though with some unimportant nits.

however, since it is off-topic for nanog, i'm going to forward it to
the [EMAIL PROTECTED] mailing list and make detailed comments
there.
-- 
Paul Vixie

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Great Suggestion for the DNS problem...?

[Michael Smith]

Hello All:


> From: Paul Vixie <[EMAIL PROTECTED]>
> Date: Tue, 29 Jul 2008 01:24:43 +
> To: Nanog <[EMAIL PROTECTED]>
> Subject: Re: Great Suggestion for the DNS problem...?
> 
> [EMAIL PROTECTED] ("Jay R. Ashworth") writes:
> 
>> [ unthreaded to encourage discussion ]
>> 
>> On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote:
>>> Nameservers could incorporate poison detection...
>>> 
>>> Listen on 200 random fake ports (in addition to the true query ports);
>>> if a response ever arrives at a fake port, then it must be an attack,
>>> read the "identified" attack packet, log the attack event, mark the
>>> RRs mentioned in the packet as "poison being attempted" for 6 hours;
>>> for such domains always request and collect _two_ good responses
>>> (instead of one), with a 60 second timeout, before caching a lookup.
>>> 
>>> The attacker must now guess nearly 64-bits in a short amount of time,
>>> to be successful. Once a good lookup is received, discard the normal
>>> TTL and hold the good answer cached and immutable, for 6 hours (_then_
>>> start decreasing the TTL normally).
>> 
>> Is there any reason which I'm too far down the food chain to see why
>> that's not a fantastic idea?  Or at least, something inspired by it?
> 
> at first glance, this is brilliant, though with some unimportant nits.
> 
> however, since it is off-topic for nanog, i'm going to forward it to
> the [EMAIL PROTECTED] mailing list and make detailed comments
> there.
> -- 
Still off topic, but perhaps a BGP feed from Cymru or similar to block IP
addresses on the list?

Regards,

Mike

Re: Great Suggestion for the DNS problem...?

[Matt F]

What would the ip-blocking BGP feed accomplish?  Spoofed source 
addresses are a staple of the DNS cache poisoning attack. 

Worst case scenario, you've opened yourself up to a new avenue of attack 
where you're nameservers are receiving spoofed packets intended to 
trigger a blackhole filter, blocking communication between your network 
and the legitimate owner of the forged ip address.


Michael Smith wrote:

Hello All:


  

From: Paul Vixie <[EMAIL PROTECTED]>
Date: Tue, 29 Jul 2008 01:24:43 +
To: Nanog <[EMAIL PROTECTED]>
Subject: Re: Great Suggestion for the DNS problem...?

[EMAIL PROTECTED] ("Jay R. Ashworth") writes:



[ unthreaded to encourage discussion ]

On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote:
  

Nameservers could incorporate poison detection...

Listen on 200 random fake ports (in addition to the true query ports);
if a response ever arrives at a fake port, then it must be an attack,
read the "identified" attack packet, log the attack event, mark the
RRs mentioned in the packet as "poison being attempted" for 6 hours;
for such domains always request and collect _two_ good responses
(instead of one), with a 60 second timeout, before caching a lookup.

The attacker must now guess nearly 64-bits in a short amount of time,
to be successful. Once a good lookup is received, discard the normal
TTL and hold the good answer cached and immutable, for 6 hours (_then_
start decreasing the TTL normally).


Is there any reason which I'm too far down the food chain to see why
that's not a fantastic idea?  Or at least, something inspired by it?
  

at first glance, this is brilliant, though with some unimportant nits.

however, since it is off-topic for nanog, i'm going to forward it to
the [EMAIL PROTECTED] mailing list and make detailed comments
there.
--


Still off topic, but perhaps a BGP feed from Cymru or similar to block IP
addresses on the list?

Regards,

Mike



  

Re: Great Suggestion for the DNS problem...?

[Brian Dickson]

What would the ip-blocking BGP feed accomplish? Spoofed source 
addresses are a staple of the DNS cache poisoning attack.
Worst case scenario, you've opened yourself up to a new avenue of 
attack where you're nameservers are receiving spoofed packets intended 
to trigger a blackhole filter, blocking communication between your 
network and the legitimate owner of the forged ip address.




Yes, but what about blocking the addresses of recursive resolvers that 
are not yet patched?


That would certainly stop them from being poisoned, and incent their 
owners to patch...


1/2 :-)

Brian


Michael Smith wrote:

Still off topic, but perhaps a BGP feed from Cymru or similar to 
block IP

addresses on the list?

Regards,

Mike

Re: Software router state of the art

[Aaron Glenn]

On 7/28/08, Seth Mattinen <[EMAIL PROTECTED]> wrote:
>
> Junpier's J-series is a BSD based platform as far as I understand it.
> ImageStream is *much* more affordable for me, but is Linux-based, and I fear
...snip...

AFAIK, none of Juniper's Juniper kit rocks BSD outside of the
management interfaces and control plane (not even sure about the
latter, tbh).

someone feel free to correct me...

Re: Off topic - RE: So why don't US citizens get this?

[Paul Wall]

On Mon, Jul 28, 2008 at 11:12 AM,  <[EMAIL PROTECTED]> wrote:
> Recommendation: Bandwidth purchase agreements (Service Level Agreements)
> that specify bandwidth, uptime and cost actually define connectivity thus they
> should contain a list of peers or network interconnections that will be
> maintained for the length of the agreement.
> Prepared by Nancy Paterson, York University July 23, 2008 [EMAIL PROTECTED]

How many buyers out there have SLAs which cover inter-provider/domain
connectivity?

How many sellers are willing to guarantee this level of connectivity
to their customers with a SLA?

How many peering contracts are worth the paper they're printed on, and
have teeth when subjected to attorney review, and none of the usual
30-90 day unilateral severability nonsense?

Therein lies your problem.

Drive Slow,
Paul Wall