Re: i think the cogent depeering thing is a myth of some kind

[Daniel Golding]

I don't know that NLayer was depeered yesteray for a fact, although  
someone I trust did report that to me. I do know for a fact that  
Limelight was. No offense to the good folk at nLayer, but most of the  
people who I work for care a good bit more about Limelight


Didn't know about VW Fiber. Sorry, Randy - didn't mean to leave you  
guys out :)


- Dan

On Sep 28, 2007, at 7:24 PM, Randy Epstein wrote:




I think Dan overstepped here.  Richard has made comments of a de- 
peering

notice received by nLayer, not an actual de-peering occurrence.

AFAIK, the only two networks in recent weeks that have been de- 
peered are WV

Fiber and LimeLight.  WV was de-peered a couple on September 17th and
LimeLight was de-peered yesterday.

Randy

Re: i think the cogent depeering thing is a myth of some kind

[Daniel Golding]

Paul,

This is the scenario. Peer B is send lots of outbound to Peer A.

Peer A depeers Peer (well former Peer) B. Why? Well, Peer A is having  
ratio problems with other Peers C-F. Keep reading...


After depeering, some of (now former) Peer B's outbound traffic to  
Peer A will now flow over links from Peer B to Peers C-F, before  
finally terminating at Peer A. Peer A sees their ratios with Peers C- 
F improve.


This is a proven maneuver and Cogent is not the first to do it. Of  
course, it gets more complex with multihoming and the assumptions of  
a meshy enough connectivity to ensure this will happen.


This is better explained with a whiteboard. That full explanation was  
missing from the writeup that is posted (and I'll allow it to stay up  
for now), because that report was aimed at folks who may not be fully  
conversant in peering - financial professionals. BTW, thanks for  
dropping me an email to ask me about it, before posted to NANOG.


As far as reachability from one provider to another - I've heard that  
one can make routing changes quickly and easily on this crazy  
Internet thing. Perhaps in the 24 hours since I wrote that, a few  
changes occurred?


 Dan

On Sep 28, 2007, at 6:00 PM, Paul Vixie wrote:



at  there is a plain text  
document with

the following HTTP headers:

Date: Fri, 28 Sep 2007 21:56:34 GMT
Server: Apache/2.2.3 (Unix) PHP/5.2.3
Last-Modified: Fri, 28 Sep 2007 19:15:53 GMT
ETag: "92c1e1-a85-43b36ea5bcc40"
Content-Length: 2693
Content-Type: text/plain

the plain text title is:

Cogent shows hypocrisy with de-peering policy

the plain text authorship is ascribed to:

Dan Golding

the first plain text assertion that caught my eye was:

	Cogent, has, in fact, de-peered other Internet networks in the  
last 24

hours, including content-delivery network Limelight Networks and
wholesale transit provider nLayer Communications, along with several
European networks.

since i appear to be reaching the aforementioned web server by a  
path that
includes cogent-to-nlayer, i think this part of the plain text is  
inaccurate.


traceroute to www.e-gerbil.net (69.31.1.2), 64 hops max, 52 byte  
packets

 1  rc-main.f1.sql1.isc.org (204.152.187.254)  0.336 ms
 2  149.20.48.65 (149.20.48.65)  0.509 ms
 3  gig-0-1-0-606.r2.sfo2.isc.org (149.20.65.3)  1.163 ms
 4  g0-8.core02.sfo01.atlas.cogentco.com (154.54.11.177)  2.757 ms
 5  t4-2.mpd01.sfo01.atlas.cogentco.com (154.54.2.89)  2.958 ms
 6  g3-0-0.core02.sfo01.atlas.cogentco.com (154.54.3.117)  2.525 ms
 7  p6-0.core01.sjc04.atlas.cogentco.com (66.28.4.234)  4.183 ms
 8  g3-3.ar1.pao1.us.nlayer.net (69.22.153.21)  2.637 ms
 9  ge-2-1-1.cr1.sfo1.us.nlayer.net (69.22.143.161)  3.806 ms
10  so-0-2-0.cr1.ord1.us.nlayer.net (69.22.142.77)  69.022 ms
11  60.po1.ar1.ord1.us.nlayer.net (69.31.111.130)  69.491 ms
12  0.tge4-4.ar1.iad1.us.nlayer.net (69.22.142.113)  81.580 ms
...

the second plain text assertion which caught my eye was:

Why is this happening? There are a few possibilities. First, Cogent
may simply want revenue from the networks it has de-peered, in the
form of Internet transit. Of course, few de-peered networks are
willing to fork over cash to those that have rejected them. Another
possibility is that Cogent is seeing threats from other peers
regarding its heavy outbound ratios, and it seeks to disconnect
Limelight and other content-heavy peers to help balance those ratios
out.

this makes no sense, since dan golding would know that cogent's  
other peers
would not be seeing traffic via cogent from the allegedly de-peered  
peers.


so, i think the document is a hoax of some kind.  (i saw it  
mentioned here.)

Re: Best way to supply colo customer with specific provider

[Daniel Golding]

On Jan 31, 2007, at 5:10 AM, matthew zeier wrote:



Steve Gibbard wrote:

If you actually want to do this, you've got four choices:
- Policy route, as mentioned below.
- Get the customer their own connection to Cogent.
- Have a border router that only talks to Cogent and doesn't  
receive full

  routes from your core, and connect the customer directly to that.
- Do something involving route servers and switches outside your  
border

  routers, a-la-Equinix Direct.


What about an MPLS VPN?


There are a variety of layer 2 solutions for this problem. One simple  
solution: Get Cogent to provide you two "sessions" via link layer  
identifiers - FR encaps  with separate DLCI on POS or two separate  
VLANs on Ethernet. Then use the L2 solution of your choice - GRE  
tunnel, Martini, whatever.


I also sort of like "get the customer their own connection to Cogent".

- Dan

Re: Google wants to be your Internet

[Daniel Golding]

One interesting point - they plan to use Broadband over Power Line  
(BPL) technology to do this. Meter monitoring is the killer app for  
BPL, which can then also be used for home broadband, Meter reading is  
one of the top costs and trickiest problems for utilities.


- Dan

On Jan 22, 2007, at 12:28 PM, Niels Bakker wrote:



* [EMAIL PROTECTED] (Jim Shankland) [Mon 22 Jan 2007, 18:21 CET]:

"Travis H." <[EMAIL PROTECTED]> writes:
IIRC, someone representing the electrical companies approached  
someone representing network providers, possibly the IETF, to ask  
about the feasibility of using IP to monitor the electrical  
meters throughout the US

The response was "yeah, well, maybe with IPv6".


Which is nonsense.  More gently, it's only true if you not only  
want to use IP to monitor electrical meters, but want the use the  
(global) Internet to monitor electrical meters.


I'd love to hear the business case for why my home electrical  
meter needs to be directly IP-addressable from an Internet cafe in  
Lagos.


It's not nonsense.  Those elements need to be unique.  RFC1918  
isn't unique enough (think what happens during a corporate merger).



-- Niels.

Re: Internet Video: The Next Wave of Massive Disruption to the US Peering Ecosystem (v1.2)

[Daniel Golding]

On Jan 10, 2007, at 12:33 PM, William B. Norton wrote:



Why are folks turning away 10G orders?



Some of this depends on how much you are willing to pay. The issue is  
as much 10G orders at today's transit prices as it is the capacity.  
We're used to paying less per unit for greater capacity, but when  
we're asking networks to sell capacity in chunks as large as the ones  
they use to build their backbones, that may simply not work.


One other issue is that willingness to sell 10G is one vital  
competitive distinguisher in an otherwise largely commodity transit  
market. There have been rumors that older legacy carriers wish to  
punish more agile competitors for daring to "steal" 10G customers  
away from them, in spite of the fact that those older carriers have  
lots of trouble delivering 10G.


- Dan

Re: Collocation Access

[Daniel Golding]

On Dec 28, 2006, at 11:14 AM, Leo Vegoda wrote:

On Dec 28, 2006, at 4:49 PM, Joe Abley wrote:

[...]


Which makes it hard for me to understand why they bother, and why  
they go to such great lengths to enforce arbitrary rules about  
what is acceptable and what isn't.


Indeed. I'm surprised the market hasn't produced facilities with  
better thought through and executed security and access controls.  
Is there not enough competition in each metro area for anything  
other than lowest common denominator?


Leo


Time for a colocation reality check. Why would facilities need to  
have tight security? Lets count off the reasons...


- Federally mandated - For some government and gov contractor work,  
there are high security requirements. There are a few data centers,  
run by defense contractors, that cater to this sector. It is highly  
specialized.


- Customer demand for higher security - In light of the lack of  
security issues that we've encountered so far, most customers are  
unwilling to pay anything more for higher security.


- Need for colocation facilities to differentiate themselves - Right  
now, having available power and cooling is differentiation enough.  
For those who haven't noticed, its a very "tight" colocation market -  
demand growth exceeds supply growth overall,  and in several areas  
(London, Chicago) there is effectively no available high quality  
carrier neutral colocation. Given this, why beef up security, which  
will eat into colocation provider margins?


What constitutes tougher security anyway?

- Armed guards?
- Outside facility video surveillance? (as well as inside), more  
careful reception of incoming hardware (explosive swabs, anyone?),
- Mandated biometric authentication? (yes, we have hand geometry  
readers, but their use isn't mandated for all),


The current fetish for ID checking is "security as theatre" rather  
than true security. However, some aspects of the colocation  
experience ARE, in fact, perceptual. Neon, cool mantraps, snap glass,  
anyone?


Until supply catches up to demand, only price and power will matter  
to most folks, along with an acceptable level of facility redundancy  
(Tier III for most).


- Daniel Golding

RE: Kremen's Buddy?

[Daniel Golding]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Adi Linden
> 
> Here is a very good point of why ip space should not be a property traded
> on an open market. To me ip space is like a house number or a telephone
> number. A resource required and useable for a presence on the global
> internet only. The current process of allocating ip space based on need
> makes perfect sense. In order to assess the need, certain aspects of a
> network have to be disclosed to ARIN, that makes perfect sense as well.
> 
> I'd hate to see an open market place for ip space. The ability to afford
> ip space based on wealth rather then technical merit makes little sense
> to me.
> 

"From each according to his abilities, to each according to his needs" could
be replaced with "From each according to the ARIN fee schedule, to each
according to our impossible to decipher allocation templates". Marx would be
proud! Centrally managed economic systems seem so wonderful on paper -
that's why so many otherwise very smart people have championed the idea.
Real world experience, on the other hand, has shown that capitalism is the
worst possible method for distributing resources - except for all the other
methods, which are even worse. 

Address trading prevents hording, which we have now. And its not just a
little hording, either - Look at Geoff Huston's reports too see how much of
the total IPv4 space is wasted. We economically incent people to waste space
and not turn it back in. If that IP space was fungible, people would sell
it, and more addresses would be available. The sorts of controls we have in
place today tend to raise, rather than lower prices - again, history has
shown this - they encourage scarcity and hoarding. 

And, if people have noticed, the Internet is what we use to make money,
these days - at least, the folks on this list.

My opinion is that ARIN should use some of its not inconsiderable warchest
and hire some economists to do some real work on modalities for address
distribution (i.e. give some grants). Aside from the practical utility, some
real science around this topic would be of great intellectual benefit.

- Daniel Golding

RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Daniel Golding]

Nick,

You make an incorrect assumption - that IP addresses are currently free
(they are not, in either money or time) and that commoditizing them will
increase their cost (there is significant evidence it will not). 

If I have the choice between paying $500 for a /24 of PI space or going to
my upstreams, getting IP space, applying to ARIN for a /22 of PI space,
eventually numbering out of the PA space - how much money have I spent?

- Daniel Golding

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Michael Nicks
> Sent: Friday, September 08, 2006 2:19 PM
> To: [EMAIL PROTECTED]
> Cc: nanog@merit.edu
> Subject: Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have
> feedback?]
> 
> 
> The real fundamental flaw with this free-market approach to handling IP
> assignments is the fact that it will further create an environment where
> smaller (start-ups, small businesses) entities trying to acquire PI
> space will face insurmountable challenges (eg, financial).
> 
> While I think the majority of people these days would agree that the
> free-market approach to economics is definitely the best, certain
> resources are not very applicable to be traded in a free-market
> environment. I myself do not like over-bureaucratic processes, and while
> all of us at one time or another have complained about ARIN's
> procedures, policies, and practices, the purpose they serve is a needed
> one.
> 
> Best Regards,
> -Michael
> 
> --
> Michael Nicks
> Network Engineer
> KanREN
> e: [EMAIL PROTECTED]
> o: +1-785-856-9800 x221
> m: +1-913-378-6516
> 
> 
> 
> [EMAIL PROTECTED] wrote:
> >
> > 3) What's wrong with treating assignments like property and setting up a
> > market to buy and sell them? There's plenty of precedent for this:
> >
> >  Mineral rights, mining claims, Oil and gas leases, radio spectrum.
> >
> >  If a given commodity is truly scarce, nothing works as good as the free
> > market in encouraging consumers to conserve and make the best use of it.
> >
> >
> > I think you're dead-on there, but you forget who you're really trying to
> > convince.  It'll happen eventually but in the meantime the greybeards
> > who were largely responsible for the Internet as we know it (and who by
> > and large still wield significant influence if not still stewardship)
> > will be dragged there kicking and screaming from their
> > academic/pseudo-Marxist ideals, some of whom seem to still resent the
> > commercialization of the Internet.  It's also hard to see the faults in
> > the system when you are insulated by your position as member of the
> > politburo.
> >
> > The flip side of the coin of course is that if you let the free market
> > reign on IP's, you may price developing countries right off the Internet
> > which I don't think anyone sees as a desirable outcome.  There's sure to
> > be a happy middle ground that people smarter than I will figure out, and
> > maybe it takes a silly lawsuit such as this to kick things off.
> >
> > Andrew Cruse

RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]

[Daniel Golding]

Joe makes a good point. Everyone is
shouting “no one owns IP addresses”, but that is proof by
assertion. Yelling louder doesn’t make it so. Neither does ARIN’s assertions
or their policies. What would establish IP addresses as some sort of ARIN-owned
and licensed community property? Well, winning a court case like this, or congress
passing a law. Frankly, those who want ARIN’s ownership of IP addresses
to be established, should hope Kremens put on a good case here, to establish a
nice solid precedent. 

 

Who cares about when CIDR came out? It was
background information and not really material to the case. 

 

Kremens was the victim of a very nasty
fraud. People are acting like he’s a bad guy, when, in fact, he was a
victim of one of the worst cases of domain hijacking, and his original case is
one that we rely on for protection today. 

 

There is a strong argument to be made for
ownership of IP addressing and subsequently trading address space as a
commodity, with ARIN as a commodity exchange and clearinghouse. 

 

Is this reaction people hating lawyers
more than ARIN, or what?

 

- Daniel Golding

 











From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe mcguckin
Sent: Friday, September 08, 2006
1:37 PM
To: nanog@merit.edu
Subject: Re: [Fwd: Kremen VS Arin
Antitrust Lawsuit - Anyone have feedback?]



 



I read the complaint. I don't like the fact that a lot of my friends
are named in the suit, but I think there are some





points worth discussing within the community:





 



1) IP address blocks are not 'property'



 





"Domains are not
property. The assignee of a domain has no ownership interest"





 





Network Solutions
made this same argument years ago. That was their shield against lawsuits when
negligence





(or worse) on NetSols
part would cause a domain to be erroneously transferred. When mistakes were
made,





Network Solutions was
notoriously unwilling to reverse the transaction to correct the error.





 





Then they got sued
for refusing to reverse a fradulent domain transfer, and they lost. The case
had the side effect of setting 





the precedent that
domains *are* in fact tangible property. Now when a registrar or registry makes
a mistake, they can be 





legally held
responsible. (What case was that? Kremen v. Network Solutions)





 





I would say that's an
improvement.





 





2) Why does ARIN
believe that it can ignore a court order?





 





3) What's wrong with
treating assignments like property and setting up a market to buy and sell
them? There's plenty of precedent for this:





Mineral rights,
mining claims, Oil and gas leases, radio spectrum. 





 





If a given commodity
is truly scarce, nothing works as good as the free market in encouraging
consumers to conserve and make the best 





use of it.





 





 





Joe McGuckin





ViaNet Communications





 





[EMAIL PROTECTED]





650-207-0372 cell





650-213-1302 office





650-969-2124 fax





 





 











 

RE: Sitefinder II, the sequel...

[Daniel Golding]

That's absolutely ridiculous. Enterprise IT organizations make decisions on
behalf of their userbase all day. Frankly, I'd be shocked if many tried this
out - most enterprises run their own DNS servers as part of an Active
Directory scheme. In any case, those workstations belong to the enterprise
and they can point them to whatever DNS servers they want. 

For most end-users, their Internet access provider already selects their DNS
caching server. ISPs are within their rights to do this - I'm surprised most
broadband ISPs haven't done exactly what OpenDNS is doing to generate
revenue.

I'm sure if you look really hard, you can find something else to be outraged
about. OpenDNS isn't it. I'm at a loss to explain why people are trying so
hard to condemn something like this. 

- Daniel Golding

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Stephane Bortzmeyer
> Sent: Tuesday, July 11, 2006 3:09 AM
> To: Steve Sobol
> Cc: Joseph Jackson; [EMAIL PROTECTED]
> Subject: Re: Sitefinder II, the sequel...
> 
> 
> On Mon, Jul 10, 2006 at 11:19:51PM -0700,
>  Steve Sobol <[EMAIL PROTECTED]> wrote
>  a message of 16 lines which said:
> 
> > There's a big difference, of course, between INTENTIONALLY pointing
> > your computers at DNS servers that do this kind of thing, and having
> > it done for you without your knowledge and/or consent.
> 
> As Steven Bellovin pointed out, most OpenDNS users will not choose it:
> it will be choosen for them by their corporate IT department or by
> their Internet access provider.

RE: Tier 2 - Lease?

[Daniel Golding]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> 
> What make a provider a tier 2, versus a tier 1 provider...
> 

This has been answered by Richard, but to put my two cents in - you
shouldn't care. There is very little correlation between performance,
support quality, or footprint and "tier status". That's one reason folks
like Vijay Gill have been trying to get people to use more precise terms
like "Settlement Free Interconnection" (e.g. "Verizon Business is completely
SFI") rather than "Tier 1". Also, many companies (or their sales staffs)
aren't truthful about their status, or make misrepresentations about what
their status means. 

The list of extremely large and important non-Tier 1 carriers is long - look
at DTAG, for instance, or Singtel. 

> Is it possible to determine who a tier 2 (i.e. Cogent) leases fiber from?
> 
> Rob

Cogent, for example, is a Tier 2, but that's not a good reason to either buy
or not buy transit from them. There ARE good reasons (both ways) but that's
not one of them.

Daniel Golding

Network Neutrality Panel at NANOG

[Daniel Golding]

Are you anti-network neutrality? Do you think that Ed Whitacre has the right
idea for the future of the net? Do you think that the only way to pay for
next generation broadband services is for content providers to pay up?

I'm looking for a panelist for the next NANOG to speak from a
pro-Bell/anti-neutrality POV. Of course, an employee of Verizon or AT&T, or
a smaller iLEC (or an MSO) would be wonderful, but not required. There will
be three other panelists with a variety of opinions.

Please email me if you are interested.

Thanks,
Daniel Golding

RE: Google AdSense Crash

[Daniel Golding]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> william(at)elan.net> 
> On Sat, 22 Apr 2006, John Palmer (NANOG Acct) wrote:
> 
> >
> > Google Adsense has been down for several hours now. This is the
> interface that partners use to manage
> > their advertising settings.
> 
> And this is reported on nanog because...?
> 

Because this is the Internet's most profitable advertising service and ISP's
will get complaints if their customers (esp. business customers) can't reach
it, even on the weekend. Outage reports are operational, unlike many
threads. More, please.

Daniel Golding

RE: data center space

[Daniel Golding]

Marty Said...
> At 08:11 PM 4/19/2006, Alex Rubenstein wrote:
> 
> 
> >>On many of the public colo houses earnings calls, they told
> >>analysts that they are trying to keep contracts to one year
> >>so they can raise prices year over year, that power pricing is
> >>fluid and many facilities are being expanded both space and
> >>environmental, that most locations really are full or being held
> >>down by lack of cooling for existing dense rack space. Basically
> >>get ready to hold out your wallet.

Well, Peter Van Camp of Equinix was asked this during the (extremely
informative) Equinix call for Q1 and said that many contracts being signed
are still 2-year. The analyst who asked it made the (correct) assertion that
shorter contracts are more advantageous now (for IDC providers), considering
the tight data center market. And the market is really tight, especially in
particular areas. I expect to see many more NANOG postings "where can I find
good colocation in area X" over the next year.

Of course, the colocation companies must raise their prices - for one thing,
many folks got sweetheart deals during the lean years. For another, energy
prices are way up, as we've all noticed, and IDCs use lots of juice.
Finally, its supply and demand. 

> >
> >Is it that?
> >
> >Or, is it some of these companies no realising that charging $250
> >for a 20 amp outlet is less than their cost, even three years ago?
> 
> 
> I don't know, but I was selling only measured power in 2001 and people
> liked
> it. Granted, power was cheaper, but pay as you go was a good model. You
> still
> had to cool to breaker density, but it was nice to have no power risk and
> I
> would recommend that anyone who can, should convert to measured power
> billing.

If energy prices keep going up, one would think that submetered power would
be the wave of the future, so that colos can pass through electricity prices
- both direct electrical power consumed by the equipment, and the HVAC
needed to dissipate the heat. The move to super-dense server platforms is a
real killer. Anyone know of many colos currently submetering individual
tenants?

> 
> Remember when folks thought Exodus was crazy for 220w per square foot?

Well, in hindsight that aspect of their plan was visionary. I don't suppose
if anyone knows if the Exodus designed were seeking to future-proof in
general, anticipated these dense server platforms, or just wanted to build
more bigger?

- Dan

BTW, for the folks who like this stuff, there will hopefully be some great
datacenter-related talks at NANOG this time, thanks to Josh Snowhorn. Its
not too late to make a submission... :)

Re: Abovenet vs UUnet

[Daniel Golding]

On 3/28/06 8:58 AM, "Patrick W. Gilmore" <[EMAIL PROTECTED]> wrote:


> 
> Why would someone believe what the networks tell them over what other
> _users'_ experiences are?  You say it is a good basis for comparison,
> but I have trouble believing that - unless you mean: "A good basis to
> see which network's marketing department is better."
> 
> If I were doing things like leased lines or dark fiber - something
> more objective and not quite such a moving target - an RFP might make
> sense.  For things like transit, you need real people who know how
> networks really react to real problems, how networks really pass real
> packets, how clueful real network NOC techs are, etc., etc.  None of
> these are covered in RFPs (despite what the networks might tell you).
> 
> So thanx for the suggestion, but I think I'll stick with _customer_
> feedback rather than what the networks want to tell me themselves.
> 
> Also, many networks will not respond to an RFP for the levels of
> traffic people here are considering.

Those who don't believe that an RFP can work for them don't know how to
write an appropriate RFP.

Clue level is important, but frankly, less important than it used to be, now
that the business of building large IP networks is a more or less known
quantity. 

How to assess support? There are plenty of metrics like time to resolve
complaints, and percentage of issues resolved in a single call (very
important). Escalation paths are also an important element of an RFP.

Getting hard numbers on stuff like packet loss across peering and upstream
transit links is important and an RFP is a good way to get these numbers
with more assurance than an email from your sales rep.

Of course, there are plenty of silly RFP questions like "who do you peer
with and where" - with no mention of capacities or utilization!

-- 
Daniel Golding

Re: Honest Cogent opinions without rhetoric.

[Daniel Golding]

On 3/8/06 8:57 AM, "Patrick W. Gilmore" <[EMAIL PROTECTED]> wrote:

> 
> On Mar 8, 2006, at 1:56 AM, [EMAIL PROTECTED] wrote:
> 
> 
> 
>> With regard to depeerings: they are a fact of life on the internet
>> - and
>> as a service provider, you should always have multiple transits,
>> for this
>> and other reasons. Yes, you obviously will have more risk of being
>> caught
>> in a depeering fight if you are buying from $low-price-leader-du-jour,
>> because these are the ones more likely to be depeered by $big-boys for
>> being "too-competitive". ;)
> 
> De-peering is a fact of life, but Cogent takes something that other
> people consider a nuisance and turn it into a Real Problem.  No other
> network has been "de-peered" for multiple days multiple times in the
> last several years.  No other network has refused to provide some
> type of help (e.g. credits) for customers who were affected by the
> depeering.  (Hell, Cogent offered more help to L3's customers than
> they did to their own - although many people say they did not honor
> those offers.)
> 
One way to look at this is that you are getting a very low price per mbps
with Cogent. Therefore, when Cogent's CEO decides its in his best interest
to partition for a week over a depeering situation, their customer's role is
to suck it up. You get what you pay for, and in this case, that means
mediocre to average transit with periodic partitioning. Frankly, for the
price, that's pretty darn good.

If your choice is between Cogent and some other provider, you are making a
mistake. Cogent (and other low cost transit providers) can be part of a
balanced stable of transit providers. Folks who single-home to Cogent
deserve whatever Darwin delivers to them.

Do what Peter Cohen said and run an RFP. Every competent network engineer
should be able to write an Internet transit RFP.

-- 
Daniel Golding

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

[Daniel Golding]

On 3/6/06 6:14 PM, "Stephen Sprunk" <[EMAIL PROTECTED]> wrote:

> Thus spake "Daniel Golding" <[EMAIL PROTECTED]>
>> On 3/6/06 10:25 AM, "Stephen Sprunk" <[EMAIL PROTECTED]> wrote:
>>> So, unless there's policy change, most end-user orgs will have no
>>> choice but to pay the market rate for IPv4 addresses.  Spot markets
>>> are good when demand is elastic, but we're faced with a market that
>>> has growing inelastic demand that will outstrip fixed supply in a
>>> decade.  Capitalism doesn't handle that well.
>> 
>> There will be a average cost per host to transition from v4 to v6. When
>> the
>> cost of IPv4 addresses exceeds the transition cost, then you have the one
>> thing missing from IPv6 discussions: an ROI.
> 
> Please quantify the cost of not being able to multihome your
> mission-critical business.  Compare to the cost of obtaining an IPv4 PI
> block.  Both are likely to exceed the possible revenue for small businesses
> at some point not too far off.
> 

This is of course, making the assumption (which may be in error) at PI IPv6
space will happen, through 2005-1 or some other policy. Absent PI IPv6
space, IPv6 simply wont happen, shim6 or not.

-- 
Daniel Golding

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

[Daniel Golding]

On 3/6/06 10:25 AM, "Stephen Sprunk" <[EMAIL PROTECTED]> wrote:

> 
> 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.
> AFAIK, none of them are rent-free, and they're not even available unless you
> have the clue and resources to prented to be an LIR.
> 
> So, unless there's policy change, most end-user orgs will have no choice but
> to pay the market rate for IPv4 addresses.  Spot markets are good when
> demand is elastic, but we're faced with a market that has growing inelastic
> demand that will outstrip fixed supply in a decade.  Capitalism doesn't
> handle that well.
> 
> S
> 
> Stephen Sprunk"Stupid people surround themselves with smart
> CCIE #3723   people.  Smart people surround themselves with
> K5SSS smart people who disagree with them."  --Aaron Sorkin
> 

Stephen,

There will be a average cost per host to transition from v4 to v6. When the
cost of IPv4 addresses exceeds the transition cost, then you have the one
thing missing from IPv6 discussions: an ROI.

Many organizations wont even look at this without an ROI. Folks who want to
see v6 adopted would be well advised to support the creation of a hard ROI
through these means.

(Just as an aside - capitalism has historically been the best mechanism for
resource allocation - scarce resource or plentiful. Command economics have
never historically beaten a fair and open market, despite the beliefs of a
certain sector of those involved with IP address allocation.

ARIN (and/or RIPE, APNIC) should really use a bit of their budget surplus to
provide a few grants to economics professors who are experts in commodity
market issues. As engineers, we grope in the dark concerning fairly well
established scientific principles we are unfamiliar with. Its like
reinventing the wheel. :(

-- 
Daniel Golding

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

[Daniel Golding]

On 3/3/06 11:04 AM, "Stephen Sprunk" <[EMAIL PROTECTED]> wrote:
> 
> Keep in mind that current RIR allocations/assignments are effectively leases
> (though the RIRs deny that fact) and, like any landlord, they can refuse to
> renew a lease or increase the rent at any point.
> 
> There might be some interesting political battles when it comes to legacy
> allocations which are currently rent-free, but those tenants will find
> themselves woefully outnumbered when that day comes.
> 

> Stephen Sprunk"Stupid people surround themselves with smart
> CCIE #3723   people.  Smart people surround themselves with
> K5SSS smart people who disagree with them."  --Aaron Sorkin
> 

Leases are actually a bad thing, from an address exhaustion point of view.
Its like a country where the government owns all the land, but people have
been farming it for generations. They can't sell it.

If an address trading scheme evolves, address block holders will need clear
title granted them by the RIRs. That would make an IP address market,
moderated through the RIRs as clearing houses, tenable.

Sadly, many of the folks who are involved with ARIN are sadly short sighted
in this regard. They dismiss both the idea of an address market upon v4
exhaustion and the idea of clear title to address blocks. While I can't
state unequivocally that this is the answer, it does seem to merit further
study.

-- 
Daniel Golding

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

[Daniel Golding]

On 3/2/06 7:57 AM, "Edward B. DREGER" <[EMAIL PROTECTED]>
wrote:

> 
>> Date: Thu, 2 Mar 2006 10:07:33 +
>> From: [EMAIL PROTECTED]
> 
> [ snip ]
> 
>> Is there something inherently wrong with independent
>> organizations deciding where to send their packets?
> 
> 1. Many a transit seems to think so.
> 2. Is there an inherent need?
> 3. Is this DPA+sourceroute cocktail the best method?
> 

What Eddy said and also: The designers of shim6 seem to live in a different
network security world than I do. Even assuming that shim6 ever gets
deployed, which is pretty close to complete fantasy, the threat of a massive
TE botnet being used to control large amounts of Internet traffic is a
serious threat to Internet stability. Right now, DDoS attacks from Botnets
are bad enough. Think about what happens when they have source routing
control. 

Shim6 is a non-starter. A critical mass of host OS's will not get their
software upgraded to support this in the next 5 years - there isn't running
code ANYWHERE. Time to stop screwing around.

There is a tremendous amount of effort being wasted here arguing against it
and even more so in the IETF, where time being wasted on shim6 could be
better spent on a new IDR paradigm.

Where is the IETF leadership?

> 
> Eddy
> --
> Everquick Internet - http://www.everquick.net/
> A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
> Bandwidth, consulting, e-commerce, hosting, and network building
> Phone: +1 785 865 5885 Lawrence and [inter]national
> Phone: +1 316 794 8922 Wichita
> 
> DO NOT send mail to the following addresses:
> [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
> Sending mail to spambait addresses is a great way to get blocked.
> Ditto for broken OOO autoresponders and foolish AV software backscatter.

-- 
Daniel Golding

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

[Daniel Golding]

On 2/28/06 5:21 PM, "Iljitsch van Beijnum" <[EMAIL PROTECTED]> wrote:

> 
> On 28-feb-2006, at 23:15, John Payne wrote:
> 
>>> Should be doable with a DNS SRV record like mechanism. Don't worry
>>> too much about this one.
> 
>> Where does the assumption that the network operators control the
>> DNS for the end hosts come from?
> 
> ...or in another way. Don't worry too much about this one.

Unacceptable. This is the whole problem with shim6 - the IETF telling us to
"sit back and enjoy it, because your vendors know what's best". This
attitude combined with Shim6's (many) limitations speed it toward
irrelevance.

-- 
Daniel Golding

Re: USG posts RFI re: IANAI

[Daniel Golding]

Money.

On 2/24/06 11:05 AM, "Owen DeLong" <[EMAIL PROTECTED]> wrote:

> Because so far, DOC still thinks they control the oversight functions of
> some aspects of what used to be under the NSF and the USG wants to continue
> pretending that they control the internet.
> 
> Owen
> 
> 
> --On February 24, 2006 9:27:40 AM -0500 Martin Hannigan
> <[EMAIL PROTECTED]> wrote:
> 
>> 
>> 
>> 
>> 
>> This was interesting, operationally. I don't know why the USG does
>> RFI's on stuff like IANA:
>> 
>> http://www.fbo.gov/spg/DOC/OS/OAM/Reference-Number-DOCNTIARFI0001/Synopsi
>> sR.html
>> 
>> 
>> -M<
>> 
>> 
>> --
>> Martin Hannigan(c) 617-388-2663
>> Renesys Corporation(w) 617-395-8574
>> Member of Technical Staff  Network Operations
>> [EMAIL PROTECTED]
> 
> 

Re: So -- what did happen to Panix?

[Daniel Golding]

In terms of the larger question

ConEd Communications was recently acquired by RCN. I'm not sure if the
transaction has formally closed. I suspect there are serious transition
issues occurring. "Financial Stability", "Employee Churn", and "Ownership"
are, unfortunately, tough things to factor into BGP algorithms.

http://investor.rcn.com/ReleaseDetail.cfm?ReleaseID=181194

Internet access has always been a sideline for CEC - they are more of a
provider of transport, and their customers have included some very well
known entities in the NY metro area.

Perhaps someone from RCN would care to comment?

- Dan

Re: The Backhoe: A Real Cyberthreat?

[Daniel Golding]

Sean,

This is a question of hierarchy of risk and scarce resource allocation.
Fiber infrastructure is relatively well protected (by the ground), hard to
damage (requires big machines), and has service restoration capabilities
(routing protocols, optical ring protection, et al). A large scale
(regional) telecom network outage is a big deal and can be economically
devastating. However, its tough to pull off, and, more importantly, it takes
time to do the damage.

Walking into a Boston/NY/Chicago subway station with a vest packed with c4
at rush hour, is another ball of wax. Its easier to pull of 10 simultaneous
suicide attacks against public transit than it is to induce a major regional
telecom outage through fiber cuts, IMHO.

If I was a terrorist, I'd rather try to take out points of fiber
concentration, and my tool would not be a backhoe. I won't elaborate, but I
think most folks can figure out a few modalities of attack.

Too many people know where those points of concentration are and how to
crack them open. I don't think restricting government information is going
to help much. Scarce DHS resources should be applied elsewhere.

- Dan

On 1/19/06 1:00 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> 
> 
> While it is always fun to call the government stupid, or anyone else for that
> matter, there is a little more to the story.
> 
> - For one you do not need a backhoe to cut fiber
> - Two, fiber carries a lot more than Internet traffic - cell phone, 911,
> financial tranactions, etc. etc.
> - Three, while it is very unlikely terrorists would only attack telecom
> infrastructure, a case can be made for a telecom attack that amplifies a
> primary conventional attack.  The loss of communications would complicate
> things quite a bit.
> 
> I'll agree it is very far fethced you could hatch an attack plan from FCC
> outage reports, but I would not call worrying about attacks on
> telecommunications infrastructure stupid.  Enough sobriety though, please
> return to the flaming.
> 
> 
> - Original Message -
> From: Joe Maimon <[EMAIL PROTECTED]>
> Date: Thursday, January 19, 2006 12:01 pm
> Subject: Re: The Backhoe: A Real Cyberthreat?
> 
>> 
>> 
>> 
>> Dennis Dayman wrote:
>> 
>>> "In 2004, Department of Homeland Security officials became
>> fearful that
>>> terrorists might start using accidental dig-ups as a road map
>> for deliberate
>>> attacks, and convinced the FCC to begin locking up previously
>> public data on
>>> outages. In a commission filing, DHS argued successfully that
>> revealing the
>>> details..."
>>> 
>>> --MORE--
>>> 
>>> http://wired.com/news/technology/0,70040-0.html?tw=wn_tophead_1
>>> 
>>> -Dennis
>>> 
>>> 
>>> 
>> 
>> This is really stupid. Assuming the terrorist actually have the
>> dozens 
>> of backhoes needed to completely erase meaningfull internet
>> connectivity 
>> in north america, they would probably prefer to use them to smash
>> cars 
>> and kill people on the interstate highways or something.
>> 
>> Terrorist inflict terror by killing people, not by forcing
>> internet 
>> explorer to display "page cannot be displayed".
>> 
>> Let us not assume that murderous terrorist are as dumb as people
>> in DHS.
>> 

Re: is this like a peering war somehow?

[Daniel Golding]

More like a preference/QoS war - peering has little to do with it. BS et al
will provide their customers a route to Google, Yahoo, etc - anything else
is economic suicide.

The big question is, can they convince the content players that they need
preferential transport. Anyone with a clue would say that things are working
just fine, and that the bits won't move any faster in an uncongested and
uncontested modern Internet backbone network.

The RBOCs need to get over this - they are floundering around to try and
find a way to recoup network costs. This is one front. IMS is another. I
feel their pain, but this battle has been lost. It has taken ten years, but
content has turned out to be king, at least as far as profit margins go. The
RBOCs are paying for their lack of vision.

Perhaps the RBOCs can do better with IPTV and take on the MSOs? Who knows,
but this effort to wring profit out of done deals is a sign of desperation
from companies that have lost the ability to innovate.

- Daniel Golding

On 1/19/06 6:44 PM, "Paul Vixie" <[EMAIL PROTECTED]> wrote:

> 
> proving once again that "peering ratios" only matter if the other guy's
> customers can live without your "assymetric" content, here are two articles
> i saw today via slashdot.  what's interesting to me is whether bellsouth
> will be sued some time later by some other content provider for de-peering
> them without also having applied the same rules to google.  note, this isn't
> a bellsouth-specific rant, they just happen to be mentioned in today's story.
> 
> 
> 
> http://www.networkingpipeline.com/blog/archives/2006/01/google_we_wont.html
> Google: We Won't Pay Broadband Cyberextortion
> January 18, 2006
> 
> BellSouth and Verizon have been trying to force big Web sites to pay
> extortion-type fees if the sites want adequate bandwidth, with Google a prime
> target. But Google has news for them: It won't pay.  [...]
> 
> 
> 
> http://www.networkingpipeline.com/blog/archives/2006/01/bellsouth_cyber.html
> BellSouth: Cyberextortion Pays Off
> January 17, 2006
> 
> BellSouth's new business model, a slightly more polite form of the kind of
> extortion practiced by Tony Soprano, is starting to pay off. The company says
> it is in negotiations with several Web sites willing to pay extra fees to
> BellSouth for more bandwidth than it provides to other sites.  [...]
> 
> 

Re: QWest is having some pretty nice DNS issues right now

[Daniel Golding]

On 1/6/06 9:54 PM, "Steve Gibbard" <[EMAIL PROTECTED]> wrote:

> 
> On Fri, 6 Jan 2006, william(at)elan.net wrote:
> 
>> On Fri, 6 Jan 2006, Wil Schultz wrote:
>> 
>>> Apparently they have lost two authoritative servers. ETA is unknown.
>> 
>> You forgot to mention that they only have two authoritative servers for
>> most of their domains...
> 
[snip]
> 
> So from my uninformed vantage point, it looks like they started doing this
> more or less right -- two servers or clusters of servers in two different
> facilities, a few thousand miles apart on different power grids and not
> subject to the same natural disasters.  In other words, they did the hard
> part.  What they didn't do is put them in different BGP routes, which for
> a network with as much IP space as Qwest has would seem fairly easy.
> While it's tempting to make fun of Qwest here, variations on this theme --
> working hard on one area of design while ignoring another that's also
> critical -- are really common.  It's something we all need to be careful
> of.
> 
> Or, not having seen what happened here, the problem could have been
> something completely different, perhaps even having nothing to do with
> routing or network topology.  In that case, my general point would remain
> the same, but this would be a bad example to use.
> 
> -Steve

At some point in a carrier's growth, Anycast DNS has got to become a best
practice. Are there many major carriers that don't do it today, or am I just
a starry-eyed idealist?

- Dan

Re: Bogon stupidity... warning... operational post.

[Daniel Golding]

On 12/22/05 1:35 PM, "Christopher L. Morrow" <[EMAIL PROTECTED]>
wrote:

> 
> 
> On Thu, 22 Dec 2005, william(at)elan.net wrote:
> 
>> 
>> 
>> On Thu, 22 Dec 2005, Robert Boyle wrote:
>> 
>>> At 12:56 PM 12/22/2005, you wrote:
>>> P.S. 204/8 was not the only problem, there were problems with 128/8 and
>>>> 133/8 as well so my apologies to people who may have noticed problems
>>>> overnight.
>>> 
>>> 199.128.0.0/9 too.
>> 
>> Yes, legacy blocks (with large number of smaller allocations) whenever
>> datasize during processing exceeded certain amount. The bad data was
>> present at 2 of 4 servers for duration of the night but dns was being
> 
> so 50+% of your system was hozed for some long period of time :( bad.
> 
>> changes same time as well, so I don't know how much affect there was
>> but apparently considerable; this is the most serious problem in months.
>> 
> 
> 'most serious problem in months' ... this has happened in smaller chunks
> during the past 'months' ? yikes... is that noted on your site so users of
> the 'service' will know what sorts of 'problems' they might be
> encountering due to their reliance on this 'service'?

I wonder how many problems cymru has had in that period? I'm guess not so
many...

-- 
Daniel Golding

Re: SBC/AT&T + Verizon/MCI Peering Restrictions

[Daniel Golding]

On 11/2/05 2:04 PM, "Randy Bush" <[EMAIL PROTECTED]> wrote:

> the two year window is far too low given the sbc ceo's recent public
> statements on the use of his wires by google and the like.
> 
> randy
> 

For the curious on the list...

"How do you think they're going to get to customers? Through a broadband
pipe. Cable companies have them. We have them. Now what they would like to
do is use my pipes free, but I ain't going to let them do that because we
have spent this capital and we have to have a return on it. So there's going
to have to be some mechanism for these people who use these pipes to pay for
the portion they're using. Why should they be allowed to use my pipes?

The Internet can't be free in that sense, because we and the cable companies
have made an investment and for a Google or Yahoo! or Vonage or anybody to
expect to use these pipes [for] free is nuts!"

- Ed Whitacre, CEO of SBC

-

I choose to view this as ineffectual railing against the seemingly
inevitable subordination of bit transport to compelling content.

Memo to Ed Whitace:

They ARE using your pipes right now, and they AREN'T paying you money. The
funny thing is that your customers ARE paying you money for access to Google
and Yahoo. Broadband gets a lot less compelling without content, so don't
push it. 

-- 
Daniel Golding

SBC/AT&T + Verizon/MCI Peering Restrictions

[Daniel Golding]

Any thoughts on this:

http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=16437

--- 
The applicants committed, for a period of three years, to maintain
settlement-free peering arrangements with at least as many providers of
Internet backbone services as they did in combination on the Merger Closing
Dates.

The applicants committed for a period of two years to post their peering
policies on publicly accessible websites. During this two-year period, the
applicants will post any revisions to their peering policies on a timely
basis as they occur.
 

Published SFI peering policies are nice, but the overlap in SFI peering
between each pair of merging carriers may require them to peer with
additional networks. For example, there is some overlap between SBC and AT&T
in regards to SFI peers. This might require the combined network to
interconnect with additional networks to MAINTAIN the overall number of SFI
peers. 

I guess its a good time to apply to 701 for SFI, although it appears the
number of slots are limited to some unknown (and probably low) number.
Gentlefolk, start your engines :)

Can anyone else think of regulatory restrictions previously placed on SFI
relationships in North America? I realize this is more like a consent decree
than true regulation, but its an interesting move by the regulators.

Regulation is generally a bad thing, but publishing SFI requirements - and
even SFI relationships - won't hurt anyone, IMHO.


-- 
Daniel Golding

Re: cogent+ Level(3) are ok now

[Daniel Golding]

On 10/28/05 7:37 PM, "Crist Clark" <[EMAIL PROTECTED]> wrote:

> 
> Eric Louie wrote:
>> Now, one really needs to wonder why the agreement could not be reached
>> *prior* to the depeering on 10/5
>> 
>> It's not rocket science.
> 
> As people have pointed out repeatedly, this was surely not rocket science
> since it wasn't a technical problem at all. It was a business conflict.
> 
> It seems clear to me what probably happened. First-round negotaitions
> failed 'cause Level 3 thought Cogent was bluffing (and perhaps vice
> versa). Level 3 called the bluff, but it wasn't a bluff, and Level 3
> then blinked (or so it appears from reading between the lines of what
> I've seen). They both got back to negotiation, and with a better
> understanding of to how much pain the other willing to take to get what
> they want, this time they came out with an agreement.
> 
> Doesn't seems mysterious.

It should. Level(3) knew that Cogent would partition. Why? Because they've
done it before, more than once. Their business model supports that strategy
(some would say, demands it). The Level(3) folks are well informed and would
certainly have anticipated this action.

The Cogent folks also knew, with a high degree of probability, that Level(3)
would carry out their threat. No one sends out a depeering letter unless
they are willing to pull the plug. Why? Because sometimes the other party
pre-empts you and downs the session before you can.

Peering is one of those things that seems very simple. On the small scale
that is correct. On the larger scale, especially when dealing with SFI
networks, the rules change and things get hairy. Things like ratios matter a
great deal when your traffic is in a zero-sum condition with ratio sensitive
SFI peers. 

Cogent is an interesting case, as their peering decisions are typically made
with more-than-ordinarily ruthlessness.
 
> [snip]

- Dan

Re: cogent+ Level(3) are ok now

[Daniel Golding]

On 10/28/05 5:45 PM, "JC Dill" <[EMAIL PROTECTED]> wrote:

> 
> Christopher Woodfield wrote:
>> 
>> "...the companies have agreed to the settlement-free exchange of
>> traffic subject to specific payments if certain obligations are not  met."
>> 
>> So it does look like Cogent bent somwhat...I'm guessing they agreed  to
>> pay some sort of "traffic imbalance fee"?
> 
> There are other possibilities.
> 
> Maybe they agreed to pay a transit fee should they fail to carry the L3
> user's requested traffic as far as possible before handing it off (cold
> potato routing) and hand it off at the earliest possibility (hot potato
> routing) leaving L3 to backhaul it across the L3 network to the user who
> requested the data.

I doubt it. Cold potato is normally the first thing Cogent offers in a
situation like this. I'm guessing this went something beyond that. Cogent
would have offered cold potato well before the original depeering.

I have no specific information, but I'm guessing there is a per-mbps charge
that kicks in at certain ratio levels. Or, there may be a flat "port charge"
per month under certain conditions - Sprint did this many years ago.

> 
> Etc.
> 
> jc
> 

I'm having a bit of trouble figuring out Level(3)'s goal in all this. A bit
of incremental revenue? For all of this trouble? I could understand feeling
that Cogent's ratios are a violation of their peering requirements and
depeering them on principle, but if that's the case, why back down for a
little cash? 

Of course, various external pressures may have been brought to bear on
Level(3). Customers, regulators, press, creditors, etc.

- Dan

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

[Daniel Golding]

On 10/17/05 4:51 PM, "Tony Li" <[EMAIL PROTECTED]> wrote:
> Fred,
> 
>> If we are able to reduce the routing table size by an order of
>> magnitude, I don't see that we have a requirement to fundamentally
>> change the routing technology to support it. We may *want* to (and
>> yes, I would like to, for various reasons), but that is a different
>> assertion.
> 
> 
> 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. We can't see
into the future. However, assuming that IPv6 is the Last Protocol seems a
bit short sighted. If we get 20 years out of IPv6, that will be just peachy.

Of course, if we can't get PI address space for enterprises and real
multihoming, there won't be any real IPv6 deployment. Lots of (possibly
illegitimate) IPv4 trading and NAT, but not IPv6.

These aren't nice to haves. Even if it shortens the life of IPv6, that is an
acceptable trade-off.

IPv6 is not the Last Protocol.

> 
> Regards,
> Tony
> 

Dan

Re: IPv6 news

[Daniel Golding]

On 10/12/05 3:13 PM, "Randy Bush" <[EMAIL PROTECTED]> wrote:

> 
> geoff's predictions for a very lively market in v4 space will
> seriously come into play.

Maybe its time to have a serious talk about IPv4 commodity trading schemes.
Anyone interested in this enough to have a BOF at ARIN/NANOG?

This could extend the lifetime of the IPv4 space significantly by promoting
efficient use through economic incentives, provide positive economic
incentives to move to v6 when needed, and eliminate the grey market.

Proper controls could be put into place to prevent de-aggregation through
utilization of the RIRs as clearing houses.


> 
> randy
> 

Re: Regulatory intervention

[Daniel Golding]

On 10/7/05 11:02 AM, "Ross Hosman" <[EMAIL PROTECTED]> wrote:

> 
> Google Goes to Washington
> 
> One of the issues Google will tackle has become news
> this week: Level 3 and Cogent Communications are
> involved in a spat that has made Web sites on each
> network inaccessible or very slow to users on the
> opposite network. Google said the government has a
> responsibility to monitor the Internet so events like
> this do not occur.
> 
> http://www.betanews.com/article/Google_Goes_to_Washington/1128691070
> 

Google also has a responsibility not to bite the hand that feeds it - the
laise faire, unregulated Internet.

Shame on them. Google is not suffering at all from this.

> Ross Hosman
> 
> 

-- 
Daniel Golding

Re: Cogent/Level 3 depeering

[Daniel Golding]

On 10/6/05 10:37 AM, "Patrick W. Gilmore" <[EMAIL PROTECTED]> wrote:

> 
> On Oct 6, 2005, at 10:19 AM, tony sarendal wrote:
> 
>> This is not the first and certainly not the last time we see this kind
>> of event happen.
>> Purchasing a single-homed service from a Tier-1 provider will
>> guarantee that you
>> are affected by this every time it happens.
> 
> s/every time it happens/every time it happens to YOUR upstream
> 
> People on Sprint, AT&T, GLBX, MCI, etc. were unaffected.  Only people
> who single-home to L3 or Cogent have disconnectivity.

Take-away: Do not single home. I'm shocked folks aren't figuring this out.
If you are a webhoster or enterprise and your business model can not support
multiple Internet pipes, than you have a suboptimal business model (to put
it lightly)

> 
> 
>> Now, is being a tier-1 now a good or bad sales argument when selling
>> internet access ?
> 
> It's still a good argument, because Marketing != Reality. :)


Dan

Re: Cogent/Level 3 depeering

[Daniel Golding]

On 10/6/05 10:30 AM, "Randy Bush" <[EMAIL PROTECTED]> wrote:

>>> Is being a tier-1 now a good or bad sales argument when
>>> selling internet access ?
>> Its a great sales argument. That's why everyone claims to be
>> one. It just sounds SO good. And its not like the Peering
>> Police are going to enforce it.  What does it mean in real
>> life? Nothing. Nada. An organization's SFI status is a
>> particularly poor criteria for choosing a transit
>> provider. There are so many better factors to use - support,
>> packet loss, price, latency, availability, provisioning speed
>> - you name it, its a better criteria than SFI status.
> 
> packet loss and latency to *where*?  before replying, consider
> that most of a leaf's traffic is either to/from another leaf of
> a tier-1 to which they're (possibly indirectly) downstream, or
> to/from the tree of a tier-1 which peers with the tier-1 to
> which they're attached.
> 

Consider this: A Tier 1 (SFI network) with congested peering links vs a
non-SFI network with wide open transit pipes. I know I'd pick the latter.

Latency when all inter-network links are uncongested is going to be pretty
low in any case. 

> if tier-n, where n > 1, is buying transit from tier-1s, which
> they have to do, then the price game seems to be pretty
> determined unless one likes to run at a loss or is cross-
> subsidizing from some other product line.
> 
> all your bases are belong to us. :-)
> 
> randy
> 

Dan

Re: Cogent/Level 3 depeering

[Daniel Golding]

On 10/6/05 6:43 AM, "tony sarendal" <[EMAIL PROTECTED]> wrote:

> 
> Is being a tier-1 now a good or bad sales argument when selling
> internet access ?


Its a great sales argument. That's why everyone claims to be one. It just
sounds SO good. And its not like the Peering Police are going to enforce it.

What does it mean in real life? Nothing. Nada. An organization's SFI status
is a particularly poor criteria for choosing a transit provider. There are
so many better factors to use - support, packet loss, price, latency,
availability, provisioning speed - you name it, its a better criteria than
SFI status. 

- Dan

> 
> --
> Tony Sarendal - [EMAIL PROTECTED]
> IP/Unix
>-= The scorpion replied,
>"I couldn't help it, it's my nature" =-

Re: Cogent/Level 3 depeering

[Daniel Golding]

On 10/6/05 1:41 AM, "Patrick W. Gilmore" <[EMAIL PROTECTED]> wrote:

> 
> On Oct 5, 2005, at 4:13 PM, Daniel Golding wrote:
> 
>> They can. Cogent has transit and is preventing traffic from
>> traversing its
>> transit connection to reach Level(3). Level(3) does not have
>> transit - they
>> are in a condition of settlement free interconnection (SFI). The
>> ball is in
>> Cogent's court. This is not the first time or the second that they
>> have
>> chosen to partition.
> 
> Cogent does purchase transit from Verio to Sprint, AOL, and other
> locations (but not to Level 3).  Perhaps Dan would like to explain
> why that is relevant to the discussion at hand?  Or why that puts the
> "ball" in Cogent's court?

Since you demanded it - Cogent buys transit. Regardless of what their route
filters are currently set to, or what communities or arrangements they have
with Verio, its transit. They purchase bandwidth to access other networks.
Although I have not seen their transit contract, its not a stretch to say
that they can use these connections to reach L3. I realize they may claim
otherwise, but I have personal experience with them lying about their
transit arrangements. And no, not some call center rep or NOC guy, either.
Try a Cogent executive.

> 
> And no, L3's "SFI" status does not mean it's Cogent's fault.

There is no fault here. This is a business arrangement for all concerned.
Cogent can make a configuration change to use their transit to reach
Level(3). Level(3) has depeered them. I don't think anyone is "right" or
"wrong". Generally, when one plays the peering game and loses, one eats it.
Cogent however, is putting up a fight first. I don't blame them - its what I
would do. However, they must face the music with their customers.

> 
> 
> It is strange that people have to be reminded no network has the
> "right" to use any other network's resources without permission.
> Most people realize this in one direction.  For instance, the "tier
> ones" love to point out Cogent has no "right" to peer with Level 3.
> Absolutely correct.
> 
> What some people seem to forget is that Level 3 has no right to force
> Cogent to buy transit to get to Level 3.

Sure. Cogent is free to offer a partial routing table and take their chances
with their customers.

> 
> If Level 3 doesn't mind not being able to pass packets to Cogent,
> that's fine.  If they do mind, they need to figure out a way to solve
> the problem - with Cogent.  The inverse is true as well.  As RAS
> said, it takes two to tango.
> 
> 
> This problem will be solved "soon" (in human time - days, weeks at
> most).  One of the networks may go out of business, but that "solves"
> the problem because there would no longer be locations on the
> Internet someone couldn't reach.  I suspect it will be solved by less
> drastic means.

Usually these situations resolve in 2 - 10 days. At least, that's been the
pattern. My prediction is that Cogent will fold, because they have in the
past. Of course, I can't speak to Level(3)'s intestinal fortitude.


- Dan

Re: Cogent/Level 3 depeering

[Daniel Golding]

On 10/5/05 1:43 PM, "Jeff Shultz" <[EMAIL PROTECTED]> wrote:
> 
> Undereducated rant to follow...
> 

Don't ever rant when uneducated. Its like driving angry. (/groundhog day)

> While I realize that the "nuke survivable" thing is probably an old
> wives tale, it seems ridiculous that "the Internet" can't adjust by
> routing any packets that used to go directly from Cogent to Level 3
> though some 3rd (and) 4th (and) 5th set of providers that are connected
> in some fashion to both...

They can. Cogent has transit and is preventing traffic from traversing its
transit connection to reach Level(3). Level(3) does not have transit - they
are in a condition of settlement free interconnection (SFI). The ball is in
Cogent's court. This is not the first time or the second that they have
chosen to partition.

I'm not judging them on this, its a strategic call. However, considering the
have backed down the last couple times, Level(3) would be smart to call
their bluff.

> 
> Level 3 and Cogent can't be operating in a vacuums - if we can get to
> Kevin Bacon in 6 degrees, Level 3 and Cogent should be able to get to
> each other in under 30 hops through other providers.
> 
> And why isn't this apparently happening automatically? Pardon the
> density of my brain matter here, but I thought that was what BGP was all
> about?
> 
> I welcome any education the group wishes to drop on me in this matter.

This is about more than routing protocols. Its about how the Internet (large
I) works. Peers, transit, etc. Not usually found in your favorite BGP book.

Think of the SFI networks in the center. They may not be the largest
networks in terms of traffic, but they have complete mesh SFI relationships
with each other. Then, there are numerous other networks with some degree of
SFI - think of them as a donut surrounding the SFI core. They are
interconnected with a subset of the SFI networks and to each other in order
to "short circuit" those networks who won't perform settlement free
interconnection with them.

Cogent has been attempting to establish SFI relationships with many of
Level(3)'s customers since Level(3) threatened them with depeering. This is
so that a) the partition is less painful and/or b) they'll have to buy less
transit.

We will now return this thread to the normal stream of "why is Cogent
broken", "Level(3) is a bunch of meanies", and "my traceroutes feel FUNNY".
;) 

- Daniel Golding

Re: Cogent/Level 3 depeering

[Daniel Golding]

On 10/5/05 3:02 PM, "Matthew Crocker" <[EMAIL PROTECTED]> wrote:

> Is it really that hard to understand?
> 
> As a paying Cogent customer I expect to be able to get to the
> Internet through them.  Isn't that the business they are in?
> 

Break your contract for non-performance and call it a day. Cogent and L(3)
deciding to depeer is an operational issue. Crocker Communications getting
shafted on a transit contract? Not so much.

- Dan

> --
> Matthew S. Crocker
> Vice President
> Crocker Communications, Inc.
> Internet Division
> PO BOX 710
> Greenfield, MA 01302-0710
> http://www.crocker.com
> 

Re: OT - Vint Cerf joins Google

[Daniel Golding]

Getting back on-topic - how can this be? I thought only service providers
(with downstream customers) could get PI v6 space. Isn't this what policy
proposal 2005-1 is about? Can someone (from ARIN?) explain the current
policy?

- Daniel Golding

On 9/9/05 2:16 PM, "Steven J. Sobol" <[EMAIL PROTECTED]> wrote:

> 
> On Fri, 9 Sep 2005, JORDI PALET MARTINEZ wrote:
> 
>  
>> I was thinking yesterday that IPv6 evangelization is a good reason,
>> specially when recalling that Google asked for a prefix some time ago
>> (http://www.ipv6tf.org/news/newsroom.php?id=1001) and something is probably
>> being baked there ?
> 
> So is the idea that Google adopts IPv6 and then, seeing that a large,
> well-trafficked(sp?) website is actually using the technology, lots of
> service providers and smaller sites follow suit?
> 
> How widespread *is* IPv6 adoption, anyhow?

Re: MPLS security book

[Daniel Golding]

I'm not sure this is on-topic for NANOG, but I'll have a go. This is a great
book. It doesn't make any assumptions about spoofing or access to P and PE
routers - it analyzes what will happen if that occurs.

Security is about risk management. In order to manage risks, you have to
know what they are. The authors of this book obviously put a lot of thought
into exactly what security means, how it applies to networks, and how it
applies to MPLS. 

The network operations community has no idea if any of the scenarios
discussed in the book have happened. More importantly, who cares? Security
comes in two forms - reactive and proactive. Just because an attack has
occurred in the past is not a reasonable indicator of future threat on its
own. Similarly, the absence of a particular attack does not mean a threat
doesn't exist. In any event, we do not have any idea of what attacks have
really occurred, so we must act without that knowledge.

This is a great book for two audiences: enterprise network engineers who are
getting asked if their new MPLS VPN is secure (for some definition of
secure) and carrier network engineers trying to answer that question.

- Daniel Golding

On 8/28/05 8:28 AM, "Kim Onnel" <[EMAIL PROTECTED]> wrote:

> 
> Hello,
> 
> I've been reading through Cisco press MPLS VPN Security book, too many
> assumtions about spoofing labels, getting access to core, PE, another
> VPN,
> 
> in security nothing should be taken for granted, but has there been
> any real world incidents where such scenarios have been really
> occuring ?
> 
> Regards

Re: ISP's In Uproar Over Verizon-MCI Merger

[Daniel Golding]

On 8/24/05 7:38 PM, "Joe Abley" <[EMAIL PROTECTED]> wrote:

> 
> On 24-Aug-2005, at 19:16, Lewis Butler wrote:
> 
>> And what does every country ahead of the US have in common?  Tiny
>> populations.
>> 
>> And waht does every country but one have in common?  Very small
>> area.  The US has states taht are larger than 10 of the 11
>> countries ahed of use, COMBINED.
> 
> (populations; population densities in people per square km, pasted
> from <http://en.wikipedia.org/wiki/
> List_of_countries_by_population_density>)
> 
>South Korea 48M; 491
>Netherlands 16M; 395
>Denmark 5M; 126
>Iceland 0.3M; 2
>Canada 33M; 3
>Switzerland 7M; 181
>Belgium 10M; 339
>Japan 128M; 337
>Finland 5M; 15
>Norway 5M; 14
>Sweden 9M; 20
>United States 296M; 30
> 
> So, of the 11 countries that the OECD thinks have greater broadband
> penetration than the USA, 6 are more densely-populated than the USA
> and 5 are not.

Joe,

I suggest you take another look at these numbers. Those countries with
overall population densities lower than the US's all have something in
common - they are really cold. Iceland, Canada, Finland, Norway, Sweden.
Folks in those countries are densely packed into relatively small regions of
their overall land area (near oceans or in cities). Sure, some folks live
out in Nunavut, but a relatively small number. Contrast that with the US
where the population is far more spread out.

This is an issue of both distribution and density, not just density.

> 
> Not that this necessarily means anything, but I thought your
> sentiments above could do with some numbers. I don't see a strong
> correlation between broadband penetration and population density here.
> 
> 
> Joe
> 

-- 
Daniel Golding

Re: 4-Byte AS Number soon to come?

[Daniel Golding]

Susan,

In light of Geoff Huston's recent article which urged alacrity in finalizing
a standard and implementing the eventual solution, where are we in this
process? Geoff's article suggest that we have about three years until
Internet transit AS's should begin transitioning. Given the QA cycle at both
router vendors and major carriers, this means that the timeframe is quite
condensed, at least by IETF standards.

My question, in short, is, will we make it? (the corollary is, does the
IETF/IDR have a sense of urgency as they move this process along?)

Thanks,
Dan

On 8/24/05 2:57 AM, "Iljitsch van Beijnum" <[EMAIL PROTECTED]> wrote:

> 
> On 24-aug-2005, at 5:50, Susan Hares wrote:
> 
>> This is the first of many steps.  And to be fair to the authors, the
>> process got held up due to the base draft being re-written.
> 
>> So, the key discussion points are (as Yakov has indicated as well):
>> a) Are there any technical problems with the specification
>> b) Does the specification cause operational problems?
>> c) General concerns about the design of the additions to BGP
>> (scaling, etc).
> 
> I find the design less robust than it could be.
> 
> What it does is define that toward a neighbor that also supports wide
> AS numbers it will send the AS path with 32-bit AS numbers, and
> toward a neighbor that doesn't support wide AS numbers it sends the
> AS path with 16-bit AS numbers and a "new AS path" with 32-bit AS
> numbers.
> 
> I think it makes more sense to ALWAYS send the old 16-bit AS path and
> the new 32-bit AS path attribute. This makes the code path identical
> for the two types of peers, which is less likely to lead to new bugs
> and makes for easier (operational) debugging.
> 
>> Implementation reports give us the opinion of those who have already
>> implemented the protocol.  That's usually worth hearing about.
> 
> As an operator, I'm sorry to say I don't always have the highest
> possible opinion of the people implementing the protocols. (I always
> say: never ask the people who built the thing what it can do.)
> Obviously implementing a specification is a crucial step, and an
> illuminating one because it brings out bugs and hidden assumptions in
> the specification. It can also uncover a broken design, but I hope
> and believe this is relatively rare. (And it's not like a broken
> design is automatically unimplementable, so implementation is
> certainly not guaranteed to bring out design problems.) So yes, it's
> worth hearing about, but not worth delaying publication for. And
> since the IETF only has one way to publish documents for periods
> extending six months...

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: Blocking certain terrorism/porn sites and DNS

[Daniel Golding]

There are actually perfectly valid reasons for not blocking such sites, even
if you feel (as I do) that jihadis are the enemies of civilization.

Many of these sites are used to transmit data concerning terrorist attacks
or for recruitment, etc. Some include forums where supporters can post
messages. Its a safe bet to assume that various law enforcement bodies may
monitor such sites.

If you block them at the DNS level, they will simply move elsewhere.
Logically, it will take longer for law enforcement to catch up than it will
for the bad guys to start using another domain name. That's a bad thing.

So, to answer your original question: yes, it is entirely possible, from a
technical point of view*. If you were going to block a web site, using DNS
is probably the best way to ensure there is minimal "collateral damage" -
blocking via IP address will result in other sites getting blocked due to
virtual hosting (using a single IP address for many web sites). However,
there are legal, ethical, and law enforcement reasons why such action may
not always be wise.

Discussing any sort of blocking will always arouse passions. Talking about
blocking port 445 to stop an (alleged) worm infestation seems to get
people's undergarments in a knot. For good or ill, the Internet was built as
an open network and seems to work best that way. That ideal has been
transmitted to most of those who currently toil away to keep it running and
to improve it.

Don't be afraid to keep asking questions, Abhishek. Just remember that the
inmates of this particular asylum get testy now and again :)

Thanks,
Daniel Golding

(*There are additional questions on where you should do this blocking.
That's an entirely separate can of worms)

On 8/18/05 6:38 AM, "Abhishek Verma" <[EMAIL PROTECTED]> wrote:

> 
> coz i assumed that everyone wants to block such sites.
> 
> sorry if i hurt some feelings.
> 
> apologies,
> abhishek
> 
> On 8/18/05, Randy Bush <[EMAIL PROTECTED]> wrote:
>>> Again, I am not discussing "censoring ideas".
>> 
>> then why did you use emotionally loaded words such as "terrorist?"
>> 
>> randy
>> 
>> 
> 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: zotob - blocking tcp/445

[Daniel Golding]

On 8/15/05 4:46 PM, "Randy Bush" <[EMAIL PROTECTED]> wrote:

> 
 I'm not nearly confident enough to decide on behalf of almost
 billion other people how they should benefit from the Internet
 and how not to.
>>> thanks for that!
>> Indeed.  Also see
>> http://www.iab.org/documents/docs/2003-10-18-edge-filters.html
> 
> as i just replied to a private message from an enterprise op,
> 
>   o backbone isps can not set their customers' security policy
> - some customers want to run billyware shares over the wan
>   whether we advise it or not
> - some of us host security researchers, who have a taste
>   for 445 and other nasty traffic
> 

While its not uncommon to run SMB/Windows file system drive mounts across
private WANs, doing so across the Internet, on a non-encrypted tunnel, is
the equivalent of running with scissors.

I am unaware of any enterprise security folks foolish enough to allow that.
Of course, I may be sheltered.

(as an aside - running windows file system mounts across enterprise WANs is
so common that there are WAN optimization devices that improve remote disk
mount performance via protocol spoofing)

- Dan



>   o enterprise / site ops can set their users' security policies
> as that's part of their job and charter
> 
> randy
> 

Re: /8 end user assignment?

[Daniel Golding]

On 8/7/05 4:54 PM, "Christopher L. Morrow" <[EMAIL PROTECTED]>
wrote:

> 
> On Sun, 7 Aug 2005, William Warren wrote:
> 
>> 
>> I think i did not make myself clear.  The corrections off-list are
>> valid..:)  However the modems are accessed by the providers using
>> RFC1918 space and not public IP space.  This is true it does not mean
> 
> and there was a mention at IETF by Alian of comcast (formerly of FT I
> thought?) that comcast was looking at an immediate ipv6 rollout: "because
> net 10 is not big enough"... 'immediate' on some scale not 'ten years out'
> (no timeframes mentioned, sorry)

I suspect Comcast's mouth is bigger than its stomach, as it were. They have
a few other things they may want to tackle before rolling out v6. I don't
see a Comcact v6 rollout positively impacting their reliability.

- Dan

Re: /8 end user assignment?

[Daniel Golding]

On 8/4/05 6:49 PM, "Steve Feldman" <[EMAIL PROTECTED]> wrote:

> 
>> I meant to ask this at a nanog or this IETF... why don't some of the
>> larger content providers (google, msn, yahoo, to name 3 examples) put 
>> records in for their maint content pieces? why don't they get v6
>> connectivity from their providers (that offer such services) ? There are
>> starting to be more and more folks with v6 connectivity... it'd be
>> interesting as a way to drive usage on v6, eh?
> 
> (I work for a not-quite-as-large content player.  These are my own
> opinions, but this is what I'd tell my empolyer if they asked.)
> 
> - We can't get provider-independent IPv6 space (without pretending
>   to be a service provider.)
> 
> - None of our transit providers appear to provide IPv6 transit.
>   Or if they do, they keep it pretty quiet.  (Does UUNET?)
> 
> - Most of our content is delivered via load balancer hardware
>   that would also need to support IPv6.  Last time I checked,
>   it didn't.
> 
> - There are (perceived to be) more important things to spend
>   our limited resources on.
> 
> Steve

Why should content providers be at all interested in driving v6 usage? They
are interested in meeting demand, innovating, collecting ad revenue, etc.
The ROI to the given content provider is what? There ARE more important
things to spend one's limited resources on.

- Dan

Re: /8 end user assignment?

[Daniel Golding]

On 8/4/05 4:46 PM, "Daniel Roesen" <[EMAIL PROTECTED]> wrote:
> 
> Famous last words when driving down a long road towards a firm wall of
> concrete. You want to rush then? Do you wait for the pain to fully
> extend? I prefer orderly, planned, concious migrations, not a state of
> "uhm, we cannot get new IPv4 address space anymore, and the grey market
> prices for IPv4 space is skyrocketing... I cannot afford it anymore and
> our customers switch to ISPs who can still".
> 
> I thing that things will become very very nasty when we not only see the
> wall on our map but actually see it coming quickly on the horizont and
> warning signs at the side of the road tell something about "last exit to
> IPv6 in x miles. Toll applicable.".

This is a good reason for every major service provider to request some IPv6
space, ensure that future equipment acquisitions support v6, and have
someone playing with it in the lab. Not a very good reason to deploy.

Why do so many v6 folks fill their arguments with notes of alarmism? Why
don't we just make an orderly migration when it is called for, rather than
using hyperbole to scare people?

Of course, making IPv4 a fungible commodity would help with this (yes, I'm a
broken record). When prices get too high, you know its time for v6.

> 
>
> Regards,
> Daniel

-- 
Daniel Golding

Re: [Administrivia]: Please end this Thread: RE: "Cisco gate" and "Me et the Fed" at Defcon....

[Daniel Golding]

I suspect the problem is not the operation aspects of the discussion, but
rather the nasty and sometimes personal invectives flying around. They were
particularly prevalent in the "Cisco gate" thread, and generally absent in
the other threads.

Just my 2 cents. YMMV

- Dan

On 8/2/05 11:28 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:

> On Tue, 02 Aug 2005 08:28:58 CDT, "Malayter, Christopher" said:
>> Perhaps Susan was not clear enough yesterday.  The mailing list
>> administrative committee would request that you allow this thread to stop.
>> It has certainly outlived its operational usefulness.  I am now reiterating
>> that request.
> 
> Unfortunately, there's enough places where this touches on operational issues
> (such as getting enough information about a new release of router software so
> you
> can make informed decisions affecting your customers).  And obviously, a
> number
> of people think this is an important subject.
> 
> I suspect that adding a "This would be more on-topic/relevant on the XYZ list"
> would help kill it here...
> 
> Any suggestions where it would be more relevant?

Re: Boing Boing: Michael Lynn's controversial Cisco security presentat ion

[Daniel Golding]

On 7/29/05 12:56 PM, "John C. A. Bambenek" <[EMAIL PROTECTED]> wrote:

> 
> Remind me why I bother with information security when industry and the
> government seems to want to ensure things can be pwn3d as easily as
> possible...
> 


If the "digital pearl harbor" does come to pass, this won't be remembered as
a shining hour for Cisco, ISS, Homeland Security (which is also in the mix),
or the FBI. 

I hope the leadership at Cisco reflects on this incident and will utilize
different tactics the next time this happens. Similarly, I hope the
cybersecurity folks in our governments realize that, while a strong
relationship with vendors is essential, they must recognize that vendors
have different goals than they do.

The FBI raiding Lynn's house over a commercial dispute is too reminiscent of
Cryptonomicon for me.

- Dan

Re: Cisco and the tobacco industry

[Daniel Golding]

On 7/28/05 4:51 PM, "Geo." <[EMAIL PROTECTED]> wrote:

> 
> No, the point is if you want the internet to be patched then you can't
> torture people when they come to you for the patches.
> 
> Cisco routers are being sold to every company who connects to the internet,
> it's one step up from consumer products. You can't expect every company who
> owns a cisco router to buy an expensive contract or be willing to go thru
> the gauntlet to get the patches.
> 

Sorry, but its a traditional part of the product model for
telecommunications equipment. PBX's, routers, pretty much everything -
support contract required. Sure, you could have it a different way, but you
would have to be willing to pay significantly more up front to pay for that
ongoing support. Its not like the vendors are deceiving anyone here - a
support contract is listed on the quote for pretty much every new piece of
gear you buy from a vendor.

Take it from Ice-T - "don't hate the player, hate the game". Words to live
by.

[snip] 
> Geo.
> 
> George Roettger
> Netlink Services

Daniel Golding

Re: Cisco and the tobacco industry

[Daniel Golding]

On 7/28/05 4:29 PM, "Christopher L. Morrow" <[EMAIL PROTECTED]>
wrote:

> 
> 
> 
> On Thu, 28 Jul 2005, Geo. wrote:
> 
>> 
>> Jared,
>> 
>> Have you ever actually tried to get the updates using this method? It really
>> does take the better part of a week and no less than half a dozen emails or
>> phone calls and then there is the begging...
> 
> if it's critical to your business you'd think you'd have a support
> contract for it, eh? (or you decided that the 'better part of a week' and
> associated risk was an acceptable cost to your business)
> 
> ('you' in the royal sense, not 'you geo')
> 

Software has bugs. Deal with it. Sometimes you have to pay for updates to
fix those bugs. If you don't like it, find another vendor. Except - all
vendors do that, don't they? Well, I guess if your business model isn't
compatible with purchasing support contracts on vital gear, you may not have
a viable business. YMMV.

Cisco's conduct in this case may or may not be improper - we'll have to wait
for a little more information. From a PR point of view, they probably should
have let things ride and allowed the Blackhat talk to occur. They look like
bullies now, which is never good. Hindsight is 20/20, though.

That being said, their policy of offering free updates for certain bug fixes
to those who don't pay them for support is generous. See that hand feeding
you? Don't bite it.

-- 
Daniel Golding

Re: Cisco IOS Exploit Cover Up

[Daniel Golding]

Since the talk was actually delivered - does anyone have a transcript or a
torrent for audio/video?

- Dan

On 7/27/05 8:10 PM, "Jeff Kell" <[EMAIL PROTECTED]> wrote:

> 
> Cisco's response thus far:
> 
>http://www.cisco.com/en/US/about/security/intelligence/MySDN_CiscoIOS.html
> 
> Jeff

Re: Customer DNS records best practices

[Daniel Golding]

There are a couple possibilities.

Mice and Men and INS both make software that can "front-end" BIND servers
via a secure web interface. You can also utilize a secure DNS appliance to
serve your customer DNS - Infoblox, Bluecat, and INS all make these. They
generally have a pretty rich multi-user security model, can use RADIUS for
authentication, etc.

There are lots of good reasons to keep your customer DNS separate from your
own DNS if you are going to allow customers to remotely administer their
zone records. 

I would ensure you have a good idea of your requirements before you jump
into this - do you want the software to validate changed records? Just
accept changes? Do you plan to support a subset of Resource Records, or the
whole enchilada? 

- Dan

On 7/14/05 2:45 PM, "Peter Kranz" <[EMAIL PROTECTED]> wrote:

> 
> I am looking for any suggestions on tool/utilities that you are using to
> allow customers to manager their forward/reverse DNS records that reside on
> your DNS servers. Linux/Unix based preferred.
> 
> Peter Kranz
> Founder/CEO - Unwired Ltd
> Mobile: 510-207-
> [EMAIL PROTECTED]
> 
> 

-

Re: OMB: IPv6 by June 2008

[Daniel Golding]

Rubbish. Many of the organizations that hold legacy /8s are Universities. If
a .edu can pick up even a few million dollars from selling off a class A,
they will. After all, they could simply sell chunks.

$1 per IP address is the going rate, as I understand - not so much for "grey
market" transactions, but as a valuation used in merger/divestiture
situations.

If we simultaneously start making address space fungible (#nanog vocabulary
word of the day!) and keep giving it away from the RIRs folks will have a
choice. Choice is good.

As some point, as address space becomes scarce, it will become more
valuable. As it becomes more valuable, people will be willing to spend more
money to get addresses. This is basic economics. We have an artificially
scarce (but finite) resource - the market can fix our problems.

At some point, the cost of buying enough address space for a given service
provider or enterprise will become more than the cost of implementing IPv6.
The market will then drive v6 implementation.

Our system of allocating IP addresses is a cross between soviet-style
central planning and FCC spectrum allocation. That doesn't need to occur. We
can morph the RIRs into commodity exchanges and solve the following issues:

- irritation with RIR procedures for getting address space
- justification for address space ("cash is my justification")
- worries about running out of address space as folks sell their hoarded
space and the market loosens
- motivation for shifting to v6 - there will be a real cost to using v4
addresses, but v6 addresses will be free.

We can try to regulate the heck out of this, or let the market handle it. To
quote Gorden Gecko, "greed is good" - at least for driving IPv6 adoption.

- Dan

On 7/8/05 5:27 AM, "Iljitsch van Beijnum" <[EMAIL PROTECTED]> wrote:

> 
> On 8-jul-2005, at 9:42, David Conrad wrote:
> 
> 
>>> There are some 45 - 50 /8s assigned to single organizations. Let's
>>> assume for simplicity that those can all be reclaimed. That's 4
>>> years at a /8 a month. So far so good. Then there are 40 - 45 /8s
>>> in class B space. That means 256 times as much effort to reclaim
>>> the address space, or reclaiming about 10 class Bs a day...
>>> 
> 
> 
>> There is, of course, a slightly different model:
>> 
> 
> 
>> As IPv4 address space becomes less freely available, there will be
>> an increase in black and gray market transactions for that address
>> space.  Since these transactions involve actual money instead of
>> the more difficult to account for human activity dealing with the
>> RIRs or ISPs, there will be financial incentive both to reduce
>> consumption as well as offer allocated but unused space via the
>> black and gray markets.
>> 
> 
> I'm not saying you're wrong (although the RIRs may do their best to
> stop the sale of address space, with unknown success), but I'm not
> sure this will make a huge difference.
> 
> There are currently both holders of big chunks of address space, and
> holders of small chunks of address space, as well as organizations
> that burn up massive amounts of address space and those that use up
> very little. I can easily see how it makes sense for the users of
> relatively small amounts of address space to purchase or lease it
> from holders of (largely) unused /8s. At $1 per address, buying a /24
> rather than jump through RIR hoops is probably a good deal for most
> people, while at $1 per address selling off your /8 is certainly
> worth the trouble.
> 
> However, I don't think the likes of Comcast (which received 3 /10s or
> 3/4 of a /8 this year, or more than $12 million worth at our
> speculated $1/addr) are going to want to spend this kind of money as
> long as there is ANY chance they can get addresses from the RIRs.
> 
> And then, think about it: how much money per address would you have
> to offer to someone with a spare /24 to part from those addresses?
> $1? $5? $10? I doubt the big ISPs that burn millions of addresses per
> year will be interested in that. Suddenly the transition to IPv6 (or
> recursive NAT...) is going to look very attractive.
> 
> So basically the tradeoffs between market forces and regular
> reclaming are similar: easy for /8s, hard for /16s and close to
> impossible for /24s.
> 
> And the real fun starts when people holding big blocks of address
> space start holding on to it because they expect to make more money
> that way in the future...
> 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: OMB: IPv6 by June 2008

[Daniel Golding]

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: [OT] network monitoring/visibility appliance

[Daniel Golding]

Just to ignore your wishes and reply on-list :)

Other folks may be interested. The general area is known as "route
analytics". The box you are talking about may be from Packet Design (the HP
solution is OEMed from them, I believe) or Ipsum networks. This is separate
from modeling and simulation tools like Cariden, Opnet, and Wandl which all
offer some greater or lesser degree of routing protocol support.

I believe the original idea for these boxes was to target service providers,
but enterprises are also quite interested in the field, especially with the
growth of RFC2547 VPNs. A box like this can help an enterprise keep track of
the BGP advertisements and any OSPF/EIGRP redistribution at their sites
(which can number in the thousands).

Sales of these products are pretty small now, but that may change. Imagine
doing data correlation between IGP (or BGP) convergence and dropped calls on
a softswitch across a few thousand sites.

My personal opinion is that questions about Internet/WAN technology vendors
on a _high_ level are perfectly appropriate for NANOG - at least as much as
"is xyz down?" :) More in-depth stuff ("how do I configure my GSR to dance
the lambada") belong on the appropriate NSP lists...

-- 
Daniel Golding


On 6/24/05 5:55 PM, "Aaron Glenn" <[EMAIL PROTECTED]> wrote:

> 
> I apologize for the off-topic post, but I'm at my wits end trying to
> "rediscover" a peice of equipment I came across a few months ago but
> some how lost the datasheet/bookmark too. The appliance was a standard
> 1U rackmount "pizzabox" that spoke a whole variety of protocols
> (IS-IS, BGP, OSPF, MPLS + TE, etc). Basically, the pitch was you
> plugged the box into your network, and it spat out a pretty map with
> all sorts of interesting information without having to poll (much). I
> realize there might be more than a few of these products, but I've
> somehow managed to avoid all of them in my search.
> 
> Please contact me offlist if you might be familiar with a/the device
> described above. Thanks
> 
> Regards,
> aaron.glenn

Re: [NON-OPERATIONAL] Re: NANOG Evolution

[Daniel Golding]

The PC has 16 seats. Finding eight qualified people will be doable. Finding
16 qualified people, capable of hitting the ground running, with a
conference 4 months in their future to plan, would be untenable. It takes a
non-trivial amount of time to recruit and organize that many folks. I'm not
crazy about this being written into the bylaws, but in practice, its the
most efficient approach and probably the one that would have been taken in
any case.

The other issue is, when looking at the current composition of the PC, there
are at least 8 qualified, dedicated people. The idea of moving the PC to a
be more representative of the operational and infrastructure community is a
good one. The PC has, in the past, been too heavily weighted towards vendors
and ex-Merit folks. Appointing 8 new folks will move the PC in the direction
that the community wants to take.

I don't think we should be worried about the "power" of the SC. Instead, we
should be concerned about being able to effect the necessary changes that
the community wants - a more representative PC, better talks on a wider and
more interesting range of topics, etc. Part of this will involve changed to
the mission of the PC...

- an expectation that each PC member will actively recruit/present/moderate
at least one quality session per conference.

- expanding the scope of presentations to include new (to us) topics such as
those related to providing VoIP services, hosting, access networks
(DSL/Broadband/Wireless), network security, MPLS VPN scalability and
interconnection issues, etc. I'd rather have a great talk on WiMax (IEEE
802.16-2000) than a bad talk on BGP any day.

- Finding ways to inject the material we've seen in recent BOFs into the
plenary or tracking sessions. The BOF material has been the most innovative
stuff due to a relative lack of oversight combined with a freer format.

- Maintaining and expanding the educational aspects of NANOG's mission
through tutorials and other sessions.

PC folks who are ok with this, old or new, will be able to contribute to and
lead this effort.

(BTW, for those responding or posting to this thread or others which are
similar, please include a "non-op" tag in the subject line so that folks who
don't want to read about political machinations can procmail us efficiently)

- Daniel Golding

On 6/21/05 3:03 AM, "Steve Gibbard" <[EMAIL PROTECTED]> wrote:

> On Mon, 20 Jun 2005, Hannigan, Martin wrote:
> 
>>>> Ultimately, the SC is elected to represent the membership and
>>>> carry out it's will and that should be uniformly actionable
>>>> across the board in order for the SC to be taken seriously
>>>> by the group and by Merit.
>>> 
>>> I'm not sure what you mean here.
>> 
>> It means that it doesn't make a lot of sense to handcuff
>> the SC out of the gate on a supposition that they will do
>> 'something bad' to the PC.
>> 
>> Anyhow, it's a window dressing handcuffing. Looks like anyone can be
>> removed with a 5 to 7 vote of the SC. You've all read the revised
>> Charter, top to bottom? Kind of makes 6.2.1 ceremonial. It should
>> be removed based on that alone.
> 
> As the charter is currently written, every future steering committee will
> be stuck with a specific half of the program committee, left over from the
> previous year.  The first steering committee gets to decide which of the
> current program committee members are in the half that they're stuck with,
> so they're much more powerful when it comes to program committee selection
> than any future steering committee will be.
> 
[snip] 
> -Steve

[NON-OPERATIONAL] Re: NANOG Evolution

[Daniel Golding]

Randy,

People's employers are posted at http://www.nanog.org/candidates05.html.

It gets a bit complicated because some folks work at "infrastructure"
companies - collocation/peering or DNS (Mark, Bill, Josh, Marty). Others do
significant consulting work for large providers or hosters, but aren't
actually employed by any of them at present (at least Steve and myself,
probably some others). It gets more fun because sometimes folks who work for
operators or hosters are actually researchers who don't do lots of
operational things (and other times, they are researchers who actually DO
lots of operational things).

I'd guess folks can look at the bios and figure it all out for themselves :)

- Dan

On 6/17/05 10:55 AM, "Randy Bush" <[EMAIL PROTECTED]> wrote:

> 
>> The candidates for the Steering Committee are:
>>Joe Abley
>>Randy Bush
>>Christopher Chin
>>Ron da Silva
>>Vince Fuller
>>Steve Gibbard
>>Dan Golding
>>Martin Hannigan
>>Dorian Kim
>>Mark Kosters
>>Jared Mauch
>>Chris Morrow
>>William B. Norton
>>Philip Smith
>>Josh Snowhorn
>>Dave Wodelet
>>Lixia Zhang
> 
> could you annotate which of these candidates actually work
> at an isp or large content provider?
> 
> randy
> 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: Micorsoft's Sender ID Authentication......?

[Daniel Golding]

Reputation is a missing element in all sender authentications schemes and
will (likely) be solved separately.

No approach is perfect, but building closer to a solution is preferred over
sitting on our hands and debating, which (historically) seems to be the
IETF's approach.

- Dan

On 6/8/05 12:37 AM, "John Levine" <[EMAIL PROTECTED]> wrote:

>> Yes, there was lots of teeth gnashing and screams of agony allegedly because
>> MS refused to license the technology on the terms that folks wanted. MS was
>> more than willing to let folks have it at no cost, they just weren't willing
>> to give the naysayer everything they wanted, so everyone went home.
>> 
>> (that is, of course, a biased assessment, but not an unfair one)
> 
> There were two problems with the patent license that the MS lawyers
> offered.  The first was that it reserved to them the right to stop
> granting new licenses, thereby pulling the rug out from under anyone
> who'd used licensed technology in a product, particularly an open
> source product.  The said they didn't plan to do that, but MS' lawyers
> adamantly refused to change that, so a lot of us concluded that if
> they thought the pull out the rug language was important, so did we.
> 
> The second problem was that the license was for two unpublished patent
> applications that they described in general terms.  When the
> applications were published (on a schedule known from the day they
> were filed), they turned out to cover vastly more than MS had ever
> said.  That left a bad taste in a lot of people's mouths.  See my blog
> entry at http://www.taugh.com/weblog/patapp.html
> 
>> In the mean time, nothing stops MS (and everyone else) from building
>> Sender-ID into their MTAs. SPF is a standard and Sender-ID utilized SPF
>> records to perform inbound phishing control based on PRA.
> 
> (Danger: operational content ahead.)
> 
> Sender-ID and SPF have serious practical problems.
> 
> The first is that they don't match the way that a lot of mail is
> really sent.  If all of your mail comes from a single set of servers,
> like if you're a big company or an ESP, then SPF or Sender-ID work
> reasonably well to tell people which mail is yours.  On the other
> hand, if you're a university who lets its graduates keep using their
> whatever.edu addresses after they graduate and forwards their mail to
> them, they doen't work at all.  (Other than a legalistic version of
> "work" in which you publish a useless SPF record saying that mail
> could come from anywhere.)
> 
> This would not be a problem except that SPF has been greatly oversold,
> the SPF community has not been particularly diligent in disabusing
> people of their misconceptions, and I can promise that the moment
> there is a Sender-ID checkbox in Exchange, clueless MCSEs will set it
> to reject anything that fails Sender-ID, it'll reject buckets of
> normal valid mail, and when people complain, they will insist that the
> mail must have been sent wrong because Sender-ID said it was spam.
> 
> Even for fixed senders, Sender-ID is useless against phishing, because
> it can only tell you that a message purporting to be from phoop.com
> came from a source that is OK for phoop.com, but it cannot tell you
> whether phoop.com is someone you want to get mail from.  This is a
> real problem.  For example, I got mail the other day from
> customercenter.net purporting to tell me about the status of my MBNA
> credit card, with a link to mbnanetaccess.com.  Was that a phish?  Or
> consider mbna-account.com and mbna-accounts.com.  One is MBNA, one is
> not.  Does your MUA know which one is which?  Spammers and phishers
> can publish SPF records just like anyone else, and Ciphertrust has
> said that of the mail they see that passes SPF, there's more spam
> than legit mail.
> 
> I am all in favor of sender authentication, if it's real sender
> authentication.  But Sender-ID isn't.  Domainkeys will be better since
> it matches mail sending patterns better, but it has the same problem
> that a sender that's been authenticated has nothing to do with whether
> its mail is desired.
> 
> Shameless plug: over in the anti-spam research group at asrg.sp.am I
> sure would like it if people were working on reputation systems to
> plug the gaping hole left by all these authentication schemes.
> 
> Regards,
> John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for
> Dummies",
> Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
> "More Wiener schnitzel, please", said Tom, revealingly.

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: Micorsoft's Sender ID Authentication......?

[Daniel Golding]

Yes, there was lots of teeth gnashing and screams of agony allegedly because
MS refused to license the technology on the terms that folks wanted. MS was
more than willing to let folks have it at no cost, they just weren't willing
to give the naysayer everything they wanted, so everyone went home.

(that is, of course, a biased assessment, but not an unfair one)

I'm not MS's biggest fan, but they are on the side of good, here.

In the mean time, nothing stops MS (and everyone else) from building
Sender-ID into their MTAs. SPF is a standard and Sender-ID utilized SPF
records to perform inbound phishing control based on PRA.

Presumably, SPF and Sender-ID checking on inbound mail would be enabled via
a checkbox of some sort.

I'd also like to see DomainKeys support in Exchange.

Ok, will all those who believe that MS, SPF, Sender-ID and/or DomainKeys are
the work of the devil, please commence flaming.

- Dan

On 6/7/05 1:58 PM, "Fergie (Paul Ferguson)" <[EMAIL PROTECTED]> wrote:

> 
> 
> Wasn't there a lot of turmoil within the IETF last year
> on sender authentication because Microsoft was trying to
> push it's own sender ID authetication mechasnisms as a
> draft standard?
> 
> Or maybe I'm confused...
> 
> Microsoft Adds Sender ID Anti-Spoofing Protocol To Exchange 2003 SP2
> http://www.techweb.com/wire/security/164301084
> 
> - ferg
> --
> "Fergie", a.k.a. Paul Ferguson
>  Engineering Architecture for the Internet
>  [EMAIL PROTECTED] or [EMAIL PROTECTED]
>  ferg's tech blog: http://fergdawg.blogspot.com/

Re: OT: NOC Display's

[Daniel Golding]

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: soBGP deployment

[Daniel Golding]

The thing we should keep in mind is that the problem set is really very
limited. Although I acknowledge Tony's cockpit door analogy, we live in the
world of today.

The most significant problem is hijacking of IP address space for various
purposes. That's it. Solve that in the SIMPLEST way possible, lets implement
it (because everyone sees the problem) than we can either iteratively
improve the solution or start working on the next solution.

Steve's attitude (and mine) is pretty close to universal amongst operators.
We don't need complexity to solve problems that aren't there. There has been
a bit of a historic issue with vendors and IETF folks (congruent sets, yes),
telling operators what their problems are and how to fix them. I won't
enumerate the various "problems". Hijacked IP address space is a real
problem. Simple solution please :)

- Dan

On 5/26/05 6:33 AM, "Todd Underwood" <[EMAIL PROTECTED]> wrote:

> 
> steve, tony, all,
> 
> just catching up.  trying to ignore the TOS fest but the soBGP thread
> actually is interesting.
> 
> On Wed, May 25, 2005 at 03:51:25PM -0700, Tony Li wrote:
> 
>>> And yet, in the nine or so years I've been working on network
>>> infrastructure stuff, spoofed BGP announcements have never been a major
>>> cause of problems for me.
>> 
>> That's what we can say so far.  Do you really want to wait until we have
>> a major problem?
> 
> i want to agree with tony here.  i find steve's attitude troubling and
> unfortunately common.  i hear about hijackings that cause *major*
> problems on a regular basis (several times per month) and i hear a lot
> of frustration from major *edge* ASes about the inability to do much
> about it.  in the past two years i've presented at least one, very
> interesting, high-profile hijacking at some public event (NOTA peering
> forum, S&D peering forum, LINX members meeting, nanog, etc) every 3
> months or so, and i'm not spending *any* time looking for them.
> 
> i also hear a lot of nonchalance on the part of transit and SP ASes
> about the problem.  and i can understand that.  because the current
> tools don't give you many options and the current customers want
> *cheap* and not *good*.  depressing but true.
> 
> i also hear steve's point about not making things work *less* well.
> if we've learned anything from the md5 debacle it is that it is easy
> to create a new vulnerability or attack vector while preventing a
> non-problem.  so it's prudent to be cautious.
> 
> but i would suggest that doing anything that could *delay* a *new*
> announcement on a *new* path is completely acceptable.  it's already
> happening now for edge ASes.  you get new space.  you contact your
> providers and peers and tell them to accept it.  they do the same
> thing.  and after a little while (usually more than a day but less
> than a week) the advertisements reach some plausible imitation of the
> "global" table and you call it good enough.
> 
> so why not seriously consider options that don't impact existing
> routes on existing paths, but make it more difficult to get a new
> prefix working on a never-before-seen origination path pattern?
> 
> like steve, i haven't yet formed an opnion on soBGP or sBGP (other
> than the fact that they've obviously been around for a while and
> obviously aren't being implemented by anyone yet).  so my comments are
> more general.
> 
> t.

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: Stanford Hack Exposes 10,000

[Daniel Golding]

People are missing the point a bit. Most schools HAVE switched over to new
numbering systems. Most student ID's have school-specific ID numbers. The
problems are:

1) Older student records are indexed by SSN and they must be retained.
2) Some information is still indexed by SSN out of necessity - student
financial aid for example

That means you have a translation database somewhere, with all those SSNs
and the new student index numbers.

SSNs are already forbidden going forward at pretty much all school. For
example, they can't be used to post grades. However, the need to retain them
for backwards compatibility remains. Education institutions need a clear set
of guidelines for handling sensitive data like that. A good start would be
that such data can only be stored in an encrypted format in a physically
secure facility. 

Yes, that seems obvious, but it doesn't happen. Considering the sort of free
wheeling environment prevalent in University networks, you would think they
would be a bastion of high security. Sadly, this isn't the case.

- Dan

On 5/26/05 6:10 AM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:

> 
>>> Around about whenever the US Federal Government gets the hint and
>>> passes a bill which makes it illegal to use social security numbers
>>> for any purpose other than the administration of social security.
> 
> Wrong answer. Federal laws do not stop people from doing stupid
> things and they do not stop people from doing illegal things.
> 
> What we need is a Hollywood blockbuster in which some highschool
> hackers wreak havoc by aquiring SSNs from gradesheets and using
> mother's maiden names to steal lots of money and identities.
> Then, pointy-haired bosses will ask their sysadmins to make sure
> that it can't happen in their department.
> 
> Hollywood movies change people's behavior. Federal laws do not.
> 
> --Michael Dillon
> 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: soBGP deployment

[Daniel Golding]

One correction: I shouldn't have said: "The RIRs are iffy". It should have
been "The IRRs are iffy". A world of difference.

I understand the limitations. However, no one is rushing to implement most
of the things that folks in this thread are obsessing over: DNSSec, IPV6,
sBGP, soBGP. 

A bizarre assertion was made that only a "few" are implementing SPF, which
is demonstrably untrue. Its getting implemented because its easy, not
because its complete. This obsession with perfection will (as usual) result
in exactly no progress. Folks need to be willing to get 70% of the benefit
for 10% of the effort.

- Dan

On 5/23/05 2:33 PM, "Edward Lewis" <[EMAIL PROTECTED]> wrote:

> At 14:00 -0400 5/23/05, Daniel Golding wrote:
> 
> My reply is mostly tongue-in-cheek.  I think it's always healthy to
> explore alternatives.
> 
>> Why not do something simple? The in-addr.arpa reverse delegation tree is
>> pretty accurate. We use it for lots of different things. Why not just give
>> IP address blocks a new RR (or use a TXT record) to identify ASN? This
>> solves the biggest problem we have right now, which is stealing of address
>> blocks. It requires little processor overhead, and only a few additional DNS
>> lookups. Its reasonably foolproof.
> 
> I'll ignore that you said "(or use a TXT record)". ;)
> 
> Without DNSSEC, what does this buy?  "Secure" information on a
> non-secure channel.
> 
> If, by "stealing addresses" you mean that the RIR records are
> changed, then changing the name servers is trivial - changing to
> servers that have the hijacker's preferred data (or none!).
> 
>> Why create reliance on more databases? The RIRs are iffy. We rely on DNS
>> right now. Why not keep relying on it? This solution doesn't solve all of
>> our problems, but it does help, its easy, and people will implement it.
> 
> Who populates the DNS (well, the .arpa domain)?  The RIRs do.
> 
>> Ok, please start flaming now :)
> 
> Brave to make such a request on a Monday afternoon.

Re: soBGP deployment

[Daniel Golding]

I suspect the right thing to do is to ask why soBGP and sBGP have failed?

And yes, they've failed. Just like DNSSec, we aren't seeing even limited
adoption. Why? Too complex, too many moving parts, too much reliance on iffy
third parties and requires mass adoption.

I suggest that the community finds something that gives us most of what we
want, is simple to understand, and can be implemented in a piece-wise
fashion. Look at SPF - not perfect, but certainly useful. It is simple, easy
to implement, and IS being implemented.

One of the Internetworking community's biggest problems is a fixation on the
perfect solution. Its natural - we're engineers, after all. We want an
elegant 100% solution to our ills. This often leads to something that never
gets implemented in real life.

Why not do something simple? The in-addr.arpa reverse delegation tree is
pretty accurate. We use it for lots of different things. Why not just give
IP address blocks a new RR (or use a TXT record) to identify ASN? This
solves the biggest problem we have right now, which is stealing of address
blocks. It requires little processor overhead, and only a few additional DNS
lookups. Its reasonably foolproof.

Why create reliance on more databases? The RIRs are iffy. We rely on DNS
right now. Why not keep relying on it? This solution doesn't solve all of
our problems, but it does help, its easy, and people will implement it.

Ok, please start flaming now :)

- Dan

On 5/23/05 1:45 PM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:

> 
> 
> for the old-timers this is not quite sBGP or soBGP, but does
> have many of the desirable traits  for the new kids on the block,
> if ISPs want to do this, its something they can do themselves, w/o
> centralized coordination, on an incremental basis.
> 
> http://www.isoc.org/inet98/proceedings/6h/6h_3.htm
> 
> --bill

Re: Port 25 - Blacklash

[Daniel Golding]

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.

CircleID, was: Re: Paul Wilson and Geoff Huston of APNIC on IP address allocation ITU v/s ICANN etc

[Daniel Golding]

On that note, I suggest that folks from the NANOG community get involved
with CircleID. Its a great site with articles on everything from DNS and
addressing issues to domain naming and ICANN. It sometimes misses the
network operator perspective - a few articles or comments by some of the
folks on this list would be very helpful (see Geoff and Suresh's
contributions for evidence of this)

Thanks,
Dan



On 4/25/05 9:36 PM, "Suresh Ramasubramanian" <[EMAIL PROTECTED]> wrote:

> 
> On 4/20/05, Suresh Ramasubramanian <[EMAIL PROTECTED]> wrote:
>> http://www.circleid.com/article/1045_0_1_0_C/
>> 
>> That's a must read article, I'd say.
> 
> Followup article by Paul Wilson -
> http://www.circleid.com/article.php?id=1049_0_1_0_C/
> The Geography of Internet Addressing

Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations

[Daniel Golding]

Aside from individual OS behavior, doesn't this seem like very bad advice?

What sort of DNS cache poisoning attack could possibly work against a
workstation that has a caching resolver but no DNS server? If a hacker
really wished to do a name resolution attack against workstations, wouldn't
they just write some spyware that injected a hosts file? Seems easier.

At any rate, wouldn't disabling caching/not paying attention to TTLs have a
truly adverse impact on the DNS infrastructure? What is the % difference in
incremental DNS server load between a host that obeys TTLs and one that not,
but makes a new query each time? A single host wouldn't have much impact -
how about a couple million?

Is there something I'm missing here that's motivating Yarden's advice?

- Dan



On 4/18/05 1:35 PM, "Chris Adams" <[EMAIL PROTECTED]> wrote:

> 
> Once upon a time, Patrick W. Gilmore <[EMAIL PROTECTED]> said:
>> Depends on what you call "caching".  Does honoring a TTL qualify as
>> caching?
> 
> What other kind of DNS caching is there?
> 
>> Can you imagine what would happen if every time anyone ever looked up
>> any hostname they sent out a DNS query?
> 
> That's what most Unix/Linux/*BSD boxes do unless they are running a
> local caching name service of some time (BIND, nscd, etc.).  I wasn't
> actually aware that Windows had a DNS cache service.

Re: Memory leak cause of Comcast DNS problems

[Daniel Golding]

Several of the servers that were down are not BIND, at least these:

prospero:~/Desktop/fpdns-0.9.1 dgold$ ./fpdns.pl 68.87.66.196
fingerprint (68.87.66.196, 68.87.66.196): Cisco CNR

I ran fpdns against them between outages. They now respond differently.

prospero:~/Desktop/fpdns-0.9.1 dgold$ ./fpdns.pl 68.87.66.196
fingerprint (68.87.66.196, 68.87.66.196):
q0r?1,IQUERY,0,0,1,1,0,0,REFUSED,0,0,0,0

These are the Comcast "national" DNS servers. (I am using plural, because
there are several reverse DNS entries for this IP address -
ns.cmc.co.denver.comcast.net and ns.inflow.pa.bo.comcast.net)

I wouldn't rush to blame BIND for this. For purposes of investigation, does
anyone have DNS servers from those periods of downtime other than the ones
above? Comcast is quite a patchwork, that's to the incomplete integrations
of MediaOne, AT&T Broadband, etc.

It would be interesting to see data on other DNS servers during the downtime
periods. Many folks on various forums were suggesting the use of ns1. And
ns2.level3. Of course, logic suggests that the vast majority of folks,
having no Internet access, could not have read the advice.



There have been three explanations given for the outage -

1) Upgrade issues
2) Memory leak/software issue
3) DDoS

There is also the possibility of some combination of the above. There are a
number of possible permutations.

- Dan

On 4/17/05 2:18 PM, "Steven M. Bellovin" <[EMAIL PROTECTED]> wrote:

> 
> In message <[EMAIL PROTECTED]>, "Fergie
> (Paul
>  Ferguson)" writes:
>> 
>> 
>> Not to my knowledge, or at least, none that has been
>> publicly acknowledged.
>> 
>>> From a Washington Post article yesterday (posted via Yahoo!
>> News), Comcast said that the problem manifested itself when
>> they were in the process of upgrading their DNS servers:
>> 
>> 
http://story.news.yahoo.com/news?tmpl=story&ncid=1212&e=3&u=/washpost/2005041>>
6
>> /tc_washpost/a56223_2005apr15&sid=96168964
>> 
> 
> 
> At least in my neighborhood, Comcast appears to be running BIND 9.2.4rc6
> 
> --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
> 
> 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: New Outage Hits Comcast Subscribers

[Daniel Golding]

I'm not complaining about it - heck, I use it.

I just wanted to point out that desktop DNS servers are a reality. Right
now, few folks use them. If ISP DNS server quality gets worse or there are a
few big outages, we may see desktop DNS usage climb. This may have
deleterious effects on the roots and TLD servers.

It might be interesting to pull query data on a root server and correlate it
with known dynamic IP address pools to spot a trend.

- Dan

On 4/15/05 9:54 AM, "Patrick W Gilmore" <[EMAIL PROTECTED]> wrote:

> 
> On Apr 15, 2005, at 8:59 AM, Daniel Golding wrote:
> 
>> Too late. Every Mac ships with a working version of BIND. Its not
>> enabled by
>> default, but it can be turned on with a few keystrokes.
> 
> Name a flavor of unix which doesn't?
> 
> And even if you can, name a flavor of unix which can't get it installed
> "with a few keystrokes [or mouse clicks]."
> 
> We want people to use unix, stop complaining when they do. :-)
> 
> Besides, the OSX named is well behaved in its default configuration (in
> my limited personal experience on my own laptops).

Re: New Outage Hits Comcast Subscribers

[Daniel Golding]

Jerry,

Too late. Every Mac ships with a working version of BIND. Its not enabled by
default, but it can be turned on with a few keystrokes.

If you take a look at the dslreports.com forums, there are numerous
complains about DNS performance from various DSL and cable modem users. I'm
not sure how reasonable these complains are. The usual solution from other
users is to install a piece of Windows software called "Treewalk" which will
magically cure their problems.

Guess what "Treewalk" is? Yep, its a freeware recursive DNS server (
http://ntcanuck.com/). I have no idea how well behaved it is, but its
getting deployed pretty widely on user's machines.

I also wonder how long it will be before home routers have DNS servers
built-in, with a switch to let users select between iterative queries of
their upstream's DNS and a normal recursive query. Has anyone seen this in
the consumer market?

- Dan

On 4/15/05 1:45 AM, "Jerry Pasker" <[EMAIL PROTECTED]> wrote:

> 
>> On Apr 15, 2005, at 1:13 AM, Jerry Pasker wrote:
>> 
>>> Jeff Cole wrote:
>>>> 
>>>> Run bind locally on your laptop. There's a Win32 version available
>>>> if you're not running some sort of Unix or Linux on there. It's
>>>> what I do as my ISP's DNS is wonky at times, as is $ork's as they
>>>> choose to use Active Directory for DNS.
>>> 
>>> For the sake of the root servers, I hope everyone doesn't start doing this.
>> 
>> Well configured laptops will not put that much pressure on the
>> roots.  A single misconfigured / broken recursive name server puts a
>> lot more pressure on the roots than lots of well-configured laptops.
>> 
>> I guess one could argue that the chance of misconfiguration go up as
>> the number of systems goes up.
>> 
>> --
>> TTFN,
>> patrick
> 
> I didn't say "I hope a few cluefull people don't do this."  I said "I
> hope _everyone_ doesn't start doing this."  Big difference.
> 
> For the sake of the net, I hope no one, not even a semi popular OS
> venduh, gets the idea to build a dns server in to their next OS some
> day.

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: OpenTransit (france telecom) depeers cogent

[Daniel Golding]

This is part of the game.

Party A depeers Party B. Party B has received 30 to 60 days notification.
That gives party B enough time to do one of two things.

1) They can ensure they have sufficient transit and/or peering with Party
A's customers to ensure that all packets will be delivered. They can make
sure that they are seeing all of A's routes through those other networks.
This is what's called "being good to your customers"

2) They can take the time to put measures in place to punish party A. Things
like route filters to make sure that the only places A gets B's routes are
through the (soon to be gone) direct peering. Things like canceling or
turning down enough transit so they can claim they CAN'T send the traffic
anywhere else. Things like filtering out A's routes from their upstream's
BGP feeds. This is called "try to inflict enough pain to effect a reversal"

#2 is the stand-off scenario. The next step is, will party B keep up their
fortress defense or go home? Will party A back down and turn the peering
back up? How long can party B go without their customers canceling?

Much of this depends on the relative size of A and B, as well as their
customer mixes. If party B is a small porn hoster and party A is a big
broadband ISP, then A has nothing to worry about - evidence suggests there
won't be many complaints. Customers will be upset, but they won't complain.

If party B is hosting something more socially acceptable (if equally
pointless) like fantasy football or a popular Everquest server, well, things
just got dicey for party A. Party A may just back down.

Game theory is fun, folks! With real money on the line, its also very
interesting.

- Dan

On 4/14/05 5:46 PM, "Stephen J. Wilcox" <[EMAIL PROTECTED]> wrote:

> 
> On Thu, 14 Apr 2005, Patrick W Gilmore wrote:
> 
>> 
>> On Apr 14, 2005, at 5:16 PM, Richard A Steenbergen wrote:
>> 
>>>> Surely FT's customers pay for access to Cogents network and vice
>>>> versa?
>>> 
>>> In such a case, FT has done its part by paying Sprint for full transit
>>> service. It is Cogent who is not accepting the route from their
>>> transit,
>>> and who intentionally does not carry the global routing table. If I
>>> put up
>>> a filter on my transit that says I will not accept routes from you
>>> unless
>>> you peer with me, should your customers leave you because I did this?
>>> Doesn't sound very fair to me. I guess it depends how important I am,
>>> doesn't it?
>> 
>> Is Cogent filtering the prefixes they get from Verio?  Or is Verio
>> filtering what they send to Cogent?  Does it matter?
>> 
>> I think you have a very good point - FT is buying full transit.  Cogent
>> is the one without full reachability.
>> 
>> Doesn't mean that FT didn't know this would be a problem when they took
>> the step, though.
> 
> Well, FT took the step as you say.. they are the instigator here.
> 
> But, they are in their right to do so and would have given proper written
> notice 
> to Cogent so this isnt as much a surprise to them as is being suggested
> either.
> 
> Steve
> 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: OpenTransit (france telecom) depeers cogent

[Daniel Golding]

This is a matter of human nature, I suppose. Everyone is terribly pleasant
when they hear what they want. The true test is what happens when folk hear
the "wrong" answer.

I've depeered and I've been depeered. I've seen folks on the receiving end
of bad peering news handle it with consummate professionalism. I've also
seen folks act like spoiled children, forgetting the fundamental rule of
peering: 

Peering is a business relationship. Peering is about meeting the mutual
business needs of two networks. Emotionalism , "hurt feelings", and actions
that violate the bounds of trust and the normal bounds of professionalism
have no place in internetwork peering.

Depeering is always a gamble and, as such, is to be generally avoided as
unnecessary risk. Given that, folks need to resist their urge to put black
hats on networks who decide that certain peering relationships have outlived
their usefulness. The true picture is always more complex than the spaghetti
western. 

If enough folks are actually interested, I'd be happy to do a talk at an
upcoming NANOG on depeering (methods, etiquette, likely outcomes, necessary
pre-action analysis). This might be good for a future peering track.

- Dan

On 4/14/05 1:38 PM, "Steve Gibbard" <[EMAIL PROTECTED]> wrote:

> 
>> On Thu, Apr 14, 2005 at 11:28:00AM -0400, [EMAIL PROTECTED] wrote:
> 
>>> in depeering. However, dealing with Cogent on peering matters is
>>> incredibly unpleasant. I can understand networks and peering
>>> coordinators feeling that it just isn't worth it.
> 
> Just for the record, I've dealt with Cogent's peering people on behalf of
> a few networks over the last two years, and in my experience they've been
> extremely pleasant to work with.
> 
> -Steve

Re: Vonage Hits ISP Resistance

[Daniel Golding]

On the attack, are we? Its a free market. If folks don't like what
unregulated, non-monopoly ISPs are doing, they can go elsewhere.

I dislike the moralizing. This is business, not a battle of good vs evil.

- Dan

On 3/30/05 7:51 PM, "Eric A. Hall" <[EMAIL PROTECTED]> wrote:

> 
> 
> On 3/30/2005 11:27 AM, Greg Boehnlein wrote:
>> On Wed, 30 Mar 2005, Fergie (Paul Ferguson) wrote:
>> 
>>> Intersting article on ISP issues regarding competitive
>>> VoIP services:
>>> 
>>> http://www.lightreading.com/document.asp?site=lightreading&doc_id=71020
>> 
>> Hmm.. I was quoted in it.
> 
> Oh good, maybe you can clarify some things:
> 
> | ³As much as I want to see VOIP survive and thrive, I also don't want
> | to bear the additional cost of my customers choosing to use a
> | competitor's VOIP service over my own,² says Greg Boehnlein, who
> | operates Cleveland, Ohio-based ISP N2Net.
> |
> | ³Without control of the last mile, we're screwed,² Boehnlein says,
> | ³which is why I can identify with Clearwire's decision and say
> | Œmore power to them¹.²
> 
> Do you also block NNTP so that customers have to use your servers?
> 
> And if some other service used higher cumulative bandwidth than VoIP (say,
> Apple's music service) and didn't ~reimburse you for the use of your
> network, would|do you block that service too? For that matter, do you
> block the various P2P systems that don't make money but that generate
> massive traffic?
> 
> What don't you plan on blocking exactly?

Re: phishing sites report - March/2005

[Daniel Golding]

And I appreciate Gadi's efforts. I hope they will soon be willing to make
this methodology public, as their work continues. And to take down some
phishing sites of course :)

- Dan

On 3/29/05 8:12 AM, "Gadi Evron" <[EMAIL PROTECTED]> wrote:

> We provided Daniel with all the information he requested in private, and
> even learned a thing or two. Others are always welcome to contact us.
> 
> Gadi.
> 

Re: phishing sites report - March/2005

[Daniel Golding]

Gadi,

This report isn't terribly useful without the IP addresses (or URLs) in
question. How could an ISP start investigating and/or null routing these
addresses without having the list?

I suppose I'm skeptical because some of those ASNs are not big content
hosters. Some are transit-only ASN's.

Also, if you are using WHOIS to check the IP addresses for their owner, how
are you correlating to ASN? Through an IRR? Or is there a route lookup
somewhere in the mix?

Even if you won't release full data (although I can't imagine why not), you
need to fully disclose the methodology. "Digested" is insufficient when ISPs
and hosters are being called out by name.

- Dan


On 3/28/05 2:19 PM, "Gadi Evron" <[EMAIL PROTECTED]> wrote:

> Daniel Golding wrote:
>> Forgive me for being skeptical, but...
> 
> I would prefer you being skeptical. Please don't take my word on any of
> this.
> 
>> How do you come up with these? Are these the direct upstream ISPs of the
> 
> These are the digested results from the reports sent to the malicious
> websites and phishing research and mitigation list.
> 
>> phishing sites or the next hop AS's from your test site?
> 
> Plainly put, these are the results you get when you feed the IP's of the
> hosting web sites to the Cymru whois.
> 
>> Is there a link to the original data?
> 
> Nope. We hope to release more data in our next reports. Please let us
> know what kind of data you'd like available. We'll do our best to
> provide it.
> 
> One of our main goals is public awareness, so we are very interested in
> feedback.
> If you have further questions on the process itself, I'd gladly direct
> you to the guy who actually does the data mining and statistics - but
> the list data itself is not open to the public.
> 
> Gadi.

Re: phishing sites report - March/2005

[Daniel Golding]

Forgive me for being skeptical, but...

How do you come up with these? Are these the direct upstream ISPs of the
phishing sites or the next hop AS's from your test site?

Is there a link to the original data?

- Dan

On 3/28/05 12:25 PM, "Gadi Evron" <[EMAIL PROTECTED]> wrote:

> 
> Below is a periodic public report from the Malicious Websites and
> Phishing research and mitigation mailing list (a sub-group of the drone
> armies / botnets research and mitigation mailing list).
> For this report it should be noted that we base our analysis on the data
> we have accumulated from various sources.
> 
> According to our incomplete analysis of information we have thus far, we
> now publish the following report.
> 
> Notes on the report:
> * The report is in descending order.
> * In the listing are also included suspected child pornography sites,
>however, their numbers are not large enough to effect the statistics.
> 
> 
> Number of phishing sites found: 276.
> 
> 
> The ISP's that are most often plagued with phishing sites:
> --
> ASN Responsible Party
> 14780   INKTOMI-LAWSON - Inktomi Corpo
> 14779
> 13768   PEER1 - Peer 1 Network Inc.
> 21844   THEPLANET-AS - THE PLANET
> 1668AOL-ATDN - AOL Transit Data Ne
> 4134CHINANET-BACKBONE No.31 Jin-ro
> 29761   OC3-NETWORKS-AS-NUMBER - OC3 N
> 27699   TELECOMUNICACOES DE SAO PAULO
> 15201   Universo Online Ltda.
> 
> * We would gladly like to establish a trusted relationship with
>these and any organizations to help them in the future (especially the
>attacked eCommerce sites and the hosting service providers).
> 
> * By previous requests here is an explanation of what "ASN" is, by Joe
>St Sauver:
>http://darkwing.uoregon.edu/~joe/one-pager-asn.pdf
> 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: "Bandwidth Advisors" - www.bandwidthadvisors.com

[Daniel Golding]

Tim,

I hope you're joking. "Extortion" means something pretty specific, legally.
There is absolutely no extortion going on here. The appropriate term is
"agency". Its a pretty widely used concept in the business world.

In terms of the integrity of Bandwidth Advisors or any other consultant -
its caveat emptor. The party buy such services is responsible for asking
about how the money flows and about vendor neutrality policies. The
consulting Terms and Conditions should clearly state who the consultant is
acting as an agent FOR - the carrier or the customer. This is just like Real
Estate - the Seller's Agent may seem very nice and even help you out, but
they work for the seller, not the buyer.

Selling IP transit or other telecommunications services is a business. One
of the great problems I've seen in the last ten or so years is that people
tend to forget this and take things way too personally or emotionally.

- Dan

On 3/24/05 7:29 PM, "Tim Pozar" <[EMAIL PROTECTED]> wrote:

> Hannigan, Martin wrote:
>> They're brokers. There's really nothing wrong with what they
>> are doing, although they may not have explained it to you too
>> well.
> 
> I guess not.
> 
>> What they do is become an agent, or reseller, for a company and
>> they get a residual on anyone they refer. So if you are a corp IT
>> guy and you have no clue as to who's out there and what the prices
>> are, these kinds of services "can" be useful. Almost everyone will
>> give someone a residual for a referral, but you have to ask. :-)
> 
> Brokers are one thing.  Consultants or "advisors" are another thing.  I
> don't see anything on their web site that labels them as "brokers".  I
> do see under their FAQ...
> 
> Q. How does Bandwidth Advisors get paid?
> 
> A. Bandwidth Advisors receives a small residual payment from the
>   Telcos once the Client begins paying for the service.
> 
> Nice to see it there.
> 
> I know a bunch of consultants out there (me being one, Bill Woodcock,
> etc.) that do not take money from vendors they recommend.  How can a
> client of a consultant really know they have the best deal when the
> "consultant" will not investigate all of the options out there?
> 
> For those that don't know... I am now the COO of UnitedLayer.  It sounds
> like, since I am not going to pay the "extortion" fee to Bandwidth
> Advisors, that their consultants won't know about our pricing and
> services.  Even if I did pay the fee, that means that their clients
> can't get the best deal as I need to raise my fees to client to cover
> the "small residual payment" going to "Bandwidth Advisors".
> 
> Tim

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: Who is watching the watchers?

[Daniel Golding]

Was it part of a plea agreement?!

Maybe this is like the FBI employing forgers and burglars to get advice on
stopping crime?

Well, probably not... :(

- Dan

On 2/24/05 9:30 AM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:

> 
> Former chief privacy officer of Gator has been appointed to the Data
> Privacy and Integrity Advisory Committee of the Department of Homeland
> Security.
> 
> http://www.salon.com/politics/war_room/2005/02/23/gator/index.html?source=RSS
> 
> 
> --Michael Dillon
> 

Re: Why do so few mail providers support Port 587?

[Daniel Golding]

On 2/15/05 9:36 PM, "Thor Lancelot Simon" <[EMAIL PROTECTED]> wrote:

> 
> On Wed, Feb 16, 2005 at 02:23:04AM +, Adrian Chadd wrote:
>> 
>> Quite useful when it works (read: the other party has implemented
>> AUTH-SMTP on port 587).
> 
> And if they's implemented unauthenticated SMTP on port 587, like,
> say, Sendmail, you've achieved nothing, or possibly worse, since you
> have encouraged people to simply run open relays on a different port
> than 25.  How long do you think it's going to take for spammers to
> take advantage of this?  (That's a rhetorical question: I already see
> spam engines trying to open port 587 connections in traces).
> 
> Slavishly changing ports isn't the solution.  Actually using authentication
> is the solution.  It is silly -- to say the least -- to confuse the benefits
> of the two.
> 
> Thor

Thor,

I don't think anyone is confusing the benefits. Sean's suggestion was quite
clear. Run SMTP-Auth on port 587 and leave port 25 for email from other mail
servers. There are lots of benefits to this approach.

For one thing, it eliminates a lot of the "reasons" for provider email
smarthosting, which needs to go away due to massive abuse. Sender email
authentication will make smarthosting obsolete and users will need a
different way of sending outgoing mail that isn't spam to their own mail
servers for legitimate relay. ISPs filter port 25 outbound, but leave 587
open with the idea that users would have to authenticate against distant
mail servers on that port. Everything works well.

587 running SMTP auth (and relaying for authenticated users) and port 25 for
local (non relay) delivery without authentication should be the default on
all servers. 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: Vonage complains about VoIP-blocking

[Daniel Golding]

Is there any move on the part of providers/manufacturers to use more secure
protocols for this?

- Dan

On 2/15/05 5:22 PM, "Jason L. Schwab" <[EMAIL PROTECTED]> wrote:

> 
> Hi;
> 
> I unplugged and reset my vonage Motorola MTA device, and it did tftp to
> home to get its configs.
> 
> -Jason
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Hannigan, Martin
> Sent: Tuesday, February 15, 2005 3:14 PM
> To: 'Jay Hennigan'
> Cc: Eric Gauthier; nanog@merit.edu
> Subject: RE: Vonage complains about VoIP-blocking
> 
> 
>> -Original Message-
>> From: Jay Hennigan [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, February 15, 2005 5:10 PM
>> To: Hannigan, Martin
>> Cc: Eric Gauthier; nanog@merit.edu
>> Subject: RE: Vonage complains about VoIP-blocking
>> 
>> 
>> On Tue, 15 Feb 2005, Hannigan, Martin wrote:
>> 
>>>> Something else to consider.  We block TFTP at our border for
>>>> security reasons
>>>> and we've found that this prevents Vonage from working.
>>>> Would this mean that
>>>> LEC's can't block TFTP?
>>> 
>>> 
>>> Was that a device trying to phone home and get it's configs?
>>> Cisco, Nortel, etc. phone home and get configs via tftp.
>>> 
>>> Vonage doesn't need to phone home for config. The device is
>>> programmed (router) and it registers with the call manager.
>>> If you analyze the transactions it's about 89% SIP and 11% SDP.
>> 
>> Vonage devices initiate an outbound TFTP connection back to Vonage to
>> snarf their configs on initial connection and also
>> (presumably) on reboot.
> 
> I tested the reboot. I didn't see it. I agree in general
> and think that providers shouldn't block tftp, IMHO.
> 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: Vonage complains about VoIP-blocking

[Daniel Golding]

I've gotten a couple emails on this. To summarize:

1) some malware uses tftp. However much malware now uses other ports, such
as 80

2) There are numerous buffer overflow bugs with tftp. This would seem to be
better resolved with rACLs or ACLs towards loopback/interface blocks. (and,
of course, turning tftp off and using scp or sftp)

It would be interesting to find out what percentage of Internet accessible
routers are remotely upgradable via TFTP presently. Sadly, this would be
non-zero...

- Dan

On 2/15/05 4:28 PM, "Rob Thomas" <[EMAIL PROTECTED]> wrote:

> Hi, Dan.
> 
> ] Why block TFTP at your borders? To keep people from loading new versions of
> ] IOS on your routers? ;)
> 
> Funny you should mention that.  :)  We have seen miscreants do exactly
> that.  They will upgrade or downgrade routers to support a feature set
> of their choosing.
> 
> A lot of malware uses TFTP to update itself as well.
> 
> Please note that I am NOT advocating the blocking of TFTP.
> 
> Thanks,
> Rob.

Re: White House may make NSA the 'traffic cop' over U.S. computer networks

[Daniel Golding]

Considering the fairly high quality security guides that have come out of
the NSA in recent years, this is probably the right choice.

- Dan

On 2/15/05 3:30 PM, "Fergie (Paul Ferguson)" <[EMAIL PROTECTED]> wrote:

> 
> 
> ...and following up on my last post, it would appear that the
> U.S. gummint is at least taking some action wrt U.S. gummint
> networks:
> 
> http://www.securityfocus.com/news/10494?ref=rss
> 
> Not leaping to any conclusions here, but it would illustrate
> that, at the very least, someone has concluded that the info-
> security posture needs to be approached a bit more seriously.
> 
> $.03,
> 
> - ferg
> 
> --
> "Fergie", a.k.a. Paul Ferguson
>  Engineering Architecture for the Internet
>  [EMAIL PROTECTED] or
>  [EMAIL PROTECTED]

Re: Vonage complains about VoIP-blocking

[Daniel Golding]

Why block TFTP at your borders? To keep people from loading new versions of
IOS on your routers? ;)

Not trying to be flippant, but what's the basis for this?

- Dan

On 2/15/05 1:45 PM, "Eric Gauthier" <[EMAIL PROTECTED]> wrote:

> 
>>> On Tue, Feb 15, 2005 at 11:53:59AM -0600, Adi Linden wrote:
 How is this any different then blocking port 25 or managing the bandwidth
 certain applications use.
> 
> Something else to consider.  We block TFTP at our border for security reasons
> and we've found that this prevents Vonage from working.  Would this mean that
> LEC's can't block TFTP?
> 
> Eric :)

Old McDonald Had a Pharm?!

[Daniel Golding]

There have been a couple recent articles about a phenomenon allegedly known
as "pharming", which people are supposedly worried about. This includes some
combination of DNS cache poisoning and/or worm-powered URL rewriting.

This may also be a form of "fear-driven marketing" by companies inventing
solutions to "fix" the problem which may not exist. (Mac Anti-virus
software, anyone? ;)

Is anyone aware of actual "pharming" in the wild? Please reply off-list and
I will summarize answers to the list.

Thanks,
-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: Vonage complains about VoIP-blocking

[Daniel Golding]

Anyone know which rural LECs might be involved?

I find it interesting that it isnt an MSO or RBOC doing the blocking -
perhaps the greater lawyer:engineer ratio at those organizations prevents
it?

The other interesting aspect is that there seems to be a bit of a
persecution complex on the part of some VoIP providers. Of course, even
paranoids have enemies, as they say :)

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group


On 2/15/05 1:22 PM, "Majdi Abbas" <[EMAIL PROTECTED]> wrote:

> 
> On Tue, Feb 15, 2005 at 11:53:59AM -0600, Adi Linden wrote:
>> How is this any different then blocking port 25 or managing the bandwidth
>> certain applications use.
> 
> If the article is correct, and the ISP involved is also a LEC, then
> it would be pretty clearly anticompetitive, and the LECs have some legal
> obligations to provide access to their customers.
> 
> I don't think any such restriction would also apply to a
> normal ISP, but that could change.  We'll see.
> 
> --msa

Those interested in NANOG governance, please read...

[Daniel Golding]

I'd like to remind everyone of the Sunday evening meeting at the upcoming
NANOG conference in Las Vegas. Everyone who has an interest in how NANOG is
administered, be it the mailing list or conferences, should attend.
Participation is vital in making the community's voice heard. If you think
the status-quo is ok or if you would like to see some changes made,
participation will ensure that your voice is heard.

A phone bridge and IRC-cast are being worked on now. More information on
these should be available by the end of the week.

Also, please take a chance to visit http://www.nanog-reform.org. If you
agree with the contents, please endorse it by "signing".

Thanks. We will now return to our regularly scheduled thread, which seems to
be intent on convincing people to violate their NDA's with a major network
equipment vendor :)

Thanks,
Daniel Golding

FW: Graphing Peering

[Daniel Golding]

Additional information on MAC accounting from Hakan Lindholm...

(specifically, the SNMPv2c object to pull 64bit MAC accounting counters)

- Dan

-- Forwarded Message
From: Hakan Lindholm <[EMAIL PROTECTED]>
Date: Fri, 21 Jan 2005 20:36:45 +0100 (CET)
To: Daniel Golding <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>, andrew matthews <[EMAIL PROTECTED]>
Subject: Re: Graphing Peering

I'm not registerred to post on nanog.
You may send this info in, with or without quoting me..

On Thu, 20 Jan 2005, Daniel Golding wrote:

>
> Andrew,
>
> The 32 bit counters are a significant problem when using gigabit ethernet
> public peering interfaces. Needless to say, MAC accounting was not designed
> for gigabit speeds. Frequent polling is, sadly the only solution. If you
> write your own scripts, make sure to account for counter wrapping.

What about the .1.3.6.1.4.1.9.9.84.1.2.3.1.2 tree?
Remeber to use SNMPv2c.

We use the following to generate some MRTG config:


while (!$session->{ErrorStr} and
$$vars[0]->tag eq "ipNetToMediaNetAddress"){

 if ($type eq "dynamic") {

 @mac = split(/:/, $mac);
 $decmac = join('.', hex $mac[0], hex $mac[1], hex $mac[2], hex
$mac[3], hex $mac[4], hex $mac[5]);
 ($iname, @junk) = gethostbyaddr( pack( "C4", split( "\\.", $ip )),
AF_INET );

 if (-z $iname) {$iname = $ip};
 if (!defined($peers{$ip})) {$peers{$ip} = "no BGP peer"};

 $ifi = $ix{$router}[1];

 print "\n";
 print "Target\[$ip\]:
1.3.6.1.4.1.9.9.84.1.2.3.1.2.$ifi.1.$decmac\&1.3.6.1.4.1.9.9.84.1.2.3.1.2.$i
fi.2.$decmac:[EMAIL PROTECTED]:2\n",

 "MaxBytes\[$ip\]: 2500\n",
 "Title\[$ip\]: $ix{$router}[0]: $peers{$ip}\n",
 "PageTop\[$ip\]: $ix{$router}[0]: $peers{$ip}\n",
 "\tIP: $ip, DNS: ", $iname, "\n";
 }
 ($ip,$mac,$type) = $session->getnext($vars);
};

(This is only part of the script.  You should make it work in your
environment quite easy though.)


> - Dan
>
> on 1/20/05 9:45 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
>>
>> On Wed, 2005-01-19 at 22:41, andrew matthews wrote:

>> Another problem you might run into is counter wrapping. When polling
>> every 5 minutes, some counters may wrap. (there is no 64 bit counter for
>> the mac-address accounting). So you have to run it in short timeframes,
>> causing more cpu utilization.

Talking about Cisco, see above.  There is such counters.


>> But all in all, mac-accounting and Netflow source-as give you a very
>> good overview of your network flows.

Yes indeed.

/H

-- End of Forwarded Message

Re: Graphing Peering

[Daniel Golding]

Andrew,

The 32 bit counters are a significant problem when using gigabit ethernet
public peering interfaces. Needless to say, MAC accounting was not designed
for gigabit speeds. Frequent polling is, sadly the only solution. If you
write your own scripts, make sure to account for counter wrapping.

- Dan

on 1/20/05 9:45 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> 
> On Wed, 2005-01-19 at 22:41, andrew matthews wrote:
>> Anyone have any suggestions on graphing peering on a cisco router? I'm
>> using mrtg and i did mac address accounting but the numbers are off.
> 
> 
> off in what sense? We use mac-accounting, snmp nad mrtg to graph per
> peer utilization. The following script is helpful
> 
> http://www.thiscow.com/dl/bgp-peers-1.5.pl
> 
> I reworked it to spit out the AS number instead of the ip address. The
> issue you then have is that multiple sessions with one As number all
> show as the same target. Which MRTG does not like. You can fix that as
> well of course in the script. And it does not "autoscan", which means
> that if people change their mac-address, you lose the data, until you
> rerun the script.
> 
> Another problem you might run into is counter wrapping. When polling
> every 5 minutes, some counters may wrap. (there is no 64 bit counter for
> the mac-address accounting). So you have to run it in short timeframes,
> causing more cpu utilization.
> 
> But all in all, mac-accounting and Netflow source-as give you a very
> good overview of your network flows.
> 
> Frank 
> 

Re: Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19

[Daniel Golding]

Is there an RFC or other standards document that clearly states that static
bogon filter lists are a bad idea? While this seems like common sense, there
was just an RFC published on why IP addresses for specific purposes (like
NTP) shouldn't be encoded into hardware.

Using a dynamic feed needs to be codified so that it finds its way into
training classes, documentation, etc. Otherwise, this problem will recur
indefinitely.

- Dan 

On 1/20/05 10:18 AM, "Fergie (Paul Ferguson)" <[EMAIL PROTECTED]> wrote:

> 
> 
> 
> ...and it's not like ARIN, etc., does not announce to the
> Internet community when it allocates from address space
> which may have previously been listed in various operational
> places as "bogon" or "unalloacted" -- they do.
> 
> I recall seeing similar announcements on the list from time
> to time, suggesting due diligence on ARIN's behalf to notifying
> people to modify their filtering. *plonk*
> 
> Scanning the archives, an example:
> 
> http://www.merit.edu/mail.archives/nanog/2004-01/msg00374.html
> 
> - ferg
> 
> 
> -- Jared Mauch <[EMAIL PROTECTED]> wrote:
> 
> This hurts Ciscos reputation that they are causing
> pockets of the internet to not work.  Next subnets to get allocated
> will increase the size of those pockets and so on.  Then the internet
> will become less reliable as an end-to-end transport medium, hurting
> *everyone*.
> 
> --
> "Fergie", a.k.a. Paul Ferguson
>  Engineering Architecture for the Internet
>  [EMAIL PROTECTED] or
>  [EMAIL PROTECTED]

Re: Graphing Peering

[Daniel Golding]

Andrew's issue is this - he's got an Ethernet port on a public peering
switch with a bunch of peers. He can see the interface stats just fine but
he's having trouble figuring out how much traffic is going to (or coming
from) each peer. One interface, many peers, confusing problem. There isn't
one VLAN per peer on most public peering switches - its one big Ethernet
segment with each peer getting an IP out of a common subnet. Welcome to the
world of broadcast multi-access peering.

The classical way to do this is mac accounting. This can be pretty rough -
its not really useful for anything more than a ratio, from what I've seen -
the numbers tend to not add up properly.

Another possibility (on Cisco) is using BGP Policy Accounting, although
support can be spotty depending on hardware.

For other platforms, there's some good information here:
http://www.switch.ch/misc/leinen/snmp/monitoring/bucket-accounting.html

The link on that page for Juniper's Destination Class Usage (DCU) is broken.
Try this one instead:
http://www.juniper.net/techpubs/software/junos/junos70/swconfig70-interfaces
/html/interfaces-family-config25.html

- Dan


On 1/19/05 5:56 PM, "Bill Nash" <[EMAIL PROTECTED]> wrote:

> 
> 
> If you're already using MRTG, hopefully you're at least passingly familiar
> with perl and SNMP. If so, you can do some hackery to identify your BGP
> peer interfaces automatically and then use it to reference existing
> interface graphs.
> 
> Take a peek in the BGP4 mib, specifically at the BgpPeerEntry subtree. You
> may need to do some correlation inside the ifTable or maybe even ifX,
> depending on platform and implementation, to correctly identify the
> interface of your peer.
> 
> - billn
> 
> 
> On Wed, 19 Jan 2005, andrew matthews wrote:
> 
>> 
>> no i mean graph bgp sessions...
>> 
>> it's a single interface, and i want to graph every bgp session so i
>> can see how much traffic i'm doing between each peer.
>> 
>> 
>> On Wed, 19 Jan 2005 22:25:37 + (GMT), Stephen J. Wilcox
>> <[EMAIL PROTECTED]> wrote:
>>> On Wed, 19 Jan 2005, andrew matthews wrote:
>>> 
>>>> Anyone have any suggestions on graphing peering on a cisco router? I'm
>>>> using mrtg and i did mac address accounting but the numbers are off.
>>> 
>>> do you mean how to graph traffic to each host on a lan..?
>>> 
>>> what platform do you have?
>>> 
>>> Steve
>>> 
>>> 
>> 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: Proper authentication model

[Daniel Golding]

On 1/12/05 12:05 PM, "Joe Abley" <[EMAIL PROTECTED]> wrote:

> 
> 
> On 12 Jan 2005, at 11:53, Hannigan, Martin wrote:
> 
>>> You mean you'd *request* a different path from different providers.
>> 
>> Provisioning a circuit from two different ^providers^, other than
>> your OC3 provider.
> 
> I realise that's what you meant.
> 
> My point was that competing, differently-named and
> organisationally-separate suppliers of network services frequently use
> common suppliers for metro fibre, long-haul transport, building access,
> etc. Just because you buy different services from different providers
> doesn't mean there will be no common points of failure.
> 
> 
> Joe
> 
Fate sharing is bad. The only way to be sure you aren't fate sharing is to
request GIS data from the carriers. And even that could be wrong...

- Dan
-- 

Re: Proper authentication model

[Daniel Golding]

On 1/12/05 8:46 AM, "Erik Haagsman" <[EMAIL PROTECTED]> wrote:

> 
> On Wed, 2005-01-12 at 12:37, David Gethings wrote:
>> On Wed, 2005-01-12 at 12:25 +0100, Iljitsch van Beijnum wrote:
>>> IPv6 is also very useful in providing non-IPv4 management.
>> Well if we're offering protocols other than IP(v4) for OOB management
>> then might I chip in with MPLS?
> 
> What ever happened to simple ISND or analogue dial-up with a small
> router or modem attached...? Not very hi-tech en often quite slow, but
> usually suffices for emergency maintenance and prolly as far apart from
> the operational network as possible (provided your not using
> transmission from the same telco that supplies the phone lines that is
> ;-)
> 

The biggest problem I've seen with dial-up OOB is reliability. You really
need you really need to have a good series of testing scripts to ensure that
all the phone lines are working, modems have reset properly, serial ports
are ok, etc. Without this, reliability is low.

- Dan

Re: Cisco 2611XM as cheap border router

[Daniel Golding]

It would be fairly useful if Cisco had a published document that detailed
the minimum configuration for each major router line to support BGP with 1
to 4 full views. Of course, this would have to be periodically updated. By
this, I mean a separate overlay document for their entire router product
line. This would be very helpful to operators and integrators who get asked
about minimum configurations fairly frequently...

(I'm only picking on Cisco because they are 1) big and 2) have routers that
support BGP but don't have enough memory for full tables)

- Dan

On 1/11/05 12:21 PM, "Rodney Dunn" <[EMAIL PROTECTED]> wrote:

> 
> This will not work for full routes.
> The memory upgrade is utilized for larger
> IOS images with new features.
> 
> An update to the product bulletin is
> in the works to clarify it.
> 
> Further specific questions in regards to
> the memory can be moved over to the
> cisco-nsp alias.
> 
> Rodney
> 
> On Tue, Jan 11, 2005 at 07:39:49AM +0200, Mark Bojara wrote:
>> Hello people of nanog :)
>> 
>> Ive been doing some reading up and I see that that 2600 series is now
>> supporting 256MB of memory. Do you guys think this router could handle
>> 3/4 peers a QoS setup (RSVP or something)?
>> 
>> http://www.cisco.com/en/US/products/hw/routers/ps259/products_qanda_item0900a
>> ecd800f71dd.shtml
>> 
>> Regards
>> Mark
>> 

Re: Proper authentication model

[Daniel Golding]

Kim,

Its terribly important that your routers' management traffic be encrypted
all the way to the device. For this reason, the best practice is to use
ssh2. There are some other hacks that can be used, but they are hacks, and
are not scalable.

Bastion hosts are a good thing and can be a great place to put in checks for
multi-factor authentication (another must-have), but they do not replace the
need for end-to-end encryption. Turn off telnet and web administration
today.

While you are at it, look at your SNMP setup. You want your SNMP management
to have the same characteristics as your vty management - strong
authentication and encryption. Cleartext community strings don't cut it, as
an example. 

Also, you need a secure Out of Band management network.

You may want to check out the NSP-Security mail list.

- Dan


On 1/11/05 4:17 AM, "Kim Onnel" <[EMAIL PROTECTED]> wrote:

> 
> Hello,
> I'd like everyones 2 cents on the BCP for network management of an ISP
> PoPs, with a non-security oriented NOC,
> 
> Most of my routers doesnt have crypto IOS images,
> couldnt agree with core members to do a major upgrade, just a promise
> of doign that when other needs to an IOS upgrade come up,
> So i need to workaround it and secure management traffic somehow,
> 
> Usually the NOC logs to the PoPs 24x7, so i definitely need to hit a
> balance between encryption/security and usability,
> thats why i excluded OTP,
> 
> My homework concluded:
> 
> 1) Establishing an ipsec tunnel from each NOC Pc to a VPN
> concentrator, and of course on every PC, there would be static routes
> injected to take management traffic through the tunnel,
> 
> Major advantage is usability and transperancy to the user,
> One major pitfall here is when ipsec tunnels break, my presence would
> be needed to troubleshoot that,
> 
> 2) An OpenBSD bastion host(s), where the NOC would ssh in, get
> authenticated from TACACS+ or ssh certs, and then just telnet from
> there all day,
> 
> One major advantage here is the heavy monitoring/limiting i can do on
> a *nix box, systrace their login shell to a policy
> (telnet/ping/traceroute only)
> 
> 3) Or just an IOS based bastion router that also runs ssh,
> 
> 
> This has the advantage of IOS limitations in a way, not much
> maintaining is needed but being limited with 16 vtys is a problem,
> also vtys may get stuck and all these ssh sessions would kill the
> memory of the router,
> 
> I would of course have multiple setups one at the Datacenter, another
> at some PoP, redundant solutions incase one fails,
> 
> and For the record, I do run rancid, syslogging and we do AAA, so its
> just down to whats others experiences/ideas about secure management?

Re: soliciting agenda topics for the sunday night meeting

[Daniel Golding]

The (many) authors of the NANOG-Reform proposal would like to put out this
brief clarification to address some concerns from the community...



Clarification: There has been concern that this proposal would limit NANOG
mailing list reading/posting privileges or meeting attendance privileges.
This is not the case. The only benefit of "membership" would be the ability
to vote for the Board. List posting and conference attendance would remain
as they are: to operators, vendors, academics, enterprise users, and any
other interested party.

Additionally, there has been concern that this proposal seeks to narrow the
definition of "on-topic" for NANOG-L. In fact, the reverse is closer to the
truth. The shift from Merit to community moderation is intended to lighten
the hand of the moderator. All topics of general interest to the
Internetworking community would be considered on-topic. Any further
clarification would come from the elected BoD's, which would act in
accordance with the wishes of the community. It is the desire of this
document's authors that "warnings", "suspensions" and other such punitive
actions would be unnecessary (or, at the least, extremely rare), following
such a transition.

Lastly, readers should remember that this proposal is a working document and
not a standard or set of bylaws. As such, its very much open to debate and
discussion. If the community desires a more open standard for "membership",
than it can be opened up, provided there is a reasonable way to define the
constituency for election purposes.



(this will also be posted to the web site)

Please remember to check out www.nanog-reform.org.

Thanks,
Dan

On 1/10/05 2:40 PM, "Paul Vixie" <[EMAIL PROTECTED]> wrote:

> 
> here's the updated agenda, with three changes.
> 
> 1. added betty burke's presentation.
> 2. added adjournment.
> 3. added webcast/concall.
> 
> --
> 
> introduction   martin hannigan   5 minutes
> & paul vixie
> (moderators)
> 
> overview of history betty burke 15 minutes
> & history structure
> of NANOG
> 
> program committee steve feldman   20 minutes
> overview
> 
> "reform proposal" dan golding (et al)  15 minutes
> http://nanog-reform.org/
> 
> adjournment paul vixie  5 minutes
> (& directions  & martin hannigan
> to the hotel bar) (moderators)
> 
> Q&A and discussion will follow each presentation, with moderation but
> without specific time limits set in advance.  (Q&A and open discussion
> will take most of the time of this meeting.)
> 
> a webcast or one-way speakerphone will be made available, and there
> will be an IRC channel with local note takers for possible remote Q&A.
> 
> --
> 
> and as before...
> 
>>> anybody else got anything else?  send to martin, myself, both of us, or
>>> the nanog@ mailing list if you want to put something on the sunday night
>>> agenda.

Re: Weekly Routing Table Report

[Daniel Golding]

How much has the second number changed? Is this the result of worsening
aggregation or simply more address space being advertised?

Core routers won't even blink at 200k routes. I wonder how many enterprise
3x00/7x00 routers will fall over due to memory issues.

Also,  as we have learned previously, past routing table growth (especially
for a short period) is an extremely poor predictor of future growth.

- Dan

On 1/7/05 3:02 PM, "Joe Maimon" <[EMAIL PROTECTED]> wrote:

> 
> 
> 
> Routing Table Analysis wrote:
> 
>> This is an automated weekly mailing describing the state of the Internet
>> Routing Table as seen from APNIC's router in Japan.
>> Daily listings are sent to [EMAIL PROTECTED]
>> 
>> If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>.
>> 
>> Routing Table Report   04:00 +10GMT Sat 08 Jan, 2005
>> 
>> Analysis Summary
>> 
>> 
>> BGP routing table entries examined:  153319
>>Prefixes after maximum aggregation:   89967
>> 
>>  
>> 
> Should it matter that in six months its gone from 140k to 153k?
> At this rate it might crack 200k in less than two years.
> 

Re: soliciting agenda topics for the sunday night meeting

[Daniel Golding]

Just as a clarification - the "et al" in golding-et-al is pretty important.
I'm just the face man - we had a very large group of folks who put
significant effort into a proposal to improve NANOG. Please take some time
to look at the list of people involved - a great cross-section of long-time
NANOG participants, hosts, speakers and sponsors. In addition to the (long)
list of authors, input was received from at least 15 other folks.

Also, keep in mind that this was designed as a strawman, a proposal, not as
a set of bylaws. These are concepts that the authors hope to get a larger
consensus behind. 

Thanks,
Dan

On 1/7/05 12:02 PM, "Paul Vixie" <[EMAIL PROTECTED]> wrote:

> 
> here's the updated agenda, with two changes.
> 
> 1. added steve feldman's talk.
> 2. added URL for golding-et-al (as provided by golding-et-al).
> 
> --
> 
> introduction   martin hannigan   5 minutes
> & paul vixie
> (moderators)
> 
> program committe steve feldman   20 minutes
> overview
> 
> "reform proposal" dan golding (et al)  15 minutes
> http://nanog-reform.org/
> 
> Q&A and discussion will follow each presentation, with moderation
> but without specific time limits set in advance.
> 
> --
> 
> and as before...
> 
>> anybody else got anything else?  send to martin, myself, both of us, or
>> the nanog@ mailing list if you want to put something on the sunday night
>> agenda.
> 
> (steve feldman clarified that he's speaking not moderating.)
> 
> (we've not heard yet whether betty or susan from merit will also be speaking.)
> --
> paul vixie
> martin hannigan
> (moderators)

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group