Re: the O(N^2) problem

[Steven M. Bellovin]

The risk in a reputation system is collusion.

Re: Dubai impound ships suspected in cable damage

[Steven M. Bellovin]

On Tue, 8 Apr 2008 19:31:47 -0400 (EDT)
Sean Donelan <[EMAIL PROTECTED]> wrote:

> 
> 
> Wow, civilian satellite images are getting very sharp.
> 
> http://www.hindu.com/2008/04/07/stories/2008040759181200.htm
> 
> Using satellite images of ship movements in the area, Reliance
> Globalcom identified two ships in the area at the time which
> may have damaged the cable.
> 
> Reliance also confirmed the cable was damaged because of "jerks and
> force of the ship."
> 
Thanks.  I wish, though, the article had said *which* cable cuts those
ships were responsible for -- remember that Egyptian authorities had
said that their videos showed no ships off Alexandria.

There's a bit more at
http://web20.telecomtv.com/pages/?newsid=42942&id=e9381817-0593-417a-8639-c4c53e2a2a10&view=news


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Any tool or theorical method on detecting number of computer behind a NAT box?

[Steven M. Bellovin]

On Mon, 7 Apr 2008 23:51:55 +0800 (CST)
Joe Shen <[EMAIL PROTECTED]> wrote:

> 
> hi,
> 
>Sharing internet access bandwidth between multiple
> computers is common today. 
> 
>Usually, bandwidth sharer bought a little router
> with NAT/PAT function. After connecting that box to a
> ADSL/LAN access link, multiple computer could share a
> single access link.
> 
>I heard some company provide prdouct for detecting
> number of computers behind NAT/PAT box. 
> 
>Is there any paper or document on how such product
> work? where could I fint them ?
> 
THere was a paper of mine from a few years ago:
http://www.cs.columbia.edu/~smb/papers/fnat.pdf


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Superfast internet may replace world wide web

[Steven M. Bellovin]

On Mon, 7 Apr 2008 08:24:54 -0700 (PDT)
Lucy Lynch <[EMAIL PROTECTED]> wrote:

> 
> On Mon, 7 Apr 2008, Bill Woodcock wrote:
> 
> >
> >  On Mon, 7 Apr 2008, Glen Kent wrote:
> >> says the solemn headline of Telegraph.
> >> .. and we in Nanog are still discussing IPv6! ;-)
> >
> > It's because we don't have a hadron demolition derby to power our
> > American interwebs:
> >
> >"The power of the grid will be unlocked this summer with the
> > switching on of the Large Hadron Collider (LHC)."
> >
> 
> http://xkcd.com/401/
> 
Also http://ars.userfriendly.org/cartoons/?id=20080330 and
http://ars.userfriendly.org/cartoons/?id=20080406


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)

[Steven M. Bellovin]

On Sat, 5 Apr 2008 01:02:24 -0400
"Christopher Morrow" <[EMAIL PROTECTED]> wrote:

> 
> On Fri, Apr 4, 2008 at 9:51 PM, Paul Vixie <[EMAIL PROTECTED]> wrote:
> 
> >  (i'd hate to think that everybody would have to buy
> > roberts' (anagran's) Fast Flow Technology at every node of their
> > network to make this work.  that doesn't sound "inexpensive" to me.
> 
> I suppose he could try to sell it... and people with larger networks
> could see if keeping state on a few million active flows per device is
> 'expensive' or 'inexpensive'. Perhaps it's less expensive than it
> seems as though it would.
> 
> Oh, will this be in linecard RAM? main-cpu-RAM? calculated on
> ASIC/port or overall for the whole box/system? How about deconflicting
> overlapping ip-space (darn that mpls!!!) what about asymmetric flows?
> 
> I had thought the flow-routing thing was a dead end subject long ago?
> 
And you can't get high speeds with Ethernet; you get too many
collisions.  Besides, it doesn't have any fairness properties.
Clearly, you need token ring.

Oh yeah, they fixed those.

I have no idea if it's economically feasible or not -- technology and
costs change, and just because something wasn't possible 5 years ago
doesn't mean it isn't possible today.

It does strike me that any such scheme would be implemented on access
routers, not backbone routers, for lots of good and sufficient
reasons.  That alone makes it more feasible.

I also note that many people are using NetFlow, which shares some of
the same properties as this scheme.

As for the need -- well, it does deal with the BitTorrent problem,
assuming that that is indeed a problem.

Bottom line: I have no idea if it makes any economic sense, but I'm not
willing to rule it out without analysis.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Nanog 43/CBX -- Hotel codes etc

[Steven M. Bellovin]

On Fri, 4 Apr 2008 17:21:41 -0400
"David Diaz" <[EMAIL PROTECTED]> wrote:

> TIPS:
> New York is a wonderful city, however, as with any large city travel
> safely
> -Do not use your iPod white ear pieces. Especially on the
> subway at night
> -Travel in groups or with a local
> -Know where you are going ahead of time so you do not need to keep
> the map open
> -Using your laptop on the train at night and storing it in a big
> laptop bag that says LAPTOP or FORUM on it is a no-no
> -DO NOT go to the wonderful local Apple Store and walk around the
> city with that white APPLE bag full of iPhones
> -Stay on the main streets not the allays especially off-Broadway
> -Car services from the hotel are flat rates and very cost effective.
> 
> It's a very safe city for the last decade but travel smartly and
> enjoy.
> 
I think you're contradicting yourself here...

Anyway -- I regard most of those warnings as quite overblown.  I mean,
on lots of subway cars you stand out more if you don't have white
earbuds in, probably attached to iPhones.  Midtown is very safe.  Your
laptop bag doesn't have to say "laptop" on it to be recognized as such,
but there are so many other people with laptop bags that you won't stand
out if you have one.  Subway crime?  The average daily ridership is
about 5,000,000; there are on average 9 felonies a day on the whole
system. To quote a city police official I met, that makes the subways
by far the safest city in the world.

Yes, you're probably at more risk if you look like a tourist.  But there
are lots of ways to do that, like waiting for a "walk" sign before
crossing the street...  (Visiting Tokyo last month was quite a shock to
my system; I had to unlearn all sorts of things.)

Enjoy the city and don't worry about crime.  The real danger is not
remembering that you never have the right of way anywhere, unless you
take it...  (I currently live in a neighborhood that ~20 years ago, I
probably wouldn't have dared to visit.  But the city is safer now than
it's been in at least 40 years.)

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: latency (was: RE: cooling door)

[Steven M. Bellovin]

On 30 Mar 2008 21:00:25 +
Paul Vixie <[EMAIL PROTECTED]> wrote:

> 
> [EMAIL PROTECTED] ("Buhrmaster, Gary") writes:
> 
> > > ... feed "tcp throughput equation" into your favorite search
> > > engine for a lot more references.=20
> > 
> > There has been a lot of work in some OS stacks
> > (Vista and recent linux kernels) to enable TCP
> > auto-tuning (of one form or another), ...
> 
> on
> 
> i'd read that freebsd 7 also has some tcp auto tuning logic.

There are certain things that the stack can do, like auto-adjusting the
window size, tuning retransmission intervals, etc.  But other problem
are at the application layer, as you noted a few posts ago.

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: latency (was: RE: cooling door)

[Steven M. Bellovin]

On Sun, 30 Mar 2008 13:03:18 +0800
Adrian Chadd <[EMAIL PROTECTED]> wrote:
 
> Oh, and kernel hz tickers can have similar effects on network
> traffic, if the application does dumb stuff. If you're (un)lucky then
> you may see 1 or 2ms of delay between packet input and scheduling
> processing. This doesn't matter so much over 250ms + latent links but
> matters on 0.1ms - 1ms latent links.
> 
> (Can someone please apply some science to this and publish best
> practices please?)
> 
There's been a lot of work done on TCP throughput.  Roughly speaking,
and holding everything else constant, throughput is linear in the round
trip time.  That is, if you double the RTT -- even from .1 ms to .2 ms
-- you halve the throughput on (large) file transfers.  See
http://www.slac.stanford.edu/comp/net/wan-mon/thru-vs-loss.html for one
summary; feed "tcp throughput equation" into your favorite search
engine for a lot more references.  Another good reference is RFC 3448,
which relates throughput to packet size (also a linear factor, but if
serialization delay is significant then increasing the packet size will
increase the RTT), packet loss rate, the TCP retransmission timeout
(which can be approximated as 4x the RTT), and the number of packets
acknowledged by a single TCP acknowledgement.

On top of that, there are lots of application issues, as a number of
people have pointed out.

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Mitigating HTTP DDoS attacks?

[Steven M. Bellovin]

On Mon, 24 Mar 2008 23:13:25 -0400
"Rodrick Brown" <[EMAIL PROTECTED]> wrote:

> 
> They're a few companies that specialize in "DDOS protection type
> services" one company that comes to mind is Prolexic and their  IPN
> infrastructure protection service. Prolexic will basically absorbs all
> attacks filter out the bad data and then deliver clean traffic back to
> your network. Its completly transparent to you're clients. Its not
> cheap but i've worked with a few internet based trading companies who
> used this service to litigate DDOS attacks on their network
> infrastructure.
> 
Prolexic was indicted about 1.5 years ago for aiding gambling sites:

http://www.infoworld.com/article/06/11/15/HNnyillegalonlinegambling_1.html
http://www.firstamendment.com/media/NYQCIndictment.pdf

Does anyone know if the indictment has been dropped?  (It should be.)
A quick poke around their site didn't show any news items saying that.

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: YouTube IP Hijacking

[Steven M. Bellovin]

On Mon, 25 Feb 2008 01:49:51 -0500 (EST)
Sean Donelan <[EMAIL PROTECTED]> wrote:

> 
> On Mon, 25 Feb 2008, Steven M. Bellovin wrote:
> > How about state-of-the-art routing security?
> 
> The problem is what is the actual trust model?
> 
> Are you trusting some authority to not be malicious or never make a 
> mistake?
> 
> There are several answers to the malicious problem.
> 
> There are fewer answers to never making a mistake problem.
> 
> The state of the art routing security proposals let the "trusted"
> securely make mistakes.  At one time or another, I think every router
> vendor, every ASN operator, every RIR, and so on has made a mistake
> at some time.
> 
> Yeah, I know some of those mistakes may have actually been malicious,
> but so far the mistakes have outnumbered the malicious.
> 
> If someone comes up with the anti-mistake routing protocol ...

Right.  Everyone makes mistakes, but not everyone is malicious.And
the RIRs and the big ISPs are *generally* more clueful than the little
guys and the newcomers.  Note also that secured BGP limits the kinds
of mistakes people can make.  If I have a certificate from my RIR for
192.0.2.0/24, I can't neither announce 10.0.0.0/8 nor delegate it to
you, no matter how badly I type.  Secured BGP still strikes me as a net
win.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: YouTube IP Hijacking

[Steven M. Bellovin]

On Sun, 24 Feb 2008 20:42:51 -0500
"Patrick W. Gilmore" <[EMAIL PROTECTED]> wrote:

> > 4: With state of the art security and operations.
> 
> I think we agree, but I wouldn't have said it like that.
> 

How about state-of-the-art routing security?

Seriously -- a number of us have been warning that this could happen.
More precisely, we've been warning that this could happen *again*; we
all know about many older incidents, from the barely noticed to the very
noisy.  (AS 7007, anyone?)  Something like S-BGP will stop this cold.

Yes, I know there are serious deployment and operational issues.  The
question is this: when is the pain from routing incidents great enough
that we're forced to act?  It would have been nice to have done
something before this, since now all the world's script kiddies have
seen what can be done.

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: A couple or advanced references...

[Steven M. Bellovin]

On Tue, 19 Feb 2008 06:27:52 GMT
"Paul Ferguson" <[EMAIL PROTECTED]> wrote:
 
> And thirdly is a figure that some folks may already be aware of; the
> fact that identity theft was the number one source of consumer
> fraud complaints submitted to the U.S. Federal Trade Commission
> in 2007.
> 
> According to the agency's yearly report on fraud complaints for
> 2007, of 813,899 total complaints received in 2007, 258,427, or
> 32 percent, were related to identity theft:
> 
> http://www.ftc.gov/opa/2008/02/fraud.pdf
> 
> According to the FTC, total consumer fraud losses totaled $1.2
> billion, with the average monetary loss for an individual at
> $349.
> 
> Credit card fraud was the most common form of reported identity
> theft at 23 percent, followed by utilities fraud at 18 percent,
> employment fraud at 14 percent, and bank fraud at 13 percent.
> 
Right, but that may or may not have anything to do with the Internet;
see http://www.schneier.com/blog/archives/2007/11/identity_theft_6.html
(among many others).


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Blackberry List

[Steven M. Bellovin]

On Mon, 11 Feb 2008 14:15:20 -0800
"Justin Pauler - Lists" <[EMAIL PROTECTED]> wrote:

> Hello everyone...
>  
> I realize this isn't the right forum for this, so, does anyone have a
> Blackberry list that has discussions much like what we do here? Even
> better, that might have information or alerts for when there are
> issues? I'm seeing an issue right now where phones from two
> independant providers have not recieved updates from two independant
> BES servers since 2:30 PM CST (that's now about 2 1/2 hours). Justin

From the Wall Street Journal:

A widespread service outage hit BlackBerry users Monday
afternoon. AT&T said it has been told by Research In Motion
that the problem is with RIM's infrastructure, and is
affecting all wireless carriers in North America. The
disruption follows an outage last April that left millions
of customers without email access.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Abandoned ship anchor found at FALCON cable cut

[Steven M. Bellovin]

On Thu, 7 Feb 2008 15:29:38 -0500
"Jason Seemann" <[EMAIL PROTECTED]> wrote:

> Thats exactly what they want you to think!

No, it's perfectly legitimate.  It's the anchor from the USS Jimmy
Carter...  (Nuclear submarines do indeed have anchors; see
http://boomer.user-services.com/drydock/990313-12-675.html )  It had
to leave in a hurry when the cable repair ship showed up, so its anchor
was left behind



> 
> On Feb 7, 2008 2:50 PM, Rod Beck <[EMAIL PROTECTED]>
> wrote:
> 
> >  Doesn't sound like sabotage to me. In fact, it sounds like bad
> > luck.
> >
> > Roderick S. Beck
> > Director of European Sales
> > Hibernia Atlantic
> > 1, Passage du Chantier, 75012 Paris
> > http://www.hiberniaatlantic.com
> > Wireless: 1-212-444-8829.
> > Landline: 33-1-4346-3209.
> > French Wireless: 33-6-14-33-48-97.
> > AOL Messenger: GlobalBandwidth
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > ``Unthinking respect for authority is the greatest enemy of truth.''
> > Albert Einstein.
> >
> >
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED] on behalf of Sean Donelan
> > Sent: Thu 2/7/2008 4:48 PM
> > To: nanog@merit.edu
> > Subject: Abandoned ship anchor found at FALCON cable cut
> >
> >
> >
> > The repair ship arrived on site between UAE and Oman, recovered
> > the an end of the cable for splicing.  It also found a 5-6 tonnes
> > ship anchor abandoned near the cable cut.
> >
> > http://www.flagtelecom.com/index.cfm?channel=4328&NewsID=27493
> >
> >
> >
> >



--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Fourth cable damaged in Middle Eest (Qatar to UAE)

[Steven M. Bellovin]

On Tue, 05 Feb 2008 10:11:13 -0600
Frank Coluccio <[EMAIL PROTECTED]> wrote:

> 
> Today's MIT Technology Review newsletter contains an article by John
> Borland, aided in large part by Tim Strong of Telegeography Research,
> covering the recent spate of submarine cable failures in the ME:
> 
> Analyzing the Internet Collapse
> By John Borland | Feb 5, 2008
> MIT Technology Review
> 
> Multiple fiber cuts to undersea cables show the fragility of the
> Internet at its choke points.
> 
> http://www.technologyreview.com/Infotech/20152/?nlid=854
>

Good article; thanks.  My own summary is at
http://www.cs.columbia.edu/~smb/blog/2008-02/2008-02-04.html


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Fourth cable damaged in Middle Eest (Qatar to UAE)

[Steven M. Bellovin]

On Sun, 3 Feb 2008 22:56:39 -0500 (EST)
Sean Donelan <[EMAIL PROTECTED]> wrote:

> 
> 
> Caution: upon further research it appears there may be some language
> misscommunication in some of the reports; and some of the outages may
> be multiple reports of the same incidents.
> 
> 
> 
> http://www.khaleejtimes.com/DisplayArticle.asp?xfile=data/theuae/2008/February/theuae_February115.xml§ion=theuae
>Confirming international media reports, an Etisalat official
> yesterday told Khaleej Times that the cable network was not
> completely severed, though the damage slowed down the already
> affected system. He did not give any further details regarding the
> cause of damage. [...]
>This is the third incident of its kind in the area since January 30
>since the cables were first damaged in the Mediterranean and then
> off the coast of Dubai, causing widespread disruption to Internet and
>international telephone services in Egypt, Gulf Arab states and
> south Asia.
> 
> FLAG restoration update information:
> http://www.flagtelecom.com/media/PDF_files/Submarine%20Cable%20Cut%20Update%20Bulletin%20Release%20030208.pdf
> 

http://www.telegeography.com/cu/article.php?article_id=21567&email=html
is probably as authoritative a source as one can find for what
happened.  It says there were two cuts in the Mediterranean (SEA-ME-WE 4
near Marseille) and Flag Telecom's Europe-Asia cable near Alexandria.
The Flag Telecom Falcon cable was cut between UAE and Oman, and the
Qatar-UAE cable failed due to a power issue.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Sicily to Egypt undersea cable disruption

[Steven M. Bellovin]

On Fri, 1 Feb 2008 23:07:16 -
"Rod Beck" <[EMAIL PROTECTED]> wrote:

> Hi Steve, 
> 
> TransAtlantic cables average three repairs a year. That's the
> industry average. So given 7 high capacity cable systems, that's 21
> repairs a year. 
> 
> Now, not all damaged cables go out of service. In fact, most stay in
> service until the repair begins. 
> 
> But the public rarely hears about a TransAtlantic cable going dark.
> Yet it does happen quite regularly in the business. 
> 
> Why? Because there are seven very high capacity (multi-terabit)
> systems to route traffic across! There is no need to announce to the
> public that a cable been cut. 
> 
> That is not the case in the Midterranean or the Persian Gulf. 
> 
> You have only a few systems (relatively low capacity) serving a huge
> population. In fact, I suspect Flag is probably the sole provider for
> many of these countries. 
> 
> So yes, when the only guy in town falls down, it's going to be
> noticed. 
> 
I hope you're right.  As I noted, by profession I'm paranoid.  I've
even contemplated the uses of deliberate cable cuts; see
http://www.cs.columbia.edu/~smb/papers/reroute.pdf for some thoughts
from five years ago.

But I hope you're right.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Sicily to Egypt undersea cable disruption

[Steven M. Bellovin]

On Fri, 1 Feb 2008 22:42:02 -
"Rod Beck" <[EMAIL PROTECTED]> wrote:

> Well, when you have all these cables running through narrow straits
> or converging to the same stretch of beach, it does not strike me as
> at all extraordinary.  
> 
But they aren't near each other.
http://www.nytimes.com/2008/01/31/business/worldbusiness/31cable.html
says that the first two cuts were in the Mediterranean, near Marseille
and Alexandria; the third was in the Persian Gulf, near Dubai
(http://www.nytimes.com/aponline/technology/AP-Internet-Outages.html).


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption

[Steven M. Bellovin]

On Fri, 1 Feb 2008 14:21:00 -0800
"Scott Francis" <[EMAIL PROTECTED]> wrote:

> 
> On Feb 1, 2008 6:37 AM, Suresh Ramasubramanian <[EMAIL PROTECTED]>
> wrote:
> >
> > http://www.marketwatch.com/news/story/third-undersea-cable-reportedly-cut/story.aspx?guid={1AAB2A79-E983-4E0E-BC39-68A120DC16D9}
> >
> >  "We had another cut today between Dubai and Muscat three hours
> > back. The cable was about 80G capacity, it had telephone, Internet
> > data, everything," one Flag official, who declined to be named,
> > told Zawya Dow Jones.
> > The cable, known as Falcon, delivers services to countries in the
> > Mediterranean and Gulf region, he added.
> 
> this (3 undersea cables in about a week, serving the same geographic
> area, with two of the cuts happening on the same day!) is leaving the
> realm of improbability and approaching the realm of conspiracy ...
> 
> (either that, or the backhoe operators' union has decided there's
> better money to be made on water than on land.)

Yah.  I'm a security guy, and hence suspicious by nature -- our slogan
is "Paranoia is our Profession" -- and I'm getting very concerned.  The
old saying comes to mind: "once is happenstance, twice is coincidence,
but the third time is enemy action".  The alternative some common mode
failure -- perhaps the storm others have noted.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption

[Steven M. Bellovin]

There's an interesting article at
http://www.nytimes.com/aponline/technology/AP-Internet-Outages-Cables.html
on cable chokepoints.

Re: Sicily to Egypt undersea cable disruption

[Steven M. Bellovin]

On Thu, 31 Jan 2008 13:20:07 -
"Rod Beck" <[EMAIL PROTECTED]> wrote:

> Cables are mostly damaged by fishing in coastal areas (continental
> shelf) or by deep undersea currents that erode the polyurethane
> jacket that protects them. So it is crucial that the cable be buried
> at least one meter and preferably two meters in coastal waters. The
> big fishing boats scrape sea floor -  the ecological equivalent of
> surface or 'strip' mining. These boats scrap the ocean floor and can
> hit the cables or even sever them.  
> 
In some areas, shark bites are a threat, too -- see
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel1/48/1267/00029600.pdf
(subscription required for the full text), or
http://www.tscm.com/phone/oceanic_cable.html


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Sicily to Egypt undersea cable disruption

[Steven M. Bellovin]

Today's NY Times reports that the problem was caused by two
near-simultaneous cable failures:
http://www.nytimes.com/2008/01/31/business/worldbusiness/31cable.html

Re: request for help w/ ATT and terminology

[Steven M. Bellovin]

On Thu, 17 Jan 2008 17:35:30 -0500
[EMAIL PROTECTED] wrote:

> On Thu, 17 Jan 2008 21:29:37 GMT, "Steven M. Bellovin" said:
> 
> > You don't always want to rely on the DNS for things like firewalls
> > and ACLs.  DNS responses can be spoofed, the servers may not be
> > available, etc.  (For some reason, I'm assuming that DNSsec isn't
> > being used...)
> 
> Been there, done that, plus enough other "stupid DNS tricks" and
> "stupid /etc/host tricks" to get me a fair supply of stories best
> told over a pitcher of Guinness down at the Undergroud..

I prefer nice, hoppy ales to Guiness, but either works for stories..
> 
> *Choosing* to hardcode rather than use DNS is one thing.  *Having* to
> hardcode because the gear is "too stupid" (as Joe Greco put it) is
> however "Caveat emptor" no matter how you slice it...
> 
Mostly.  I could make a strong case that some security gear shouldn't
let you do the wrong thing.  (OTOH, my preferred interface would do the
DNS look-up at config time, and ask you to confirm the retrieved
addresses.)  You can even do that look-up on a protected net in some
cases.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: request for help w/ ATT and terminology

[Steven M. Bellovin]

On Thu, 17 Jan 2008 15:45:24 -0500
[EMAIL PROTECTED] wrote:

> On Thu, 17 Jan 2008 09:15:30 CST, Joe Greco said:
> > make this a killer.  That could include things such as firewall
> > rules/ACL's, recursion DNS server addresses, VPN adapters, VoIP
> > equipment with stacks too stupid to do DNS, etc.
> 
> I'll admit that fixing up /etc/resolv.conf and whatever the Windows
> equivalent is can be a pain - but for the rest of it, if you bought
> gear that's too stupid to do DNS, I have to agree with Leigh's
> comment: "Caveat emptor".
> 
You don't always want to rely on the DNS for things like firewalls and
ACLs.  DNS responses can be spoofed, the servers may not be available,
etc.  (For some reason, I'm assuming that DNSsec isn't being used...)


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: ISPs slowing P2P traffic...

[Steven M. Bellovin]

On Wed, 9 Jan 2008 21:54:55 -0600
"Frank Bulk - iNAME" <[EMAIL PROTECTED]> wrote:

> 
> I'm not aware of any modern cable modems that operate at 10 Mbps.
> Not that they couldn't set it at that speed, but AFAIK, they're all
> 10/100 ports.
> 
Yup.  I've measured >11M bps on file transfers from my office to my
house, over Comcast.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: v6 subnet size for DSL & leased line customers

[Steven M. Bellovin]

On Sat, 22 Dec 2007 12:29:54 +0900
Randy Bush <[EMAIL PROTECTED]> wrote:

> 
> simon, there are a million chances.  and we are notoriously bad at
> predicting any of them more than a year or so out.
> 
In general, you're right.  But we have ~60 years of experience teaching
us that *every* successful computer architecture runs out of address
space.  I see no reason to think that today's models for home address
space will be the exception (unless, of course, IPv6 is unsuccessful,
but in that case it doesn't matter much what we do for allocation
policy unless our actions are sufficiently stupid to cause the failure).

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: v6 subnet size for DSL & leased line customers

[Steven M. Bellovin]

On Fri, 21 Dec 2007 08:48:35 -0600 (CST)
Joe Greco <[EMAIL PROTECTED]> wrote:

> I keep coming to the conclusion that an end-user can be made to work
> on a /64, even though a /56 is probably a better choice.

A /56 is definitely better.  Of course, I used to have 4 LANs just in
my house (wired, wireless, VPN to employer, "teen-net" to which certain
users were consigned for violation of the house AUP...).  I suspect
there are others on this list with more than that, today.

Sure, we're power users.  We're also talking about technology that's
been around for a while.  If all of my lights were controlled over the
net, I'd probably want a separate subnet for that, for access control.
I might want a separate subnet for environmental controls, because
access problems there can result in physical damage.  I really need to
set up a VPN for remote access to the house.

To quote a line from a science fiction book I'm fond of, "no artificial
shortages!"



--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Using RIR info to determine geographic location...

[Steven M. Bellovin]

On Fri, 21 Dec 2007 02:13:17 +
Greg Skinner <[EMAIL PROTECTED]> wrote:

> 
> Personally, I have trouble accepting some of the claims the
> geotargeting companies have made, such as Quova's 99.9% to the country
> level, and 95% to the US state level.  ( More info at
> http://www.quova.com/page.php?id=132 ) Perhaps I'm just part of the
> outlying data; using the "three top search engines" I rarely see them
> get the city correct (ie. where *I* am physically located, as opposed
> to where the registration data says the block is located), and have
> seen some glaring errors for the country in some cases.
> 
> Geotargeting has turned into quite a business, and I'm concerned that
> people who rely on these services do not fully understand the risks.
> 
Some folks are relying on it for serious purposes.  Many Internet
gambling sites use it to avoid serving US customers, for example.
Their risk is criminal liability for the executive -- the have a
strong incentive to get reliable data...  Some sports media sites use it
to enforce local area blackouts; though that doesn't need to be
perfect, if it's too imperfect they risk breach of contract and
expensive lawsuits.

For the advertisers, best effort is probably good enough...

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: European ISP enables IPv6 for all?

[Steven M. Bellovin]

On Tue, 18 Dec 2007 12:14:52 +0100
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:

> On 18 dec 2007, at 6:37, Steven M. Bellovin wrote:
> 
> > In a slightly more realistic vein, a huge address space makes life
> > harder for scanning worms.  As Angelos Keromytis, Bill Cheswick,
> > and I have pointed out, "harder" is by no means equivalent to
> > "impossible", but the myth, new as it is, still propagates.
> 
> I'd say that the huge address space makes life impossible for
> scanning worms.

Right, by simple arithmetic.
> 
> That doesn't mean that there can be no successful scanning at all
> with IPv6, but it needs to be highly targeted if you want results the
> same year, so just pumping random numbers in the destination address
> field like SQL slammer did so successfully doesn't cut it in IPv6.

See http://www.cs.columbia.edu/~smb/papers/v6worms.pdf


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: European ISP enables IPv6 for all?

[Steven M. Bellovin]

On Mon, 17 Dec 2007 15:29:21 -0800
"Christopher Morrow" <[EMAIL PROTECTED]> wrote:

> how does it improve data security exactly?
> 
Back in 1994, it was expected to be true because v6 would mandate
IPsec, and v6 would be deployed long before the installed base of v4
machines would be upgraded to IPsec.  Obviously, that's not what
happened; while IPsec was indeed late in coming, v6 was even later, so
the original belief has been OBE.  The mythos, however, hasn't caught
up.  Similar statements can be made about stateless autoconfig vs. v4
DHCP.

In a slightly more realistic vein, a huge address space makes life
harder for scanning worms.  As Angelos Keromytis, Bill Cheswick, and I
have pointed out, "harder" is by no means equivalent to "impossible",
but the myth, new as it is, still propagates.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: US Provisioned GSM cards abroad... SSL Issues?

[Steven M. Bellovin]

On Wed, 14 Nov 2007 09:05:32 -0800
"Mike Lyon" <[EMAIL PROTECTED]> wrote:

> 
> Curious. Has anyone on the list here ever encountered issues while
> traveling in EMEA accessing SSL websites back in the states while
> using an ATT/Cingular GSM data card? We are seeing some issues with
> this and were curious to see if anyone else is seeing the same issue.
> 
> Any insight would be appreciated.
> 
Do you have a tcptraceroute?  Might some "helpful", "transparent" proxy
be getting in your way?  (You don't say anything about what your issues
are.)


--Steve Bellovin, http://www.cs.columbia.edu/~smb

local routing problem...

[Steven M. Bellovin]

Somewhat OT, but this audience will appreciate it more than most.  This
item appeared in RISKS Digest.


Date: Mon, 5 Nov 2007 09:55:50 +0100
From: Stefan Alfredsson <[EMAIL PROTECTED]>
Subject: Cellphone in USB charger became default route

His cellphone charger was broken, so 17 year old Christoffer connected
his phone, a Sony Ericsson k800i, via USB to his parents computer and
left it to charge over night.

A month later, he got a bill of SEK 6911  (about USD $1100).

It turns out that the phone became the "default broadband" when plugged
in via USB, and his long-running downloads were done over the phone
instead of his broadband connection. The common price per Mbyte
GPRS/UMTS data traffic is SEK 10 to 15 (about USD $1.5 to $2.3), which
would correspond to about 500 Mbyte downloaded data.

Christoffer claims "there was no warning to allow the phone to take
over the connection. I did not even know it was possible".  According
to the operator Tele2, he must pay the bill even if it was a mistake.
They concluded that the phone modem had been used, but could not tell
how it happened. The operator were not aware of previous incidents, but
claims that "there is software to link the phone to the computer and
start the phone Internet function, but it's not possible for the
computer to do this on its own".

Original article in Swedish:
  http://www.aftonbladet.se/goteborg/article1141706.ab

Re: Hey, SiteFinder is back, again...

[Steven M. Bellovin]

On Mon, 5 Nov 2007 23:46:08 -0800
"Christopher Morrow" <[EMAIL PROTECTED]> wrote:

> 
> On 11/5/07, Eliot Lear <[EMAIL PROTECTED]> wrote:
> 
> >
> > Cough.  So, how much is that NXDOMAIN worth to you?
> 
> So, here's the problem really... NXDOMAIN is being judged as a
> 'problem'. It's really only a 'problem' for a small number of
> APPLICATIONS on the Internet. One could even argue that in a
> web-browser the 'is nxdomain a problem' is still up to the browser to
> decide how best to answer the USER of that browser/application. Many,
> many applications expect dns to be the honest broker, to let them know
> if something exists or not and they make their minds up for the upper
> layer protocols accordingly.
> 
> DNS is fundamentally a basic plumbing bit of the Internet. There are
> things built around it operating sanely and according to generally
> accepted standards. Switching a behavior because you believe it to be
> 'better' for a large and non-coherent population is guaranteed to
> raise at least your support costs, if not your customer-base's ire.
> Assuming that all the world is a web-browser is at the very least
> naive and at worst wantonly/knowingly destructive/malfeasant.
> 
> MarkA and others have stated: "Just run a cache-resolver on your local
> LAN/HOST/NET", except that's not within the means of
> joe-random-sixpack, nor is it within the abilities of many
> enterprise/SMB folks, talking from experience chatting up misbehaving
> enterprise/banking/SMB customers first hand. What's to keep the ISP
> from answering: provider-server.com when they ask for Yahoo.com or
> Google.com or akamai-deployed-server.com aside from (perhaps) a threat
> of lawyers calling?

Hey -- I can so run a cache/resolver...

More seriously: you're right; most people can't and won't.  But a
majority of customers in that space are using small NATs.  Those
certainly can; in fact, they often do.  It's just that today, they
simply talk to their upstreams, rather than starting from the root and
going down.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Hey, SiteFinder is back, again...

[Steven M. Bellovin]

On Mon, 5 Nov 2007 11:17:29 -0800
David Conrad <[EMAIL PROTECTED]> wrote:

> On Nov 5, 2007, at 8:23 AM, David Lesher wrote:
> > What affect will Allegedly Secure DNS have on such provider
> > hijackings, both of DNS and crammed-in content?
> 
> If what Verizon is doing is rewriting NXDOMAIN at their caching
> servers, DNSSEC will _not_ help.  Caching servers do the validation
> and the insertion of the search engine IP addresses in the response
> would occur after the validation.
> 
Depends on whether or not the endpoints delegate DNSSEC validation to
Verizon.  They don't have to.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Hey, SiteFinder is back, again...

[Steven M. Bellovin]

On Sun, 4 Nov 2007 11:52:11 -0500 (EST)
Sean Donelan <[EMAIL PROTECTED]> wrote:


> 
> And for all the other non-Web protocols which get confused, can treat
> that artificially generated crap/answers like NXDOMAIN.  Yes, I know
> it sounds like the evil bit; but if these folks are so convinced
> people really want this crap/address correction...
> 
They're not convinced their customers want it; they simply say that
publicly.  They're convinced that (a) they're going to make money from
it from equally sleazy advertisers/marketdroids, and (b) their
customers will be either too clueless or too sheeplike to do anything.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: BitTorrent swarms have a deadly bite on broadband nets

[Steven M. Bellovin]

According to
http://torrentfreak.com/comcast-throttles-bittorrent-traffic-seeding-impossible/
Comcast's blocking affects connections to non-Comcast users.  This
means that they're trying to manage their upstream connections, not the
local loop.

For Comcast's own position, see
http://bits.blogs.nytimes.com/2007/10/22/comcast-were-delaying-not-blocking-bittorrent-traffic/

Re: BitTorrent swarms have a deadly bite on broadband nets

[Steven M. Bellovin]

On Sun, 21 Oct 2007 13:03:11 -0400 (EDT)
Sean Donelan <[EMAIL PROTECTED]> wrote:

> 
> 
> http://www.multichannel.com/article/CA6332098.html
> 
>The short answer: Badly. Based on the research, conducted by Terry
> Shaw, of CableLabs, and Jim Martin, a computer science professor at
> Clemson University, it only takes about 10 BitTorrent users bartering
> files on a node (of around 500) to double the delays experienced by
> everybody else. Especially if everybody else is using "normal
> priority" services, like e-mail or Web surfing, which is what tech
> people tend to call "best-effort" traffic.
> 
> Adding more network bandwidth doesn't improve the network experience
> of other network users, it just increases the consumption by P2P
> users. That's why you are seeing many universities and enterprises
> spending money on traffic shaping equipment instead of more network
> bandwidth.
> 
This result is unsurprising and not controversial.  TCP achieves
fairness *among flows* because virtually all clients back off in
response to packet drops.  BitTorrent, though, uses many flows per
request; furthermore, since its flows are much longer-lived than web or
email, the latter never achieve their full speed even on a per-flow
basis, given TCP's slow-start.  The result is fair sharing among
BitTorrent flows, which can only achieve fairness even among BitTorrent
users if they all use the same number of flows per request and have an
even distribution of content that is being uploaded.

It's always good to measure, but the result here is quite intuitive.
It also supports the notion that some form of traffic engineering is
necessary.  The particular point at issue in the current Comcast
situation is not that they do traffic engineering but how they do it.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Upstreams blocking /24s? (was Re: How Not to Multihome)

[Steven M. Bellovin]

On Mon, 8 Oct 2007 16:06:52 -0700
David Conrad <[EMAIL PROTECTED]> wrote:

> 
> Hi,
> 
> On Oct 8, 2007, at 2:48 PM, Scott Weeks wrote:
> > However, if it's less than a /24 it won't get very far as most >
> > upstreams block prefixes longer than a /24.
> 
> I'm curious: a couple of people have indicated they do not believe
> this to be the case. Anybody have any hard data on what filters are
> actually in use today?

That's a good question.  http://www.nanog.org/mtg-0105/prefix.html says
what was in use 6.5 years ago; it would be good to look at newer data.
> 
> Others have indicated that such filters (assuming they exist) will
> not last in the face of paying customers presenting longer than /24
> prefixes for routing.  Specifically, that ISPs will relax their
> filters (allowing longer than /24) in order to get their peers to
> accept their long prefixes.  Anybody have an opinion on the
> likelihood of this?
> 
The traditional answer has been "paying whom?"  A given ISP's customers
might pay it to announce their routes; *maybe* they'll have bilateral
agreements with some of their peers to carry each other's longer
routes.  But what about the next hop?

Put another way, there's been a lot of discussion -- pardon me, a
*FLEEPING LOT of DISCUSSION* -- on this list lately about how lots of
folks need to upgrade line cards and/or IOS and/or routers to keep up
with the growth of the routing table.  If the growth is due to long
prefixes, who pays?  Again, it's (relatively) easy to charge your own
customers.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Question on Loosely Synchronized Router Clocks

[Steven M. Bellovin]

On Thu, 20 Sep 2007 14:41:16 -0500
"Brandon Galbraith" <[EMAIL PROTECTED]> wrote:

> On 9/20/07, James R. Cutler <[EMAIL PROTECTED]> wrote:
> >
> >  Kerberos does not assume clock synchronization.
> > Kerberos requires reasonable clock synchronization.
> > And, as near as I can tell, clock synchronization is not part of the
> > Kerberos protocol.
> >
> > Kick me if I err in this.
> >
> > Cutler
> >
> 
> http://en.wikipedia.org/wiki/Kerberos_%28protocol%29#Kerberos_drawbacks
> 
> "Kerberos requires the clocks of the involved hosts to be
> synchronized. The tickets have time availability period and, if the
> host clock is not synchronized with the clock of Kerberos server, the
> authentication will fail. The default configuration requires that
> clock times are no more than 10 minutes apart. In practice,
> NTPdaemons are
> usually employed to keep the host clocks synchronized."

That's correct, though I believe some versions use an offset hack.

The initial exchange with the Kerberos server is strongly
authenticated.  It's used to issue a ticket-granting ticket; replay of
TGTs (and service tickets obtained via TGTs) partially relies on
synchronized clocks.  The offset hack has the Kerberos server -- a
universally trusted party -- note and seal in the tickets -- the
client's time offset from KDC reality.  Any services that accept the
tickets can use this value to correct for clock skew.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Question on Loosely Synchronized Router Clocks

[Steven M. Bellovin]

On Tue, 18 Sep 2007 13:51:55 -0400
[EMAIL PROTECTED] wrote:

> On Tue, 18 Sep 2007 09:27:32 PDT, Bora Akyol said:
> > 
> > It is not dependent on time. You'd like a protocol to be self
> > sufficient if at all possible.
> > 
> > Moving the vulnerability of one protocol to another is not highly
> > desirable in general.
> 
> The interesting failure mode is, of course, what happens when you're
> not in time sync, so the routing protocol falls over - and due to the
> lack of routing table entries, you become unable to reach your
> timesource.

I've been talking with Xin offline, and raised that exact point.  That
said, in some security contexts there's little choice: you have to have
some way to assure that a message is fresh.  There are other choices in
some environment, such as monotonically increasing counters and
challenge/response protocols; depending on other decisions and the
particular context, these may be worse or not even possible.  For
example, if someone several hops away from the origination needs to
examine a signed *object*, a timestamp is probably better than a
counter, and challenge/response isn't even possible.  That doesn't make
timestamps good -- and they do have many disadvantages -- but they may
be the only choice.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Congestion control train-wreck workshop at Stanford: Call for Demos

[Steven M. Bellovin]

On Mon, 3 Sep 2007 21:21:26 -0400
Joe Abley <[EMAIL PROTECTED]> wrote:

> 
> 
> On 3-Sep-2007, at 1328, [EMAIL PROTECTED] wrote:
> 
> > Spurred on by a widespread belief that TCP is showing its age and >
> > needs replacing
> 
> I don't mean to hijack this thread unnecessarily, but this seems like
> an interesting disconnect between ops people and research people
> (either that or I'm just showing my ignorance, which will be nothing
> new).
> 
> Is there a groundswell of *operators* who think TCP should be
> replaced, and believe it can be replaced?
> 
> Or is the motivation for replacing TCP mainly felt by those who spend
> a lot of time trying to get maximum performance out of single flows
> over high bandwidth-delay product paths?
> 

Operators speak IP, not TCP -- not your problem...

More seriously -- the question is whether new services will cause
operator congestion problems that today's mechanisms don't handle.
It's also possible, per the note that some solutions will have operator
implications, such as new tuning knobs for routers and/or new funky new
DNS records to make it clear which hosts support TCP++.  Beyond that,
there are likely implications for things like firewalls, ACLs, and
service measurements.



--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: For want of a single ethernet card, an airport was lost ...

[Steven M. Bellovin]

On Sat, 18 Aug 2007 17:09:10 GMT
"Paul Ferguson" <[EMAIL PROTECTED]> wrote:

 
> They don't even have to touch the hardware. :-)
> 
> http://www.wired.com/science/discoveries/news/2006/11/72051
> 
Did you see what the GAO found when they audited the US-VISIT network?
The summary is at
http://www.washingtonpost.com/wp-dyn/content/article/2007/08/02/AR2007080202260.html?hpid=sec-nation;
the full report is at http://www.gao.gov/new.items/d07870.pdf



--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: large organization nameservers sending icmp packets to dns servers.

[Steven M. Bellovin]

On Mon, 06 Aug 2007 11:57:08 -0400
[EMAIL PROTECTED] wrote:

> On Mon, 06 Aug 2007 11:53:15 EDT, Drew Weaver said:
> > Is it a fairly normal practice for large companies such as Yahoo!
> > And Mozilla to send icmp/ping packets to DNS servers? If so, why?
> 
> Sounds like one of the global-scale load balancers - when you do a
> (presumably) recursive DNS lookup of one of their hosts, they'll ping
> the nameserver from several locations and see which one gets an
> answer the fastest.
> 
> Yes, it's a semi-borkken strategy, because it assumes that:
> 
> 1) ICMP is handled at the same rate as TCP/UDP packets in all the
> routers involved (so there's no danger of declaring a path "slow"
> when it really isn't, just becase a router slow-pathed ICMP).

This is aimed at hosts, not routers, right?  As far as I know, routers
don't slow-path forwarded ICMP.  Hosts will probably reply to ICMP from
their kernel, so it's a faster response than a user-level DNS reply.
> 
> 2) That the actual requester of service is reasonably near net-wise
> to the server handling the end-user's recursive DNS lookup.

Right.  But there's no particular reason to block it, unless the rate
is high enough that it's causing you CPU or network load problems.  (If
it's your IDS that's getting overloaded, perhaps tell it not to worry
unless you see other load issues...)


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: DNS Hijacking by Cox

[Steven M. Bellovin]

Several people have email me privately to disagree with my statement
about DNSSEC, on various grounds.  I stand by my statement, but I am
making a fair number of assumptions, some perhaps invalid.  Let me be
less terse.

I'm assuming fairly universal deployment.  In other words, the root
zone is signed, as is most or all of .com/.net/.org are signed and
the .ccTLDs of your choice.  I don't assume that domains under,
say, .com are signed, but of course unsigned zones aren't protected.

I assume that user machines have a configuration file with the root
keys.  (I'm carefully not saying anything here about how root key
rollover is done.)  I'm assuming that ISPs are *not* changing that
configuration file; this may be a dubious assumption.  One
correspondent felt that it was; I stand by my statement, because if the
ISP plays games there and the user falls to a pharming attack that
DNSSEC may have prevented, the ISP may be liable.  Besides, there's an
easier attack for the ISP...

DNSSEC can be end-to-end, or it can be terminated by a full-service
caching server which has a security association with user resolver
(typically via TSIG, which uses shared secrets).  In that case, the
caching server would verify the digital signatures and set a bit in the
response to the user saying "all is cool".  This is the most likely way
an ISP would spoof a response, since it doesn't strip protection from
other zones, doesn't require them to do massive resigning, etc.

The way this is signaled by the end-user's resolver and handled by the
caching name server is complex (see Section 3.2 of RFC 4035); briefly,
though, it's ultimately under the control of the end system.  I have no
idea what the Windows default will be or if it will let the user's
machine do its own validation.  My guess, though, is that it will prefer
ISP validation but be able to do it itself.  Note that 4035 requires a
secure channel (i.e., a shared secret) for upstream validation; since
that won't exist out of the box, the PC would have to be able to do its
own.  For obvious reasons, I'm focusing on Windows here.  It's 99%
certain that Linux and *BSD machines can do their own checking, if they
wish; I'll leave to others to speculate what MacOS will do.  The net,
though, under my assumptions, is that ISP-supplied user configurations
will likely have the user's machine trust them, but sophisticated users
will be able to override that -- and DNSSEC is very much something for
sophisticated users.

The ISP can always ignore the RFC and strip out the signature RRs.
That's detectable by an end-system that has requested that they be sent
along.  After all, that's no different than a monkey-in-the-middle
attacker doing the same thing -- DNSSEC doesn't distinguish between
offensive ISP and other enemies...

So -- I think that DNSSEC, if deployed, will protect users who care,
even against their ISP.  It won't protect the clueless; I'm not sure
what will.  (See
http://didierstevens.wordpress.com/2007/05/07/is-your-pc-virus-free-get-it-infected-here/
for an example of people you can't protect with technology...)  But it
is, as the tube of toothpaste almost says, an effective
attack-prevention mechanism if used as part of a program of good
Internet hygiene and regular professional care.

Re: DNS Hijacking by Cox

[Steven M. Bellovin]

On Sun, 22 Jul 2007 21:40:05 -0400
"Patrick W. Gilmore" <[EMAIL PROTECTED]> wrote:

> 
> On Jul 22, 2007, at 9:29 PM, Steven M. Bellovin wrote:
> > On Sun, 22 Jul 2007 14:56:13 -0700
> > "Andrew Matthews" <[EMAIL PROTECTED]> wrote:
> >
> >> It looks like cox is hijacking dns for irc servers.
> >>
> > And people wonder why I support DNSsec
> 
> Steve,
> 
> One of us is confused.  It might be me, but right now I think it's
> you.
> 
> To be clear, here is the situation as I understand it: Cox has
> configured their recursive name servers such that when an end user
> queries the recursive server for a specific host name (names?), the
> recursive server responds with an IP address the host's owner did not
> configure.
> 
> How exactly is DNSSEC going to stop them from doing this?
> 
If my host expects the response to be signed and it isn't, my host can
scream bloody murder.  The whole point of DNSSEC is to prevent random
changes to DNS replies, whether by hackers or by ISPs.

Yes, they can change it, but they can't change it without being caught.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: DNS Hijacking by Cox

[Steven M. Bellovin]

On Sun, 22 Jul 2007 14:56:13 -0700
"Andrew Matthews" <[EMAIL PROTECTED]> wrote:

> 
> It looks like cox is hijacking dns for irc servers.
> 
> 
>
And people wonder why I support DNSsec


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: The Choice: IPv4 Exhaustion or Transition to IPv6

[Steven M. Bellovin]

On Thu, 28 Jun 2007 17:46:53 -0400
[EMAIL PROTECTED] wrote:

> On Thu, 28 Jun 2007 13:08:52 PDT, Bora Akyol said:
> > At a very low, hardware centric level, IPv6 would be a lot easier to
> > implement if
> > 
> > 1) The addresses were 64 bits instead of 128 bits.
> > 2) The extension headers architecture was completely revamped to be
> > more hardware friendly. 
> 
> Wow, a blast from the past.  The *current* IPv6 design was selected
> to a good extent because it was *easier* to do in hardware than some
> of the other contenders.  You think 64 versus 128 is tough - think
> about the ASIC fun and games to support *variable length* addresses
> (not necessarily even a multiple of 4 bytes, in some of the
> proposals. Could be 7, could be 11, check the address length field
> for details. Yee. Hah).

I'm not going to revist all of the design issues; as I said, at this
point IPv6 is what is is.  On that point, you're mostly right; there
were indeed a class of CLNP-derived solutions that were rejected.  That
said, some of us -- including me -- wanted to use the two high-order
bits of the address to select among {64,128,192,256}-bit addresses.
Settling on 128 bits was a compromise between that group and advocates
of a 64-bit fixed-length address.  History since then persuades me that
sticking with 64 bits would have been a very bad mistake.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: The Choice: IPv4 Exhaustion or Transition to IPv6

[Steven M. Bellovin]

On Thu, 28 Jun 2007 12:23:30 -0700
brett watson <[EMAIL PROTECTED]> wrote:

> 
> 
> On Jun 28, 2007, at 11:44 AM, Steven M. Bellovin wrote:
> 
> > Whatever -- it
> > exists as a reasonably stable design; starting over would cost us 15
> > more years that we just don't have.)
> 
> Are you saying we (collectively) would take yet *another* 15 years to
> come up with another and/or better design?

Not so much to design it as to reach this point of maturity.

More precisely, I don't see any reason why it would take significantly
less.  In fact, it can't take much less, no matter what.  Figure two
years for the basic design, 3-5 years for the IETF (or whomever) to
engineer all the pieces (it's more than just the IP header, and until
we have a new design we won't even be able to start identifying the
pieces), 3 years for design/code/test (in the NANOG world, that
includes new ASICs, line cards, etc.), and 3-5 years for much existing
gear (routers, end systems, etc.) to be replaced with the IPvN stuff.
That adds up to 11-15.

I have a lot of confidence in those figures; if anything, I suspect
that I'm being too optimistic.

IPv6 isn't what I wanted it to be (and I was on the IPng directorate).
That said, it's what we have, and I think we *really* need something
with a lot more address space.

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: The Choice: IPv4 Exhaustion or Transition to IPv6

[Steven M. Bellovin]

On Thu, 28 Jun 2007 13:27:15 -0400
John Curran <[EMAIL PROTECTED]> wrote:

> 
> At 10:16 AM -0700 6/28/07, Randy Bush wrote:
> > > Interoperability is achieved by having public facing
> >> servers reachable via IPv4 and IPv6.
> >
> >that may be what it looks like from the view of an address allocator.
> >
> >but if you actually have to deliver data from servers you need a path
> >where data from/in both protocols is supported on every link of the
> >chain that goes all the way to every bit of back end data in your
> >system.  and if one link in that chain is missing,  >idea
> >imploding>.
> 
> Randy,
>  
>Organizations need to have IPv6 on their DMZ servers.
> 
>ISP's needs to provide IPv6 to these organizations, either
>directly or via tunnel.
> 
>It's actually rather simple.
> 
Randy is right.  It's very simple from 30,000 feet; it's a lot messier
in detail if done at scale.  I'll give just example, using your
suggestion of converting DMZ: how do you keep your firewall rules
consistent between v4 and v6 addresses and prefixes?  This involves
vendor technology (the firewall box), communication with your ISP
(handling prefix changes), local technology (you do have a change
control process for firewall rules, right, and perhaps a database of
machines and addresses?), and training.  It may also involve upgrading
some of the servers because of the rapid changes in v6 support.  (I'll
cite a personal example: I upgraded the OS on a machine of mine
recently, and found that my mailing lists weren't working.  Why?
Because the version of Postfix had been changed to one with v6 support,
and I had to specify v6 loopback addresses in some mysterious place.)

That's not to say this is an excuse for delay.  Converting is going to
get harder when you acquire more gear, not easier.  Planning and
back-end conversions (i.e., ISP databases that hold customer IP
address ranges) should have been done years ago.  It's now become
urgent; I'm glad people are finally starting to take it seriously.
(Metanote:  IPv6 is far from the best possible design.  Given all of
the constraints, including the political ones, it may be, as Bjarne
Stroustrup said of C++, the best design possible.  Whatever -- it
exists as a reasonably stable design; starting over would cost us 15
more years that we just don't have.)

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Security gain from NAT

[Steven M. Bellovin]

On Mon, 04 Jun 2007 22:06:25 -0400
Daniel Senie <[EMAIL PROTECTED]> wrote:

> 
> At 09:07 PM 6/4/2007, Jason Lewis wrote:
> 
> 
> >I figured SMB would chime in...but his research says it's not so
> >anonymous.
> >
> >http://illuminati.coralcdn.org/docs/bellovin.fnat.pdf

The traffic load on this list is rather high; I've had to flush most
of this and other threads 
> 
> Give or take NAT boxes / firewalls that specifically have features to
> mess with the IP ID. The SonicWALL products have, for example, a
> checkbox that says: "Randomize IP ID".

That's relatively new, and possibly in response to my paper; as of when
I wrote it, I couldn't find any vendors that DTRT.
> 
> Some vendors apparently have taken measures to ensure methods such as
> monitoring IP ID are less effective. The paper notes this, and the
> issues with doing this.
> 
> So the "not so anonymous" statement above is really "not so
> anonymous, give or take the implementation of the firewall/NAT".
> 
I suspect there are other information leaks, such as the RFC 1323
timestamps, TCP sequence numbers (for some platforms), port number
allocation, etc.  Many of these are (or can be) randomized on some
platforms, but I don't know of any systematic analysis.  I also wonder
if some popular web sites' cookies embed the IP address -- possibly
encrypted to them, so they can track where you are.  I'm 100% that some
sites do that for authenticated connections.

(On the larger issue, I feel that typical NATs provide no security
benefit over typical stateful packet filters.  Given other issues --
traceability of attacks, impediments to end-to-end secure connections,
the need for special-purpose things like STUN servers, etc. -- I could
make a good case that they're a net disadvantage.  But I'm on the verge
of flushing this thread, so I may not see the responses)


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: ISP CALEA compliance

[Steven M. Bellovin]

On Wed, 23 May 2007 16:02:35 -0400
Jared Mauch <[EMAIL PROTECTED]> wrote:

> 
> On Wed, May 23, 2007 at 07:08:21PM +, Chris L. Morrow wrote:
> > 
> > 
> > On Wed, 23 May 2007, Joe Abley wrote:
> > 
> > 
> > > Oh! That was a really old message I just replied to. Mail got
> > > kidnapped in a rogue barracuda, it seems, and someone just paid
> > > the ransom. Sorry about the noise :-)
> > 
> > don't swim with them and bait... Was there a final disposition on
> > this? (I suppose maybe the agenda might show it too? though I don't
> > see it currently there...)
> 
>   I was unable to get someone from DoJ CALEA Impl. Unit to
> attend this upcoming NANOG.  They said they had folks available the
> next week but obviously that wouldn't work :(.

I do have a volunteer from EFF...


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: RTT from NY to New Delhi?

[Steven M. Bellovin]

On Wed, 16 May 2007 09:20:48 -0400
Joe Maimon <[EMAIL PROTECTED]> wrote:

> What should I expect?
> I am seeing ~350 from a vendor provided mpls cloud to a site in
> Sukhrali Chowk, Gurgaon, Haryana, India
> Thanks,
> Joe

What does traceroute show?  I was doing some looking glass tests
recently to some places in Asia and it looked -- from host names and
differential RTTs -- like there might have been a satellite hop
involved.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: ISP CALEA compliance

[Steven M. Bellovin]

On Fri, 11 May 2007 12:47:56 -0700 (GMT-07:00)
Todd Glassey <[EMAIL PROTECTED]> wrote:

> Gee Steven, that's what everyone thought prior to a Federal Judge
> ordering Microsoft to produce seven years of Email...
> 

We're getting off-topic here, but I'll respond.

First -- the context of the conversation is wiretap law, including the
stored communications and customer records provisions.  This covers
what communications providers do for their customers, not internal
emails.

Second:

(a) The judge's order was for a civil lawsuit, under
discovery procedures;

(b) The order was for records that they apparently had.
If Microsoft had had and enforced a policy, prior to that
lawsuit, of not retaining internal email older than 30
days, they'd have been in the clear.  Microsoft got in
trouble because the judge believed they were not complying
with his order to turn over data he believed they had,
either deliberately or by not exerting sufficient effort;

(c) you may have business reasons to retain certain records
for longer, including the requirements of external auditors.
For example, if you do usage-sensitive billing, you may
need to retain certain records for a while so that your
accounting firm can verify that your financial records
accurately reflect actual customer behavior.

(d) What doesn't exist can't be subpoenaed; what does exist,
in general, can be, subject to other specialized exceptions
(i.e., attorney work product)

Third -- that isn't what I'm talking about.  Please see, among others,


http://news.com.com/Gonzales+pressures+ISPs+on+data+retention/2100-1028_3-6077654.html

http://www.theregister.co.uk/2006/09/20/gonzales_calls_for_data_retention/
http://news.com.com/2100-1028_3-6156948.html

Note especially that last one, since it's only 3 months old and provides
for jail time for "employees of any Internet provider who fail to store
that information", and not just fines for the company.

I've tried hard to keep this discussion factual, with copious
references. But I think I've run out of things to say that are even
vaguely on-topic, so I'll shut up.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: ISP CALEA compliance

[Steven M. Bellovin]

On Fri, 11 May 2007 12:17:04 -0400
Jared Mauch <[EMAIL PROTECTED]> wrote:


>   If there is interest, perhaps I can make a call to DoJ and
> see if someone can present on CALEA at nanog in a few weeks?  (incase
> the PC can accomodate them).
> 
And perhaps someone from CDT?  I mean that in all seriousness.  DoJ and
the FBI have pushed the statutory envelope on CALEA, in my opinion.
Different lawyers will often disagree on what the law actually requires
(I'm not even talking about what it should require); it's worth getting
other perspectives.  

Education on this subject is good.  When NANOG met in DC a few years
ago, I personally invited a DoJ attorney to speak on Sunday on wiretap
law (http://www.nanog.org/mtg-0010/justice.html).  I'm not
unsympathetic to legitimate law enforcement or national security needs,
and I'm aware that ISPs need to obey the law.  But DoJ needs to obey
it, too.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: ISP CALEA compliance

[Steven M. Bellovin]

On Fri, 11 May 2007 10:52:21 -0400
William Allen Simpson <[EMAIL PROTECTED]> wrote:

> 
> David Lesher wrote:
> > > Speaking on Deep Background, the Press Secretary whispered:
> >> You work so hard to defend people that exploit children?
> >> Interesting. We are >> talking LEA here and not the latest in
> >> piracy law suits. The #1 request from a >> LEA in my experience
> >> concerns child exploitation.
> > That's nonsense, or his (press secretary's) experience consists of
> > watching
> /Law & Order/ and /Without a Trace/.
> 
> No official statistics backs that up.  Where in the world does he
> operate?
> 
> 
> > I think you'll find most intercept orders are drug cases. > So I've
> > heard, but my experience was the Ashcroft 'net p0rn crackdown.
> What a waste of time and resources for a perfectly legal activity!
> 
> Of course, CALEA (and PATRIOT) were supposed to be about tracking
> terrorists, not common criminals.  That was never the real purpose;
> it was just a wish list.
> 
> Also, with so many college students, we *are* talking about piracy
> lawsuits. But that's civil law, not CALEA or PATRIOT.  Hopefully,
> they haven't tried to expand into that, too?
> 

The latest revisions to copyright law did provide for more criminal
penalties...

Let me toss in a few more factual URLs.

First, on this topic: Federal wiretap warrants can only be issued for
specific crimes.  That list is in 18 USC 2516; see
http://www4.law.cornell.edu/uscode/html/uscode18/usc_sec_18_2516000-.html
The list is long, but it doesn't seem to include the RIAA's least
favorite activities -- at least, not yet...  (The list has also been
expanded significantly in recent years.  I haven't bothered to check
the details, but I think that most of the expansion was via the PATRIOT
Act.  Much of the PATRIOT Act, I might add, was a long set of DoJ/FBI
wish list amendments, things they'd wanted for years but couldn't get
through Congress until after 9/11.  My source for that, btw, is
conversations with people in DoJ.)

For CALEA deployment status, see
http://www.usdoj.gov/oig/reports/FBI/a0613/final.pdf
Note in particular how much more expensive CALEA taps are...

For the latest wiretap report, just out last week, see
http://www.uscourts.gov/wiretap06/contents.html
Pay particular attention to Table 3.  The highlight: 80% of all
wiretaps were for narcotics offenses.  There is *no* separate category
for pornography, child or otherwise, which caps the percentage at the
3.5% for "Other".  To be sure, the report notes that sensitive ongoing
cases are not counted; this may reflect ongoing sting operations or
national security wiretaps,  There are no national security or
terrorism wiretaps listed, possibly because those fell under FISA (50
USC 1801 --
http://www4.law.cornell.edu/uscode/html/uscode50/usc_sec_50_1801000-.html
 ).

For those who remember the Crypto Wars of the 1990s, it's interesting
to note this section of the wiretap report:

Public Law 106-197 amended 18 U.S.C. 2519(2)(b) to require that
reporting should reflect the number of wiretap applications
granted for which encryption was encountered and whether such
encryption prevented law enforcement officials from obtaining
the plain text of communications intercepted pursuant to the
court orders. In 2006, no instances were reported of encryption
encountered during any federal or state wiretap.

The situation may be different for national security wiretaps, but of
course that's where compliance with any US anti-crypto laws are least
likely.

Folks, the factual and legal data is out there, and it's not that hard
to find.  Interpreting it is harder, and frequently does require a
lawyer who really knows the field.  (My favorite example there is 18
USC 2072(c)(6), which *permits* communications providers to disclose
customer records (except for content) to "any person other than a
governmental entity".  I was surprised enough when I first read that
that I went and looked up the legislative history, and it means exactly
what it says.  *But* -- such activity is no longer legal.  Why?  The
Telecom Reform Act of 1996 bars telcos, at least, from certain forms
of information sharing internally, to promote competition in the
telephony market.  They weren't trying to fix the privacy flaw in the
older statute; fortunately, they did -- by accident...)

As Bill Simpson has quite correctly pointed out, you're also not
required to roll over and play dead when someone from the government
asks you for some data. There are laws they're obligated to follow,
too.  Even if you want to look at it from a purely selfish position,
you and/or your company may be liable if you co-operate with an
improper or illegal request.  Have a look at
http://www4.law.cornell.edu/uscode/html/uscode18/usc_sec_18_2520000-.html
which provides for civil liability for illegal wiretaps.  You're clear,
under that statute, if you have good reason to believ

Re: ISP CALEA compliance

[Steven M. Bellovin]

On Fri, 11 May 2007 10:42:14 -0400
"Jason Frisvold" <[EMAIL PROTECTED]> wrote:

> 
> On 5/11/07, Brandon Galbraith <[EMAIL PROTECTED]> wrote:
> > My understanding was data you had needed to be turned over when
> > requested, but CALEA provides no specification/guidance on log
> > retention.
> 
> Agreed.  My understanding, to date, is that the data to be turned over
> is data collected from the beginning of the CALEA tap.  Historical
> data can be requested, but I'm not aware of any official legal
> guidelines on retention time.
> 
There are no legal requirements on proactive data retention in the
US.  Gonzales has suggested that there should be one, but at this
point it's just that -- a suggestion.  I think that at the moment,
the odds of Congress enacting a Gonzales proposal are rather low;
they'd much rather impeach him than listen to him...  There is now an EU
requirement on retention, but the EU's jurisdiction rules are, shall we
say, complex.



--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: ISP CALEA compliance

[Steven M. Bellovin]

On Thu, 10 May 2007 16:03:49 -0400
William Allen Simpson <[EMAIL PROTECTED]> wrote:


> Congress "authorized" CALEA (and there is also argument about whether
> the recent expansion to ISPs was authorized at all), it cannot be
> required of the public until Congress *appropriates* the funds, and
> they are received by us.
> 
> Just like the current argument about how to end the Iraq war.  Only
> actual appropriations count.
> 
> Even non-lawyers should remember our basic civics lessons.
> 
What appropriation?

Have a look at the actual text of the law at
http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=103_cong_bills&docid=f:h4922enr.txt.pdf
(If the link doesn't work, go to thomas.loc.gov and look for bill
H.R. 4922 from the 103rd Congress.  If that still doesn't help, email
me and I'll send you the PDF.)

Anyway -- for the most part, the law does not impose mandates on the
government, so there's no necessary appropriation.  The law requires
carriers to do certain things, which doesn't necessarily cost the
government money.  To be sure, the CALEA act does authorize money to
reimburse carriers for the changes -- see Section 109.  But that money
was for upgrading facilities deployed before 1995, which I suspect
applies to none of the gear we're talking about here... ("Help, my AGS+
isn't CALEA-compliant!")  The law (Section 109(d)) does say what
happens if the money isn't appropriated -- you're exempt until "the
equipment, facility, or service is replaced or significantly upgraded
or otherwise undergoes major modification."  Does that sound like your
POPs?

(OT: When government spending is involved, Bill is absolutely right.
The framers of the Constitution were very careful to make sure that
Congress, not the President, had the right to raise taxes and
authorize spending, and that military appropriations in particular
could not be for longer than two years.  Why?  Because they were
intimately familiar with British history, much of which included a
perpetual struggle between the monarch and Parliament over money to
wage war.  If memory serves, Parliament gained control over that in
1243 (and definitely not very long after the Magna Carta), and it
regularly used that power to rein in the king or queen.  The monarch
did have direct control over certain revenue sources -- but anything
like that was carefully excluded from the American constitution  It
isn't possible to understand the Constitution without knowing British
history.)


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: barak-online.net icmp performance vs. traceroute/tcptraceroute, ssh, ipsec

[Steven M. Bellovin]

On Sun, 06 May 2007 20:27:20 -0400
Joe Maimon <[EMAIL PROTECTED]> wrote:

> 
> 
> 
> Lincoln Dale wrote:
> 
> >>traceroute/tcptraceroute show packet loss and MUCH higher rtt than
> >>the corresponding direct pings on the reported hop entries.
> >>
> >>Is this some sort of massaging or plain just "faking it"? Or is such
> >>things merely net-urban myth?
> > > > the vast majority of routers on the internet respond very
> > > > differently to
> > traffic 'directed at them' as opposed to traffic 'routed through
> > them'.
> 
> Thanks for your reply.
> 
> I did include icmp echo directly to each hop as a comparison.
> 
Right, but from what you posted you didn't send 1500-byte packets.  My
reaction was the same as Lincoln's -- it smells like a Path MTU
problem.  To repeat -- ping and traceroute RTT from intermediate nodes
is at best advisory, especially on timing.

I should add -- DSL lines often use PPPoE, which in turn cuts the
effective MTU available for user packets.  If the PMTUD ICMP packets
don't get through -- and they often don't, because of misconfigured
firewalls -- you're likely to see problems like this.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: BOGON Announcement question

[Steven M. Bellovin]

On Mon, 30 Apr 2007 16:12:16 +0100
Randy Bush <[EMAIL PROTECTED]> wrote:

> 
> > Collector: CIXP
> > Prefix:   128.0.0.0/2
> 
> oh.  any prefix of use is longer and hence is preferred
> 
Right.  Think of it as the world's largest packet telescope.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: from the academic side of the house

[Steven M. Bellovin]

On Tue, 24 Apr 2007 09:24:13 -0700
Jim Shankland <[EMAIL PROTECTED]> wrote:

> (2) Getting this kind of throughput seems to depend on a fast
> physical layer, plus some link-layer help (jumbo packets), plus
> careful TCP tuning to deal with the large bandwidth-delay product.
> The IP layer sits between the second and third of those three items.
> Is there something about IPv6 vs. IPv4 that specifically improves
> perfomance on this kind of test?  If so, what is it?

I wonder if the router forward v6 as fast.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: BGP Problem on 04/16/2007

[Steven M. Bellovin]

On Thu, 19 Apr 2007 12:00:53 -0400
Warren Kumari <[EMAIL PROTECTED]> wrote:
> 
> There was also an issue where one of the large manufacturers of
> (binary) CAMs received a batch of polyimide that was contaminated
> with an alpa-emitter (for some reason thorium oxide springs to mind)
> and their quality control didn't catch it... As far as I know the
> problem was identified before any products with the CAMs were
> shipped, but I had an order held up while the vendor tried to source
> alternate parts...

Contamination by alpha emitters was a major problem some years ago.
Manufacturers had to change their formulations to avoid the problem.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Thoughts on increasing MTUs on the internet

[Steven M. Bellovin]

On Thu, 12 Apr 2007 16:12:43 +0200
Florian Weimer <[EMAIL PROTECTED]> wrote:

> * Steven M. Bellovin:
> 
> > A few years ago, the IETF was considering various jumbogram options.
> > As best I recall, that was the official response from the relevant
> > IEEE folks: "no". They're concerned with backward compatibility.  
> 
> Gigabit ethernet has already broken backwards compatibility and is
> essentially point-to-point, so the old compatibility concerns no
> longer apply.  Jumbo frame opt-in could even be controlled with a
> protocol above layer 2.
> 
I'm neither attacking nor defending the idea; I'm merely reporting.

I'll also note that the IETF is very unlikely to challenge IEEE on
this.  There's an informal agreement on who owns which standards.  The
IETF resents attempts at modifications to its standards by other
standards bodies; by the same token, it tries to avoid doing that to
others.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Thoughts on increasing MTUs on the internet

[Steven M. Bellovin]

On Thu, 12 Apr 2007 11:20:18 +0200
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:

> 
> Dear NANOGers,
> 
> It irks me that today, the effective MTU of the internet is 1500
> bytes, while more and more equipment can handle bigger packets.
> 
> What do you guys think about a mechanism that allows hosts and
> routers on a subnet to automatically discover the MTU they can use
> towards other systems on the same subnet, so that:
> 
> 1. It's no longer necessary to limit the subnet MTU to that of the
> least capable system
> 
> 2. It's no longer necessary to manage 1500 byte+ MTUs manually
> 
> Any additional issues that such a mechanism would have to address?
> 

Last I heard, the IEEE won't go along, and they're the ones who
standardize 802.3.

A few years ago, the IETF was considering various jumbogram options.
As best I recall, that was the official response from the relevant
IEEE folks: "no". They're concerned with backward compatibility.  

Perhaps that has changed (and I certainly) don't remember who sent that
note.  


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: New RIPE NCC IPv4 blocks pingable addresses

[Steven M. Bellovin]

On Tue, 10 Apr 2007 11:56:57 +0200
Alex Le Heux <[EMAIL PROTECTED]> wrote:

> 
> [Apologies for duplicate emails]
> 
> Dear Colleages,
> 
> The IANA recently allocated the IPv4 address ranges 92/8 and 93/8 to
> the RIPE NCC.
> 
> The following pingable addresses are now available in these blocks:
> 
> 92.192.0.1
> 92.255.248.1
> 93.192.0.1
> 93.255.248.1

I was relieved to read the body of this note -- from the subject line,
I thought that RIPE was blocking pings to certain addresses...


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: On-going Internet Emergency and Domain Names

[Steven M. Bellovin]

On Fri, 30 Mar 2007 19:44:23 -0700
Jeff Shultz <[EMAIL PROTECTED]> wrote:

> 
> So, is there a list of domains that we could null-route if we could
> convince our DNS managers to set us up as the SOA for those domains
> on our local DNS servers - thus protecting our own customers somewhat?
> 
> I won't discount the assertion that there is some sort of emergency
> occurring. I would however, like to see a bit of a reference to where
> we can learn more about what is going on (I assume this is the
> javascript exploit I heard about a couple days ago).
> 

No -- it's a 0day in Internet Explorer involving animated cursors --
and it can be spread by visiting an infected web site or even by email.

See 
http://blogs.zdnet.com/security/?p=141&tag=nl.e622
http://www.avertlabs.com/research/blog/?p=230
http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=TROJ%5FANICMOO%2EAX&VSect=T

or see lots of news stories about it at
http://news.google.com/?ned=us&ncl=1114901719&hl=en

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Fw: Protocol Action: 'BGP Support for Four-octet AS Number Space' to Proposed Standard

[Steven M. Bellovin]

Begin forwarded message:

Date: Fri, 09 Mar 2007 16:34:36 -0500
From: The IESG <[EMAIL PROTECTED]>
To: IETF-Announce 
Cc: idr mailing list , idr chair
<[EMAIL PROTECTED]>,Internet Architecture Board
,RFC Editor  Subject:
Protocol Action: 'BGP Support for Four-octet AS Number  Space' to
Proposed Standard 


The IESG has approved the following document:

- 'BGP Support for Four-octet AS Number Space '
as a Proposed Standard

This document is the product of the Inter-Domain Routing Working Group. 

The IESG contact persons are Bill Fenner and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-13.txt

Technical Summary
 
   Currently the Autonomous System number is encoded as a two-octet
   entity in BGP. This document describes extensions to BGP to carry the
   Autonomous System number as a four-octet entity.

   Based on historical and current allocation rates, the range available
   to two-octet AS numbers is expected to run out in 2010.

Working Group Summary
 
 This is a long-standing work item for the working group, with the
 first draft being published in February 2001.

 The approach described in the draft to support 4 Byte AS numbers
 is one of no change to BGP in terms of protocol in all but one
 aspect: The OPEN message uses a 4-Byte capability advertisement
 and the use of a 2 Byte MyAS field value. In all other respects
 there is no change to the protocol elements of BGP, other than
 using 4 bytes where ASs are used.

 The other substantive topic of the draft is in the interoperation
 of 4-Byte AS speakers with 2-Byte AS speakers.

 The OPEN message with capability advertisement has attracted one
 comment that this is contrary to RFC3392, however a detailed
 analysis of this comment has not lead to substantiation of this
 comment.  Using this as a dynamic capability rather than an OPEN
 capability was raised as a comment, with the response that there
 is no reason to make the capability dynamic in this case.

 The tunnelling technique of using an opaque transitive community
 attribute to carry the 4-Byte AS Path attracted some comment. The
 comment was concerned with the reconstruction of the 4-Byte AS
 path across a 2-to-4 byte BGP boundary, where the algorithm for
 the reconstruction was, in some comments, not sufficiently
 well-defined.

 However it is also the case that the critical elements of the role
 of the AS Path are adequately described in the draft. The AS path
 length is used as a metric in the BGP path selection process, and
 the AS path itself is used for loop prevention. The draft
 specifies that the reconstruction of the AS path across a 2-byte
 to 4-byte AS transition should preserve the AS path length. The
 draft does not cover every possible eventuality of reconstruction
 of the 4-byte AS path, but a closer examination of the loop
 detection issue reveals that loops that may occur across a mixed 2
 Byte / 4 Byte path are detectable within one iteration of the loop
 within the 2-Byte component of the mixed loop path in all
 circumstances. Accordingly, both the use of the AS path length as
 a path metric and the use of the AS path as a loop detection
 mechanism are preserved in this approach, even though the draft is
 not definitive in describing the AS path reassembly algorithm in
 every possible eventuality. In other words the draft contains the
 necessary and sufficient minimum set of properties for AS path
 reconstruction, leaving the precise algorithm up to the
 implementation. This approach is not seen as impairing the
 functionality, interoperability or integrity of BGP, either within
 the context of the individual peering session or in the context of
 the broader IDR framework.

 A comment was raised that on-the-wire inspection of BGP updates
 would not know in all cases whether they were seeing 2-byte or
 4-byte AS BGP updates. The BGP update contains no additional
 control flags, and unless the on-the-wire device collects the
 initial OPEN message with the capability negotiation then the
 information as to 2-byte or 4-byte AS updates is not explicit. It
 has been noted that heuristics could be readily applied here, and
 the presence of the reserved 2-byte AS value 0 in the AS path is
 one indicator that the momitor is applying a 2-byte interpretation
 to a 4-byte BGP update.

 There were no other approaches referenced in the working group
 during Last Call, and the choice of this draft as representing one
 that is backwards compatible with existing BGP appears to have
 been an obvious obvious choice to the working group.

 The IETF Last call comments concernd the RFC3392 Capability
 Advertisement examination of these comments indicates that the
 concern

Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Steven M. Bellovin]

On Sun, 4 Mar 2007 07:46:12 -0800
"Barry Greene (bgreene)" <[EMAIL PROTECTED]> wrote:


> 
> To 'globally' monitor, we have
> http://www.cymru.com/BGP/robbgp-bogon.html and
> http://www.cymru.com/BGP/asnbogusrep.html and
> http://www.cidr-report.org/ and http://www.routeviews.org/ and
> http://www.completewhois.com/bogons/active_bogons.htm. 
> 
> (Steve B, you were looking for data, here are your sources. I'm sure
> Geoff might be persuaded to do a historical graph on the 'Possible
> Bogons.')
> 

I'd love to see a paper based such data.  And I'll suggest that SRUTI
-- http://www.usenix.org/events/sruti07/cfp and yes, I'm the program
chair -- would be a perfect venue for the analysis.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Comcast contact for the East Coast

[Steven M. Bellovin]

On Fri, 02 Mar 2007 21:08:58 -0500
Jim Popovitch <[EMAIL PROTECTED]> wrote:

> On Fri, 2007-03-02 at 17:58 -0800, Ashe Canvar wrote:
> > Could someone from Comcast please contact us
> > ([EMAIL PROTECTED]).
> > 
> > Customers behind Comcast on the east coast cannot get to our
> > 216.219.126.0 prefix in Santa Barbara, CA. Comcast's peering with
> > Cox on ashbbbrj02-ae0.0.r2.as.cox.net may be to blame.
> 
> I'm presently hanging off of Comcast in Atlanta (76.17.105.x) and I
> can ping traceroute and ping 216.219.126.1
> 
As can I from Comcast in NJ.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Steven M. Bellovin]

On Fri, 2 Mar 2007 15:37:01 -0600
"Eric Ortega" <[EMAIL PROTECTED]> wrote:

> 
> I think Sean raises a good point. I guess the larger picture is what
> are we trying to protect and what are trying to protect that from. 
> 
Bingo.

The problem isn't with "security people", it's with "security people
who use checklists -- and old ones at that -- in preference to
thinking".

Droids exist in every field


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: FCC on wifi at hotel

[Steven M. Bellovin]

On Wed, 28 Feb 2007 19:55:37 -0800
Brian <[EMAIL PROTECTED]> wrote:

> a small number of wifi users with a card in a laptop to get to
> cellular broadband, itd be pretty easy..
> 
You might want to check the terms of service for cellular "broadband"
-- it's certainly not permitted by Verizon for the EVDO service.



--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Steven M. Bellovin]

On Thu, 01 Mar 2007 14:22:37 + (GMT)
"Chris L. Morrow" <[EMAIL PROTECTED]> wrote:

> 
> On Thu, 1 Mar 2007, Jon Lewis wrote:
> 
> > On Wed, 28 Feb 2007, Eric Ortega wrote:
> >
> > > I'd like to thank the group for the responses and help with this
> > > issue. I find it ironic that Randy's study actually uses 96 space.
> >
> > The amazing/sad thing is that people have been facing and fixing
> > the same problem for more than 4 years.  How many times does a
> > network have to fix their static bogon filters before coming to the
> > realization that those filters are a bad idea?
> 
> So, where are static bogon filters appropriate? (loaded question
> perhaps) I ask because just about every 'security expert' and
> 'security whitepaper' or 'security suggestions' has some portion that
> speaks to "why it's a grand idea to have acl-lines/firewall-policy tp
> block 'bogon' ip space" (for some definition of 'bogon' of course).
> 
Well, not all of us advocate that; see
http://www.merit.edu/mail.archives/nanog/2006-01/msg00150.html  



--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Every incident is an opportunity

[Steven M. Bellovin]

On Mon, 12 Feb 2007 17:12:56 -0500
Barry Shein <[EMAIL PROTECTED]> wrote:

> 
> Of course, but the point was the goal of that targetting. The US
> public by and large believed, and seems to still believe (i.e., the TV
> show Jericho) that the goal of a USSR attack was purely vindictive,
> complete annhilation. Apparently Civil Defense leaned more towards
> invasion as a goal.
> 
> No doubt as weapons systems evolve how you achieve one goal or the
> other evolves.
> 
> Either goal leads to different targeting strategies, as possible. If
> your goal is invasion then value preservation is important (factories,
> bridges, civilian infrastructure, etc.) If anniliation is the goal
> than it's of no importance, just bomb the densest population centers.
> 

Some of the time, that was the goal...  It's not that anyone wanted
that; however, it was (a) achievable, and (b) it was part of the MAD --
mutual assured destruction -- deterrent strategy.  One could argue that
that part, at least, worked, though I would assert that that was at
least partially by accident.



--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Every incident is an opportunity

[Steven M. Bellovin]

On Mon, 12 Feb 2007 15:05:45 -0500
Barry Shein <[EMAIL PROTECTED]> wrote:


> In the late 60s I remember having an interesting conversation with
> someone who did this kind of strategizing for the Dept of Civil
> Defense.
> 
> His scenarios were markedly diferent from the "urban folklore" you'd
> hear from people about what the Russkies were likely to nuke, other
> than everyone agreed they'd try to get the silos and a few other key
> military assets to try to prevent retaliation.
> 
Targeting strategy changed over time, because of changes in technology,
quantity of bombs available, accuracy, perceived threats, and internal
politics.  For a good history of US nuclear targeting strategy, see
"The Wizards of Armageddon", Fred Kaplan, 1983.  The short answer,
though, is that it changed markedly over time.  To give just one
example, at one time the US targeted cities, with very big bombs,
because the missiles of the day couldn't reliably hit anything
smaller.  Since that's what was possible, a strategic rationale evolved
to make that seem sensible.  


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Every incident is an opportunity (was Re: Hackers hit key Internet traffic computers)

[Steven M. Bellovin]

On Sun, 11 Feb 2007 10:49:30 -0600
Dave Pooser <[EMAIL PROTECTED]> wrote:

> 
> > He was both right and wrong -- patches do break a lot of stuff.  He
> > was facing two problems: the probability of being off the air
> > because of an attack versus the probability of being off the air
> > because of bad interactions between patches and applications.
> > Which is a bigger risk?
> 
> That's an argument for an organizational test environment and testing
> patches before deployment, no? Not an argument against patching. That
> said, I would LOVE to see MS ship a monthly/quarterly unified updater
> that's a one-step way to bring fresh systems up to date without
> slipstreaming the install CD. Then press a zillion of 'em and put
> them everywhere you can find an AOL CD, for all those folks on
> dial-up who see a 200MB download and curl up in the fetal position
> and whimper.
> 

Surveys have shown an inverse correlation between the size of a company
and when it installed XP SP2.  

Yes, you're right; a good test environment is the right answer.  As I
think most of us on this list know, it's expensive, hard to do right,
and still doesn't catch everything.  If I recall correctly, the post I
was replying to said that it was a non-profit; reading between the
lines, it wasn't heavily staffed for IT, or they wouldn't have needed a
consultant to help clean up after Blaster.  And there's one more thing
-- at what point have you done enough testing, given how rapidly some
exploits are developed after the patch comes out?


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Every incident is an opportunity (was Re: Hackers hit key Internet traffic computers)

[Steven M. Bellovin]

On Sat, 10 Feb 2007 23:36:32 -0600
"Stasiniewicz, Adam" <[EMAIL PROTECTED]> wrote:
 
> Another time I was do some consulting work for a NPO.  I was going
> over the findings of my audit and I told the IT manager that all of
> his machines were missing patches.  His response: "we only install
> service packs, individual patches take too much time to install and
> tend to break more stuff than they fix".  Ironically, a month latter
> he calls me back asking for help because his network got infect with
> Blaster...

He was both right and wrong -- patches do break a lot of stuff.  He was
facing two problems: the probability of being off the air because of an
attack versus the probability of being off the air because of bad
interactions between patches and applications.  Which is a bigger risk?

It's not an easy question to answer.  One scenario that scares me is
what happens if the April Patch Tuesday takes out, say, TurboTax, just
as Americans are getting ready to file their tax returns.

There are no good answers to this question.  Of course, being an
academic I can view such problems as opportunities, and it is in fact
a major focus of my research.  Today, though, it's a serious issue for
system managers.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Hackers hit key Internet traffic computers

[Steven M. Bellovin]

On Wed, 7 Feb 2007 10:17:34 -0800
"Aaron Glenn" <[EMAIL PROTECTED]> wrote:

> 
> On 2/7/07, Alexander Harrowell <[EMAIL PROTECTED]> wrote:
> >
> > A caveat - Ndex 4 is usually "situation normal, members bored and
> > discussing the relative merits of the Chicago and Kansas City cable
> > tie knots."
> >
> 
> to be fair that was a pretty informative discussion for those of us
> who were still wearing diapers when ma bell was broken up.
> 
But that aspect was wasted time, since they're putting Ma Bell back
together again...


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: broken DNS proxying at public wireless hotspots

[Steven M. Bellovin]

On Sat, 03 Feb 2007 13:29:13 -0600
Carl Karsten <[EMAIL PROTECTED]> wrote:

> 
> > Sure I could route dns queries out through a ssh tunnel but the
> > latency makes this kind of thing unusable at times. instead of an
> > ssh tunnel, how about simple port forwarding?
> 
> /etc/resolv.conf
> nameserver 127.0.0.1
> 
> And then whatever it takes to forward 127.0.0.1:53 to a dns that is
> listing on some other port?
> 
> hmm, I think running a local caching dns was mentioned, but the parts
> that may have been un-verified:
> 
> man named
> 
> -p port
>Listen for queries on port port. If not specified,
> the  default is port 53.
> 
> man named.conf
>   everywhere there is an address, there is also the option to
> specify port:  ( ipv4_address | * ) [ port ( integer | * ) ]
> 

Right, plus 'forward only' in the config file.

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Google wants to be your Internet

[Steven M. Bellovin]

On Mon, 29 Jan 2007 19:57:24 -0500
Joseph S D Yao <[EMAIL PROTECTED]> wrote:

> 
> On Wed, Jan 24, 2007 at 01:48:04PM -, [EMAIL PROTECTED] wrote:
> ...
> > IPv6 makes NAT obsolete because IPv6 firewalls can provide all
> > the useful features of IPv4 NAT without any of the downsides.
> ...
> 
> IPv6 firewalls?  Where?  Good ones?
> 
Checkpoint claims to have supported IPv6 since 2002:
http://www.checkpoint.com/press/2002/ipv6_081402.html


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: NATting a whole country?

[Steven M. Bellovin]

On Thu, 4 Jan 2007 00:53:23 +0100
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:

> On 4-jan-2007, at 0:31, Steven M. Bellovin wrote:
> 
> > According to
> > http://www.nytimes.com/aponline/technology/AP-TechBit-Wikipedia->
> > Block.html all of Qatar appears on the net as a single IP address.
> 
> I wonder what they use the other 241663 addresses for.
> 
> +-+-+--+--++
> | rir | country | type | descr| num|
> +-+-+--+--++
> | ripencc | QA  | ipv4 | 81.29.160.0  |   4096 |
> | ripencc | QA  | ipv4 | 82.148.96.0  |   8192 |
> | ripencc | QA  | ipv4 | 86.36.0.0| 131072 |
> | ripencc | QA  | ipv4 | 86.62.192.0  |  16384 |
> | ripencc | QA  | ipv4 | 89.211.0.0   |  65536 |
> | ripencc | QA  | ipv4 | 212.77.192.0 |   8192 |
> | ripencc | QA  | ipv4 | 213.130.96.0 |   8192 |
> | ripencc | QA  | ipv6 | 2001:1a10::  | 32 |
> +-+-+--+--++
> 
> They have 0.4 addresses per person in Qatar, which isn't all that
> bad: Italy has 0.33. (Caveats about EU labeled address space etc
> apply.)
> 
Honeypots?

(As I noted, there might also be a port 80 packet filter, combined with
an official web proxy that can get out.)


--Steve Bellovin, http://www.cs.columbia.edu/~smb

NATting a whole country?

[Steven M. Bellovin]

According to
http://www.nytimes.com/aponline/technology/AP-TechBit-Wikipedia-Block.html
all of Qatar appears on the net as a single IP address.  I don't know
if it's NAT or a proxy that you need to use to get out to the world,
but whatever the exact cause, it had a predictable consequence -- the
entire country was barred from editing Wikipedia, due to abuse by
(presumably) a few people.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: on a different "manners" topic, was Re: Phishing...

[Steven M. Bellovin]

> Don't include the email you're responding to then it's no longer top
> posting, plus you can still read the archive easily.
>
It would be nice if mailing list software added the archive URL to all
email forwarded.  Then people could easily say

In http://lists.nanog.org/nanog/2007/01/03/314159.html you
wrote...



--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Regarding NDU.EDU

[Steven M. Bellovin]

On Tue, 2 Jan 2007 21:48:29 GMT
"Fergie" <[EMAIL PROTECTED]> wrote:

> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> They  took their systems offline a few weeks ago:
> 
>  http://www.fcw.com/article97160-12-19-06-Web
> 

Right -- something's definitely going on on that part of the world.
See http://fcw.com/article97178-12-22-06-Web which talks about how DoD
is banning HTML email (what a wonderful thought in any event!) and
Outlook Web Access.  Why?  The threat level has been raised from
Information Condition 5 to Information Condition 4 -- but they won't
say why



--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: would you run this little script, please

[Steven M. Bellovin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 2 Jan 2007 12:48:29 -0500
Marshall Eubanks <[EMAIL PROTECTED]> wrote:

> In the spirit of "trust, but verify," I preferred to read the script.
> 

As did I, when Randy sent it to me earlier for testing...

--Steve Bellovin, http://www.cs.columbia.edu/~smb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (NetBSD)

iQCVAwUBRZqboU7/+MPD/ExpAQL8yAQAsGy/RIiEnVk6Nc9PNu+bGHFhbcdLGJto
Dke0s9YAWcKO+NuYjlnsmcriADO+Nqhs3vgdIy34BY3lM8PKiTuI1+uV9TcytFek
8e5Y4oj/n1d8Zwv37MZdmk0M03Cnn1+whKFH33b9YSeAK3yu7Lf0Flmisu8Ri82g
9gZZC8bl0zM=
=/bUw
-END PGP SIGNATURE-

Re: would you run this little script, please

[Steven M. Bellovin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 2 Jan 2007 07:16:42 -1000
Randy Bush <[EMAIL PROTECTED]> wrote:

> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> > I would be glad to run the script but I just want to verify that it
> > was you who sent it.
> 
> darned good point, ron.  
> 
> yes, it was i.
> 
> randy
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (FreeBSD)
> Comment: Processed by Mailcrypt 3.5.8
> 
> 
> iQCVAwUBRZqTePvCP42xMxQ5AQo1fgP9EkgUcKnjNXfpU3hgVAG0oVwVyxZZtmXq
> xdpUv0oDDeTBeu8QrbgU6UHRY4hWHqHVj30tUq9BQP8+knyYLImPj6ZBoVhtnEta
> uuTo9wUyfZovhpWJtsTNflMHaE1QlhCyLUESAJVHiEQeT0LeY7urA7N9GVWRsH/f
> GZii7iIpna0=
> =0bdG
> -END PGP SIGNATURE-
> 
And the signature even checks out


--Steve Bellovin, http://www.cs.columbia.edu/~smb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (NetBSD)

iQCUAwUBRZqaDU7/+MPD/ExpAQLkYwP48ziUerSczFe4ncncz/qPdbnXPCyo77FX
Jj7Px2w6/oDj1fgW0fP4uO5t8wYvplif9IPdPNvTKTV89LnTehrTBaV7VRo5fTwp
GbxGvqeBia01iwWRCiHJ9oAMYDoYlNnxhdNJjKfIA0BVs9M9duCay+lzWYlZd95D
J7Tb9Pr2Bw==
=ssq5
-END PGP SIGNATURE-

Re: today's Wash Post Business section

[Steven M. Bellovin]

On Wed, 20 Dec 2006 22:48:06 -0500
Edward Lewis <[EMAIL PROTECTED]> wrote:

> 
> Yeah, granted anyone looking for myspace might meet that demographic,
> but how many neophytes would use Google for a "IP Who Is" "search"?
> That's the listing I thought odd.
> 

Maybe it's a script written and run by someone semi-clueful -- or too
clueful to use a real whois server, which might notice the attempt to
enumerate the space.  Google undoubtedly knows in some sense but
doesn't care.

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: The IESG Approved the Expansion of the AS Number Registry

[Steven M. Bellovin]

On Fri, 01 Dec 2006 16:02:55 + (GMT)
"Chris L. Morrow" <[EMAIL PROTECTED]> wrote:

> 
> 
> On Fri, 1 Dec 2006, Andy Davidson wrote:
> >
> > RIPE will be accepting requests for 32-bit ASNs from 1/1/07,
> > according to an email to ncc-services two weeks ago.  It does not
> > feel too early to start to understand what we must do to as a
> > community to guarantee ubiquity of reachable networks.
> 
> So, all of the current devices need to get upgraded before 'day one'
> of 32-bit ASN use... that'll be fun :) Why is RIPE passing out the
> 32-bit ASN's now? aren't there still plenty (+20k or so) 16-bit ASN's
> out there for assignment? (perhaps I'm missing something on the need
> to allocate the new asn's?)
> 
Testing -- better to find out now what breaks, before we really need it.



--Steve Bellovin, http://www.cs.columbia.edu/~smb

experience with Ethernet taps?

[Steven M. Bellovin]

Does anyone have any recommendations for Ethernet tap devices?  Please
reply privately; I'll summarize if there's interest.

    --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Re: UUNET issues?

[Steven M. Bellovin]

On Sun, 05 Nov 2006 07:16:07 -0800, Stephen Satchell <[EMAIL PROTECTED]>
wrote:

> 
> David Lesher wrote:
> > Speaking on Deep Background, the Press Secretary whispered:
> >> On Nov 5, 2006, at 1:51 AM, Randy Bush wrote:
> >>>>>> "Could you be any less descriptive of the problem you are seeing?"
> >>>>> the internet is broken.  anyone know why?
> >>>> Did you ping it?
> >>> is that what broke it?
> >> I'm sure it just needs to be rebooted.
> > Is this the day we disconnect everything and blow all the dirt out?
> 
> You only *think* you are joking.  I still remember the Day of the Great 
> Restart when everyone on the ARPAnet had to shut down the IMPs and TIPs, 
> and reload the control software.  Why?  There were literally thousands 
> of rogue packets flying around the net, eating up bandwidth (and in 
> those days, we are talking 56 kbps links!) and boy were those 
> tubie-thingies plugged up!
> 
> Shortly after that cusp event, per-packet TTL field was added to the NTP 
> protocol, which is why TCP/IP has the TTL field in the IP packet.

I assume you mean NCP rather than NTP.

Anyway, I don't think that would have helped if you're talking about the
same incident I'm thinking of.  There were application-level
retransmissions of (corrupted) packets, complete with building new bad
packets from bad data structures, all over the net

The problem is documented in RFC 789  It and "The Bug Heard 'Round the
World" are two of my favorite "how complex systems fail" papers; all
system designers should read, memorize, and undertand both.
> 
> The network had added to it a self-cleaning function.  Think of it as 
> one long continuous sneeze.
> 


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Re: passports for NANOG-39, Toronto

[Steven M. Bellovin]

On Thu, 26 Oct 2006 10:19:18 -0400, Joe Abley <[EMAIL PROTECTED]>
wrote:

> 
> 
> On 26-Oct-2006, at 09:26, [EMAIL PROTECTED] wrote:
> 
> > You could do the same fly-drive via Detroit but there is
> > a lot more driving.
> 
> Indeed. Rough estimates, excluding time taken to cross the border and  
> assuming good weather:
> 
>BUF to Toronto: 2 hours
>DTW to Toronto: 5 hours
>CLE to Toronto: 6 hours
>LGA to Toronto: 9 hours
>BOS to Toronto: 9 hours
>ORD to Toronto: 10 hours
>IAD to Toronto: 10 hours
> 
Don't neglect the border crossing delay.  Driving home from Montreal after
the IETF, we had to wait close to two hours because of congestion at U.S.
Immigration.  (Of course, that was the way home -- folks going into Canada
had virtually no wait, as best we could see...)


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Re: BCP38 thread 93,871,738,435

[Steven M. Bellovin]

On Thu, 26 Oct 2006 17:07:32 +0200, Florian Weimer <[EMAIL PROTECTED]>
wrote:

> * Steven M. Bellovin:
> 
> > As you note, the 20-25% figure (of addresses) has been pretty constant
> > for quite a while.  Assuming that subverted machines are uniformly
> > distributed (a big assumption)
> 
> I doubt this assumption about distribution is valid.  At least over
> here, consumer-grade ISPs (think DSL with dynamic IP addresses) apply
> ingress filters, while real ISPs don't.  If you're lucky, you get
> egress filters at some border routers, but it's not standard at all.
> Customer-facing interfaces are generally unfiltered.
> 
Those are good points.  It would be interesting to look at the raw AS
data and see what classes of organizations were represented.
Unfortunately, that data is not publicly available, according to the FAQ
for that project. 


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Re: BCP38 thread 93,871,738,435 (was Re: register.com down sev0?)

[Steven M. Bellovin]

On Thu, 26 Oct 2006 02:20:48 -0400 (EDT), Sean Donelan <[EMAIL PROTECTED]>
wrote:

> 
> The only data I have is from the MIT anti-spoofing test project which
> has been pretty consistent for a long time.  About 75%-80% of the nets, 
> addressses, ASNs tests couldn't spoof, and about 20%-25% could.
> 
> The geo-location maps don't show much difference between parts of
> the world.  RIPE countries don't seem to be better or worse than ARIN
> countries or APNIC countries or so on.  ISPs on every continent seem
> to be about the same.
> 
> http://spoofer.csail.mit.edu/summary.php
> 
> If someone finds the silver bullet that will change the remaining 25% or
> so of networks, I think ISPs on every continent would be interested.

That would be nice -- but I wonder how much operational impact that would
have.

As you note, the 20-25% figure (of addresses) has been pretty constant
for quite a while.  Assuming that subverted machines are uniformly
distributed (a big assumption) and assuming that their methodology is
valid (another big assumption), that means we've already knocked out the
75-80% of the sources of spoofed IP address attacks.  Has anyone seen a
commensurate reduction in DDoS attacks?  I sure haven't heard of that.
Are people saying that the problem would be several times worse if
anti-spoofing weren't in place?  As best I can tell, the limiting factor
on attack rates isn't the lack of sources but the lack of a profit motive
for launching the attacks.

Put another way, anti-spoofing does three things: it makes reflector
attacks harder, it makes it easier to use ACLs to block sources, and it
helps people track down the bot and notify the admin. Are people actually
successfully doing either of the latter two?  I'd be surprised if there
were much of either.  That leaves reflector attacks.  Are those that large
a portion of the attacks people are seeing?

I agree that anti-spoofing is a good idea, and I've said so for a long
time.  I was one of the people who insisted that AT&T do it, way back
when.  But I'm not convinced it's a major factor here.


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Re: Collocation Access

[Steven M. Bellovin]

On Mon, 23 Oct 2006 10:40:19 -0700 (PDT), "John A. Kilpatrick"
<[EMAIL PROTECTED]> wrote:

> 
> On Mon, 23 Oct 2006, Craig Holland wrote:
> 
> > In fact he did have an AT&T badge which he was not allowed to hand over
> > either.  The fellow I chatted with at AT&T said they are not allowed to
> > hand over their badge because it would compromise their security.
> 
> My tech said the same thing.  That keycard could grant central office 
> access so he couldn't surrender it.

That's quite likely accurate.  My AT&T badge let me in via unattended
entrances at a variety of facilities; I'd expect that a tech's badge would
indeed work for many COs.

A better answer is for the COLO management to supply a number, on
request, to tenants; they'd pass this number on to their supplier, for
one-time use by the tech.

A government-issued ID (at most) proves your identity; it says nothing
about your authorization to be somewhere.  A company-issued ID (at most)
proves that you work for some company that may or may not (a) be present
at the COLO, and (b) may or may not be there for legitimate reasons.
What's necessary here is *permission*.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Re: Broadband ISPs taxed for "generating light energy"

[Steven M. Bellovin]

On Wed, 11 Oct 2006 13:57:17 -0400, Joseph S D Yao <[EMAIL PROTECTED]>
wrote:

> 
> On Tue, Oct 10, 2006 at 11:36:41AM -0400, Joe Loiacono wrote:
> > Notice the date: October 10. That is the Indian equivalent of our April 1.
> 
> 
> Ah.  Culture clash.  Therefore the story can be relegated to the same
> coop as the IP-carrying pigeons.
> 
> The sole justification for asking this is to help us all remember this
> for any further similar postings that might otherwise cause lengthy and
> weighty discussions on something so lightweight.
> 
> Why is 10 October their 01 April?
> 
It's 10/10, which if viewed as the binary number 1010 is 10 base 10.
Surely that has to mean something!  (Well, I just made it up, but it
sounds goodd)


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Fw: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)

[Steven M. Bellovin]

FYI.  This RFC was inspired by comments at the last NANOG on the
operational problems with 2385.



Begin forwarded message:

Date: Thu, 28 Sep 2006 16:54:00 -0400
From: The IESG <[EMAIL PROTECTED]>
To: IETF-Announce 
Subject: Last Call: 'Key Change Strategies for TCP-MD5' to Informational
RFC (draft-bellovin-keyroll2385) 


The IESG has received a request from an individual submitter to consider
the following document:

- 'Key Change Strategies for TCP-MD5 '
as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2006-10-26.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-bellovin-keyroll2385-03.txt


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

Re: Outages mailing list

[Steven M. Bellovin]

On Fri, 29 Sep 2006 14:24:43 -0700, Jay Hennigan <[EMAIL PROTECTED]> wrote:

> 
> Rick Kunkel wrote:
> > I thought about cutting and pasting verbatim the notification I got from
> > InterNAP, but then noticed the "The contents of this email message are
> > confidential and proprietary" blurb at the end, and thought better of it,
> > even though they weren't to blame...
> 
> Somebody actually reads those???
> 
While in general I agree with your point, this case may be different -- it
may be governed by the contract Rick has with InterNAP.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Re: fyi-- [dns-operations] early key rollover for dlv.isc.org

[Steven M. Bellovin]

On Fri, 22 Sep 2006 17:01:31 -0700 (PDT), Gregory Hicks
<[EMAIL PROTECTED]> wrote:


> > 
> > 
> > On Fri, Sep 22, 2006 at 11:39:51PM +, Fergie wrote:
> > > Hmmm. It wouldn't have anything to do with prime numbers, now would
> > > it? :-)
> > 
> > 
> > Well, yes, but there are an infinite number of them.
> > 
> > Of course, 17 is the most prime of them all.
> 
> isc.org announced the early key rollover just as a discussion about
> "exponent 3 damage spreads" on the cryptography list was heating up.
> 
> This discussion started with a statement that:
> 
> > I've just noticed that BIND is vulnerable to:
> >
> > http://www.openssl.org/news/secadv_20060905.txt
> >
> > Executive summary:
> >
> > RRSIGs can be forged if your RSA key has exponent 3, which is BIND's
> > default. Note that the issue is in the resolver, not the server.
> >
> > Fix:
> >
> > Upgrade OpenSSL.
> 
> So I thought that the early key rollover was due to this.  Yet it seems
> to me that this discussion is still recommending that "-e 3" be used.
> 

There are no known attacks on e=3 *if* everything else is done properly.
There have, however, been many different attacks if mistakes are made,
such as the implementation attacks here or various problems with the
padding scheme.  See, for example, 

http://www.rsasecurity.com/rsalabs/staff/bios/bkaliski/publications/hash-firewalls/kaliski-hash-firewalls-ct-rsa-2002.pdf
http://citeseer.ist.psu.edu/746101.html
http://citeseer.ist.psu.edu/coppersmith96lowexponent.html

Poking through the cryptanalytic literature shows many other problems
and near-problems with small exponents and RSA.  My conclusion is that e=3
is too fragile -- it's too easy to make mistakes (or do things that are
later determined to be mistakes by mathematicians).  

NIST's latest draft of FIPS-186-3 says:

   (b) The exponent e shall be an odd positive integer such that
   65,537 <= e < 2**(nlen - 2*security_strength)
   where nlen is the length of the modulus n in bits.

("security_strength" appears to be the symmetric system attack work factor,
i.e., 128 for AES-128.)  They don't give a reason; we can assume, though,
that their friends in Ft. Meade specified it.  (Why the upper bound?  It
turns out that you don't want the decryption exponent to be too small,
either...)

So -- my very strong recommendation is that e=3 be avoided.  For
efficiency in implementation, numbers of the form 2^2^n+1 are good for e.
Numbers of that form are known as "Fermat Numbers"; see
http://en.wikipedia.org/wiki/Fermat_prime .  e=5 is almost as vulnerable
as e=3, especially for larger RSA moduli. e=17 might be at risk for really
large moduli to match large AES keys (see RFC 3766).  I don't know why F3
(257) isn't a good choice, but 65537 has been a popular alternative for
years.  

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Re: fyi-- [dns-operations] early key rollover for dlv.isc.org

[Steven M. Bellovin]

On Fri, 22 Sep 2006 19:29:31 -0400, Joseph S D Yao <[EMAIL PROTECTED]>
wrote:


> 
> Not having committed the maths to heart, I might be able to explain it a
> little differently.

Well, yes, I did just teach the RSA equations to my Network Security
class


            --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Re: fyi-- [dns-operations] early key rollover for dlv.isc.org

[Steven M. Bellovin]

On 21 Sep 2006 17:01:45 +, Paul Vixie <[EMAIL PROTECTED]> wrote:


> 
> > Paul, what exponent does the new key use?  (I clicked on the public key
> > link, but I can't decode the base64 that easily...)
> 
> it was made with bind9's "dnssec-keygen" utility, using the -e option, so...
> 
> -e use large exponent (RSAMD5/RSASHA1 only)
> 
> ...hopefully it's a good exponent.  (every few years someone tries to explain
> to me what a key exponent is, i think you steve have tried, but it just 
> doesn't
> stick.)

It's pretty simple, if you don't want to understand why it works...

An RSA public key is the pair ; the private key is .  'n' is the
famous product of two primes; e and d have a particular mathematical
relationship relative to those two primes.  Broadly speaking, to generate
an RSA key, you find two large random primes, pick a more-or-less
arbitrary number for e, then use e and the two primes to calculate d.  You
encrypt (or verify a signature) by calculating m^e mod n; you decrypt or
sign by calculating m^d mod n.  The question is how arbitrary e can be.

>From a mathematical perspective -- that is, making the equations work,
but not necessarily being secure -- e can be any odd number greater
than 1 that isn't a multiple of either prime, i.e., from 30,000 feet it
doesn't matter too much what you pick as long as it's odd. For years,
people have used 3, because it makes calculations that use e -- in
particular, signature verification -- much more efficient. RFC 3110, for
example, recommends 3 for DNSSEC.  (Demonstration of that is left as an
exercise for the programmer.)

The problem, from my perspective, is that there have been a fair number of
attacks over the last several years that work only for low exponents such
as 3.  All of them are special-case attacks; they rely on something else
being true.  This latest one relies on an implementation bug and (roughly
speaking) the fact that many more numbers are cube roots than are, say,
65537th roots.  Again, without going into details, it turns out that the
bug was easy to commit, arguably because of glitches in the standard, and
OpenSSL had it.

>From my perspective, the deeper issue is that exponent 3 seems to be
fragile -- there have been so many different attacks on it that I suspect
we'll see many more.  The only solution is to avoid the fragility.  For
reasons I don't understand, 65537 is a frequently-recommended larger
exponent.  NIST, in fact, requires that exponents be at least that large.
(Their suggested upper bound is more mysterious to me.)  Anyway, 65537 is
reasonably efficient, though not nearly as good as 3.  However, its
density of 0 bits helps a lot.

I tried figuring out just what -e does, but I ended up in a maze of twisty
little indirect function calls.  But almost anything is going to be better
than 3.  (I'm probably going to write a BCP on that.)


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Re: fyi-- [dns-operations] early key rollover for dlv.isc.org

[Steven M. Bellovin]

Paul, what exponent does the new key use?  (I clicked on the public key
link, but I can't decode the base64 that easily...)

Re: Zimbabwe satellite service shutdown for non-payment

[Steven M. Bellovin]

On Tue, 19 Sep 2006 08:23:17 -0400, Joe Abley <[EMAIL PROTECTED]>
wrote:

> 
> 
> On 2006-09-19, at 03:59, Brandon Galbraith wrote:
> 
> > Does any fiber run into Zimbabwe? Or is everything via satellite?
> 
> Having fibre to your neighbiour is the exception in Africa, not the  
> rule.
> 
Remember the (proposed?  built?) circum-Africa oceanic cable, with drops to
each (coastal) country?  Avoid the politics and instability of depending
on a neighbor.


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb