Re: WSJ: Big tech firms seeking power

[Alexei Roudnev]

Mecahnical work converts to heat in the very end. Not _mostly 100%_ but
_absolutely 100%_.

Except if it is cell station which inducts energy into the radio wawes, and
minus some light coming out of the building (which removes energy as well).


- Original Message - 
From: "David Lesher" <[EMAIL PROTECTED]>
To: "nanog list" 
Sent: Saturday, June 17, 2006 4:08 AM
Subject: Re: WSJ: Big tech firms seeking power


>
>
> Speaking on Deep Background, the Press Secretary whispered:
> >
> >
> >
> > > who insist on perpetuating that most medieval of units... the BTU.
> >
> > Well, if you do away with that you can continue with the "mile" as well,
> > then lose the pounds and yards and gallons while you're at it.
>
> Great! Let's get started...
>
> > What is the amount of energy coming out of a server as heat as opposed
to
> > what you put in as electricity? My guess would be pretty close to 100%,
>
> Actually, it's closer to 100.00%. Most is heat directly, but some
> very small amount is mechanical work on the HD's, etc... and that
> is then room heat as the drives radiate heat to the room.
> The LED's emit photons that then heat the room, and so forth.
>
> The only energy that 'escapes' the building would likely be
> outgoing copper & glass data connectionsbut wait, there's
> incoming of THOSE too. [But...  if a server farm, there's more
> bits out than in...]
>
> > In one of our data centers we use community cooling, we get 4 C (I think
> > it was approx 4 C) degree water and we're required to heat it at least
by
> > 8 C before we return it, this is then used in the community power plant
to
> > produce hot community water, and this process I've been told is quite
> > effective. Any thoughts on this? Guess it doesn't work in the boondocks
> > though...
>
> > I guess none of this makes sense in the southern part of the US, but
> > further up north where houses actually need heating and not cooling most
> > of the year, are things like this done?
>
> Almost never. In the immediate focus of the US it's cheaper to
> import foreign oil/mine & burn coal than to invest capital to do
> something more efficiently.
>
> [Hmmm, I wonder what the current power price is in the
> Niagara River Valley? Their cheap power was why so many steel
> mills/aluminum smelters/etc located there eons ago. Plus, there's
> copious H2O cooling and I have to think there are massive buildings
> available in the area just for paying the back taxes...]
>
> [This has drifted way OT and I'm out of here...]
>
>
> -- 
> A host is a host from coast to [EMAIL PROTECTED]
> & no one will talk to a host that's close[v].(301) 56-LINUX
> Unless the host (that isn't close).pob 1433
> is busy, hung or dead20915-1433
>

Re: WSJ: Big tech firms seeking power

[Alexei Roudnev]

Seen few data centers:
- biggerst cages are about 500 servers, may be you can pack 1,000 servers;
- ok, how many cagses in the medium size building? I''d say, 100 - 200 (may
be less).

So, 1 building can handle 50,000 - 100,000 servers. A very big building, I
guess, can handle 450,000. But what for?
You can put it al together, but how you deliver input data and ship output
data from 450,000 servers?


- Original Message - 
From: "Michael Loftis" <[EMAIL PROTECTED]>
To: "Alex Rubenstein" <[EMAIL PROTECTED]>; 
Sent: Friday, June 16, 2006 3:32 PM
Subject: Re: WSJ: Big tech firms seeking power


>
>
>
> --On June 16, 2006 5:24:27 PM -0400 Alex Rubenstein <[EMAIL PROTECTED]> wrote:
>
>
> > But wait, there is more. Just a point of comparison -- Oyster Creek
> > Nuclear Power generation plant, located here on the Jersey Shore,
> > produces 636 megawatts. You'd take one-tenth of that capacity -- in a
> > bulding that would sit on a 10 or 20 acre chunk of land. I put this into
> > the 'unlikely' category. The substation alone to handle stepping 68
> > mwatts from transmission to 480v would be probably 4 acres. And, 68
> > megawatts of power at 480 volts 81,888 amps. A typicall 200,000 sq-ft
> > multi-tenant office building has 1600 amps of service; this would be the
> > equivalent of 50 buildings.
> >
> > Having fun yet?
>
> I happen to know that a very large power line project was just finished in
> that area :)  (I have family that works for the company that did the job).
> It's a huge amount of power that's for sure.  I'm not sure what the exact
> route was, nor the endpoint right now, but when I did ask him at the time
> it didn't make senseNow it might.  I'll talk to him again.
>
>
>

Re: WSJ: Big tech firms seeking power

[Alexei Roudnev]

I used very raw estimation (which is not well correct but dont make too much
of errors)  - to remive 1 KW out of building, yiou spend extra 1 KW.

But anyway, 450,000 servers have a great power consumption - you can use
river or a lake to cool them, but you still need 45,000 KW of power to make
them work. So, to say 60,000KW - 100,000KW will nopt be a big mistake (total
power consumption).

Of course, if you build data center inside the the power plant dam, then you
have both, enough cooling and enough power. -:)


- Original Message - 
From: "Matthew Crocker" <[EMAIL PROTECTED]>
To: 
Sent: Friday, June 16, 2006 1:16 PM
Subject: Re: WSJ: Big tech firms seeking power


>
> > I wonder just how much power it takes to cool 450,000 servers.
>
> 450,000 servers * 100 Watts/Server = 45,000,000 watts / 3.413 watts/
> BTU = 13.1 Million BTU / 12000 BTU/Ton = 1100 Tons of cooling
>
> A 30 Ton Liebert system runs about 80 amps @ 480 volts or 38400
> watts,  you'll need at least 40 or them to cool 1100 tons which is
> 1536 Kw * 24 hours * 7 days * 4.3 weeks = 1,110,000 KwH/month * $0.10/
> KwH = $111,000 /month in cooling.
>
> I think my math is right on this...
>
> --
> Matthew S. Crocker
> Vice President
> Crocker Communications, Inc.
> Internet Division
> PO BOX 710
> Greenfield, MA 01302-0710
> http://www.crocker.com
>

Re: WSJ: Big tech firms seeking power

[Alexei Roudnev]

450,000 * 100 WT (power itself)

Cooling - I donot know, but I should estimate it as extra 70% of consumed
power.

So,

 450,000 * 0.2KWT = 90,000KWT.


- Original Message - 
From: "chuck goolsbee" <[EMAIL PROTECTED]>
To: 
Sent: Friday, June 16, 2006 10:47 AM
Subject: Re: WSJ: Big tech firms seeking power



>I wonder just how much power it takes to cool 450,000 servers.

I've heard mumbles that the per kWh rates from
Bonneville in the locations along the Columbia
are in the sub-4¢ range.

Grant county is seeing a huge fiber building boom
as a result. It will be more wired up than King
county soon. Woody was here last night and
remarked (feel free to correct me if I misquote
you Bill) that it was funny that nowadays
"network geeks were more interested in kilowatts
than kilobits"


--chuck (in Seattle)

Re: Black Frog - the botnets keep coming

[Alexei Roudnev]

I did not mean _dont fight them_. I mean _fight and learn to live with
them_. They did existed and will exist; and it is better,
if they exist in some numbers (they play a role of predators in wildlife,
eating weakerst -:) - of course, it looks strange and I do not like them,
too).

Netwok must be designed to survive few DDOS attacks easily, by
auto-isolating and auto-limiting such traffic. Else,
you will have a serious problems if real traffic became congested (for
example, everyone rush to download fee iPOD songs).

Script-kiddies... what's about them, they existed in 199x-th as well and
they will exist in 201x. Just as mountain lionss do exists in Bay Area (and
sometimes can eat your favorite cat...)



- Original Message - 
From: "Suresh Ramasubramanian" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>
Cc: "Fergie" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;

Sent: Monday, May 29, 2006 10:38 PM
Subject: Re: Black Frog - the botnets keep coming


> On 5/30/06, Alexei Roudnev <[EMAIL PROTECTED]> wrote:
> >
> > You have not other chance than to accept it - itr is real life. Period.
> >
>
> So are (for example) skript kiddies.

Re: Black Frog - the botnets keep coming

[Alexei Roudnev]

You have not other chance than to accept it - itr is real life. Period.

- Original Message - 
From: "Fergie" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; 
Sent: Saturday, May 27, 2006 2:59 PM
Subject: Re: Black Frog - the botnets keep coming


Sorry, this is not acceptable, regardless of national boundaries.

And it will be fought against, regardless of where it originates,
or resides. Always.
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Black Frog - the botnets keep coming

[Alexei Roudnev]

Internet IS a wild west. You should live with it. It will never be _quet,
dead american's residential area, where dogs do not bark and kids do not
play themself on streets in age of 8 (normal dogs bark, and normal kids
often play themself when they are 8)_.

It is the whole WORLD, not one country.

So, we must live with it, and do not hope, that it will have numerous _speed
tickets_ and _police officers_ (as 90% of the people live every day, making
their own decisions and protecting themselves.

It is, in fact, a very effectiv way to stop spammers. But it definitely
became a dangerous DDOS service. So - learn how to live with it, it's the
only choice. (Make sure, that no single protocol or botnet can kill the
whole network or deplete all resources, for example).


- Original Message - 
From: "Gadi Evron" <[EMAIL PROTECTED]>
To: "Florian Weimer" <[EMAIL PROTECTED]>
Cc: 
Sent: Thursday, May 25, 2006 3:38 AM
Subject: Re: Black Frog - the botnets keep coming


>
> On Thu, 25 May 2006, Florian Weimer wrote:
> >
> > * Gadi Evron:
> >
> > > http://news.google.com/news?q=black+frog
> > >
> > > How do we make this folly stop?
> >
> > Ignore it?  It's an inactive Sourceforge project (with some Google
> > forums attached), and news reports seem to be based on a Slashdot
> > diary entry announcing it:
>
> Ignoring is the high-road. How long are we going to cry about the Internet
> being a battle-ground, the wild west, or whatever else if we legitimize
> DDoS?
>
> Sometimes being quiet is not going to win the war. There will be other
> Blue Frogs.
>
> >
> >   
> >
> > There are far more dangerous Sourceforge projects out there. 8-/
> >
>

Re: Open Letter to D-Link about their NTP vandalism

[Alexei Roudnev]

Hmm, if some idiot wrote my NTP IP into his hardware, I just stop to monitor
my NTP and make sure that it have few hours of error in time. No one require
me to CLAIM that I set up wrong time, BUT no one can require me to maintain
correct time just because some idiots use my server.

The same in this case - instead of long claiming, complaining and so on they
could just set up wrong time (and never claim that they did it - just _oo,
we have a wrong time.. Thanks, but we do not maintain this NTP server and we
cannot change anything on this server so we cannot correct it_ - and problem
could be solved forever. And even could maintain different NTP translation
fro their customers. Just again, no one can prohibit it, even in USA. Just
_DO NOT CLAIM_ that it was intentionally.

Here is a difference  - _coffee is hot, someone's server is brokn, if
'Ivan||Paul||Lisa' have a CD he/she always can make a copy,
fire can burn, dog can bite_ - everyone should know it; if he do not know,
it's his personal problems, not someone's liability. Kids MUST learn such
things when they are young. It is COMMON SENSE.

- Original Message - 
From: "Michael Froomkin - U.Miami School of Law" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "John Dupuy" <[EMAIL PROTECTED]>
Sent: Tuesday, April 11, 2006 11:29 AM
Subject: Re: Open Letter to D-Link about their NTP vandalism


>  I'd really suggest that readers confirm this claim (that
> intentional sending of false data with a malicious purpose is perfectly
> acceptable) with a local lawyer before trying it at home or at work. professor>
>
> I also bet that the claim of widespread acceptability would fail badly if
> we weigh countries by population.  Or even connectivity.
>
> Not to mention the fact that your packets might stray across borders
> sometimes.
>
> On Tue, 11 Apr 2006, Alexei Roudnev wrote:
>
> >
> > It's legal to have broken NTP server in ANY country, and it's legal in
most
> > (by number) countries to send counter-attack (except USA as usual, where
> > lawyers want to get their money and so do not allow people to
self-defence).
> >
>
> -- 
> http://www.icannwatch.org   Personal Blog: http://www.discourse.net
> A. Michael Froomkin   |Professor of Law|   [EMAIL PROTECTED]
> U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
> +1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
> -->It's warm here.<--

Re: Open Letter to D-Link about their NTP vandalism

[Alexei Roudnev]

It's legal to have broken NTP server in ANY country, and it's legal in most
(by number) countries to send counter-attack (except USA as usual, where
lawyers want to get their money and so do not allow people to self-defence).

So, it can be a GOOD prtactice in reality. But, of course, not in USA.
- Original Message - 
From: "John Dupuy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, April 11, 2006 9:00 AM
Subject: Re: Open Letter to D-Link about their NTP vandalism


>
> To keep this operational: Operationally the network operator should
> contact a lawyer before doing something like this.
>
> Purposely and knowingly sending bad data in order to do harm is a
> counter-attack. As such it might be vigilantism, which is illegal in
> most countries. Or it might be self-defense, which is not illegal.
> Might. Contact a lawyer.
>
> John
>
> At 07:36 PM 4/10/2006, Simon Lyall wrote:
>
> >On Mon, 10 Apr 2006 [EMAIL PROTECTED] wrote:
> > > One particular piece of crapware of the tucows archive variety would
retry
> > > once per second if it hadn't heard a response - but a ICMP Port
Unreachable
> > > would trigger an *immediate* query, so it would basically
> > re-query at whatever
> > > the RTT for the path was.
> >
> >I've said in other forums the only solution for this sort of software is
> >to return the wrong time (by several months). The owner might actually
> >notice then and fix the problem.
> >
> >Just not returning anything means the time still works on the querying
> >device (especially if it uses multiple servers) and the problem will not
> >be noticed and it will continue.
> >
> >--
> >Simon J. Lyall  |  Very Busy  |  Web: http://www.darkmere.gen.nz/
> >"To stay awake all night adds a day to your life" - Stilgar | eMT.
>

Re: Backbone Monitoring Tools

[Alexei Roudnev]

Snmpstat was esigned for ISP in Russia, and is used actively by a few ISP. I
modified it for enterprise here in USA and use for entyerprise monitoring as
well. It if _fixed parameter system_ so it imonitors just
routeres/switches/firewalls for a limited set of parameters (interfaes and
ports) but do it very well and have very useful compactt view, tickets,
sopund alerts for opertators, etc.

It uses simple config file which can be easily generated or can be modified
by the web. I use it (Poll.conf file) as a primary documentation (saving it
into CVS on each change). We are using snmpstat in combination with cricket
or mtg (which monitors parameters not covered by snmpstat), and combine it
with CCR - cisco configuration repository (track cisco config changes),
ProBIND2 (control all DNS'es around), acid (snort viewer), inventory
database (shows hardware in the racks), alert aliasing system (just set of
aliases + archive for alerts, warnings and so on), osiris (control server's
changes), and few other tools (you can see short description on the snmpstat
page).

It is not (yes; I have it in TODO but did not had demand so it was not
completed) packed as 'rpm' or well auto-configured (but the only problem we
hais usually _fix small inconsistancy in include files of embeddded snmp
package), but is very fast (we monitor 1,000 - 2,000 interfaces without any
visible impact on our FreeBSD servers) and relatively simple.




- Original Message - 
From: "Jim Trocki" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>
Cc: "Ray Burkholder" <[EMAIL PROTECTED]>; "'Ashe Canvar'"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 29, 2006 5:09 AM
Subject: Re: Backbone Monitoring Tools


> On Wed, 29 Mar 2006, Alexei Roudnev wrote:
>
> >
> > I use snmpstatd - snmpstat.sf.net .
> >
>
> Oooh, looks nice!
>
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> >> Ashe Canvar
>
> >>  2. actively detect routing changes / failover to redundant paths using
> >> traceroutes
> >>  i.e. alert if  SFO->CHG->NYC changes to SFO->LXE->HOU->NYC
> >>  ( link state protocols suck as far as testing backup paths go)
>
> Ashe,
>
> I've done this using "mon" (http://www.kernel.org/software/mon/). It comes
with
> two traceroute monitors which remember the past paths and alert when that
path
> changes. In fact, one of the monitors can even detect load-balanced
alternate
> paths, e.g. if there are multiple possible intermediate paths during
normal
> operation.
>
> You'll want to look at the latest 1.1 release from CVS:
>
>  http://www.kernel.org/software/mon/development.html
>
> >> 3. actively transfer a fixed file
> >>i.e. draw a datarate grid between every datacenter and every other
> >> datacenter
>
> In fact, I belive people have done precisely this with mon before.
> Try asking on the mailing list, I'm quite sure someone will respond.
>
> >> I am in a buy vs. build debate with my boss ;)
>
> Build! I think mon gets you at least 90% to where you want to go.
>

Re: Backbone Monitoring Tools

[Alexei Roudnev]

I use snmpstatd - snmpstat.sf.net .

- Original Message - 
From: "Ray Burkholder" <[EMAIL PROTECTED]>
To: "'Ashe Canvar'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, March 28, 2006 4:47 PM
Subject: RE: Backbone Monitoring Tools


>
> A few more comments.
>
> I found a link to snmp management for ospf in an archive message:
>
http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a00
> 801177ff.shtml.  That may yield you the info you need for monitoring links
> and/or routes.
>
> >From my other message, if you collect 1) and 3) with cricket, you can
> extract RTR and bandwidth data with perl from cricket's config file.  I
took
> a bit of code reverse engineering, but I managed to get some mod_perl code
> going to do such a thing, so it can be done.  If you pull out the
> appropriate interface stats, you'd be able to generate your grid for 1)
and
> 3).
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Ashe
> Canvar
> Sent: Tuesday, March 28, 2006 20:07
> To: [EMAIL PROTECTED]
> Subject: Re: Backbone Monitoring Tools
>
>
> Thanks for the quick responses. Perhaps I should have been more explicit.
>
> I already use "remstats"
> (http://remstats.sourceforge.net/release/index.html) for interface b/w
> monitoring. I have worked with nagios and openview int he past.
>
> I have an ospf based network. The specific monitoring problem I am trying
to
> solve is  :
>
>  1. actively test the currently active path for packet loss and transfer
>  i.e. draw a latency grid between every datacenter and every other
> datacenter
>
>  2. actively detect routing changes / failover to redundant paths using
> traceroutes
>  i.e. alert if  SFO->CHG->NYC changes to SFO->LXE->HOU->NYC
>  ( link state protocols suck as far as testing backup paths go)
>
> 3. actively transfer a fixed file
>i.e. draw a datarate grid between every datacenter and every other
> datacenter
>
>
> So, I am not looking for a generic graphing/alerting NMS. Does anyone use
a
> specific tool that is capable of doing this ?
>
> I am in a buy vs. build debate with my boss ;)
>
> Regards,
> Ashe.
>
>
>
>
>
>
> On 3/28/06, Josh Cheney <[EMAIL PROTECTED]> wrote:
> >
> > I have had a decent amount of success with Nagios. It is not trivial
> > to setup, but once it is up and running, it has always handled our
> > dependencies and such very well. Additionally, because it calls
> > external programs to do the checks, it is pretty simple to write a
> > script that measures whatever value you would like to monitor. As I
> > said before, it is a pain to set up initially, but after getting it
> > set up, I couldn't be happier with it.
> >
> > Ashe Canvar wrote:
> > > Hi All,
> > >
> > > I want a simple backbone monitor for my 5 datacenters. My "backbone"
> > > consists of  redundant IPSEC/GRE tunnnels.
> > >
> > > At the very least I want to ping, traceroute and transfer a small
> > > file every few minutes over all IPSEC links. I am sure there are
> > > products that do this already, but I am having a hard time finding
any.
> > >
> > > The display format should be noc-friendly. A basic grid with
> > > green/red status indicators at the least. Geographical maps a plus.
> > >
> > > Do most of you use a home grown tool for this monitoring and alerting
?
> > >
> > > Regards,
> > > Ashe
> > >
> > > .
> > >
> >
> > --
> > Josh Cheney
> > [EMAIL PROTECTED]
> > http://www.joshcheney.com
> >
>
> --
> Scanned for viruses and dangerous content at http://www.oneunified.net and
> is believed to be clean.
>
>
>
> -- 
> Scanned for viruses and dangerous content at
> http://www.oneunified.net and is believed to be clean.
>

Re: shim6 @ NANOG (forwarded note from John Payne)

[Alexei Roudnev]

>
> Thus spake <[EMAIL PROTECTED]>
> > Let's face it, IPv6 is close enough to IPv4 that any
> > attempt to put a price on IPv4 addresses will simply
> > cause a massive migration to free and plentiful IPv6
> > addresses.
>
> You assume that there will be a source of free and plentiful IPv6
addresses.
Why not? It is CORE idea of IPcv6 addres space (no matter whart is written
abouyt allocation policies).
And I can bet, we will see how every business can get PI space when required
(in ipv6) for multi home,
in less than 3 - 4 years.

Except if IPv6 will be replaced by something simpler and more reliable like
IPv8 (but it looks very unlikely now).

Re: a plea re: shim6

[Alexei Roudnev]

I love long discussion about dead cow (shim6). The early we forget about
this dumb idea the better.


- Original Message - 
From: "Michael Loftis" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, March 01, 2006 2:34 PM
Subject: Re: a plea re: shim6


>
>
>
> --On March 1, 2006 12:08:21 PM -0800 Matt Ghali <[EMAIL PROTECTED]> wrote:
>
> > AFAIK there is no deployed, or even working shim6 code.
>
> No there isn't
>
> > As such, it is not an operational issue by any stretch of the
imagination.
>
> > There are a number of more apropriate mailing lists for discussion of
> > issues surrounding the design and operation of shim6.
> >
> > Coincidentally, I am not subscribed to them.
> >
> > Please let it go.
>
> I have to agreeI'm also not subscribed because after perusing various
> information available on it I've figured out that SHIM is an acronym for
> Sorry, Half-a__ed Implementation of Multihoming.
>
> $0.1USD
>
>

Re: protocols that don't meet the need...

[Alexei Roudnev]

How do you count # of networks? 8M means - 8M of independent, multihomed
companies. What is the reson to expect so many?
Don't forget that today's number of networks is multiplied few times because
you (foten) need to get more than 1
allocation. And what is a problem with 8M networks in next 8 years (if we
easily handle 200K just now)?

No, this model is well scalable and we better solve other, REAL problems,
not mistical _# of networks_ one.


- Original Message - 
From: "Per Heldal" <[EMAIL PROTECTED]>
To: "Mikael Abrahamsson" <[EMAIL PROTECTED]>
Cc: 
Sent: Wednesday, February 15, 2006 11:45 AM
Subject: Re: protocols that don't meet the need...


>
>
> On Wed, 15 Feb 2006 16:31:56 +0100 (CET), "Mikael Abrahamsson"
> <[EMAIL PROTECTED]> said:
> [snip]
> > The current routing model doesn't scale. I don't want to sit 5 years
from
> > now needing a router that'll handle 8 million routes to get me through
> > the
> > next 5 years of route growth.
>
> agree!
>
> >
> > PI space for multihoming and AS number growth is a bad thing for scaling
> > and economics, however you look at it.
>
> agree!
>
> >
> > Shim6 would hopefully curb the prefix growth very early in the growth
> > curve as single entities won't need AS to multihome between two
different
> > ISPs.
>
> agree!
>
> [snip]
>
> All is well if shim6 succeeds it seems ... 5-10 years into the future.
> Do we all agree to postpone v6 till then?
>
> If not there's a need for an intermediary solution. To me it seems like
> people want 2 things:
>
> 1. A working solution. The only alternative with current technology is
> PI end-site assignments.
>
> 2. Reasonable predictability. To make ever-lasting technologies and
> policies may be the dream in some research communities. The rest of us
> have to work with what we got and accept that we have to upgrade and
> make substatial changes to our networks from time to time. An
> alternative to satisfy those who fear the long term effect of a growing
> routing-table could be temporary end-site assignments from dedicated
> address-blocks. At some point in the future, when new-and-mature
> technology exist, the RIR-community could decide on new policies and
> decide to re-claim the entire block on e.g. a 24-month notice.
>
> ... just my $.02 compromise ;)
>
> //per
> -- 
>   Per Heldal
>   http://heldal.eml.cc/
>

Re: protocols that don't meet the need...

[Alexei Roudnev]

So what? They are good for the customers, and then, scaling problems are
minor (esp. if you count
on decreasing of # of allocations per company).

> > PI space for multihoming and AS number growth is a bad thing for scaling

Re: Is my router owned? How would I know?

[Alexei Roudnev]

Some Cisco IOS'es have numerous bugs, related to SNMP (I watched few cases,
when all Cisco's 72xx lost configuration becuase of receivbing something
bogus), so SNMP should be filtered out from public internet.


- Original Message - 
From: "Mikael Abrahamsson" <[EMAIL PROTECTED]>
To: "NANOG" 
Sent: Thursday, January 12, 2006 2:09 PM
Subject: Re: Is my router owned? How would I know?


>
> On Thu, 12 Jan 2006, Rob Thomas wrote:
>
> > If there are new or changed SNMP RW community strings, look out!
>
> If you have any SNMP v1/v2 RW communities what so ever, you're likely to
> be owned, at least if they're common to several units in your network and
> you don't limit what part of the tree the RW communities can access.
>
> Seems like a common attack vector is to send SNMP WRITE and upload the
> router configuration to a hacked tftp server, and then iterate thru the
> network as a lot of people have a single SNMP WRITE community in their
> network.
>
> -- 
> Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: Is my router owned? How would I know?

[Alexei Roudnev]

http://snmpstat.sourceforge.net/CCR-config.htm

- Original Message - 
From: "Randy Bush" <[EMAIL PROTECTED]>
To: "Jared Mauch" <[EMAIL PROTECTED]>
Cc: "NANOG" 
Sent: Thursday, January 12, 2006 1:00 PM
Subject: Re: Is my router owned? How would I know?


> 
> >> Configuration Change Notification and Logging. Releases of Cisco IOS
> >> software prior to 12.3(4)T/12.2(25)S lack the ability to track the
> > So no 76k(*)/GSR software, or any other platform specific releases.
> > Seems like a bit of a challenge to template this across ones
> > network.
> 
> for the three nanog readers who are unaware of what most of
> us use
> 
>http://www.shrubbery.net/rancid/
> 
> randy
> 

Re: Is my router owned? How would I know?

[Alexei Roudnev]

I use CCR (Cisco COnfiguration Repository, part of snmpstat project) and
have change reports daily, + have syslog reports hourly.
The same (osiris ) with hosts, btw.

- Original Message - 
From: "Rob Thomas" <[EMAIL PROTECTED]>
To: "NANOG" 
Sent: Thursday, January 12, 2006 10:19 AM
Subject: Is my router owned? How would I know?


>
> Hi, NANOGers.
>
> You all know how I love a good segue...  ;)
>
> How can you tell if your router has been owned?  In general the
> configuration will be modified.  This is why we advocate using rancid
> (or something akin to it) as both a configuration backup tool AND an
> early warning tool.  If you have a router running BGP, it also pays
> to peer with it externally.  You can use a private ASN and rackspace
> with a buddy.  You can use this peering to detect announcements you
> don't expect or necessarily condone.
>
> How else can you tell?  Here are some tips:
>
> If there is a new user account, or if the enable and access passwords
> have changed, look out!  The miscreants love to scan and find routers
> with "cisco" as the access and enable passwords.  They know that
> other miscreants are doing the same thing.  In fact this is even more
> widespread thanks to a module found in rBot and rxBot.  Yes, even
> bots are scanning for routers now.
>
> If there are new or changed ACLs, look out!  The miscreants love to
> use routers as IRC bounces.  To avoid detection by IRC server proxy
> monitors, the miscreants will block access to the router (generally
> all access, sometimes just TCP 23) from those proxy monitors using
> ACLs.
>
> If there are new or changed SNMP RW community strings, look out!
> One of the tricks they employ is to leave a SNMP RW community
> backdoor.  Is this to avoid the actions of we good folk?  No, it's
> usually employed in the case where a compromised router is stolen
> from one miscreant by another.
>
> If the banner has changed, look out!  As with the ACLs, this is a
> method by which the miscreants attempt to fool any proxy monitors.
> The most common banner we see identifies the router as a FreeBSD
> box.
>
> If tunnels suddenly appear on the router, look out!  Chaining
> together lots of routers is also common now.  This provides
> obfuscation and sometimes encryption.
>
> Most of the changes are based on templates.  Consider this bundled
> clue, where the prowess of the template user isn't at all a factor.
>
> Use the flows.  :)
>
> Thanks,
> Rob.
> -- 
> Rob Thomas
> Team Cymru
> http://www.cymru.com/
> ASSERT(coffee != empty);
>

Re: a record?

[Alexei Roudnev]

Are you sure? ?? statistics shows me opposite.

> "There are people actively scanning for any open ports running any
> protocol, without a SPECIFIC interest in your computer."


I mean - for ANY. Pretty easy to check - set up access liost with 'log' for
2 ports - port 22 and port 63023, and show us number of hits in 1 week.

My statistics shows 0 count on big non standard ports. Reason is simple -
full range scan is very slow, and have very low ratio of success, so it is
relatively useless.


>
> Allow me to re-state again in slightly different language so you
> understand this time:
>
> Changing your port may (will?) lower the number of automated scans
> you see hitting your daemon, but it will _NOT_ eliminate them.  IOW:
> Just because someone is probing for an SSH daemon on 65K ports
> against your box does _NOT_ mean he has a specific interest in your box.

Probing - not; trying to guess password - 100% YES.
But probing rate is 0 , to my surprtise.

>
> If you honestly believe that just 'cause someone tried "ssh -p 63xxx
> $YOUR.BOX" it means he is specifically targeting your box, well, that
> is your prerogative.  You are almost certain to be wrong at least
> part of the time, though.
>
> -- 
> TTFN,
> patrick

Re: a record?

[Alexei Roudnev]

Security by obscurity eliminates all (100%) of this automated scans and
automated attacks. So, having SSH on port 63023 (for example)  and seen
probes, you can be 100% sure that someone have SPECIFIC interest in your
site, and so you can spend time and investigate, what he is looking for (by,
for example, allowing to break into sandbox). It is impossible with port 22,
because 99.9% of this _attempts_ will be just _blind search attempts_, so
you will not be able to concentrate on _really dangerous_ specific interest
to your (because if I want to break into your site, and if I am serious,
then it is only matter of time when I succeed - for example, I can use
insiders, janitors, faked messages etc... so it is quite important of see
such attacks from beginning, in clear field, and to prevent them by
non-technical methods in addition to technical ones).

It is like 'NO TRESPASSING' sign on your private road - having this sign,
you can be (relatively) sure, that if you see intruder, he is (1) burglar,
(2) someone who lost in space and want to ask _where I am_, (3) FedEXP
delivery guy, but not just _strolling around one without any goal_. It is
first line selection, which is quite important because it decrease number of
events in thousands times.

Of course, this is only SIGN. Add good fence, rifle etc (castle, water
channel, draw bridge, knights -:)) if you have something which bad guys are
interested in. But post NO TRESPASSIGN first of all.

- Original Message - 
From: "Suresh Ramasubramanian" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>
Cc: "Patrick W. Gilmore" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, November 19, 2005 7:02 PM
Subject: Re: a record?


On 11/20/05, Alexei Roudnev <[EMAIL PROTECTED]> wrote:
> Other approach exists as well - SecureID on firewall. Login to firewall,
> authenticate, and have dynamic access list which opens ssh for you (and
> still keep ssh on port != 22).

Or VPN in, or set up a tunnel of some sort.  Have ssh available over
the tunneled interface.  Yup, lots of options available.

Though, if you have a secure ssh and reasonable control of your
passwords it is probably safe to leave it at port 22 rather than
resorting to security by obscurity measures like running it on a
higher number port or (as at least one webhost does) running it on
443, with some kind of shim listening on that port, intercepting
requests to it and redirecting them to apache or sshd as appropriate.

Re: a record?

[Alexei Roudnev]

I said many times - just use non standard port. Number of hackerts who
discover this port wil decrease approx 10,000 times, to
almost 0 (number).

(Of course, except if you are a bank).

Other approach exists as well - SecureID on firewall. Login to firewall,
authenticate, and have dynamic access list which opens ssh for you (and
still keep ssh on port != 22).


- Original Message - 
From: "Patrick W. Gilmore" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Patrick W. Gilmore" <[EMAIL PROTECTED]>
Sent: Tuesday, November 15, 2005 11:02 AM
Subject: Re: a record?


>
> On Nov 15, 2005, at 12:52 PM, Church, Chuck wrote:
>
> > Isn't it just good security practice to limit telnet/SSH access to
> > only
> > a few choice hosts/subnets?  I know I'd never allow the 0/0 net access
> > to a signon screen, even if it is SSH.  If you're on vacation and need
> > to access something, call your NOC, and have them temporarily allow
> > your
> > dynamic address for SSH.  When a hacker finds an open SSH host, they
> > think two things - This host is important to someone, and that they
> > need
> > more doughnuts...
>
> That is an excellent idea.  As soon as I hire a NOC for my personal
> boxes, I'll get right on that.  But, since I Am Not An Isp, I doubt
> that is going to happen soon.
>
> Remember, not every box on the Internet is supported by a whole
> network of resources (physical and human).
>
> -- 
> TTFN,
> patrick

Re: Scalability issues in the Internet routing system

[Alexei Roudnev]

If this 500K routes come from upstream, it is just _default_ so can be
installed instantly if configuration is correct.

If this 500K routes are from the peer, you switch (in reality) 10 - 20%, so
it is simpler anyway.

Even if it is multihome customer, there is not any need in _fast_
installation for these 500K routes. You just switch from one
provider to another _some_ of the routes - if it takes 1 minute, nothing
wrong happen.

Then, calculate:
500K routes, say 32 bytes/route (if not compressed by some way), 16MB.
T1 link, 100K/second, 160 seconds, 3 minutes.
100Mbit link, 10MB/second, 2 seconds.

T1 wil not be suitable for full routing of course, so what?

Just agaion - there are many tricks todo things right, out of theoretics of
IPv6 commitees.

- Original Message - 
From: "Blaine Christian" <[EMAIL PROTECTED]>
To: "Lincoln Dale" <[EMAIL PROTECTED]>
Cc: "Alexei Roudnev" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Daniel Senie"
<[EMAIL PROTECTED]>
Sent: Wednesday, October 26, 2005 6:06 PM
Subject: Re: Scalability issues in the Internet routing system


> >
> > there have been public demonstrations of released routers
> > supporting upwards of 1.5M IPv4+IPv6 prefixes and demonstrations on
> > routing churn convergence time. <http://www.lightreading.com/
> > document.asp?doc_id=63606> contains one such public test.
> >
>
> The http://www.lightreading.com/document.asp?
> site=testing&doc_id=63606&page_number=6 part may be a bit
> misleading.  For me it would be more interesting to see what happens
> when 500k routes completely disappear from the router then come
> back.   I want to see a 500k route push from a neighboring CRS in
> that amount of time...
>
> Of course the routes can switch quick when you use a layer of
> indirection (folks have been doing that for a few years now).  My
> question is how fast can you install routes from a standing start (or
> a 1/4 of a standing start if this is 2M prefixes).
>
> I will leave the question on whether it is actually worth an
> investment in time and resources as an exercise for the reader .
>
> Lightreading people,  test it like that!  It will be much more
> entertaining and perhaps even a bit enlightening to see how major
> vendors compare on "brand new" route installation into RIB and FIB.
> They only have to twiddle a couple bits to make indirection work
> quickly.  Having to deal with a brand new prefix is a completely
> different problem.
>
>
>
>
>
>
>
>

Re: Scalability issues in the Internet routing system

[Alexei Roudnev]

Forwarding is in line cards not because of CPU issues, but because of BUS
issues. It means, that card can be software based easily.

Anyway, as I said - it is only small, minor engineering question - how to
forward having 2,000,000 routes. If internet will require such router - it
will be crearted easily. Today we eed 160,000 routes - and it works (line
cards,m software, etc - it DO WORK).

- Original Message - 
From: "Lincoln Dale" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Daniel Senie" <[EMAIL PROTECTED]>
Sent: Wednesday, October 26, 2005 2:42 AM
Subject: Re: Scalability issues in the Internet routing system


>
> Alexei Roudnev wrote:
> > You do not need to forward 100% packets on line card rate; forwarding
95%
> > packets on card rate and have other processing (with possible delays)
thru
> > central CPU can work good enough..
>
> heh.
> in the words of Randy, "i encourage my competitors to build a router
> this way".
>
> reality is that any "big, fast" router is forwarding in hardware -
> typically an ASIC or some form of programmable processor.
> the lines here are getting blurry again .. Moore's Law means that
> packet-forwarding can pretty much be back "in software" in something
> which almost resembles a general-purpose processor - or maybe more than
> a few of them working in parallel (ref:
> <http://www-03.ibm.com/chips/news/2004/0609_cisco.html>).
>
> if you've built something to be 'big' and 'fast' its likely that you're
> also forwarding in some kind of 'distributed' manner (as opposed to
> 'centralized').
>
> as such - if you're building forwarding hardware capable of (say) 25M
> PPS and line-rate is 30M PPS, it generally isn't that much of a jump to
> build it for 30M PPS instead.
>
> i don't disagree that interfaces / backbones / networks are getting
> faster - but i don't think its yet a case of "Moore's law" becoming a
> problem - all that happens is one architects a system far more modular
> than before - e.g. ingress forwarding separate from egress forwarding.
>
> likewise, "FIB table growth" isn't yet a problem either - generally that
> just means "put in more SRAM" or "put in more TCAM space".
>
> IPv6 may change the equations around .. but we'll see ..
>
>
> cheers,
>
> lincoln.

Re: Scalability issues in the Internet routing system

[Alexei Roudnev]

Vice versa. DDOS attack will never work by this way, because this router
will (de facto) prioritize
long established streams vs. new and random ones, so it will not notice DDOS
attack at all - just some DDOS packets will be delayed or lost.

You do not need to forward 100% packets on line card rate; forwarding 95%
packets on card rate and have other processing (with possible delays) thru
central CPU can work good enough.

It is all about tricks and optimizations - fast routing is not state of art
and can be optimized by many ways.
For now, it was not necessary; when it became necessary - it will be done in
1/2 year.


- Original Message - 
From: "Rubens Kuhl Jr." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 25, 2005 9:21 PM
Subject: Re: Scalability issues in the Internet routing system



Assume you have determined that a percentage (20%, 80%, whatever) of
the routing table is really used for a fixed time period. If you
design a forwarding system that can do some packets per second for
those most used routes, all you need to DDoS it is a zombie network
that would send packets to all other destinations... rate-limiting and
dampening would probably come into place, and a new arms race would
start, killing operator's abilities to fast renumber sites or entire
networks and new troubleshooting issues for network operators.

Isn't just simpler to forward at line-rate ? IP look ups are fast
nowadays, due to algorithmic and architecture improvements... even
packet classification (which is n-tuple version of the IP look up
problem) is not that hard anymore. Algorithms can be updated on
software-based routers, and performance gains far exceed Moore's Law
and projected prefix growth rates... and routers that cannot cope with
that can always be changed to handle IGP-only routes and default
gateway to a router that can keep up with full routing.
(actually, hardware-based routers based on limited size CAMs are more
vulnerable to obsolescence by routing table growth than software ones)

Let's celebrate the death of "ip route-cache", not hellraise this fragility.


Rubens





On 10/24/05, Alexei Roudnev <[EMAIL PROTECTED]> wrote:
>
> One question - which percent of routing table  of any particular router is
> REALLY used, say, during 1 week?
>
> I have a strong impression, that answer wil not be more than 20% even in
> biggerst backbones, and
> will be (more likely) below 1% in the rest of the world. Which makes a
hige
> space for optimization.
>
>
> - Original Message -
> From: "Daniel Senie" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, October 18, 2005 9:50 AM
> Subject: Re: Scalability issues in the Internet routing system
>
>
> >
> > At 11:30 AM 10/18/2005, Andre Oppermann wrote:
> >
> > >I guess it's time to have a look at the actual scalability issues we
> > >face in the Internet routing system.  Maybe the area of action becomes
> > >a bit more clear with such an assessment.
> > >
> > >In the current Internet routing system we face two distinctive
> scalability
> > >issues:
> > >
> > >1. The number of prefixes*paths in the routing table and interdomain
> > >routing system (BGP)
> > >
> > >This problem scales with the number of prefixes and available paths
> > >to a particlar router/network in addition to constant churn in the
> > >reachablility state.  The required capacity for a routers control
> > >plane is:
> > >
> > >  capacity = prefix * path * churnfactor / second
> > >
> > >I think it is safe, even with projected AS and IP uptake, to assume
> > >Moore's law can cope with this.
> >
> > Moore will keep up reasonably with both the CPU needed to keep BGP
> > perking, and with memory requirements for the RIB, as well as other
> > non-data-path functions of routers.
> >
> >
> >
> > >2. The number of longest match prefixes in the forwarding table
> > >
> > >This problem scales with the number of prefixes and the number of
> > >packets per second the router has to process under full or expected
> > >load.  The required capacity for a routers forwarding plane is:
> > >
> > >  capacity = prefixes * packets / second
> > >
> > >This one is much harder to cope with as the number of prefixes and
> > >the link speeds are rising.  Thus the problem is multiplicative to
> > >quadratic.
> > >
> > >Here I think Moore's law doesn't cope with the increase in projected
> > >growth in longest prefix match prefixes and link speed.  Doing longest
> > >prefix m

Re: IPv6 news

[Alexei Roudnev]

We do not think, that _it wil be IPv6_. IPv6 is a good example of _second_
system, and do not looks as _succesfull_ for now.
And it is not definitely _LAST PROTOCOL_.

It _can be_ IPv6, true. But it can be other protocol (or just workaround for
IPv4, as we had CIDR and CLASSLESS) instead.


- Original Message - 
From: "Gregory Edigarov" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, October 17, 2005 3:42 AM
Subject: Re: IPv6 news


>
> Just my 5 cents to the  topic:
>
> Don't you all think that IPv6 would not be so neccessary for the very
> long time yet, if the IPv4 allocation scheme would be done right from
> the very very beginning?
> If the allocation policies would be something like the ones for ASn's.
> I.e. when you ask for IP space allocation you must be in the need to set
> your own routing policies.
> In any other cases you should use private network space with only one IP
> shown outside the network. Yes, this would be a headache for some
> appplications like IP telephony,
> but, I don't see any problems in making the _correct_  protocols so they
> could work through NAT.
>
> As what I see now is that a very large address blocks are allocated  to
> large companies,  what companies do with them? Correct, they ae
> installing them as IP's of workstations, when, if IPs
> would be treated as a very valuable resource from the beggining, they
> would have to use  at max /24 (well, may be 2 or three /24) for access
> routers.
>
> When they are proposing  /48 allocation scheme for  IPv6 they  must be
> out of their mind, because in case such allocation will be ineffect,
> IPv6 address space will end shortly too.
>
> Again, IPv6 is creating more problems then solve. Better solution would
> be to freeze IPv4 allocation, then force big IPv4 users to return the
> addresses to the "public pool",  and start
> allocation from the white piece of paper, doing the things right.
>
>
> -- 
> With best regards,
> GRED-RIPE
>

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Alexei Roudnev]

Randy; we are living on Earth with small size (only 6,000 km in radius), so
we will never see unlimited grouth in multihomed networks.

It is not a problem. We are not building Internet for the whole universe.
Good old Moore can deal with our planet very well.
I repeated many times - IPv6 idea of changing multihome approach is VERY BAD
and will not survise for more that 1 - 2 years. (if IPv6 survive at all,
which I have many doubts about).

- Original Message - 
From: "Randy Bush" <[EMAIL PROTECTED]>
To: "Daniel Golding" <[EMAIL PROTECTED]>
Cc: "Tony Li" <[EMAIL PROTECTED]>; "Fred Baker" <[EMAIL PROTECTED]>; "Per 
Heldal"
<[EMAIL PROTECTED]>; 
Sent: Monday, October 17, 2005 2:16 PM
Subject: Re: And Now for Something Completely Different (was Re: IPv6 news)


>
> >> There is a fundamental difference between a one-time reduction in the
> >> table and a fundamental dissipation of the forces that cause it to
> >> bloat in the first place.  Simply reducing the table as a one-off
> >> only buys you linearly more time.  Eliminating the drivers for bloat
> >> buys you technology generations.
> >>
> >> If we're going to put the world thru the pain of change, it seems
> >> that we should do our best to ensure that it never, ever has to
> >> happen again.
> >
> > That's the goal here? To ensure we'll never have another protocol
> > transition? I hope you realize what a flawed statement that is.
>
> tony probably did not think about it because that's not what he
> said at all.  he was speaking of routing table bloat, not
> transitions.
>
> and he was spot on.
>
> randy
>

Re: Scalability issues in the Internet routing system

[Alexei Roudnev]

One question - which percent of routing table  of any particular router is
REALLY used, say, during 1 week?

I have a strong impression, that answer wil not be more than 20% even in
biggerst backbones, and
will be (more likely) below 1% in the rest of the world. Which makes a hige
space for optimization.


- Original Message - 
From: "Daniel Senie" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 18, 2005 9:50 AM
Subject: Re: Scalability issues in the Internet routing system


>
> At 11:30 AM 10/18/2005, Andre Oppermann wrote:
>
> >I guess it's time to have a look at the actual scalability issues we
> >face in the Internet routing system.  Maybe the area of action becomes
> >a bit more clear with such an assessment.
> >
> >In the current Internet routing system we face two distinctive
scalability
> >issues:
> >
> >1. The number of prefixes*paths in the routing table and interdomain
> >routing system (BGP)
> >
> >This problem scales with the number of prefixes and available paths
> >to a particlar router/network in addition to constant churn in the
> >reachablility state.  The required capacity for a routers control
> >plane is:
> >
> >  capacity = prefix * path * churnfactor / second
> >
> >I think it is safe, even with projected AS and IP uptake, to assume
> >Moore's law can cope with this.
>
> Moore will keep up reasonably with both the CPU needed to keep BGP
> perking, and with memory requirements for the RIB, as well as other
> non-data-path functions of routers.
>
>
>
> >2. The number of longest match prefixes in the forwarding table
> >
> >This problem scales with the number of prefixes and the number of
> >packets per second the router has to process under full or expected
> >load.  The required capacity for a routers forwarding plane is:
> >
> >  capacity = prefixes * packets / second
> >
> >This one is much harder to cope with as the number of prefixes and
> >the link speeds are rising.  Thus the problem is multiplicative to
> >quadratic.
> >
> >Here I think Moore's law doesn't cope with the increase in projected
> >growth in longest prefix match prefixes and link speed.  Doing longest
> >prefix matches in hardware is relatively complex.  Even more so for
> >the additional bits in IPv6.  Doing perfect matches in hardware is
> >much easier though...
>
> Several items regarding FIB lookup:
>
> 1) The design of the FIB need not be the same as the RIB. There is
> plenty of room for creativity in router design in this space.
> Specifically, the FIB could be dramatically reduced in size via
> aggregation. The number of egress points (real or virtual) and/or
> policies within a router is likely FAR smaller than the total number
> of routes. It's unclear if any significant effort has been put into this.
>
> 2) Nothing says the design of the FIB lookup hardware has to be
> longest match. Other designs are quite possible. Again, some
> creativity in design could go a long way. The end result must match
> that which would be provided by longest-match lookup, but that
> doesn't mean the ASIC/FPGA or general purpose CPUs on the line card
> actually have to implement the mechanism in that fashion.
>
> 3) Don't discount novel uses of commodity components. There are fast
> CPU chips available today that may be appropriate to embed on line
> cards with a bit of firmware, and may be a lot more cost effective
> and sufficiently fast compared to custom ASICs of a few years ago.
> The definition of what's hardware and what's software on line cards
> need not be entirely defined by whether the design is executed
> entirely by a hardware engineer or a software engineer.
>
> Finally, don't discount the value and performance of software-based
> routers. MPLS was first "sold" as a way to deal with core routers not
> handling Gigabit links. The idea was to get the edge routers to take
> over. Present CPU technology, especially with good embedded systems
> software design, is quite capable of performing the functions needed
> for edge routers in many circumstances. It may well make sense to
> consider a mix of router types based on port count and speed at edges
> and/or chassis routers with line cards that are using general purpose
> CPUs for forwarding engines instead of ASICs for lower-volume sites.
> If we actually wind up with the core of most backbones running MPLS
> after all, well, we've got the technology so use it. Inter-AS routers
> for backbones, will likely need to continue to be large, power-hungry
> boxes so that policy can be separately applied on the borders.
>
> I should point out that none of this really is about scalability of
> the routing system of the Internet, it's all about hardware and
> software design to allow the present system to scale. Looking at
> completely different and more scalable routing would require finding
> a better way to do things than the present BGP approach.
>
>

Re: multi homing pressure

[Alexei Roudnev]

It is not true. Many tier-2 ISP specializes in very ghigh quality Internet
access, so mnasking problems of big ISP (who in reality never can provide
high quality Internet at all). Good example - Internap.

So, it is not about tier-1 vs tier-2, it is about ISP specialized on cheap
acvcess and ISP specialized on quality access. Is COGENT (for example only -
I have nothing against them) tier-1 ISP - may be; are they high quality
ISP - in NO WAY (they just provide bandwidth to nowhere without any clue).

- Original Message - 
From: "John Dupuy" <[EMAIL PROTECTED]>
To: "Patrick W. Gilmore" <[EMAIL PROTECTED]>; 
Sent: Wednesday, October 19, 2005 10:05 AM
Subject: Re: multi homing pressure


>
>
> >For the customer with an Internet "mission critical app", being tied
> >to a Tier 2 has it's own set of problems, which might actually be
> >worse than being tied to a Tier 1.
>
> The key word is "might". In fact, I would posit that a Tier 2 with
multiply
> redundant transit to all of the Tier 1s could theoretically have better
> connectivity than an actual Tier 1. The Tier 2 transit provides
flexibility
> that the transit-free Tier 1s do not have. Just my opinion.
>
> Anyway, it has been my experience that most (but not all) of the customers
> that want to "multihome" are _really_ wanting either: A. geographic/router
> redundancy. or B. easy renumbering. Geographic redundancy can be done
> within a single AS and IP block. They just don't know to ask it that way.
> (And easy renumbering will eventually be solved with v6. Eventually.)
>
> The demand for multi-homing might not be as great as suspected.
>
> John
>

Re: What happen in Russia?

[Alexei Roudnev]

What is interesting - I could not find any official statement from ISP
providers, so I need to ask
my collegues in Russian ISP (I worked for them 10 years), or filter out thru
many newspapers speculations to find the truth.


- Original Message - 
From: "Frank Coluccio" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, September 24, 2005 2:48 PM
Subject: Re: What happen in Russia?



re: "Fixed already. There was cable ct bteween Moscow and St. Petersburg."

Admittedly OT, but interesting for purpose of providing contrast, from
Ghana:

http://www.balancingact-africa.com/news/current1.html

- Ghana Telecom (GT) has 'lost' the underground network cable that provides
communications to a number of major government offices in the Osu Castle in
Accra, according to The Statesman newspaper. Bulldozer operative Collins
Antwi is
currently in police custody for causing unlawful damage to state property
after
his machine allegedly tore through the GT cabling as he worked on a site
close to
the Guinean Embassy. Around 7,000 users are thought to have been cut off
following Antwi's actions, including workers at the National Police
Headquarters,
the National Fire Service and the Bureau of National Investigations. The
Statesman says that with the network down the running of the country will be
a
'Herculean task'.

Frank


- Original Message -
From: "Alexei Roudnev" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, September 24, 2005 11:35 AM
Subject: What happen in Russia?


>
> What is wrong with Internet in Russia? Looks as they experience overall
> slowness (even phone providers are affected).
>

Re: What happen in Russia?

[Alexei Roudnev]

Fixed already. There was cable ct bteween Moscow and St. Petersburg.


- Original Message - 
From: "Alexei Roudnev" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, September 24, 2005 11:35 AM
Subject: What happen in Russia?


> 
> What is wrong with Internet in Russia? Looks as they experience overall
> slowness (even phone providers are affected).
> 

What happen in Russia?

[Alexei Roudnev]

What is wrong with Internet in Russia? Looks as they experience overall
slowness (even phone providers are affected).

Re: Technical contact at Cogent

[Alexei Roudnev]

They are 'cogentco.com' .


- Original Message - 
From: "Tao Wan" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, September 06, 2005 2:08 PM
Subject: Technical contact at Cogent


> 
> Can someone from Cogent or with a technical contact there (other than 
> [EMAIL PROTECTED]) contact me offlist? I would like to discuss some BGP 
> issues with them. 
> 
> Thanks very much, 
> 
> Tao Wan
> [EMAIL PROTECTED]
> 

Re: DARPA and the network

[Alexei Roudnev]

This in reality protects from EVERYTHING! In theory - not, but in reality -
no exploits exists at all (except DDOS exploints, of course) for such
systems.



- Original Message - 
From: "Florian Weimer" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, September 06, 2005 2:43 AM
Subject: Re: DARPA and the network


>
> * Henning Brauer:
>
> > so if the BSDs are en par with preventive measures, why is OpenBSD (to
> > my knowledge) the only one shipping ProPolice, which prevented
> > basically any buffer overflow seen in the wild for some time now?
> > Why is OpenBSD the only one to have randomized library loading,
> > rendering basicaly all exploits with fixed offsets unuseable?
> > Why is OpenBSD the only one to have W^X, keeping memory pages writeable
> > _or_ executable, but not both, unless an application fixes us to (by
> > respective mprotect calls)?
>
> All these pamper over the real problems and are not very helpful in a
> service provider environment, where availability might well be more
> important than integrity.  Buffer overflows still lead to crashes.
>
> Some of the countermeasures also break lots of legitimate applications
> (Lisp implementations, for example, or precompiled headers for GCC).
>
> (Isn't this quite off-topic for NANOG?)

Re: KVM over IP suggestions?

[Alexei Roudnev]

DELL's DRAC-III is waste of money.

DELL's DRAC-IV is a very good thing, and I find it replacing al consoles
around (it have embedded monitoring with e-mail and SNMP alerts; have VNC
based console servcie with perfect /not ideal, through/ mouse
syncronisation, haVE VIRTUAL cd (SLOW, BUT WORKING) AND VIRTUAL FLOPPY,
EASY-TO-USE INTERFACE (except strange password management), and so on.

Compaq's RIB cards was good but expensive and nbot very reliable.

Serial console can be fine, but do not eliminate normal console in many
cases.

- Original Message - 
From: "Kevin" <[EMAIL PROTECTED]>
To: 
Sent: Monday, August 22, 2005 1:26 PM
Subject: Re: KVM over IP suggestions?



On 8/22/05, Matthew Black <[EMAIL PROTECTED]> wrote:
> On Mon, 22 Aug 2005 11:15:23 -0400
>  "Drew Weaver" <[EMAIL PROTECTED]> wrote:
> >Howdy, I'm looking for a way to give our remote users access
> > to their servers, perhaps a KVM-IP solution. What we need is support for
> > multiple users (more than 2), with access control that limits what users
> > can connect to what ports on the KVM switch, and would allow you BIOS
> > level access and os-installation type control over the server, would
> > also be nice if it worked with windows and linux/unix based systems.

Where possible, I strongly prefer to work with serial console on a
hardware platform with firmware serial console support.  This works
for any OS that supports a command line, including Windows Server
2003.

Dell includes serial console support in the BIOS on "servers", and
offers an enhanced remote management card which appears to work as a
KVM-IP solution for Windows and (some versions of) Linux.

I've never tried their DRAC/ERAC, only the serial console BIOS.
All of the commercial remote serial console products we've considered
so far have had serious security and/or usability flaws.  This
includes Cisco, Lantronix, Raritan, Digi, etc.


> We have a non-IP switch from Raritan and saw presentations on their
> IP KVM products. Seemed pretty impressive. One problem you may want
> to focus on is screen resolution since the video output must be
> converted to IP packets with a lower refresh rate. We're planning
> to buy a few of these switches for remote monitoring.

The "IP Reach" video compression is bearable for installation and
recovery.  Video quality is degraded, but unless you really cannot
stand moire patterns, it'll take an hour or so staring at the display
before your headache becomes unbearable.

I have experience with Raritan's "Paragon IP Reach" products, and they
do work, but are expensive for such a low port density.  Also it has
been very difficult to work with tech support to make the Paragon
product with a RADIUS server for OTP access control.

The newer "Dominion" line may be better;  I've heard some complaints
about their serial console products, nothing either way about KVM.

Kevin Kadow

Re: KVM over IP suggestions?

[Alexei Roudnev]

Things you must pay attention to:

(1) IP KVM should not use client software - good switches uses VNC and can
work via WEB.
The same with authentication.

(2) If you connect IP KVM to normal KVM, check if they are well compatible
in suich things as:
- monitor recognition on KVM;
- switching ports on KVM;

(3) If you use multiple servers, check that IP KVM can keep all your screen
resolutions and frequences.
I saw a case when everything worked, but IP KVM could not recognize still
screen and generated huge traffic all the time.
The same with frequencees - we have one Compaq KVM which refuse to work with
IP KVM.

(4) Pay attention to mouse syncronisation. It is tricky and bad IP KVM can
require turning mouse acceleration off. Good IP KVM should know mouse
acceleration rules in Windows and Linuxes.

(5) If you can use embedded IP KVM card such as DELL : DRAC-IV or Compaq -
RIB card, use them - IP KVM
do not provides server reboot function and rarely can provide virtual CD or
virtual floppy.

We use IP KVM (do nopt remember vendor; cheap one, price was about $600)
connected to 3 16 port KVMs (chained together), and it is good add-on to
other tools. But it do not replace normal console in all cases - mouse
sncronisation, slow refresh makes long work on it annoying. DRAC-IV card ,
on other hand, replaces consokle in 95% cases (5% rely to _DRAC-IV crashh;
DRAC-IV lost keybvoard; etc cases).

For the new project, I'd better take everything from one brand vendor (even
if they OEM this things in most cases), just to be sure that KVM's are
compatible. For cheap project, there are many cheap IP KVM's on the market,
but TEST IT IN YOUR ENVIRONMENT!


- Original Message - 
From: "Eric A. Hall" <[EMAIL PROTECTED]>
To: "Drew Weaver" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, August 22, 2005 9:56 AM
Subject: Re: KVM over IP suggestions?


>
>
> On 8/22/2005 11:15 AM, Drew Weaver wrote:
> > Howdy, I'm looking for a way to give our remote users access
> > to their servers, perhaps a KVM-IP solution.
>
> > Any suggestions would be helpful.
>
>
http://www.nwc.com/shared/article/printFullArticle.jhtml?articleID=168500010
>
> -- 
> Eric A. Hallhttp://www.ehsco.com/
> Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

Re: KVM over IP suggestions?

[Alexei Roudnev]

Not a switch, but if you use DELL 2850 , 1850 and other _modern_ DELL xx8x
servers, DRAC-IV cards provides very good IP-KVM functionality. (Older
DRAC-III cards, used in 1650, are just a piece of junk).


- Original Message - 
From: "Jim Mercer" 
To: "Drew Weaver" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, August 22, 2005 8:25 AM
Subject: Re: KVM over IP suggestions?


>
> On Mon, Aug 22, 2005 at 11:15:23AM -0400, Drew Weaver wrote:
> > Howdy, I'm looking for a way to give our remote users access
> > to their servers, perhaps a KVM-IP solution. What we need is support for
> > multiple users (more than 2), with access control that limits what users
> > can connect to what ports on the KVM switch, and would allow you BIOS
> > level access and os-installation type control over the server, would
> > also be nice if it worked with windows and linux/unix based systems.
> > Any suggestions would be helpful.
>
> i haven't used it, but you might want to check out:
>
> http://www.realvnc.com/products/KVM-over-IP/
>
> -- 
> [ Jim Mercerjim@reptiles.org +1 416 410-5633 ]
> [  I want to live forever, or die trying.]

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

No one real DOS attack can create traffic, sugnificant for core routers
(except one - two worm cases when millions of computers generated random
traffic). I do not see a problem there.

All problems you are talking about are resolved in modern CPU industry,
resolved in modern servers, Router vendors just never had such task. Notice,
that modern routers are MORE THEN anough for modern Internet. If routing
tables grouth 10 times, routers will follow this trend without sugnificant
difficulties.

IPv6 looks exactly as ASN.1 - when Telco created it many years ago, they
attempted to pack everything into very slow 9600 bandwidth. Result - when
you see it in H.323 today, running on 100Mbit links, it's all unnecessary
(and it explains why SIP substitutes H.323, even if it never used excellent
ASN.1 packing schema /do not bite me, there are many other reasons, of
course/).

The same here. Many many years ago it looks as CIDR is 100% required and as
MH can not be achieved for small companies and that we must limit Internet
size to 100,000 routes. Today, we have much more, and do not foresee any
problem related to route table sizes.

I am not saying that Ipv4 mh approach is excellent, but I do not see anyone,
who proved that it could not work in future networks, instead of twisty and
tricky IPv6 addressing schema without MH at all. (Of course, it all will
result in the same trick - every smalll entity in IPv6 will have it's own PI
address block, no one idiot will be able to live with constant renumbering
they proposed to use. Just wait 2 - 10 years and you will see).


- Original Message - 
From: "Dave Andersen" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>; "Syed Junaid Farooqi"
<[EMAIL PROTECTED]>; "Christopher L. Morrow"
<[EMAIL PROTECTED]>
Cc: "NANOG" ; "Brad Knowles" <[EMAIL PROTECTED]>
Sent: Saturday, July 09, 2005 11:34 AM
Subject: Re: OMB: IPv6 by June 2008


> A cache-based architecture of the sort you describe is prone to thrashing
> under weird traffic patterns (such as those introduced by DoS attacks...).
> There's something to be said for having routers that can forward at or
near
> line-rate regardless of the traffic patterns, packet sizes, etc.  If
you're
> holding 1% of your routing table in core, and it takes you several packet
> transmissions worth of time to go off-card to fetch different routing
> entries, you have a pretty serious problem.
>
> Thankfully, nobody ever tries to scan the entire 'net, causing major
> thrashing in lookup tables.  [...]
>
> Also, keep in mind that memory is either big and cheap -- in which case
> you're creating a size problem for routers that already take up enormous
> amounts of space -- or small, fast, and very expensive.  Memory,
> particularly static ram, is also a power hog.  Todays BFRs dissipate about
> as much power as my electric stove on full blast.
>
> If there are architectural solutions that can reduce the cost, size, and
> power consumption of routers while simultaneously providing improved
> availability, it seems silly to ignore them.
>
>   -d
>
> - Original Message - 
> From: Alexei Roudnev
> To: Syed Junaid Farooqi ; Christopher L. Morrow
> Cc: NANOG ; Brad Knowles
> Sent: Saturday, July 09, 2005 1:42 PM
> Subject: Re: OMB: IPv6 by June 2008
>
>
> LC can hold only 20,000 ACTIVE routes., and ask central system if it needs
> more., How many ACTIVE routes are used in any CORE router?
> 0.1% or CORE? 2% of CORE?
>
> Again, today it is not technical issue anymore.
> - Original Message - 
> From: Syed Junaid Farooqi
> To: Christopher L. Morrow
> Cc: Alexei Roudnev ; NANOG ; Brad Knowles
> Sent: Saturday, July 09, 2005 1:02 AM
> Subject: Re: OMB: IPv6 by June 2008
>
>
> Christopher L. Morrow wrote:
> randy already asked for a kibosh on the lunacy here... I agree, it'd be
> nice, but...
>
> On Fri, 8 Jul 2005, Alexei Roudnev wrote:
>
>
> You do not need to - any router have only `1 - 10% of all routing table
> active, and it is always possible to optimize these alghoritms.
>
>
>
> and routing vendor's haven't already done some optomizing you think?
>
>
> They sure have, let me explain a bit - Optimization here can be is Route
> table optimization, forwarding table optimization and the actual
forwarding
> lookup paradigm.
> But having the best and most opitmized algorithm makes no difference if
> there is not enough memory on the Line Card, having said that - 1G to 2G
mem
> is something that is already supported by a few vendors - on the Line
cards
> and 2G and above on the Processors (route processor..?)
>
>
> On the other hand - what's wrong with 4Gb on line card in big core r

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

LC can hold only 20,000 ACTIVE routes., and ask central system 
if it needs more., How many ACTIVE routes are used in any CORE 
router?
0.1% or CORE? 2% of CORE? 
 
Again, today it is not technical issue anymore.

  - Original Message - 
  From: 
  Syed Junaid 
  Farooqi 
  To: Christopher L. Morrow 
  Cc: Alexei Roudnev ; NANOG ; Brad Knowles 
  Sent: Saturday, July 09, 2005 1:02 
  AM
  Subject: Re: OMB: IPv6 by June 2008
  Christopher L. Morrow wrote: 
  randy already asked for a kibosh on the lunacy here... I agree, it'd be
nice, but...

On Fri, 8 Jul 2005, Alexei Roudnev wrote:

  
You do not need to - any router have only `1 - 10% of all routing table
active, and it is always possible to optimize these alghoritms.


and routing vendor's haven't already done some optomizing you think?

  They sure have, let me explain a bit - Optimization here 
  can be is Route table optimization, forwarding table optimization and the 
  actual forwarding lookup paradigm.But having the best and most opitmized 
  algorithm makes no difference if there is not enough memory on the Line Card, 
  having said that - 1G to 2G mem is something that is already supported by a 
  few vendors - on the Line cards  and 2G and above on the Processors 
  (route processor..?)
  
On the other hand - what's wrong with 4Gb on line card in big core router?

oh, please please name the router vendor that has 4gb of 'ram'
(tcam/fpga/asic-'memory') on the 'linecard'. Oh, can't come up with one?
One wonders why that is? If the solution were as simple as: "Joe, add
1.21jigawatts of memory to the linecard so we can support +1M routes"
Don't you think the vendor would have done this to get people to stop
bitching at them?
  Now, now, The RAM mentioned in terms of Gb should not 
  be thought, even inadvertently, to have something to do with TCAM/fpga/asic 
  -Memory here can be divided in to 1. forwarding memory , 2. Line card CPU 
  memory, 3. TCAM memory (damn costly stuff )And as for the number of 
  routes to be support -Right now venodrs do support close to 500K routes - ask 
  me to name the vendor (notice i did not say Vendors here) and i will be happy 
  to name.But, yes to do something like 1M routes - ahem mighty tricky stuff 
  aint it, but, does any one have 1M active routes in his table as of today 
  (notice how iam trying to evade commenting ;) you cant haul me for saying 
  this)

It's cheap enough, even today. And we have not 1,000,000 routes yet.


In YOUR network you don't... I'd venture to guess there are quite a few
very large networks with +1M routes in them today.

remember though, I'm the chemical engineer... and I was trained to MAKE
the crack cocaine...

  1M routes, BGP is hope so - and not on a single box i 
  suppose so. come on, 1M +  active routes- it sure would be a killing on 
  the box.Chemical engineer you say,  what a wonderfull world - Iam 
  a pharmacist- fully trained to give an anitdote to cocaine 
  addicts.CIAO 

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

It's chiken and egg problem. They do not have 4 Gb, because they do not need
it_now_. techbnically it is not a problem even today.
Small RAID systems have 1 Gb RAM easily.

Line cards do not need so much memory - they can always cache routing
tables. Just again - it is not _technical_ problem.
IPv6 addressed problem which do note exists in reality.


- Original Message - 
From: "Christopher L. Morrow" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>
Cc: "NANOG" ; "Brad Knowles" <[EMAIL PROTECTED]>
Sent: Friday, July 08, 2005 11:12 PM
Subject: Re: OMB: IPv6 by June 2008


>
>
> randy already asked for a kibosh on the lunacy here... I agree, it'd be
> nice, but...
>
> On Fri, 8 Jul 2005, Alexei Roudnev wrote:
>
> >
> > You do not need to - any router have only `1 - 10% of all routing table
> > active, and it is always possible to optimize these alghoritms.
> >
>
> and routing vendor's haven't already done some optomizing you think?
>
> > On the other hand - what's wrong with 4Gb on line card in big core
router?
>
> oh, please please name the router vendor that has 4gb of 'ram'
> (tcam/fpga/asic-'memory') on the 'linecard'. Oh, can't come up with one?
> One wonders why that is? If the solution were as simple as: "Joe, add
> 1.21jigawatts of memory to the linecard so we can support +1M routes"
> Don't you think the vendor would have done this to get people to stop
> bitching at them?
>
> > It's cheap enough, even today. And we have not 1,000,000 routes yet.
> >
>
> In YOUR network you don't... I'd venture to guess there are quite a few
> very large networks with +1M routes in them today.
>
> remember though, I'm the chemical engineer... and I was trained to MAKE
> the crack cocaine...

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

You do not need to - any router have only `1 - 10% of all routing table
active, and it is always possible to optimize these alghoritms.

On the other hand - what's wrong with 4Gb on line card in big core router?
It's cheap enough, even today. And we have not 1,000,000 routes yet.


- Original Message - 
From: "Brad Knowles" <[EMAIL PROTECTED]>
To: "NANOG" 
Sent: Friday, July 08, 2005 1:03 AM
Subject: Re: OMB: IPv6 by June 2008


>
> At 12:51 AM -0700 2005-07-08, Alexei Roudnev wrote:
>
> >  Who need this complexity?  What's wrong with old good _routing rotocol_
> >  approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when
it is
> >  for slow routing system). CPU (the same)? What else?
>
> Can you put 4GB on every linecard on every router you own?  Can
> you put a Power5 or PowerPC 970MP processor on every linecard on
> every router you own?  Does your vendor support you making any
> modifications/upgrades to any of their linecards, or do they require
> you to buy new ones with the go-faster features?
>
> And how many tens of thousands of dollars do each of those
> go-faster linecards cost?  And how many million-dollar fork-lift
> upgrades do you have to pay for in order to get the go-faster chassis
> in which to plug those go-faster cards into?
>
> Do you have thousands of routers?  Hundreds of thousands?
>
>
> I'm asking serious questions here.  I'm not a router guy, but
> I've heard a lot of comments on this list that give me pause, so I'd
> like to get real-world answers.
>
>
> Speaking from my own perspective, it seems to me that we've got a
> scalability problem here when we're expecting most devices to have a
> pretty complete picture of the entire world.  I think that's the real
> problem that has to be addressed.
>
> In terms of the routing protocols and number of ASes, we know
> that it's possible to build machines which can handle those kinds of
> things at those kinds of numbers.  The problem is that it's hard to
> do those kinds of things on a widespread basis (e.g., in every
> linecard in every router in the world), and most devices probably
> don't need that anyway.
>
> I don't know what the real solution is.  But it seems to me that
> we need to find something, and having people say "4GB of RAM?  No
> problem" is not the way to get this solved.
>
> -- 
> Brad Knowles, <[EMAIL PROTECTED]>
>
> "Those who would give up essential Liberty, to purchase a little
> temporary Safety, deserve neither Liberty nor Safety."
>
>  -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
>  Assembly to the Governor, November 11, 1755
>
>SAGE member since 1995.  See <http://www.sage.org/> for more info.

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

Moreover, if you are not multihomned, you can be aggregated. If you became
multihome - yes, you take a slot; how many entities in the world should be
multihomed?

- Original Message - 
From: "Kuhtz, Christian" <[EMAIL PROTECTED]>
To: "David Conrad" <[EMAIL PROTECTED]>; "Alexei Roudnev"
<[EMAIL PROTECTED]>
Cc: "Mohacsi Janos" <[EMAIL PROTECTED]>; "Daniel Golding"
<[EMAIL PROTECTED]>; "Scott McGrath" <[EMAIL PROTECTED]>;

Sent: Thursday, July 07, 2005 11:02 AM
Subject: RE: OMB: IPv6 by June 2008



> Alexei,
>
> On Jul 7, 2005, at 9:58 AM, Alexei Roudnev wrote:
> > What's the problem with independent address space for every entity
> > (company,
> > family, enterprise) which wants it?
>
> It doesn't scale.  Regardless of Moore's law, there are some
> fundamental physical limits that constrain technology.

I would contend that is not true.  What says that every device inside a
company, family, enterprise etc has to be available and reachable by
anyone on the planet in a bidirectional fashion as far as session
initiation is concerned?

Once you add that bit of reality to it, the scaling requirement goes
down substantially.  Wouldn't you agree?

Trust me, I would like to just see us get it over with as far as IPv6 is
concerned, provided we have a working, palatable IPv6 mh solution.  But,
man, I can't pass the red face test on a lot of these hypothesis :(

Thanks,
Christian


The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers. 163

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

What is CPU power of today's core routers? What's memory? Compare with
junk-yard server - 2 x 1.4Ggz CPU, 4 GB RAM, total price about $1.5K.

Routers have 3 - 10 times reserve _today_ . Then, you can always sacrify
reaction time a little. Reserves are tremendous in this area.

- Original Message - 
From: "Randy Bush" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>
Cc: 
Sent: Thursday, July 07, 2005 1:23 PM
Subject: Re: OMB: IPv6 by June 2008


> > Is it a pproblem keeping 500,000 routess in core routers? Of
> > course, it is not (it was in 1996, but it is not in 2005
>
> really?  we have not seen this so how do you know?  and it
> will be fine with churn and pushing 300k forwarding entries
> into the fibs on a well-known vendor's line cards?
>
> randy
>

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

Who need this complexity?  What's wrong with old good _routing rotocol_
approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when it is
for slow routing system). CPU (the same)? What else?

If it looked as a problem 10 years ago, it can not be relevant to today's
realities.

- Original Message - 
From: "Joe Abley" <[EMAIL PROTECTED]>
To: "Andre Oppermann" <[EMAIL PROTECTED]>
Cc: "NANOG list" ; "Alexei Roudnev" <[EMAIL PROTECTED]>;
"Iljitsch van Beijnum" <[EMAIL PROTECTED]>
Sent: Thursday, July 07, 2005 8:11 AM
Subject: Re: OMB: IPv6 by June 2008


>
> On 2005-07-07, at 10:23, Andre Oppermann wrote:
>
> > It was about a spot in the global routing table.  No matter if one
> > gets
> > PA or PI they get a routing table entry in the DFZ.  There is no
> > way around
> > it other than to make the routing protocols more scaleable.
>
> With the hole-punching/CIDR abuse multihoming that is widely used in
> IPv4, a slot in the DFZ gets burned each time an end site adds a
> provider, regardless of whether they are using PA or PI addresses.
> This slot represents state information for the multi-homed site which
> answers the question "how else can this set of addresses be reached?"
>
> The shim6 approach shifts this state from the DFZ to the endpoints
> which are exchanging unicast traffic. The endpoints exchange a set of
> possible locators through a protocol element within the IP layer and
> handle locator migration transparently to the transport layer above.
> Hence the question "how else can this particular remote address be
> reached" is answered using information on the host, not information
> in the network.
>
> With shim6 an end site can multi-home using one PA prefix per
> provider, without taking up additional slots in the DFZ. Hosts within
> the site are given multiple addresses (locators), and the layer-3
> shim handles any change of locator needed for traffic exchanged
> between any two hosts.
>
> If one (or both) of the hosts exchanging traffic don't support shim6,
> then the traffic is exchanged without transport-layer stability
> across re-homing events (and, potentially, without any optimisation
> as to the choice of endpoint addresses for the session).
>
> So, the shim6 future of multihoming looks like this:
>
> 1. ISPs multi-home exactly as people are used to doing today, using
> PI prefixes, and taking up a slot in the DFZ per transit provider.
> Everybody is familiar with this already. There is no change for ISPs
> in this picture.
>
> 2. Multi-homed end sites obtain one PA prefix per upstream ISP, and
> hosts within those end-sites are assigned multiple addresses (in some
> automated, secure and controllable fashion). There are no additional
> slots burned in the DFZ by end site multi-homing. Hosts obtain
> transport-layer reliability across re-homing events using shim6,
> rather than relying on the network to take care of it.
>
>
> Joe

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

What's the problem with independent address space for every entity (company,
family, enterprise) which wants it? Big routing tables? Is RT of 1,000,000
routes BIG? I do not think so. Memory is cheap, modern routing schemas like
CEF are effective. How many entities do we have on earth? It was a problem,
but it IS NOT ANYMORE.

IPSec - see all ISAKMP schema and IPSEC security associations, and see IPSec
incompatibilities. Compare with SSL (works out-of-the-box in 99.999% cases,
and allows both, full and hard security with root certificates etc, or
simple security based on _ok, I trust you first time, then we can work_. Why
MS uses PPTP? Because it is much more practuical vs IPSec.

IPv4 was strong because it was designed by practical people and not so much
by commiteets., IPv6 was designed by commiteets mainly. Do you know, that
'camel is horse designed by commiteet'?

- Original Message - 
From: "Mohacsi Janos" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>
Cc: "Daniel Golding" <[EMAIL PROTECTED]>; "Scott McGrath"
<[EMAIL PROTECTED]>; "David Conrad" <[EMAIL PROTECTED]>;

Sent: Thursday, July 07, 2005 1:08 AM
Subject: Re: OMB: IPv6 by June 2008


>
>
>
>
> On Wed, 6 Jul 2005, Alexei Roudnev wrote:
>
> >
> > IPv6 is an excellent example of _second system_ (do you remember book,
> > written by Brooks many years ago?) Happu engineers put all their crazy
ideas
> > together into the second version of first 9succesfull) thing, and they
> > wonder why it do not work properly.
> > OS/360 is one example, IPv6 will be another.
>
> But I think IPv6 will one day a primary system.
>
>
> >
> > IPv6 address allocation schema is terrible (who decided to use SP
dependent
> > spaces?), security is terrible (who designed IPSec protocol?) and so so
on.
>
>
> If you can propose better solution to not to blow up routing table with
> large number of entries you can speak at IETF v6ops.
>
> What is the problem with IPSec?
>
> >
> > Unfortunately, it can fail only if something else will be created, which
do
> > not looks so.
>
> Regards,
>
>
> Janos Mohacsi
> Network Engineer, Research Associate
> NIIF/HUNGARNET, HUNGARY
> Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98
>
> > - Original Message -
> > From: "Daniel Golding" <[EMAIL PROTECTED]>
> > To: "Scott McGrath" <[EMAIL PROTECTED]>; "David Conrad"
> > <[EMAIL PROTECTED]>
> > Cc: 
> > Sent: Wednesday, July 06, 2005 8:58 AM
> > Subject: Re: OMB: IPv6 by June 2008
> >
> >
> >>
> >>
> >> There is an element of fear-mongering in this discussion - that's why
many
> >> of us react poorly to the idea of IPv6. How so?
> >>
> >> - We are running out of IPv4 space!
> >> - We are falling behind <#insert scary group to reinforce fear of
Other>!
> >> - We are not on the technical cutting edge!
> >>
> >> Fear is a convenient motivator when facts are lacking. I've read the
above
> >> three reasons, all of which are provable incorrect or simple fear
> > mongering,
> >> repeatedly. The assertions that we are falling behind the Chinese or
> >> Japanese are weak echoes of past fears.
> >>
> >> The market is our friend. Attempts to claim that technology trumps the
> >> market end badly - anyone remember 2001? The market sees little value
in
> > v6
> >> right now. The market likes NAT and multihoming, even if many of us
don't.
> >>
> >> Attempts to regulate IPv6 into use are as foolish as the use of
fear-based
> >> marketing. The gain is simply not worth the investment required.
> >>
> >> - Daniel Golding
> >>
> >> On 7/6/05 11:41 AM, "Scott McGrath" <[EMAIL PROTECTED]> wrote:
> >>
> >>>
> >>>
> >>> You do make some good points as IPv6 does not address routing
> > scalability
> >>> or multi-homing which would indeed make a contribution to lower OPEX
and
> >>> be easier to 'sell' to the financial people.
> >>>
> >>> As I read the spec it makes multi-homing more difficult since you are

> >>> expected to receive space only from your SP there will be no 'portable
> >>> assignments' as we know them today.  If my reading of the spec is
> >>> incorrect someone please point me in the right direction.
> >>>
> >>> IPv6's hex based nature is really a joy to work with IPv6 definit

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

We have relatively PI address space in IPv4, which works fine, even with
current routers. No any problem to hold the whole world-wide routing with a
future ones. Is it a pproblem keeping 500,000 routess in core routers? Of
course, it is not (it was in 1996, but it is not in 2005 and it will not be
in 2008 - even if you will have 1,000,000 routes). IPv6 schema was build to
resolve problem which do not exists anymore (with fast CPU and cheap memory
and ASIC's).

I mean - when people switched from IPv4 to IPv6, they changed too much and
too hard, trying to implement all their ideas. Result is terrible.

IPSec - compare SSH and IPSec. Compare IPSec and PPTP. No, IPSec is
extremely bad thing.


- Original Message - 
From: "David Conrad" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>
Cc: "Daniel Golding" <[EMAIL PROTECTED]>; "Scott McGrath"
<[EMAIL PROTECTED]>; 
Sent: Thursday, July 07, 2005 12:01 AM
Subject: Re: OMB: IPv6 by June 2008


> On Jul 6, 2005, at 10:16 PM, Alexei Roudnev wrote:
> > IPv6 address allocation schema is terrible (who decided to use SP
> > dependent
> > spaces?),
>
> Well, to date, provider based addressing works (although there were
> times when it was a close thing).  Your alternative?
>
> > security is terrible (who designed IPSec protocol?) and so so on.
>
> I wouldn't say terrible.  Annoying, perhaps, but security is often
> like that.  Your alternative?
>
> > Unfortunately, it can fail only if something else will be created,
> > which do
> > not looks so.
>
> The "something else" already exists, although many are unhappy about
> it.  It has evolved a bit -- it's now called NUTSS (http://
> nutss.gforge.cis.cornell.edu/)... :-)
>
> Rgds,
> -drc
>

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

IPv6 is an excellent example of _second system_ (do you remember book,
written by Brooks many years ago?) Happu engineers put all their crazy ideas
together into the second version of first 9succesfull) thing, and they
wonder why it do not work properly.
OS/360 is one example, IPv6 will be another.

IPv6 address allocation schema is terrible (who decided to use SP dependent
spaces?), security is terrible (who designed IPSec protocol?) and so so on.

Unfortunately, it can fail only if something else will be created, which do
not looks so.
- Original Message - 
From: "Daniel Golding" <[EMAIL PROTECTED]>
To: "Scott McGrath" <[EMAIL PROTECTED]>; "David Conrad"
<[EMAIL PROTECTED]>
Cc: 
Sent: Wednesday, July 06, 2005 8:58 AM
Subject: Re: OMB: IPv6 by June 2008


>
>
> There is an element of fear-mongering in this discussion - that's why many
> of us react poorly to the idea of IPv6. How so?
>
> - We are running out of IPv4 space!
> - We are falling behind <#insert scary group to reinforce fear of Other>!
> - We are not on the technical cutting edge!
>
> Fear is a convenient motivator when facts are lacking. I've read the above
> three reasons, all of which are provable incorrect or simple fear
mongering,
> repeatedly. The assertions that we are falling behind the Chinese or
> Japanese are weak echoes of past fears.
>
> The market is our friend. Attempts to claim that technology trumps the
> market end badly - anyone remember 2001? The market sees little value in
v6
> right now. The market likes NAT and multihoming, even if many of us don't.
>
> Attempts to regulate IPv6 into use are as foolish as the use of fear-based
> marketing. The gain is simply not worth the investment required.
>
> - Daniel Golding
>
> On 7/6/05 11:41 AM, "Scott McGrath" <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > You do make some good points as IPv6 does not address routing
scalability
> > or multi-homing which would indeed make a contribution to lower OPEX and
> > be easier to 'sell' to the financial people.
> >
> > As I read the spec it makes multi-homing more difficult since you are
> > expected to receive space only from your SP there will be no 'portable
> > assignments' as we know them today.  If my reading of the spec is
> > incorrect someone please point me in the right direction.
> >
> > IPv6's hex based nature is really a joy to work with IPv6 definitely
fails
> > the human factors part of the equation.
> >
> > Scott C. McGrath
> >
> > On Wed, 6 Jul 2005, David Conrad wrote:
> >
> >> On Jul 6, 2005, at 7:57 AM, Scott McGrath wrote:
> >>> IPv6 would have been adopted much sooner if the protocol had been
> >>> written
> >>> as an extension of IPv4 and in this case it could have slid in
> >>> under the
> >>> accounting departments radar since new equipment and applications
> >>> would
> >>> not be needed.
> >>
> >> IPv6 would have been adopted much sooner if it had solved a problem
> >> that caused significant numbers of end users or large scale ISPs real
> >> pain.  If IPv6 had actually addressed one or more of routing
> >> scalability, multi-homing, or transparent renumbering all the hand
> >> wringing about how the Asians and Europeans are going to overtake the
> >> US would not occur.  Instead, IPv6 dealt with a problem that, for the
> >> most part, does not immediately affect the US market but which
> >> (arguably) does affect the other regions.  I guess you can, if you
> >> like, blame it on the accountants...
> >>
> >> Rgds,
> >> -drc
> >>
>
> -- 
> Daniel Golding
> Network and Telecommunications Strategies
> Burton Group
>
>

Re: Email peering

[Alexei Roudnev]

My e-mail is [EMAIL PROTECTED], but I send it when I am on DSL with EthLink
(and thru Earthlink SMTP). And it is 100% valid situation.


- Original Message - 
From: "John Levine" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, June 18, 2005 12:25 AM
Subject: Re: Email peering


>
> >In between the choice of accepting mail from *anybody* by default
> >which we have now and the choice of accepting mail from *nobody* by
> >default that explicit peering agreements represents there is another
> >solution; which is to accept mail only from IPs that have *some
> >relation* to the sender's From domain, for example by MX record or by
> >reverse DNS (we implemented that test and call it MX+).
>
> This has the same problem as all of the other duct tape authorization
> schemes -- it breaks a lot of valid e-mail, so that you have to
> maintain a painfully large manual exception table, or write off a lot
> of mail that your users will not forgive you for losing, or more
> likely, both.
>
> In this particular case, the biggest issue is forwarders, commercial
> ones like pobox.com, associations like the ACM and IEEE (I get some
> odd mail being uucp at computer.org), and large numbers of colleges
> and universities which let graduates keep their email address.  In all
> of those cases, the users send mail from their own ISPs, whatever they
> are, inbound mail is forwarded back to the ISP accounts, and there is
> no way to enumerate the valid sources of mail.
>
> There's also plenty of domains where the inbound and outbound mail
> servers are different, and neither one matches the domain name of the
> mail.  For example, I host about 300 small mail domains on a pop
> toaster here.  The MX is mail2.iecc.com, and the outbound host that
> many but not all of them use is xuxa.iecc.com.  (Mail for iecc.com
> itself is on another host.)  The IPs all happen to be in the same /24,
> but guessing whether two IPs are "close enough" is a poor way to
> authenticate or authorize anything.
>
> Before you point out that they could change the way those systems work
> to be compatible with your scheme, well, duh, sure.  But if you're
> going to make people change their existing working mail setups,
> there's little point in going through the vast cost of a widespread
> change for such a marginal benefit.  Read archives of SPF mailing
> lists for endless flamage on this topic, since SPF has the same
> problem.
>
> Regards,
> John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for
Dummies",
> Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
> "A book is a sneeze." - E.B. White, on the writing of Charlotte's Web

Re: OT: NOC Display's

[Alexei Roudnev]

(I do not feel it as off-topic, btw).

Q. - what really are you going to see on this projected screen? I saw  very
, very few systems and screens, which was really interesting for the big
screen. Most 'World map, colored icons, fancy lines' views are 99% useless
(many reasons). Big screen is desired, if you have compact view of your all
system, such as in Proactivenet (events + primary charts), or 'snmpstat' (up
to 300 - 500 active ports and links, including traffic bars, on one screen).
Even here, you will need MORE information.

Projectors are not designed for it. They are designed more for the
presentations, with 1200 x 1000 resolution, and so on. If I have 2,000
active links which I'd like to see, or 2,000 objects which I'd like to see
better, or something like this - I'd like to have integrated resolution as
4,000 x 2000, which iis, for example, 8 standard LCD screens.

So, what are real requirements for such projectors? 4 VGA screen on one
projector?

- Original Message - 
From: "Daniel Golding" <[EMAIL PROTECTED]>
To: "Chip Mefford" <[EMAIL PROTECTED]>; "Spencer Wood"
<[EMAIL PROTECTED]>
Cc: 
Sent: Friday, June 03, 2005 11:21 AM
Subject: Re: OT: NOC Display's


>
>
> On a related note, those interested in NOC display technology may also
want
> to check out the recent Wall Street Journal article (sorry, I don't have a
> link) that suggests that we are about to see a huge drop in large
LCD/Plasma
> display pricing as several new factories are coming on-line.
>
> I'm not sure if that changes the way we'll build NOCs - projectors have
been
> popular, but I'm not sure if that's only due to cost advantage.
>
> (I'd like to say that I don't feel a thread on NOCs is particularly
> off-topic. While I can't configure LCD projectors on an IOS command line,
> I've sure configured IOS command lines on LCD projectors - reasonable
> display technology can be the difference between a useless "Show NOC" and
a
> technically useful operations center)
>
> - Dan
>
> On 6/3/05 8:50 AM, "Chip Mefford" <[EMAIL PROTECTED]> wrote:
>
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Spencer Wood wrote:
> >> This is kind of off topic, so please feel free to delete if you want
> >> ..
> >>
> >> Anyway, in our NOC we current have two LCD projectors displaying
outputs
> >> from two different computers.  On one of the display's, I would like to
be
> >> able to take 4 VGA outputs from 4 workstations, and display it on the
> >> screen (aka: Hollywood square style).
> >
> > What is the native rez of your lcd projectors?
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.0 (GNU/Linux)
> >
> > iD8DBQFCoFId0STXFHxUucwRAlTbAJ9LRXnaf058CrUGB4zqA5U9k1IcBgCfaLK/
> > GTC6rh5wuZIoImUQpKO8zRs=
> > =tw/B
> > -END PGP SIGNATURE-
>

Re: More on Moscow power failure( was RE: Moscow: global power outage)

[Alexei Roudnev]

RIPN and Relcom was not affected, except their M9 colocations. They had, in
theory, backup connectivity thru another node, but I am not sure, if it
really worked or not.


- Original Message - 
From: "Joe Abley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: 
Sent: Saturday, May 28, 2005 8:20 AM
Subject: Re: More on Moscow power failure( was RE: Moscow: global power
outage)


>
>
> On 2005-05-26, at 07:12, [EMAIL PROTECTED] wrote:
>
> > The Russian media have lots of details about the power
> > outage, but the general media hardly mentions the fact
> > that there was a disruption of Internet service.
> >
> > The MSK-IX web page still has no news about the incident
> > and no explanation as to why they shut down.
>
> It's not clear to me that the MSK-IX shut down entirely, although it
> does look like it took a major hit. While I see most of our MSK-IX
> sessions came up around 2 days 3 hours ago we have at least one that
> has been up for 4 weeks, suggesting that at least part of one of the
> switch fabrics stayed up throughout.
>
> The F root nameserver in Moscow is colocated with RIPN. Neither of
> the nameservers in the F-root cluster there show signs of power
> failure, in case it helps anybody else here to know of a site in
> Moscow that has functional power supply protection.
>
> F-root traffic graphs in Moscow suggest local impact was limited to a
> 5-6 hour window ending around midnight Tuesday UTC.
>
>
> Joe
>
>

Few notices about Moscow, M9-IX, and last outage

[Alexei Roudnev]

1) M9 have UPS power for a few days. BUT - it is 60V DC power. Only a very
few routers or switches are able to use it.

2) Power outages in Moscow data centers are very rare event, because most
have 2 - 3 different power inputs. 24 May failure was caused mainly
by operator's error, who reconnected power system back after few
transformers broke, and caused chained failure.

3) As a result of this (I never saw power failure in Relcom data center for
15 years of working there), generators are not common there.

4) M9-IX is not the only entrance to Moscow, but it was the main entrance.
As I know, few other entrance nodes was not affected.

Re: soBGP deployment

[Alexei Roudnev]

Yes, corect - registry is as accurate as it used for the routing decisions.
The more it is used, the better is feedback and the faster
it will fix unavoidable errors.

No one registry can be accurate until it is used for every day operations.


- Original Message - 
From: "Florian Weimer" <[EMAIL PROTECTED]>
To: "Steven M. Bellovin" <[EMAIL PROTECTED]>
Cc: "Pekka Savola" <[EMAIL PROTECTED]>; "Randy Bush" <[EMAIL PROTECTED]>; "vijay
gill" <[EMAIL PROTECTED]>; 
Sent: Tuesday, May 24, 2005 1:44 AM
Subject: Re: soBGP deployment


>
> * Steven M. Bellovin:
>
> > Fundamentally, the answer to this question is this: how accurate do you
> > think the routing registries are?
>
> I don't think it's important how accurate they are *now*, but how
> accurate they will be when some "secure" BGP version makes them (or,
> more precisely, the route registration process) the weakest link in
> the chain.  The fact that careful checking on the ISP side protects
> other ISPs only (and your own business interests just in a very
> indirect fashion) makes me believe that securing BGP will be *very*
> hard.

Re: soBGP deployment

[Alexei Roudnev]

I agree with Tony. No need to overcomplicate a problem.

Today, more and more ISP verify routing, using prefixes or (less reliable)
AS--es, taking them from different sources.
If you be able to add, in small increments, certified information into this
routes, OR create external source of such information,
and intimidate people to use it, you will make a step toward the goal. _You
must not rely_ is really very strong overcomplicating.
There is better to build 90% reliable xxx-BGP extension which will work in 1
year, vs. designing theoretically ideal , 100% reliable solution and never
be able to deploy it.

(It reminds me SSL certificate problem - yes, you _should_ not rely on self
signed certificates and on _in-band_
certificate delivery; anyway, using such certificates and such delivery is
1000 times better vs. using nothing /and danger of such usage is heavily
overestimated by Verisign and other _fat certifiers_ sales. The same here -
it is better to add any, simple information allowing to certify routes,
instead of building the whole new system for this purpose.)

- Original Message - 
From: "Tony Li" <[EMAIL PROTECTED]>
To: "Russ White" <[EMAIL PROTECTED]>
Cc: "Geoff Huston" <[EMAIL PROTECTED]>; "Daniel Golding"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, May 23, 2005 10:25 PM
Subject: Re: soBGP deployment


>
>
> > -- You must not rely on routing to secure routing.
>
>
> I would like to point out that this goal is unnecesary.
>
> First, we need to understand that for ANY solution to be deployable, it
> must be incrementally deployable.  We do not get an Internet-wide flag
> day for BGP.  The Internet must continue to function, regardless of the
> percentage of NLRI that are actually authenticated.  For the forseeable
> future, we will need to have a path selection policy that rejects any
> information that clearly fails authentication, continues to use
> unauthenticated prefixes, and prefers authenticated vs. unauthenticated.
>
> Second, validating a certificate must be doable even if the router is
> using unauthenticated prefixes to do so.  Remember that the crypto
> properties of a certificate must make it unforgeable, and that routers
> must have at least one reference point in the web of trust.  If the
> route to the root of that web is spoofed, then the crypto will not be
> able to validate any other certificates in the web, but this is NOT an
> authentication failure -- the related NLRI are just unauthenticated, not
> unuseable.
>
> Obviously, authenticating the root certificate NLRI are our top
> priority, but the system MUST continue to operate even without this.
> This is the only way to truly address the chicken and egg problem.  I
> think that this also highlights the need for multiple, diversely routed
> certificate authorities.
>
> Tony

Microsoft broke MTU discovery by last security pathces??

[Alexei Roudnev]

Do you have amny information about last Microsoft problems with security
patches? We can see, how
one of last updates broke MTU discovery (not totally, but it restricts
number of discovered pathes so servers tsop working in a few days). And,
amazingly, no one published this problem.

Re: what will all you who work for private isp's be doing in a few years?

[Alexei Roudnev]

Last mile usage? May be, but it is not supported by many consumer level
firewalls/NAT's/DSL devices, cheap switches and so on.

I agree, it is most likely usage for it (multicast) - last mile and 'last
patch' -:).


- Original Message - 
From: "Frank Coluccio" <[EMAIL PROTECTED]>
To: "'Ross Hosman'" <[EMAIL PROTECTED]>; "'Joe Loiacono'"
<[EMAIL PROTECTED]>; "'Alexei Roudnev'" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, May 13, 2005 5:41 AM
Subject: Re: what will all you who work for private isp's be doing in a few
years?


Alexei Roudnev wrote:

>> What I can't understand is why multicast hasn't just gone gangbusters
into
>> use yet. I see it as a really pent-up capability that, in light of
>Because multicast standards was written by academic idiots. -:) Very
>difficult to use and full of unused features.
>
>(Do not believe? Read RSVP protocol - not exactly multicast but not far
away
>from it).
>
>And because multicast protocols (unfortunately) are not easy to implement.
>It excuse this standards and their authors.
>
>I can predict one more 'skype' like company, with really robust protocol,
>catching multicast market. Something like 'peer to peer multicast' -:).

Don't be too quick to assess the usage and value of multicast in last mile
access
networks, where it has found far greater success than over the Internet
proper
across the WAN. IP- and ATM- based multicast has worked very well for the
past
five years in telco VDSL (check out Next Level's implementations during the
late
nineties), and now in all manner of xDSL implementations, as well as a
number of
cable operator service applications in the digital region of their spectrum,
for
program video delivery to homes. Check it out.

http://www.cisco.com/warp/public/cc/so/neso/dsso/global/madsl_wp.htm

Frank A. Coluccio
DTI Consulting Inc.

On Fri May 13  2:29 , "Alexei Roudnev"  sent:

>
>>
>>
>> So imagine a residential area all pulling digital video over wireless.
>> Sound familiar? Ironically close to TV! (yet so different)
>>
>> What I can't understand is why multicast hasn't just gone gangbusters
into
>> use yet. I see it as a really pent-up capability that, in light of
>Because multicast standards was written by academic idiots. -:) Very
>difficult to use and full of unused features.
>
>(Do not believe? Read RSVP protocol - not exactly multicast but not far
away
>from it).
>
>And because multicast protocols (unfortunately) are not easy to implement.
>It excuse this standards and their authors.
>
>I can predict one more 'skype' like company, with really robust protocol,
>catching multicast market. Something like 'peer to peer multicast' -:).
>
>
>
>
>> broadband video, etc., is just going to have to break wide open soon.
>>
>> Joe
>>
>>
>>
>>
>>   Ross Hosman
>>
>[EMAIL PROTECTED]>, Fred Heutte [EMAIL PROTECTED]>
>>   @yahoo.com>  cc:  [EMAIL PROTECTED]
>>   Sent by: Subject: Re: what will all
>you who work for private isp's be doing in a few years?
>>   owner-nanog
>>
>>
>>   05/12/2005 02:16
>>   PM
>>
>>
>>
>>
>>
>>
>>
>> Not pointing any fingers but many of you think these
>> small ISP's are just going to die off instead of
>> adapt. Wireless is becoming a better and more reliable
>> technology that in the future will be able to provide
>> faster service then FTTH. I know of atleast one small
>> ISP in Michigan that went from dial-up to deploying
>> wireless. With WiMAX coming out I think you will see a
>> number of smaller ISPs switching to it as a service.
>> It is also much cheaper to deploy a wireless network.
>>
>> Me personally, I think wireless is the future for
>> residential internet/tv/phone.
>>
>> Ross Hosman
>> Charter Communcations
>>
>> --- Steve Sobol [EMAIL PROTECTED]> wrote:
>> >
>> > Fred Heutte wrote:
>> > > (1) There will be a market for independent ISPs as
>> > long CLECs
>> >
>> > I think a more appropriate term would be ALEC
>> >
>> > (anti-competitive local exchange carrier)
>> >
>> > ...That having been said, the problem with the small
>> > guys providing access is
>> > they can't generally achieve the economies of 

Re: Subject : RE: ACL Monitoring

[Alexei Roudnev]

It's all done in CCR. It encrypts passwords (allowing you to have a few
password groups, all WEB configurable), and uses
passphrases + 3DES or public/private key encryption (or just you can enter
logi and password from the web).
idea is simple - operators have WEB access and know passphrase, but they
have not cisco logins except if they granted direct cisco access, and they
never have access on the server.

Other approach could be 'snmp, but it works on a very few OS (IOS) only (do
not work for PIX, for example).

But you are correct - CCR have all this things, such as crypt / openssl;
sudo to get access top the passphrase file
from web cgi script, passphrase input for manual config downloads, webcvs
fro history analyze, etc etc.

Of course, tacacs+ accounting is necessary for full scale change monitoring.
Unfortunately, even different Cico devices have
different accounting rules (and very different access rules, counting PIX as
most useless from this point of view - you must
grant full access for 95% of operators tasks, even to monitor VPN
associations -:)).


> >
> > If you anticipate doing a lot of this kind of monitoring in the future
you
> > may want to take a look at the "expect" programming language
> > http://expect.nist.gov/ , which has very simple "send"/"expect"
constructs.
> > E.g. send "show acl 101/r" expect "access-list .." etc. Perl also allows
> > similar although is probably not quite as easy to pick up if you've
never
> > done this kind of thing before.
> >
> > Essentially you'd write a quick script to telnet or ssh to the router
"send"
> > your commands, expect a result and do something based on that result. As
I
> > said, its worth the time investment and you'll find once you get the
script
> > done you can just reuse it for many other tasks.
>
> Kind of silly to state using an expect script or any other "script" for
> that matter considering the assumption that, it seems he is not trusting
> someone (as mentioned in another post), so I would take it that this
> script would run from where?
>
> Not only that, you would go through hell configuring encrypting the
> password on an expect script for the script to decrypt, then send. Now,
> not only that, but then what? How would you configure it to monitor
> something say in real time? You would likely have to use the diff and grep
> commands for parsing, and a whole bunch of other things to get it to just
> monitor a change, not a guarantee you will find out who changed it without
> some major scripting as opposed to using accounting ala TACACS+
>
>
>
> spawn ssh [EMAIL PROTECTED]
> expect "Password: "
> send "secret\r"
> expect "something"
> send "something\r"
> expect $RESPONSE_FROM_ROUTER
> spawn $WHAT_DO_YOU_SPAWN_TO_COPY_WHAT_YOU_SEE
>
> Expect would be worthless in my opinion. Why reinvent the "kick their
> asses to accounting mode" wheel.
>
>
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> J. Oquendo
> GPG Key ID 0x0D99C05C
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0D99C05C
>
> sil @ infiltrated . net http://www.infiltrated.net
>
> "How a man plays the game shows something of his
> character - how he loses shows all" - Mr. Luckey

Re: ACL Monitoring

[Alexei Roudnev]

Used in CCR, and adapted for

  Cisco IOS
  Cisco Catos
  Pix OS
  Cisco VPN 3000 os

Really nice thing.

- Original Message - 
From: "Glynn Stanton" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, May 12, 2005 3:39 PM
Subject: RE: ACL Monitoring


>
>
> If you anticipate doing a lot of this kind of monitoring in the future you
> may want to take a look at the "expect" programming language
> http://expect.nist.gov/ , which has very simple "send"/"expect"
constructs.
> E.g. send "show acl 101/r" expect "access-list .." etc. Perl also allows
> similar although is probably not quite as easy to pick up if you've never
> done this kind of thing before.
>
> Essentially you'd write a quick script to telnet or ssh to the router
"send"
> your commands, expect a result and do something based on that result. As I
> said, its worth the time investment and you'll find once you get the
script
> done you can just reuse it for many other tasks.
>
> The TACACS+ suggestion is also good.. Not only would it allow you to limit
> who (authentication) can do what (authorization).. The accounting features
> would also provide a log entry if an authorized user did do a no
access-list
> 101.. You could then write a shell script to parse the accounting log.
>
> Cheers,
> Glynn
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Jim
> McBurnett
> Sent: Thursday, May 12, 2005 5:20 PM
> To: Paul Ryan; nanog@merit.edu
> Subject: RE: ACL Monitoring
>
>
> Paul,
> I think a better solution maybe to implement TACACS+ and resrict rights on
> who can do that..
> Sounds like you don't trust someone.
> I'd try that first...
>
>
> Later,
> Jim
>
> -Original Message-
> From: Paul Ryan [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 12, 2005 5:15 PM
> To: nanog@merit.edu
> Subject: ACL Monitoring
> Importance: High
>
>
>
>
> All - I am looking for a solution (open source, scripts) to allow me to
> monitor ACL's on Cisco routers. So if for example a line dissapears from
> an ACL or the entire ACL is removed - I am alerted via pager/e-mail etc.
>
> regards,
>
> Paul R
>
>

Re: ACL Monitoring

[Alexei Roudnev]

Other is CCR (Cisco Configuration Repository), derived from here:

 snmpstat.sf.net


- Original Message - 
From: "joshua sahala" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, May 12, 2005 2:16 PM
Subject: Re: ACL Monitoring


>
> On (12/05/05 17:14), Paul Ryan wrote:
> > All - I am looking for a solution (open source, scripts) to allow me to
> > monitor ACL's on Cisco routers. So if for example a line dissapears from
an
> > ACL or the entire ACL is removed - I am alerted via pager/e-mail etc.
>
>  http://www.shrubbery.net/rancid/
>
> /joshua
> -- 
>

Re: what will all you who work for private isp's be doing in a few years?

[Alexei Roudnev]

>
>
> So imagine a residential area all pulling digital video over wireless.
> Sound familiar? Ironically close to TV! (yet so different)
>
> What I can't understand is why multicast hasn't just gone gangbusters into
> use yet. I see it as a really pent-up capability that, in light of
Because multicast standards was written by academic idiots. -:) Very
difficult to use and full of unused features.

(Do not believe? Read RSVP protocol - not exactly multicast but not far away
from it).

And because multicast protocols (unfortunately) are not easy to implement.
It excuse this standards and their authors.

I can predict one more 'skype' like company, with really robust protocol,
catching multicast market. Something like 'peer to peer multicast' -:).




> broadband video, etc., is just going to have to break wide open soon.
>
> Joe
>
>
>
>
>   Ross Hosman
>   , Fred Heutte <[EMAIL PROTECTED]>
>   @yahoo.com>  cc:  [EMAIL PROTECTED]
>   Sent by: Subject: Re: what will all
you who work for private isp's be doing in a few years?
>   owner-nanog
>
>
>   05/12/2005 02:16
>   PM
>
>
>
>
>
>
>
> Not pointing any fingers but many of you think these
> small ISP's are just going to die off instead of
> adapt. Wireless is becoming a better and more reliable
> technology that in the future will be able to provide
> faster service then FTTH. I know of atleast one small
> ISP in Michigan that went from dial-up to deploying
> wireless. With WiMAX coming out I think you will see a
> number of smaller ISPs switching to it as a service.
> It is also much cheaper to deploy a wireless network.
>
> Me personally, I think wireless is the future for
> residential internet/tv/phone.
>
> Ross Hosman
> Charter Communcations
>
> --- Steve Sobol <[EMAIL PROTECTED]> wrote:
> >
> > Fred Heutte wrote:
> > > (1) There will be a market for independent ISPs as
> > long CLECs
> >
> > I think a more appropriate term would be ALEC
> >
> > (anti-competitive local exchange carrier)
> >
> > ...That having been said, the problem with the small
> > guys providing access is
> > they can't generally achieve the economies of scale
> > that allow them to compete
> > with the big guys.
> >
> > I'm on a Charter cablemodem, 3mbps down x 256kbps
> > up, $39.95/month. Verizon is
> > building out FTTH in this area and they're going to
> > be offering 5x2 for $39.95
> > or 10x5 for $49.95, IIRC. Those are all residential
> > prices, but Charter's
> > actually pretty competitive on business rates too.
> >
> > And yes, there are people who value service over
> > price, but the price
> > differential is only going to get worse.
> >
> >
> > --
> > JustThe.net - Apple Valley, CA - http://JustThe.net/
> > - 888.480.4NET (4638)
> > Steven J. Sobol, Geek In Charge /
> > [EMAIL PROTECTED] / PGP: 0xE3AE35ED
> >
> > "The wisdom of a fool won't set you free"
> >  --New Order, "Bizarre Love Triangle"
> >
>
>
>

Re: Internet attack called broad and long lasting

[Alexei Roudnev]

> > I agree. But I saw, how hackers intruded into XXX agency (USA's, I mean)
6
> > years ago. Cisco sources never was a great secret
>
> Then you shouldn't be talking about it.

I mean - such things was common even 6 years ago. There was (always) some
level of rooted servers, some level of teen hackers, some level of
compromised passwords. Absolutely nothing new. If you (like Cisco) have a
wide cooperation, are big, and decided (reasonably) do not sacrify in
productivity because of paranoiic security - you have some risk of be
intruded. It just means _use simple, sometimes primitive, but effective
measures for additional protection_. Host based IDS-es on ALL (ALL) servers,
single time passwords for everything, non standard ports - at least one of
such list (teher are much more on the list).

> Okay, so if it is a Good Thing for competitors and a Bad Thing for Cisco
> which is a commercial company with a vested interest in not giving away
> their secrets to competitors, how is this not a major loss? _EVEN_ if
> only in reputation?
No, exclude reputation from my list - I did not estimated it. 100% agree
about reputation. But cisco's reputation is not major thing
for anyone outside of Cisco.

I underplay it because it is overplayed by the media. If (IF!) cisco code
had not backdoors from developers (and I believe, it had not), then this
particular event is major for Cisco, but minor for the rest of the world
(even for competitors). You can not do much with this code, except if you
are Cisco or are contrafacting Cisco's as a clone - it (as any such code)
require the whole infrastructure around to be used. (It's as egg cell - we
need a whole women around to get use of it).

> > It is amazing. Cisco made  a lot of noice about IDS, IPS, etc etc
while
> > no one in reality need these super expansive and
> > complex tools (except few dozens of companies under the DDOS risk); but
>
> IDS.. IPS.. etc.. etc... DDoS risk?
>
> I can agree with many on the complete uselessness of IDS for most
> companies (I can't live without it!).. IPS systems are a different matter.
>
> > missed so simple thing as ssh exploit in their own nest. (It is not
> > harmless - we found ssh trojan on my previous job, just exactly the same
>
> Let me Google you and find where you worked. :o)
Ok, but we do few simpler measures (sometimes on 0 cost) which dramatically
decrease a chance of intrusions, and other measures to prevent any chance of
intrusion into important areas. And we do not forget to patch 'ssh' and
'ssl'  (after all -:)).

IDS and IPS are good, if you have it on _EVERYTHING_ (which means, btw, that
they can not be very expensive because you will never be able to use
expensive tool on _everything_) and, most important, main IDS and IPS have
brand names _cluefull admin and cluefull manager_.

But we got aside.

My point for this forum was _do not overestimate real harm from this Cisco
sources leak_. It is almost harmless (except for repuation) vs consumer data
leaks, consumer password's leaks, consumer OS exploits, medical data leaks
and so on.
If someone get control on ISP xxx routers - trust me, it will happen because
he found admin passwords and because
clueless admin allowed in-band access from Internet, or because NOC's server
was compromised - but not because someone had Cisco sources.

>
> >>Burrowing from that, if the attack is successful, and the loss is
> >>significant, I think the way there - although cute, is irrelevant except
> >
> > I mean _MINOR_ because lost was minor, in reality. No because it was ssh
> > exploit.
>
> Okay, I still don't follow you. I don't mean to be annoying but I really
> don't. Let's not move too much into the realm of security and stay in
> net ops.
>
> How is this not a loss and not a risk? If we can't reach an agreement I
> suggest we take this off-list.

Because it is useless for hackers, except if Cisco have a backdoors and
embedded trojans. And (most important) because it distract NOC's and
security guys from securing NOC's, access pathes to the routers, use
changable passwords and so on.

Simple question - do you control all changes on your routers and firewalls?
I mean - something like CCR system (which sends
daily change reports) or Cisco Works (as I know, do the same)? How often do
you change enable passwords? Is it enough for  intruder to set up sniffer in
the NOC, steal password, then loging and change config (and be unnoticed)?






>
> Gadi.

Re: Internet attack called broad and long lasting

[Alexei Roudnev]

> > *Your* boxes may be hardened beyond all belief and plausibility, but
you're
> > *STILL* screwed if some teenaged kid on another continent has more
effective
> > control of the router at the other end of your OC-48 than the NOC monkey
you
> > call when things get wonky
It is mostly fantasy. DNS security is much much more important and much more
real issue, vs this fictions.
If talking about Cisco, we have much more worries about chained bugs, vs
teens controlled OC-48 routers...

I mean - it is _real_, but it is far behind _much more realistic_ problems.

Re: Internet attack called broad and long lasting

[Alexei Roudnev]

> Alexei Roudnev wrote:
> > O, my god. Primitive hack, primitive ssh exploit I watched it all 6
> > years ago, bnothing changed since this.
> >
> > It is _minor_ incident, in reality.
>
> Primitive I can understand, but _minor_?
>
> First, I don't really see why an attack should be estimated by the tool
> used. If a 10 years old exploit would work, why should an attacker look
> for and use a 0day? It's silly allocation of resources.
I agree. But I saw, how hackers intruded into XXX agency (USA's, I mean) 6
years ago. Cisco sources never was a great secret
(a lot of people saw them; they are almost useless without Cisco's
infrastructure; they are interesting for competitors
 in some cases, because of very interesting technical ideas, but not for the
hackers). It is _MINOR_ in reality. Major can be,
for example, stealing 100,000 credit card numbers, because it make sence for
100, 000 people. Just Cisco sources... hmm, 100 total people in the world
will be affected, big deal...)

But I agree - it just showed old truth - good security is not technical
issue. Just simplerst _never use standard ports_ policy could prevent this
case. Better, _use One Time Passwords and single point signature_. Primitive
host based IDS (Osiris, for example). Any _real_ security policy, of course
(or better, ACCESS policy, because security is nothing - ACCESS mater! No
access required - no security issues...)

It is amazing. Cisco made  a lot of noice about IDS, IPS, etc etc while
no one in reality need these super expansive and
complex tools (except few dozens of companies under the DDOS risk); but
missed so simple thing as ssh exploit in their own nest. (It is not
harmless - we found ssh trojan on my previous job, just exactly the same
case - ssh opened to Internet, port #22! Since this, I never allow ssh on
port 22, Terminal Service on port 3389,  managemen t web on port 80 or 443,
and so on... /even when servcie is allowed, which is policy issue/...


>
> Burrowing from that, if the attack is successful, and the loss is
> significant, I think the way there - although cute, is irrelevant except
I mean _MINOR_ because lost was minor, in reality. No because it was ssh
exploit.


> for the defender.
>
> Gadi.

Re: Internet attack called broad and long lasting

[Alexei Roudnev]

O, my god. Primitive hack, primitive ssh exploit I watched it all 6
years ago, bnothing changed since this.

It is _minor_ incident, in reality.


- Original Message - 
From: "Sean Donelan" <[EMAIL PROTECTED]>
To: 
Sent: Monday, May 09, 2005 10:32 PM
Subject: NYT: Internet attack called broad and long lasting


>
>
> Internet Attack Called Broad and Long Lasting by Investigators
> By JOHN MARKOFF and LOWELL BERGMAN
>
> Published: May 10, 2005
>
> SAN FRANCISCO, May 9 - The incident seemed alarming enough: a breach of a
> Cisco Systems network in which an intruder seized programming instructions
> for many of the computers that control the flow of the Internet.
>
> [...]
> See the New York Times for the rest of the story.
>

Re: Port 25 - Blacklash

[Alexei Roudnev]

Hmm, the onses who block everything and cut wires off send 0 spam. So what?

- Original Message - 
From: "Daniel Golding" <[EMAIL PROTECTED]>
To: "Hank Nussbacher" <[EMAIL PROTECTED]>; "Adam Jacob Muller"
<[EMAIL PROTECTED]>
Cc: "Nanog Mailing list" 
Sent: Tuesday, April 26, 2005 2:50 PM
Subject: Re: Port 25 - Blacklash


>
>
> Do all of Comcast's markets block port 25? Is there a correlation between
> spam volume and the ones that do (or don't)?
>
> In any event the malware is already ahead of port 25 blocking and is
> leveraging ISP smarthosting. SMTP-Auth is the pill to ease this pain/
>
> - Dan
>
>
> On 4/26/05 2:49 PM, "Hank Nussbacher" <[EMAIL PROTECTED]> wrote:
>
> >
> > On Tue, 26 Apr 2005, Adam Jacob Muller wrote:
> >
> > Doesn't seem to be stemming the tide of emails from Comcast though:
> >
>

> >
> >
> > -Hank
> >
> >> For example, about 2 months ago, comcast decided to block outgoing
> >> port 25 from my entire neighborhood. I called comcast, and while
> >> sitting on hold I had the idea to setup a ssh tunnel to a machine at
> >> work and viola problem solved before anyone from comcast even
> >> answered the phone.
>
>

Re: ICMP Vulnerability

[Alexei Roudnev]

Too much noice on too small problem. The only use of this - BOT wars in IRC
world (mopre likely, with a very low success rate).


- Original Message - 
From: "Alex Bligh" <[EMAIL PROTECTED]>
To: "Gwendolynn ferch Elydyr" <[EMAIL PROTECTED]>; "Hannigan, Martin"
<[EMAIL PROTECTED]>
Cc: ; "Alex Bligh" <[EMAIL PROTECTED]>
Sent: Tuesday, April 12, 2005 8:59 AM
Subject: Re: ICMP Vulnerability


>
>
>
> --On 12 April 2005 11:57 -0400 Gwendolynn ferch Elydyr <[EMAIL PROTECTED]>
> wrote:
>
> > http://www.cisco.com/warp/public/707/cisco-sa-=20050412-icmp.shtml
>
> Actually
>  http://www.cisco.com/warp/public/707/cisco-sa-20050412-icmp.shtml
>
>
> Alex

Re: Vonage Hits ISP Resistance

[Alexei Roudnev]

> On Wed, 30 Mar 2005 21:36:19 -0600, Chris Adams <[EMAIL PROTECTED]>
wrote:
> >
> > Once upon a time, Eric A. Hall <[EMAIL PROTECTED]> said:
> > > Do you also block NNTP so that customers have to use your servers?
> >
> > Change that to SMTP and you'll get a bunch of "yes" answers.  Why is one
> > right and the other wrong?
>
> Heard of a little thing called 'spam'?

So what? You can use your car as a weapon; should we prohibit you from car
driving?

>
> Jamie
>
> > --
> > Chris Adams <[EMAIL PROTECTED]>
> > Systems and Network Administrator - HiWAAY Internet Services
> > I don't speak for anybody but myself - that's enough trouble.

Re: public accessible snmp devices?

[Alexei Roudnev]

Cisco drops SNMP requests but not return '0', I saw it (dropped requests
because of _busy_) many times.
- Original Message - 
From: "Petri Helenius" <[EMAIL PROTECTED]>
To: "Jim Popovitch" <[EMAIL PROTECTED]>
Cc: "Alexei Roudnev" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;

Sent: Sunday, March 06, 2005 7:18 AM
Subject: Re: public accessible snmp devices?


>
> Jim Popovitch wrote:
>
> >
> >I think this could be relevant.  a LOT of devices drop snmp requests
> >when they get busy or when too many incoming requests occur.  Are you
> >sure that you were the only one polling that device?  Perhaps someone
> >else put it into a "busy" state.  Too often with SNMP devices and tools
> >a '0' can mean things other than zero.
> >
> >
> So you are saying that it's ok for a Cisco or Juniper router to return
> zero for a counter when they feel "busy" ?
>
> My RFC collection tells a different story.
>
> Pete
>

Re: public accessible snmp devices?

[Alexei Roudnev]

It's OK to see any garbage in SNMP; I never got surprised (as I was not
surprised when I killed firewall by snmpwalk).
No one (in reality) makes good QA on SNMP functions (on routers or
switches).

I already have a few sanity checks in 'snmpstat', may be I should add one
more (ignore answers with 0 counters).


- Original Message - 
From: "Petri Helenius" <[EMAIL PROTECTED]>
To: "Jim Popovitch" <[EMAIL PROTECTED]>
Cc: "Alexei Roudnev" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;

Sent: Sunday, March 06, 2005 7:18 AM
Subject: Re: public accessible snmp devices?


> Jim Popovitch wrote:
>
> >
> >I think this could be relevant.  a LOT of devices drop snmp requests
> >when they get busy or when too many incoming requests occur.  Are you
> >sure that you were the only one polling that device?  Perhaps someone
> >else put it into a "busy" state.  Too often with SNMP devices and tools
> >a '0' can mean things other than zero.
> >
> >
> So you are saying that it's ok for a Cisco or Juniper router to return
> zero for a counter when they feel "busy" ?
>
> My RFC collection tells a different story.
>
> Pete
>

Re: public accessible snmp devices?

[Alexei Roudnev]

Hmm, good idea. I add my voice to this question.

But, btw, SNMP implementations are extremely buggy. Last 2 examples from my
experience (with snmpstat system):
- I found Cisco which have packet countters (on interface) _decreased_
instead of _increased_ (but octet counters are _increased_);
- I have Cisco and interface, which do not report type if you ask it by
exact request, but you can read type by requesting 'snmpwalk' ('get next
variable');
- many many devices can be kicked down by SNMP packets (I kicked down Pix
firewall in one point, and few 6509 switches in other).

So, it is not so easy - to have such publickly available devices. I hear
about companies  whho rent you network systems (just full network, not a
separae cisco or 3-com) for learning purposes; may be, use them?

- Original Message - 
From: "Vicky Rode" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, March 03, 2005 7:53 AM
Subject: public accessible snmp devices?


>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi there,
>
> Just wondering if there are any pool of public accessible (read-only)
> snmp enabled devices that one can access for testing purposes (such as
> snmpwalk, polling devices via oid/mib, graphing chart..etc)?
>
> I'm looking for a pool of devices that I run my test on.
>
> Any pointers will be appreciated.
>
>
> regards,
> /virendra
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.5 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFCJzLfpbZvCIJx1bcRAqLcAJ95PzxXE4v51JgzTpeqfuEDZG6ibgCaAg20
> WJxjcsJYroHriTPr635QOBE=
> =SV3b
> -END PGP SIGNATURE-

Re: Emergency Internet Backbone Provider Maintenance Tonight

[Alexei Roudnev]

I do not expect, that any carriet took this as an emergency - defect is
quite harmless (DOS in the worst case, + no exploits known, + no any
interest for anyone to do it, + VoIP gateways involved only...). Even if
someone is doing maintanance, it can be noticed by VoIP network users only.

Moreover, correct me if it was not defect in Cisco express call center (call
center @ IOS) - I can not image carriers using this (it was designed for
small businesses).

Why to get simple, relatively harmless (require ugrade in next scheduled
time, usually 1 - 3 weeks) defect as a terrible threat to everyone? Even BGP
problem was much more dangerous (and no single case known since this, so it
was not emergency as well)..

- Original Message - 
From: "Darrell Kristof (CE CEN)" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, January 22, 2005 7:52 PM
Subject: Emergency Internet Backbone Provider Maintenance Tonight



All:

Has anyone heard about some carriers doing emergency maintenance tonight
on Internet routers due to a code vulnerability?  I'm trying to find out
what vendor it involves and the details behind it.  I understand it's
still under NDA, but I'm sure someone out there knows more.

Thanks,

- Darrell

==
Darrell Kristof, CISSP, CCNP, TICSA
Network Manager/Team Leader
Whole Foods Market, Corporate Offices

Re: Gtld transfer process

[Alexei Roudnev]

Problem - you are talking about changing registrar, but in reality you
describe changing of domain owner.

Why (what for) is it  allowed to transfer from one registrar to another with
changing NS records and other owner information?
Why don't separate this 2 events - changing registrar, and changing domain
owner/information? Is it any need in reality changing registrar with
simultaneous changing domain information?

What should happen in normal situation:
- someone requested transfer of domain (without real authorisation);
- even if all checks pass and transfer was allowed, new registrar should
maintain the same NS and other information as old one, so no real damage
could happen;
- domain owner received e-mail, see frauded transfer and disputed it (having
domain in working condition on the new registrar);
- new registrar OR old registrar OR VeriSign roll back transaction.




- Original Message - 
From: "Bruce Tonkin" <[EMAIL PROTECTED]>
To: 
Sent: Monday, January 17, 2005 11:36 PM
Subject: Gtld transfer process



Hello All,

Given the recent panix.com hijacking, I will give an outline of the
current ICANN transfers process for gtlds.

In the case of panix.com, evidence so far indicates that a third party
that holds an account with a reseller of Melbourne IT, fraudulently
initiated the transfer.   The third party appears to have used stolen
credit cards to establish this account and pay for the transfer.  That
reseller is analysing its logs and cooperating with law enforcement.
There was an error in the checking process prior to initiating the
transfer, and thus the transfer should never have been initiated.  The
loophole that led to this error has been closed.

The transfer process has several checks and balances that are described
below.  It seems that in this case none of these worked.  I can only
comment on those from our end.

Note also that panix.com was held in the .com registry, that does not
use the new EPP protocol which incorporates the facility to store a
separate password (called auth_info) for each domain name that must be
checked before completing a transfer.


Transfers process
=
(see http://www.icann.org/transfers/policy-12jul04.htm for full details)

(1) A person initiates a transfer for a domain name via a reseller or
registrar

(1a) For registries (e.g org, biz, info, name) that use the EPP
protocol, the person also needs a password that is held in the registry
for each domain name (called auth_info in EPP protocol)

(2) The gaining registrar is responsible for obtaining approval from the
registrant (using the contact details available in the WHOIS of the
losing registrar) using a standardised form
(http://www.icann.org/transfers/foa-auth-12jul04.htm).  In some cases
registrars delegate the obtaining of the approval from a reseller that
has direct contact with the registrant.   A gaining registrar is not
permitted by the policy to initiate a transfer without approval from the
registrant.

(3) The registrar initiates the transfer.

(4) The registry checks to see if the name is on Registrar-LOCK, if so,
the transfer request is rejected.   Registrants may choose to put domain
names on registrar-lock.  Many registrars now put names on lock by
default, and give the registrant the opportunity to remove a lock prior
to transfer.

(4a) For registries (e.g org, biz, info, name) that use the EPP
protocol, the registry checks the auth_info supplied by the gaining
registrar against the record in the registry.  If there is no match, the
transfer request is rejected.

(5) The registry will send a message to the losing registrar confirming
that a transfer has been initiated.

(6) [OPTIONAL] A losing registrar may send a standard confirmation
message
(http://www.icann.org/transfers/foa-conf-12jul04.htm) to the registrant.
A registrant may cancel a transfer at this point.  A registrant may also
immediately confirm a transfer at this point and the transfer will be
immediately completed.

(7)  If the registry receives no response from the losing registrar
after a 5 day period, the transfer will be completed.

(8) A registrant may not further transfer a name for a period of 60 days
(apart from back to the original registrar).

(9) If the losing registrar believes that a transfer was unauthorised,
the losing registrar may contact the gaining registrar for a copy of the
authorisation in step 2 to arrange for the transfer to be reversed.

(10) If the registrars cannot resolve a dispute, the losing registrar
may initiate a dispute process with the registry operator.

(11) If the registry operator cannot resolve a dispute, the losing
registrar may initiate a dispute process with an external dispute
resolution provider
(http://www.icann.org/dndr/tdrp/approved-providers.htm).


In the case of panix.com, the step (2) failed at the gaining registrar.
I can't comment on steps taken by the losing registrar.

The principle of the process, is that a registrant can move to another
domain name p

Re: panix.com recovery in progress

[Alexei Roudnev]

There is more sertious problem here.

I can image 2 kinds of transfer:
- (1) domain is transferred WITHOUT CHANGES to the new registrar. Notice -
WITHOUT CHANGES. New registrar
should not change diomain without explicit order from owner.

- (2) Domain is expired and, after reasonable HOLD period, is transferred to
the new owner (and more likely new registrar). I can happen with the unused
domain only, or with domain which is expired.

In no case can 2 events happen together; if it happen, it is 100% indication
of hajacking. If someone want domain to be delegated to the new owner, he
91) change registrar if necessary, and (2) change donain owner.

All other approaches are very dangerous.


>
> On Sun, Jan 16, 2005 at 06:01:35PM -0500, Henry Yen wrote:
> >
> > The latest shell host motd's:
> >
> > . Hijack recovery underway (elr) Sun Jan 16 17:43:28 2005
> > .
> > .Recovery is underway from the panix.com domain hijack.
> > .
> > .The root name servers now have the correct information, as does the
> > .WHOIS registry.  Portions of the Internet will still not be able to
> > .see panix.com until their name servers expire the false data.  More
> > .info soon.
>
> Yes, some folks with serious mojo got involved and things seem to be
> on the way to "operationally fixed".  AFAIK there is still no progress as
> to the question of how this kind of transfer can happen without notice
> to the transferred-from registrar (it's possible that there's progress
> I don't know about).
>
> I have just spoken to the tremendously tired and overworked ops staff at
> Panix again.  They would appreciate it very much if network operators
> would reload their nameservers to help the good data for panix.com
> propagate over the bad.  Some Panix customer email now seems to be being
> relayed to the actual Panix mail servers by the fake ones in the UK, which
> is not such a good thing for obvious reasons.
>
> Thor

Re: The entire mechanism is Wrong!

[Alexei Roudnev]

>
> Joe Maimon <[EMAIL PROTECTED]> writes:
> > Or perhaps do you mean previous owners can call in a "stop order" or
> > "dispute" the transfer unilaterally within X days of occurence, much
> > like it works for many REAL money transactions?
>
> That makes considerable sense. You should be able to call in, say
> "roll it back", and have it stay rolled back for a few days until
> someone can investigate.
It is exactly what I was talking about.

>
> If people like Melbourne IT are going to claim they can't act on
> weekends, it might also be sensible not to allow transfers to be
> processed between Thursday and Sunday, though honestly I think if you
> are going to be a registrar, you are going to have to deal with
> problems over weekends.
It is their dirty problem - if they can not act on weekend, they can not
maintain a registry, that's all.


>
> One more disturbing problem here -- it seems (based on external
> evidence) that someone managed to fake out the system. Although
> Verisign and Melbourne IT seem to think that the transfer was
> approved, neither Dotster nor Panix have any record at all of
> it. Dotster's records make them think they are still the registrar for
> panix.com. It appears someone cracked the system, though whether by
> exploiting protocol problems or in some other way isn't clear at all.
If I am allowed to say my personal opinion here - it more likely was a
technical bnug or human mistake, not a hack. But let's see. This case
shiould be carefully investigated, no matte if this transfer was legal or
not.


>
> Perry

Re: panix.com hijacked (VeriSign refuses to help)

[Alexei Roudnev]

 >
>
> >
> > I addition, there is a good rule for such situations:
> > - first, return everything to _previous_ state;
> > - having it fixed in previous state, allow time for laywers, disputes
and
> so
> > on to resolve a problem.
>
> agreed. but then proverbially, "common sense isn't".
>
> > What happen if someone stole 'aol.com'domain tomorrow?  Or
> 'microsoft.com'?
> > How much damage will be done until this sleeping behemots wake up, set
up
> a
> > meeting (in Tuesday I believe - because Monday is a holiday), make any
> > decision, open a toicket, pass thru change control and restore domain? 5
> > days?
>
> with due respect to panix (i knew of panix before i ever knew of aol, even
> living in europe), i imagine another bigger 'behemoth', as you so deftly
put
> it, has a better way of liaising with verisign than you, me or panix.

There is _rollback to the first state in case of any conflicts_ common sense
rule, just to prevent liaising.
If you purchase domain or transferred it, and I suspended change for a week,
it may never make big harm to you.


>
> -p
>
> ---
> paul galynin
>

Re: panix.com hijacked (VeriSign refuses to help)

[Alexei Roudnev]

I addition, there is a good rule for such situations:
- first, return everything to _previous_ state;
- having it fixed in previous state, allow time for laywers, disputes and so
on to resolve a problem.

It makes VeriSign position very strange (of course, it is dumb clueless
behemot as it was all the time around) - instead of saying _OK, let's return
last transactions and then you can object this change_, they just step out.
Problem is much more serious than just one stolen domain - it shows 100%
that VeriSign is not able to manage  domain system properly.

What happen if someone stole 'aol.com'domain tomorrow?  Or 'microsoft.com'?
How much damage will be done until this sleeping behemots wake up, set up a
meeting (in Tuesday I believe - because Monday is a holiday), make any
decision, open a toicket, pass thru change control and restore domain? 5
days?


- Original Message - 
From: "William Allen Simpson" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, January 16, 2005 12:38 AM
Subject: Re: panix.com hijacked (VeriSign refuses to help)


>
> Since folks have been working on this for hours, and according to
> posts on NANOG, both MelbourneIT and Verisign refuse to do anything
> for days or weeks, would it be a good time to take drastic action?
>
> Think of what we'd do about a larger ISP, or the Well, or really any
> serious financial target.
>
> Think of the damage from harvesting <>logins and mail passwords of
> panix users.
>
>
>
>
>
>
>
>
>
>
> ===
>
> Does somebody have a fast DNS server that can AXFR the records from
> those 2 name servers, then fix the panix.com entries?
>
> Are people willing to announce some replacement servers as /32 BGP?
> Sort of an emergency anycast?
>
> ===
>
> Alternatively, are people willing to block those name servers and/or
> the entire blocks they are located in, to prevent the distribution of
> the false panix.com addresses?
>
> -- 
> William Allen Simpson
> Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
>

Re: IBGP Question --- Router Reflector or iBGP Mesh

[Alexei Roudnev]

Agree; but do not forget that you can alwys add direct connections between
clients (if I am not forgotten something).
If 2 clients have direct link between them, it may be a good practice to add
direct iBGP connection.

It means that iBGP topology should reflect (more or less) network one. Else
you can have non-optimal (but still consistant and correct) routing.


- Original Message - 
From: "David Barak" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, January 12, 2005 4:20 AM
Subject: Re: IBGP Question --- Router Reflector or iBGP Mesh


>
>
> --- Alexei Roudnev <[EMAIL PROTECTED]> wrote:
>
> >
> > Are you sure? RR should just distribute routes.
> >
> > RR do not make any route decisions, and (btw) iBGP
> > do not make route
> > decisions - they are mostly based on IGP routing.
> > All iBGP + RR are doing
> > is:
> > - tie external routes to internal IP;
> > - distribute this information using iBGP mesh, RR's
> > etc.
> > - receive this information and set up routing using
> > internal IP (which are
> > routed by IGP protocls).
> >
> > End routers receives iBGP routes and uses IGP (OSPF
> > or EIGRP or anything you
> > use) for route decisions (of course, we can image
> > exceptions, but normally ,
> > it works so that all decisions are based on IGP
> > routing). Most important
> > decisions are done , where routes are emitted from
> > EBGP into iBGP, others -
> > by iGP; which decisions are done by RR's themself?
>
> The primary decision made by a route-reflector is the
> same decision which would be made by multiple routers
> in an iBGP full-mesh: which exit point should this
> router use to reach a specific netblock.
>
> Leaving aside for the moment any manipulation of
> multipath, each router will run the BGP route
> selection algorithm on each route learned.  If
> multiple routes are learned to a given destination,
> only one will be inserted into the RIB.  The standard
> behavior for a router is to only pass on those routes
> which have been accepted into the RIB.
>
> So if you have this network
>
> C1 -R1--R2-C2
>  |   |
> C1 -R3--R4-C3
>
> And R1 is the only route-reflector (yeah, yeah, bad
> design - it's just an example), R4 will only learn
> about the path to C1 through R1, and might route
> traffic along the R4->R2->R1->C1 path rather than
> along the R4->R3->C1 path which would be preferred by
> an iBGP full-mesh.
>
> The upshot of this is the following (drumroll):
> route reflectors are a wonderful thing, but make sure
> that their topology reflects and respects your
> underlying IP network topology.  If you don't, you can
> get unpleasant consequences.
>
>
>
> =
> David Barak
> Need Geek Rock?  Try The Franchise:
> http://www.listentothefranchise.com
>
>
>
> __
> Do you Yahoo!?
> Yahoo! Mail - Helps protect you from nasty viruses.
> http://promotions.yahoo.com/new_mail

Re: IBGP Question --- Router Reflector or iBGP Mesh

[Alexei Roudnev]

It is correct more or less (I prefer to say that RR reflects only the best
routes... through I am not sure, is it
theoretical limitation or just implementation - RR can in theory reflect ALL
routes).

Anyway, usual usage of RR is _RR on backbone, and clients in the branches_,
which eliminate this problem (if client / client packets are going thru the
reflector, then reflector's decition makes more sense).

Do not forget that routing must be consistant - different nodes can not use
very different alghoritms to select routes (else you will have routing loops
easily), so problem is not so strong as it seems initially. You can always
add direct iBGP connections between 2 RR clients, if they have direct IP
connection and you suspect suboptimal routing thru RR's.

If we want to continue (I am not 100% sure in this problem), let's drow
pictures first.


>
> On 12-jan-05, at 9:06, Alexei Roudnev wrote:
>
> > Are you sure? RR should just distribute routes.
>
> > RR do not make any route decisions, and (btw) iBGP do not make route
> > decisions - they are mostly based on IGP routing.
>
> Route reflectors only propagate their idea of the best route for a
> destination. If this decision is based on eBGP-learned information such
> as the AS path this doesn't matter because all routers in the AS would
> make the same decision anyway, but if the IGP metric comes into play
> (which invariably happens in large networks) then all the reflector
> clients only see the route that is best based on the IGP metrics the
> reflector sees.
>
> (Obviously the IGP metric will be different at the client, but the
> client doesn't see the other routes, so it can't make a different
> decision. The real fun starts when the next (intra-AS) hop isn't a
> reflector client and the packet now takes a different path than the
> reflector client thought it would take.)
>

Re: IBGP Question --- Router Reflector or iBGP Mesh

[Alexei Roudnev]

Are you sure? RR should just distribute routes.

RR do not make any route decisions, and (btw) iBGP do not make route
decisions - they are mostly based on IGP routing. All iBGP + RR are doing
is:
- tie external routes to internal IP;
- distribute this information using iBGP mesh, RR's etc.
- receive this information and set up routing using internal IP (which are
routed by IGP protocls).

End routers receives iBGP routes and uses IGP (OSPF or EIGRP or anything you
use) for route decisions (of course, we can image exceptions, but normally ,
it works so that all decisions are based on IGP routing). Most important
decisions are done , where routes are emitted from EBGP into iBGP, others -
by iGP; which decisions are done by RR's themself?






> On Tue, 2005-01-11 at 13:09, Daniel Roesen wrote:
> > One of the main problems of route reflection is that the best path
> > decision is done centrally. The best route is not seen as from the
> > router making the forwarding decision, but from the route reflector's
> > point of view. Depending on network topology, geographic spread end
> > peering/transit topo, this might/will have significant negative effects.
>
> This is where good use of clusters and logical network design are
> necessary, but I don't think this is a route-reflector specific problem,
> more a general networking problem once your network starts groing and
> you start deploying a more complex edge/core based topology. I don't
> think this is a reason to not use reflection as oppossed to full mesh.
>
> Cheers,
>
> -- 
> ---
> Erik Haagsman
> Network Architect
> We Dare BV
> tel: +31(0)10 7507008
> fax:+31(0)10 7507005
> http://www.we-dare.nl
>
>

Re: Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU

[Alexei Roudnev]

Yes, it is correct.

> > 
> > It is a cisco pix, right?  Maybe just replacing the thing with a 1U
> > openbsd box will work wonders.
> 
> A PIX firewall can handle EDNS fine.  It just has to be told
> what is the maximum EDNS size being advertised by the internal
> clients.  The defaults assume there is no EDNS (e.g. 512).
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

Re: Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU

[Alexei Roudnev]

I receive DNS responses > 500 bytes every day (reported by PIX firewall). So
it is an issue, no matter wgat is recomended in RFC.


- Original Message - 
From: "Mark Andrews" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, January 09, 2005 3:08 PM
Subject: Re: Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU


>
> In article <[EMAIL PROTECTED]> you write:
> >
> >On 5-jan-05, at 17:39, Sabri Berisha wrote:
> >
> >>> Are there any common examples of the DF bit being set on non-TCP
> >>> packets?
> >
> >[...]
> >
> >> Here you go. A root-nameserver setting the DF-bit on its replies :)
> >
> >This is very bad.
> >
> >With a 296 byte MTU I don't get answers from
> >(a|b|h|j).root-servers.net, *.gtld-servers.net, tld2.ultradns.net and
> >some lesser-known ccTLD servers.
> >
> >I would have thought this impossible, but seeing is believing...
> >
> >Fortunately, this problem won't present itself with regular smaller
> >MTUs, the MTU has to be smaller than around 500 bytes. I haven't tested
> >whether these servers also suffer from the "regular" PMTUD problem
> >where the ICMP messages are ignored, but I'm assuming they don't, so
> >doing all of this over TCP should still work.
>
> Well DNS (not EDNS) is limited to 512 octets so you unless there
> are real links (not ones artificially constrained to demonstrate
> a issue) this should not be a issue in practice.  The default link
> mtus for slip/ppp/ethernet are all large enought for a DNS/UDP
> response to get through without needing fragmentation.
>
> For EDNS which will send up to 4k UDP datagrams (current recommended
> size) this could be a issue in that the clients would have to fall
> back to DNS after timing out on the EDNS query.
>
> e.g.
> EDNS query
> EDNS response (dropped due to DF)
> timeout
> DNS query
> DNS response gets through.
>
> Note for IPv6 one sets IPV6_USE_MIN_MTU on the UDP socket so this
> should be a non-issue there.
>
> Mark

Re: minimum requirements for a full bgp feed

[Alexei Roudnev]

36xx or 72xx
 
Old != bad .
 
All you need is MEMORY = >= 256 Mb.
 
 

  - Original 36xx, 72xx
   
  Message - 
  From: 
  Erik 
  Amundson 
  To: Mark Bojara ; nanog@merit.edu 
  Sent: Monday, January 03, 2005 6:27 
  AM
  Subject: RE: minimum requirements for a 
  full bgp feed
  
  Well,
   
  In my experience it depends on the model of router.  
  I had a 3640 (granted, it's old) with 128MB that was just fine until a couple 
  of months ago, now it's not enough.  For one BGP table you will have to 
  have at least 256MB in a 36xx router.  Our 720xVXR routers currently have 
  256MB in them as well, but we've already ordered upgrades to 1GB with new 
  NPE-G1s...
   
  - 
  Erik
   
  
  
  From: Mark Bojara [mailto:[EMAIL PROTECTED] 
  Sent: Monday, January 03, 2005 8:23 AMTo: 
  nanog@merit.eduSubject: minimum requirements for a full bgp 
  feed
  Hello All,If I wish to purchase a Cisco router that handles 
  a full internet BGP feed what are the minimum specs I should be looking 
  at?RegardsMark Bojara

Re: New Computer? Six Steps to Safer Surfing

[Alexei Roudnev]

Please,do not compare connections thru PNAT (DSL + Linksys) with dialup.

So, this all is incorrect - DSL providers are (in 90% cases) protected from
the very beginning by hardware (even if they never hear word FIREWALL) -
because of PNAT.

- Original Message - 
From: "Suresh Ramasubramanian" <[EMAIL PROTECTED]>
To: "Sean Donelan" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, December 18, 2004 7:43 PM
Subject: Re: New Computer? Six Steps to Safer Surfing


>
> On Sat, 18 Dec 2004 22:07:58 -0500 (EST), Sean Donelan <[EMAIL PROTECTED]>
wrote:
> > On Sun, 19 Dec 2004, Suresh Ramasubramanian wrote:
> > > Just asking .. any idea how many cable / dsl operators around the
> > > world - not just in the USA - provide hardware firewalls along with
> > > their CPE equipment - or perhaps provide CPE equipment that's capable
> > > of firewalling?
> >
> > How many dialup operators around the world provide hardware firewalls?
Or
> > is the modem built into your computer or bought as an add-on card?
>
> Not a valid comparison.
>
> At least some manufacturers make hardware firewalls that are also
> PPPoE / PPPoA dsl modems.  Linksys for example.  Several other
> manufacturers don't do this.
>
> -- 
> Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: (newbie) BGP For Dummies?

[Alexei Roudnev]

I recommend such thing (remembering, how we learned BGP ourself many years
ago, and then participated in edition of the book about BGP).


But it all depends of complexity. 2 uplink multihome site - simple case; 100
node backbone with reflectors and private AS-es - another one.

>
> On Fri, 2004-12-10 at 21:35, David E. Smith wrote:
> > "Hi, long-time listener, first-time caller..."
> >
> > Can anyone recommend a good forum for BGP questions? I've got my copy of
the
> > O'Reilly book handy, but having never really worked with BGP before, I
find
> > it's not really the best novice-level work.
>
> Within the E-Next network of excellence, we organised two weeks ago a
> two-days tutorial on BGP. This tutorial assumes that the attendees have
> a basic understanding of IP routing works but no prior knowledge of BGP
> is assumed. The tutorial has a theoretical part covering the behaviour
> of the BGP protocol and a practical part with the C-BGP simulator
> (http://cbgp.info.ucl.ac.be) whose syntax is close to Cisco routers.
>
> Upon request from some attendees of the tutorial who intend to deliver
> BGP courses within their universities, we have released all the training
> material under a creative commons licence, see :
> http://totem.info.ucl.ac.be/bgp.html
>
> Suggestions and comments on improvements to this training material are
> welcome
>
> Best regards,
>
> Olivier Bonaventure
> -- 
> CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
>

Re: (newbie) BGP For Dummies?

[Alexei Roudnev]

Here is it:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml

Very good document.

Re: (newbie) BGP For Dummies?

[Alexei Roudnev]

There was excellent docuent on Cisco (better than book). I can search for
it, if you want.

Btw, BGP is not for dummies, too many possible consequencies of config
errors are possible.

- Original Message - 
From: "David E. Smith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 10, 2004 12:35 PM
Subject: (newbie) BGP For Dummies?


>
> "Hi, long-time listener, first-time caller..."
>
> Can anyone recommend a good forum for BGP questions? I've got my copy of
the
> O'Reilly book handy, but having never really worked with BGP before, I
find
> it's not really the best novice-level work.
>
> (Or, if questions about weird inter-AS routing scenarios are on-topic
here, I'd
> be glad to bounce my problems around on NANOG.)
>
> Thanks!
>
> David Smith
> MVN.net
>

Re: Enterprise syslog management and alert generation.

[Alexei Roudnev]

In such products, only 20% value is in engine; 80% are in rules, because I
can not wrire rules myself - I have not event until it happen, and I can not
filetr out noice until it happen.

We use a few syslog analyzers (using syslog-ng as a transport), some with
simple logcheck, other with database for rules and hosts; and every time
problem is the same - writing rules is 90% of the problem.

But... do you have rules, such as fort example _send alert if any system
began to generate 10 times logs / hour more vs. average? Or saying _single
PCI ERROR on Solaris - ignore, 10 in a straight line - send warning...




- Original Message - 
From: "Bill Nash" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 07, 2004 12:48 PM
Subject: Enterprise syslog management and alert generation.


>
>
> Some people call this 'Netcool' or products of a similiar stripe. I'm
> ramping up a project to rebuild some previous work done on this front with
> an open source distribution in mind (those of you on the syslog-ng list
> have seen mention of it), so I'm fishing for requirements I may not have
> already covered.
>
> I currently have:
> Perl regexp engine for applied rules.
> Tokenization and extraction of data from inbound syslog data.
> Assigning (single|multiple) customized event handlers to rule matches
> Ability to run multiple analyzers concurrently
> Optional linear rule application versus weighted optimization
> SQL storage of rules for centralized management and redistribution.
> Fully customized alert generation.
>
> My current production implementation has handled over 20 gigs a day, at
> peak, on a single analyzer (dual amd 2800+), using syslog-ng as a
> transport mechanism (forked socket transport with local disk logging for
> backup).
>
> Every network is different, as are particular requirements. Who's got wish
> lists? I personally wouldn't mind an on-list discussion about this, as it
> applies to standard operations toolsets, but if that's not kosher, feel
> free to contact me off-list.
>
> - billn

Re: Intelligent Automation of network tasks

[Alexei Roudnev]

On Cisco it is (generation of config update) veryu complicated (in general
case) task. But we always automated every day config changes (acccess lists,
as path lists, route maps, interfaces except some special cases, and so on).

perl + 'expect+ 'conf net' was key elements.

- Original Message - 
From: "Jared Mauch" <[EMAIL PROTECTED]>
To: "Ejay Hire" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, December 07, 2004 10:53 AM
Subject: Re: Intelligent Automation of network tasks


>
> On Tue, Dec 07, 2004 at 12:39:25PM -0600, Ejay Hire wrote:
> >
> > In my opinion, every network with more than a dozen or so routers needs
> > an automated method to distribute massive configuration changes.  There
> > is a lot of fear that something will break during updates, but with some
> > intelligence, that risk can be minimized.
>
> juniper and cisco both support taking machine generated
> configurations generated by a non-router device (eg: unix host).
>
>
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d1dc2.html
>
> it's not just in 12.3T, it's also in 12.2S..
>
> on your juniper, try something like "config, load override"
>
> - jared
>
> -- 
> Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
> clue++;  | http://puck.nether.net/~jared/  My statements are only
mine.

Re: using sniffer on high-bandwidth pipes

[Alexei Roudnev]

We are using FreeBSD 4.x on 1Gbit Ethernet (for snifferring). Never had a
problems (but I should not garantee 100% snifferring on 400,000pps).

In reality, correct, pps is important, bandwidth is not important. If
traffic is VoIP, it's a problem; if it is 90% WEB, it's an easy task.

- Original Message - 
From: "Steve Francis" <[EMAIL PROTECTED]>
To: "todd romero" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, December 03, 2004 8:08 AM
Subject: Re: using sniffer on high-bandwidth pipes


>
> It probably depends more on pps than bandwidth.
> At a prior job, I used FreeBSD 4.x machines to capture over 400,000 pps,
> I think, on gigabit links.
> You need a nic that is supported with one of the device polling drivers
> to keep CPU manageable. (Intel, not yet broadcom.)
>
> FreeBSD far surpassed Solaris in packet capture performance.
>
> Linux 2.6 machines may do OK, using NAPI - but I've no experience with
that.
>
>
> todd romero wrote:
>
> >does anyone have expirience using a sniffer on a hi-capacity network
> >segment, that might know if there are limitations I need to worry about?
> >
> >example: customers doing EMC database replication across a mpls link, and
> >when the capacity reaches aprox. 250 Mbp/s packets are arriving out of
> >sequence etc.  So we need to put sniffers on both sides to capture some
> >data to see whats happeneing when the capacity reaches 250mbps.
> >
> >what kind of system requirements would be needed to be able to be able to
> >capture that amount of data. For some reason, I dont think that the Dolch
> >Pac 65 sniffers we have (running nt4 and sniffer pro2) would be able to
> >handle that kind of data?  If they cant, we can probbaly use a sun box.
> >what kind of specs would the box need?
> >
> >tia,
> >tr
> >
> >
>

Re: BIND + DLZ

[Alexei Roudnev]

probind2.sf.net

It is not Postgresql and DLZ, it generates zones using MySQL database.


- Original Message - 
From: "Erik Haagsman" <[EMAIL PROTECTED]>
To: "Micah McNelly" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, December 01, 2004 11:17 AM
Subject: Re: BIND + DLZ


> 
> And while we're on the subject...anyone know a reliable web-based admin
> front-end for BIND + DLZ + PostgreSQL...? Or does everybody just roll
> their own...?
> 
> On Wed, 2004-12-01 at 19:17, Micah McNelly wrote:
> > Nanog,
> > 
> > Does anyone have information on performance numbers comparing tinydns
> > vs. bind w/ dlz patch?
> > 
> > Hit me up off-list.
> > 
> > /m
> -- 
> ---
> Erik Haagsman
> Network Architect
> We Dare BV
> tel: +31.10.7507008
> fax: +31.10.7507005
> http://www.we-dare.nl
> 
> 
> 
> 

Re: How to Blocking VoIP ( H.323) ?

[Alexei Roudnev]

Below, please:

  s/such/VoIP filtering/

and it will be true. It do not depends of alghoritm you are using.

Moreover, if you deploy such service, someone else can deploy VoIP which
uses https tunnel to it, and you will not have any chances than to block
total https traffic.

It (such thing) can be more  practical in corporate network (on gateway) or,
yep, in case if third force (gov.) requires it and you really want to comply
(not to show a compliance).

But I just dropped an idea, not the whole solution.

> However, attempting to deploy such in the presence of any
> competitive market would likely result in widespread customer
> migration.  A government or assured monopoly could deploy
> it, though, and then charge a premium for those who want it
> removed (i.e. "premium data service") which conveniently
> happens to match their current voice tariffs...
>
> /John

Re: IPV6 renumbering painless?

[Alexei Roudnev]

Btw  - using Solaris + no_stack_exec + old ssl - appear to be 100% secure
from all random attacks (it can be broken - in theory, see articles from
'Solar designer' - but it is absolutely inpractical for hacking). I watched
such system (absolutely not patched, with apache and openssl, untouched for
3 years - we kept it as a honeypot - no single exploit). And if you add  IP
filter + non standard port protects your 100% even if your service have
broken library.

As a result - it is safer to run old openssl + filter + solaris, vs running
SuSe linux + automated upgrade + unfiltered openssl. It is wekk known
thing - want best security - do not use anything standard, customize
everything.

So, step 1 - filter;  step 2 -customize; and step 3 - update. Just updates
without first 2 steps are much more dangerous, vs no updates but first 2
steps.

PS. Why is it in IPv6 thread?  And why IP filtering is broken? Even
primitive firewall can do enough p[rotection to make any random packets
useless.

- Original Message - 
From: "Christopher L. Morrow" <[EMAIL PROTECTED]>
To: "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
Cc: "Henning Brauer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, November 13, 2004 7:09 PM
Subject: Re: IPV6 renumbering painless?


>
> On Sat, 13 Nov 2004, Iljitsch van Beijnum wrote:
> > On 13-nov-04, at 10:02, Henning Brauer wrote:
> >
> > Filtering based on IP addresses is a broken concept.
> >
> > I'm not a huge fan of sprinkling crypto over everything, but if you
> > want certain people to have access to some stuff and not others,
> > IPsec/SSL are the way to go.
>
> there are things putting random packets over the network today, trying to
> exploit services you might be using, or your customers might be using.
> IPSEC everywhere is 'nice' but not horribly practical. SSL is nice, until
> your SSL libraries have remotely exploitable DoS or root
> vulnerabilities... how many times over the last 12 months has openssl been
> upgraded due to 'security' issues?

Re: How to Blocking VoIP ( H.323) ?

[Alexei Roudnev]

I agree with Robert. But if you deal with some super tricked protocols (like
SpyPE) and you really want to block VoIP (not show that you comply to
regulations, but REALLY block it) - disruption looks as the only real
opportunity. For any filterig, I can always create a protocol which will
ignore your filters.


- Original Message - 
From: "Robert Mathews" <[EMAIL PROTECTED]>
To: "NANOG" <[EMAIL PROTECTED]>
Sent: Saturday, November 13, 2004 11:12 AM
Subject: Re: How to Blocking VoIP ( H.323) ?


>
>
>
> On Fri, 12 Nov 2004, Alexei Roudnev wrote:
>
> > Date: Fri, 12 Nov 2004 09:46:15 -0800
> > From: Alexei Roudnev <[EMAIL PROTECTED]>
> > To: Robert Mathews <[EMAIL PROTECTED]>, NANOG <[EMAIL PROTECTED]>
> > Subject: Re: How to Blocking  VoIP ( H.323) ?
> >
> > > Alexei:
> > >
> > > How exactly then would anyone implement this, without screwing-up the
> > > overall performance elements in the network?  :)
> >
> > Not too easy, but I can imagine few alghoritms doing it. Remember that
VoIP
> > uses short packets, and you cam always recognize Ack and Tcp packets
which
> > should not be disrupted. Jitter does not slow down network, except if it
> > interacts with RTT calculartion in TCP/IP.
>
>
> Alexei:
>
> Apologize for the delay in getting a reply to you.
>
> Regarding your comment on jitter, FLATLY or more generally, if introducing
> jitter is likely to complicate operational matters elsewhere in the
> network [whether this complication manifests within one's own network or
> in another - to which one is inter-connected] I would be inclined to say
> this effects the overall performance...
>
> I did not mean to take more of your time on this.  But, I wanted to merely
> clarify.
>
>
> Best,
> Robert.
> ---

Re: How to Blocking VoIP ( H.323) ?

[Alexei Roudnev]

>
> On Fri, 12 Nov 2004, Alexei Roudnev wrote:
>
> > If someone want to be insane -  allow him to do it; what's the problem?
Is
> > this question coming from Panamian government? -:)
>
> when you have to comply with some insane gov't ruling at penalty of
> legal (possibly felony type actions) you will also squeal like the virtual
> pig...
To comply with government, it is enough to SHOW blocking - block SIP and
H323 standar ports. It is not your concern, if SkyPE can make a tricks.

But I believe, that to comply with anything in Panama you need just to give
a $$$, not to set up acll lists.



>
> >
> > This is internet - if I have 10 Mbit connection and 100msec latency, I
can
> > use it for Voice, no way to block me; if it is 19200bits/second and 2
second
> > latency, I can not. That's all. Other methods can provide temporary
reliefe
> > only.
> >
>
> true, this was the arguement put forth to the folks at the time, they
> still insisted on their backwards, telco-minded thinking... Fortunately
> after a few months they saw the light and removed the requirement.
>
> Joe might not be that lucky, or he might be able to show precedent to
> others about why it's bad to try to block the voip.
>
> > - Original Message -
> > From: "Christopher L. Morrow" <[EMAIL PROTECTED]>
> > > On Thu, 11 Nov 2004, Robert Mathews wrote:
> > > > To Joe Shen:
> > > >
> > > > Perhaps 'I am failing to see it' but, what can be gained by blocking
> > VoIP
> > > > traffic other than freeing bandwidth and CPU churnings?
> > >
> > > reference panamanian gov'ts choice to protect legacy/incumbant carrier
> > > business by blocking voip. no one said it was 'smart' just that it was
> > > what the gov't wanted. Perhaps Joe lives in a similar situation?
> >

Re: How to Blocking VoIP ( H.323) ?

[Alexei Roudnev]

>
>
> On Thu, 11 Nov 2004, Alexei Roudnev wrote:
>
> > Date: Thu, 11 Nov 2004 09:38:00 -0800
> > From: Alexei Roudnev <[EMAIL PROTECTED]>
> > To: Christopher L. Morrow <[EMAIL PROTECTED]>,
> >  Irwin Lazar <[EMAIL PROTECTED]>
> > Cc: Joe Shen <[EMAIL PROTECTED]>, NANOG <[EMAIL PROTECTED]>
> > Subject: Re: How to Blocking  VoIP ( H.323) ?
> >
> >
> > Hmm - just introduce some jitter into your network, and add random delay
to
> > the short packets - and no VoIP in your company -:).
>
>
> Alexei:
>
> How exactly then would anyone implement this, without screwing-up the
> overall performance elements in the network?  :)
Not too easy, but I can imagine few alghoritms doing it. Remember that VoIP
uses short packets, and you cam always recognize Ack and Tcp packets which
should not be disrupted. Jitter does not slow down network, except if it
interacts with RTT calculartion in TCP/IP.




>
>
> To Joe Shen:
>
> Perhaps 'I am failing to see it' but, what can be gained by blocking VoIP
> traffic other than freeing bandwidth and CPU churnings?
>
> In the grand scheme of things, and in an evolutionary context certainly,
> many apps are likely to be proposed in the future, and worse still (in the
> eyes of many) - IMPLEMENTED, which will likely compel network owners and
> operators to adjust organizational and infrastructure strategies to meet
> objectives. As with the introduction of any service or app into the mix,
> accommodating something means a REQUISITE adjustment in existing
> operational practices.
>
> But WRT VoIP, Consider that by JUST ONE account, the IP telephony market
> is expected to be a US$1.4 billion business by 2008 - up from $934 million
> in 2002.  This market is expected to experience a annual growth rate of
> 7.5% through 2008.
>
> Again, what is the point.. is it that you wish to block VoIP to in order
> to DELAY/BUY MORE TIME toward implementing organizational change
> (slow-rolling, if you are going to be rolling at all), or is it to
> prohibit without reservation, any VoIP traffic over your netspace?  Just
> curious..
>
>
> Best,
> Robert.
> ---

Re: How to Blocking VoIP ( H.323) ?

[Alexei Roudnev]

If someone want to be insane -  allow him to do it; what's the problem? Is
this question coming from Panamian government? -:)

This is internet - if I have 10 Mbit connection and 100msec latency, I can
use it for Voice, no way to block me; if it is 19200bits/second and 2 second
latency, I can not. That's all. Other methods can provide temporary reliefe
only.

- Original Message - 
From: "Christopher L. Morrow" <[EMAIL PROTECTED]>
To: "Robert Mathews" <[EMAIL PROTECTED]>
Cc: "NANOG" <[EMAIL PROTECTED]>
Sent: Thursday, November 11, 2004 11:49 AM
Subject: Re: How to Blocking VoIP ( H.323) ?


>
>
> On Thu, 11 Nov 2004, Robert Mathews wrote:
> >
> >
> > To Joe Shen:
> >
> > Perhaps 'I am failing to see it' but, what can be gained by blocking
VoIP
> > traffic other than freeing bandwidth and CPU churnings?
>
> reference panamanian gov'ts choice to protect legacy/incumbant carrier
> business by blocking voip. no one said it was 'smart' just that it was
> what the gov't wanted. Perhaps Joe lives in a similar situation?

Re: How to Blocking VoIP ( H.323) ?

[Alexei Roudnev]

Hmm - just introduce some jitter into your network, and add random delay to
the short packets - and no VoIP in your company -:).

Other way - block ALL outbound connections (including DNS and HTTPS) and
require using proxy, or better do not allow external IP addresses.

-:)
(I should not be very optimistic about this).

- Original Message - 
From: "Christopher L. Morrow" <[EMAIL PROTECTED]>
To: "Irwin Lazar" <[EMAIL PROTECTED]>
Cc: "Joe Shen" <[EMAIL PROTECTED]>; "NANOG" <[EMAIL PROTECTED]>
Sent: Thursday, November 11, 2004 9:01 AM
Subject: Re: How to Blocking VoIP ( H.323) ?


>
>
> On Thu, 11 Nov 2004, Irwin Lazar wrote:
>
> >
> > The following resources may be helpful for H.323:
> >
> > IP Ports and Protocols used by H.323 Devices
> > http://www.teamsolutions.co.uk/tsfirewall.html
> >
> > The Problems and Pitfalls of Getting H.323 Safely Through Firewalls
> > http://www.chebucto.ns.ca/~rakerman/articles/ig-h323_firewalls.html
> >
>
> there is probably some traction to be had in reviewing other folks'
> attempts at this very thing as well. Check out Panama, for instance, their
> incumbent carrier (C&W as I recall) forced the federal regulators to ban
> VOIP through all ISP's in Panama, this turned out to be quite unworkable
> even in the short term. I believe a few other folks have attempted similar
> regulations with similar success rates :(
>
> VOIP, like IM runs, or can be run, across several ports/protocols with and
> without consistency in even the individual applications. For many things
> like this, if they are required via legislation in your local area, you
> might have better luck scoping the regulation's expectations, then using
> some metrics to show success/failure and WHY those metrics are the way
> they are.
>
> In the end though: "Good luck!" (Also, reference Ito-Jun's message from
> the IAB about wide scale filtering policies and their effects on the
> end-to-end nature of the Internet as a whole).

Re: How to Blocking VoIP ( H.323) ?

[Alexei Roudnev]

SkyPE was designed to work thru any firewalls (except, of course, if you
block all outbound connections and require using HTTP proxy) -:).

- Original Message - 
From: "Irwin Lazar" <[EMAIL PROTECTED]>
To: "Joe Shen" <[EMAIL PROTECTED]>
Cc: "NANOG" <[EMAIL PROTECTED]>
Sent: Thursday, November 11, 2004 8:16 AM
Subject: Re: How to Blocking VoIP ( H.323) ?


>
> The following resources may be helpful for H.323:
>
> IP Ports and Protocols used by H.323 Devices
> http://www.teamsolutions.co.uk/tsfirewall.html
>
> The Problems and Pitfalls of Getting H.323 Safely Through Firewalls
> http://www.chebucto.ns.ca/~rakerman/articles/ig-h323_firewalls.html
>
> SIP uses TCP port 5060 for signaling, however voice data traffic is
carried
> on random high ports.  Some SIP-based VoIP providers route voice data
> traffic back to a proxy server (I believe Vonage functions in this way),
so
> it may be easier to restrict.
>
> Skype requires outbound TCP access to either ports above 1024, or port 80,
> and they also recommend outbound UDP access to ports above 1024 (as well
as
> in-bound replies), so good luck blocking it. :-(
>
> And then there is VoIP as part of IM services (e.g. Apple iChatAV, AOL IM,
> or Yahoo Messenger), all of which function differently.
>
> irwin
>
> >
> >>
> >> Hi,
> >>
> >> How could it be done to block VoIP at access router?
> >>
> >> I've thought about using ACL to block UDP port
> >> 1719,but this could be overcome by modifying protocol
> >> port number.
> >>
> >> regards
> >>
> >> Joe
> >>
> >> __
> >> Do You Yahoo!?
> >> Log on to Messenger with your mobile phone!
> >> http://sg.messenger.yahoo.com
> >>
> >
> > -- 
>
> --
> > Joel Jaeggli  Unix Consulting
[EMAIL PROTECTED]
> > GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F
56B2
> >
>

Re: Network Monitoring System - Recommendations?

[Alexei Roudnev]

Here:

http://sourceforge.net/projects/snmpstat

and docs are here

http://snmpstat.sourceforge.net/CCR-config.htm


- Original Message - 
From: "Joe Shen" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>; "Jon Lyons" <[EMAIL PROTECTED]>;
"Andy Dills" <[EMAIL PROTECTED]>; "Charlie Khanna - NextWeb"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, November 01, 2004 5:53 PM
Subject: Re: Network Monitoring System - Recommendations?


>
> Hi,
>
> I googled with "CCR" but it seems nothing useful in 5
> pages. Would you please do me a favor to give the URL
> of that tool ?
>
>
> I tried to set up MRTG monitoring Unishpere BRAS 1400
> and M160, but I failed with data collection because
> wrong OID used ( CPU, mem, tempreture, BW etc ) :-(
>
> regards
>
>
>
>  --- Alexei Roudnev <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > I read document of these tools and find they work
> > with
> > > Cisco products. But, how about Juniper M160 or
> > M320,
> > > Unishpere's BRAS products?  Where can I find
> > Juniper's
> > > OID on its tempreture, chassis, CPU, bandwidth ?
> > Does
> > They use standart MIB2 and a little of Cisco
> > specific MIB's. As I already
> > said, it is a good tool to view and monitor traffic,
> > utilisation, errors,
> > and use additional tiool to deep monitor vendor
> > specific parameters. We use
> > 'snmpstat' to monitor routers, switches, ports and
> > interfaces (and bgp) and
> > cricket to watch few additional parameters (to
> > configure alerts, we use
> > aliases and mhonarc mail archives with auto
> > expiration - for alerts,
> > warnings, reports and audits, and for 'root' and
> > 'oracle' e-mail.
> >
> > > anyone have a  running configuration for M160 or
> > > Unishpere's BRAS products?
> > CCR can work with anything which (1) allow telnet or
> > ssh, and (2) can 'write
> > net' config (in any syntax).
> > You can use encrypted password file (using
> > passphrase) if you want. Using
> > SNMP was rejected, because it is absolutely
> > device-specific, impossible in
> > many cases, and we never saw it as a security
> > problem, because all devices
> > are restricted to allow ssh or telnet from 2 or 3
> > servers only, because
> > passwords are encrypted, and because automated
> > config reading and web access
> > aree much more important vs very abstract
> > possibility of hacking (in
> > reality, problem can come from insiders, not from
> > hackers, so no extra
> > accounst are allowed on monitoring server).
> >
> > You can get configuratuion (initialize tftp
> > transfer) using some snmp
> > (WRITE) variable and pre-configured tftp parameters,
> > but it works on a very
> > few Cisco devices only.
> >
> > As I said, CCR uses 3 methods:
> > - password file encrypted by public key
> > - password file encrypted by 3des passphrase;
> > - explicit password.
> >
> > In all cases, problem is with root user only - root
> > can alway decrypt
> > password or interseipt web session. User, who have
> > permission to edit CCR
> > config and know passphrase, can (in theory) see
> > passwords as well. Other
> > users can not, even if they know passphrase - they
> > can only initiate config
> > reading.
> >
> > Network admins do not know enable passwords, if they
> > do not need it - they
> > use passphrase
> >
> > To have automated config reading, any of first 2
> > methods can be used
> > (passphrase must be written into special file, if
> > method 2 is used,
> > root-only readable). For manual reading, any methgod
> > can be used, without
> > any file with passphrase.
> >
> > In reality, it is not serious security problem
> > because all devices can be
> > accessed from a very few servers only, and because
> > we can use 'ssh' instead
> > of 'telnet' (CCR can be configured or select
> > ssh/telnet automatically). You
> > can, in turn, play with security level , but it
> > (again) does not work on
> > generic case (any cisco device) and is very tricky.
> >
> > For Juniper or other device - you can try to program
> > 'expect' script, or use
> > 'snmp' initiated transfer - all other things will
> > work.
> >
> >
> >
&

Re: Network Monitoring System - Recommendations?

[Alexei Roudnev]

ï


Nagios is one of the best systems (and widely 
used).
 
CCR is part of snmpstat (but separate installation tar), see 
http://snmpstat.sf.net
 
 

  - Original Message - 
  From: 
  J 
  Sparacio 
  To: Joe Shen 
  Cc: Alexei Roudnev ; Jon Lyons ; Andy Dills ; Charlie Khanna - NextWeb ; [EMAIL PROTECTED] 
  Sent: Monday, November 01, 2004 9:54 
  PM
  Subject: Re: Network Monitoring System - 
  Recommendations?
  There's a cool one that's open source called Nagios. www.nagios.org.  We (local ISP) just 
  started using it network wide, and it rocks.On Mon, 2004-11-01 at 
  20:53, Joe Shen wrote: 
  Hi,

I googled with "CCR" but it seems nothing useful in 5
pages. Would you please do me a favor to give the URL
of that tool ? 


I tried to set up MRTG monitoring Unishpere BRAS 1400
and M160, but I failed with data collection because
wrong OID used ( CPU, mem, tempreture, BW etc ) :-(

regards



 --- Alexei Roudnev <[EMAIL PROTECTED]> wrote:   
> 
> 
> 
> > I read document of these tools and find they work
> with
> > Cisco products. But, how about Juniper M160 or
> M320,
> > Unishpere's BRAS products?  Where can I find
> Juniper's
> > OID on its tempreture, chassis, CPU, bandwidth ?
> Does
> They use standart MIB2 and a little of Cisco
> specific MIB's. As I already
> said, it is a good tool to view and monitor traffic,
> utilisation, errors,
> and use additional tiool to deep monitor vendor
> specific parameters. We use
> 'snmpstat' to monitor routers, switches, ports and
> interfaces (and bgp) and
> cricket to watch few additional parameters (to
> configure alerts, we use
> aliases and mhonarc mail archives with auto
> expiration - for alerts,
> warnings, reports and audits, and for 'root' and
> 'oracle' e-mail.
> 
> > anyone have a  running configuration for M160 or
> > Unishpere's BRAS products?
> CCR can work with anything which (1) allow telnet or
> ssh, and (2) can 'write
> net' config (in any syntax).
> You can use encrypted password file (using
> passphrase) if you want. Using
> SNMP was rejected, because it is absolutely
> device-specific, impossible in
> many cases, and we never saw it as a security
> problem, because all devices
> are restricted to allow ssh or telnet from 2 or 3
> servers only, because
> passwords are encrypted, and because automated
> config reading and web access
> aree much more important vs very abstract
> possibility of hacking (in
> reality, problem can come from insiders, not from
> hackers, so no extra
> accounst are allowed on monitoring server).
> 
> You can get configuratuion (initialize tftp
> transfer) using some snmp
> (WRITE) variable and pre-configured tftp parameters,
> but it works on a very
> few Cisco devices only.
> 
> As I said, CCR uses 3 methods:
> - password file encrypted by public key
> - password file encrypted by 3des passphrase;
> - explicit password.
> 
> In all cases, problem is with root user only - root
> can alway decrypt
> password or interseipt web session. User, who have
> permission to edit CCR
> config and know passphrase, can (in theory) see
> passwords as well. Other
> users can not, even if they know passphrase - they
> can only initiate config
> reading.
> 
> Network admins do not know enable passwords, if they
> do not need it - they
> use passphrase
> 
> To have automated config reading, any of first 2
> methods can be used
> (passphrase must be written into special file, if
> method 2 is used,
> root-only readable). For manual reading, any methgod
> can be used, without
> any file with passphrase.
> 
> In reality, it is not serious security problem
> because all devices can be
> accessed from a very few servers only, and because
> we can use 'ssh' instead
> of 'telnet' (CCR can be configured or select
> ssh/telnet automatically). You
> can, in turn, play with security level , but it
> (again) does not work on
> generic case (any cisco device) and is very tricky.
> 
> For Juniper or other device - you can try to program
> 'expect' script, or use
> 'snmp' initiated transfer - all other things will
> work.
> 
> 
> 
> >
> > On configuration bankup, rancid use telnet (ssh).
> But,
> > I take this a not-secure methode as it has to code
> > password in login script. Is there any tool to get
> > configuration file from read-only SNMP cumminity?
> >
> >
> > Joe
> >
> >
> >
> > --- Jon Lyons <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Checkout http://perfparse.sourceforge.net/ lets
> you
> &g

Re: Network Monitoring System - Recommendations?

[Alexei Roudnev]

> I read document of these tools and find they work with
> Cisco products. But, how about Juniper M160 or M320,
> Unishpere's BRAS products?  Where can I find Juniper's
> OID on its tempreture, chassis, CPU, bandwidth ? Does
They use standart MIB2 and a little of Cisco specific MIB's. As I already
said, it is a good tool to view and monitor traffic, utilisation, errors,
and use additional tiool to deep monitor vendor specific parameters. We use
'snmpstat' to monitor routers, switches, ports and interfaces (and bgp) and
cricket to watch few additional parameters (to configure alerts, we use
aliases and mhonarc mail archives with auto expiration - for alerts,
warnings, reports and audits, and for 'root' and 'oracle' e-mail.

> anyone have a  running configuration for M160 or
> Unishpere's BRAS products?
CCR can work with anything which (1) allow telnet or ssh, and (2) can 'write
net' config (in any syntax).
You can use encrypted password file (using passphrase) if you want. Using
SNMP was rejected, because it is absolutely device-specific, impossible in
many cases, and we never saw it as a security problem, because all devices
are restricted to allow ssh or telnet from 2 or 3 servers only, because
passwords are encrypted, and because automated config reading and web access
aree much more important vs very abstract possibility of hacking (in
reality, problem can come from insiders, not from hackers, so no extra
accounst are allowed on monitoring server).

You can get configuratuion (initialize tftp transfer) using some snmp
(WRITE) variable and pre-configured tftp parameters, but it works on a very
few Cisco devices only.

As I said, CCR uses 3 methods:
- password file encrypted by public key
- password file encrypted by 3des passphrase;
- explicit password.

In all cases, problem is with root user only - root can alway decrypt
password or interseipt web session. User, who have permission to edit CCR
config and know passphrase, can (in theory) see passwords as well. Other
users can not, even if they know passphrase - they can only initiate config
reading.

Network admins do not know enable passwords, if they do not need it - they
use passphrase

To have automated config reading, any of first 2 methods can be used
(passphrase must be written into special file, if method 2 is used,
root-only readable). For manual reading, any methgod can be used, without
any file with passphrase.

In reality, it is not serious security problem because all devices can be
accessed from a very few servers only, and because we can use 'ssh' instead
of 'telnet' (CCR can be configured or select ssh/telnet automatically). You
can, in turn, play with security level , but it (again) does not work on
generic case (any cisco device) and is very tricky.

For Juniper or other device - you can try to program 'expect' script, or use
'snmp' initiated transfer - all other things will work.



>
> On configuration bankup, rancid use telnet (ssh). But,
> I take this a not-secure methode as it has to code
> password in login script. Is there any tool to get
> configuration file from read-only SNMP cumminity?
>
>
> Joe
>
>
>
> --- Jon Lyons <[EMAIL PROTECTED]> wrote:
> >
> >
> > Checkout http://perfparse.sourceforge.net/ lets you
> > graph the data from the nagios plugins...
> >
> > --- Alexei Roudnev <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > I generated config for 'snmpstatd' automatically,
> > > from user;'s database (it
> > > was simple; all I need was Router, Interface,
> > > User-name, number for this
> > > user, priority).
> > >
> > > For automated config backups, I use CCR (fully web
> > > based Cisco
> > > configuration -> CVS system).
> > >
> > >
> > > - Original Message - 
> > > From: "Andy Dills" <[EMAIL PROTECTED]>
> > > To: "Charlie Khanna - NextWeb"
> > <[EMAIL PROTECTED]>
> > > Cc: <[EMAIL PROTECTED]>
> > > Sent: Thursday, October 28, 2004 11:46 AM
> > > Subject: Re: Network Monitoring System -
> > > Recommendations?
> > >
> > >
> > > >
> > > > On Thu, 28 Oct 2004, Charlie Khanna - NextWeb
> > > wrote:
> > > >
> > > > > Hi - I was interested in finding out what
> > > software applications other
> > > ISPs
> > > > > are using for network monitoring?  For
> > example:
> > > > >
> > > > >
> > > > >
> > > > > 1)   Overall network health - uptime
> > reports
> > > >
> > > > http://ww

Re: Network Monitoring System - Recommendations?

[Alexei Roudnev]

>
>
> >Nothing all in one place, that I'm aware of. But with a little work, you
snmpstat have hardcoded set of monitored parameters, but creates all graphs
anb links automartically, including customer-only view of customer's links,
link to the database record about this link, and link to the router's config
@ CCR.

This is why we use combination - for 99% of partameters, snmpstat, and for
the rest, hand-configured cricket (but I recommend nagios).



> >could probably integrate it all into nagios. After all, you can make the
> >host names or descriptions URLs that link to bandwidth and error graphs
or
> >other tools.
>
> I'll second this part. Whether you use cricket or MRTG, or even Nagios
> itself, you can use a little "notes_url" command to create a link from,
> say, the "ping" service of your core router to the MRTG charts of
bandwidth
> usage.
>
> Rob Nelson
>
> Rob Nelson
> [EMAIL PROTECTED]
>