Re: Routing Loop

[Florian Weimer]

There's also somewhat odd data in RADB (look at the changed: line):

route: 194.9.64.0/19
descr: SES-Newskies Customer Prefix
origin:AS16422
remarks:   SES-Newskies Customer Prefix
notify:[EMAIL PROTECTED]
mnt-by:MNT-NWSK
changed:   [EMAIL PROTECTED] 20080314
source:ARIN

This is in the middle of RIPE-managed swamp space, a /19 definitely
doesn't belong there.

Re: EU Official: IP Is Personal

[Florian Weimer]

* Eric Brunner-Williams:

> However, Google/DoubleClick claim they have the right to collect PII
> data and disclose less than their complete data collection policy, and
> in particular, claim that endpoint identifiers do not tend to identify
> individuals. Further, they assert a property claim on such collected
> data.

If IP addresses don't identify anything, why do they collect and keep
them?

Anyway, mandatory data retention seems to change the consensus whose job
it is to retain a certain level of perceived anonymity.  Even if the
retention policies do not actually change that much, it's usually
assumed that the ISPs do no good job at protecting customer identity
anymore.  (You have to see this in a context where most of the consumer
Internet connections change their assigned IP address at least once a
day, which explains the old expectation to some degree.)  Now that ISPs
are out of the loop, the attention turns to folks at higher protocol
levels.  Some folks probably think that by complaining loadly enough,
they might be hosting a Google Privacy Research Center soon, or
something like that. *sigh*

Re: v6 subnet size for DSL & leased line customers

[Florian Weimer]

* Tim Durack:

> Probably why some vendors support "dhcp snooping" and "private vlans" for
> IPv4 - multiple clients per subnet with isolation.

The isolation is far from perfect because you don't know from which host
the packet actually came. 8-(

Re: v6 subnet size for DSL & leased line customers

[Florian Weimer]

* Leo Bicknell:

> In a message written on Tue, Dec 25, 2007 at 12:43:45AM -0500, Kevin Loch 
> wrote:
>> RA is a shotgun.  All hosts on a segment get the same gateway.  I have 
>> no idea what a host on multiple segments with different gateways would 
>> do.  Hosting environments can get complex thanks to customer
>
> I would like to point out that in IPv4 we have ICMP Router
> Advertisement messages.  I have never seen them used on a production
> network.  I know one of the worries is security, that a compromised host
> could send out advertisements, drawing traffic to it that it can then
> snoop and pass on to the real gateway.

DHCP and ARP face the same issue.  That's why "one host per subnet" is
so appealing.

Re: v6 subnet size for DSL & leased line customers

[Florian Weimer]

* Joe Greco:

>> Right now, we might say "wow, 256 subnets for a single end-user... 
>> hogwash!" and in years to come, "wow, only 256 subnets... what were we 
>> thinking!?"
>
> Well, what's the likelihood of the "only 256 subnets" problem?

There's a tendency to move away from (simulated) shared media networks.
"One host per subnet" might become the norm.

Re: European ISP enables IPv6 for all?

[Florian Weimer]

* Sebastian Abt:

> * Florian Weimer wrote:
>> Does PPPv6 still work on the T-DSL platform? 8-/
>
> Yes, it does.

Oh.  What happened to the C10K PPPoE length field bug (CSCsd13298, if
I'm not mistaken)?

-- 
Florian Weimer<[EMAIL PROTECTED]>
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: European ISP enables IPv6 for all?

[Florian Weimer]

* Jeroen Massar:

> For a list of ISP's doing IPv6 check:
> http://www.sixxs.net/faq/connectivity/?faq=native

Does PPPv6 still work on the T-DSL platform? 8-/

The list would be more convincing if it contained links to product
pages.

-- 
Florian Weimer<[EMAIL PROTECTED]>
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: Creating a crystal clear and pure Internet

[Florian Weimer]

* Jared Mauch:

>   Within the next 2 major software releases (Microsoft OS) they're
> going to by default require signed binaries.  This will be the only viable
> solution to the malware threat.  Other operating systems may follow.
> (This was a WAG, based on gut feeling).

The code signing CAs have never been subject to serious attack.  It's
unlikely that they are sufficiently robust for this scheme to work on a
large scale.

There's also the issue that you can't reliably tell data (which,
presumably, does not need to be signed) from code.

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

[Florian Weimer]

* Sean Donelan:

> I just wish the IETF would acknowledge this and go ahead and define a
> DNS bit for artificial DNS answers for all these "address correction"
> and "domain parking" and "domain tasting" people to use for their keen
> "Web 2.0" ideas.
>
> And for all the other non-Web protocols which get confused, can treat
> that artificially generated crap/answers like NXDOMAIN.

It's not that simple, you need three states: original, rewritten NODATA,
and rewritten NXDOMAIN.  Perhaps a general "original RCODE" is
necessary; I haven't checked this.

Re: Can P2P applications learn to play fair on networks?

[Florian Weimer]

* Adrian Chadd:

> So which ISPs have contributed towards more intelligent p2p content
> routing and distribution; stuff which'd play better with their
> networks?

Perhaps Internet2, with its DC++ hubs? 8-P

I think the problem is that better "routing" (Bittorrent content is
*not* routed by the protocol AFAIK) inevitably requires software
changes.  For Bittorrent, you could do something on the tracker side:
You serve .torrent files which contain mostly nodes which are
topologically close to the requesting IP address.  The clients could
remain unchanged.  (If there's some kind of AS database, you could even
mark some nodes as local, so that they only get advertised to nodes
within the same AS.)  However, there's little incentive for others to
use your tracker software.  What's worse, it's even less convenient to
use because it would need a BGP feed.

It's not even obvious if this is going to fix problems.  If
upload-related congestion on the shared media to the customer is the
issue (could be, I don't know), it's unlikely to help to prefer local
nodes.  It could make things even worse because customers in one area
are somewhat likely to be interested in the same data at the same time
(for instance, after watching a movie trailer on local TV).

Re: Can P2P applications learn to play fair on networks?

[Florian Weimer]

* Sean Donelan:

> On Sun, 21 Oct 2007, Florian Weimer wrote:
>>> If its not the content, why are network engineers at many university
>>> networks, enterprise networks, public networks concerned about the
>>> impact particular P2P protocols have on network operations?  If it was
>>> just a single network, maybe they are evil.  But when many different
>>> networks all start responding, then maybe something else is the
>>> problem.
>>
>> Uhm, what about civil liability?  It's not necessarily a technical issue
>> that motivates them, I think.
>
> If it was civil liability, why are they responding to the protocol being
> used instead of the content?

Because the protocol is detectable, and correlates (read: is perceived
to correlate) well enough with the content?

>> If there is a technical reason, it's mostly that the network as deployed
>> is not sufficient to meet user demands.  Instead of providing more
>> resources, lack of funds may force some operators to discriminate
>> against certain traffic classes.  In such a scenario, it doesn't even
>> matter much that the targeted traffic class transports content of
>> questionable legaility.  It's more important that the measures applied
>> to it have actual impact (Amdahl's law dictates that you target popular
>> traffic), and that you can get away with it (this is where the legality
>> comes into play).
>
> Sandvine, packeteer, etc boxes aren't cheap either.

But they try to make things better for end users.  If your goal is to
save money, you'll use different products (even ngrep-with-tcpkill will
do in some cases).

> The problem is giving P2P more resources just means P2P consumes more
> resources, it doesn't solve the problem of sharing those resources
> with other users.

I don't see the problem.  Obviously, there's demand for that kind of
traffic.  ISPs should be lucky because they're selling bandwidth, so
it's just more business for them.

I can see two different problems with resource sharing: You've got
congestion not in the access network, but in your core or on some
uplinks.  This is just poor capacity planning.  Tough luck, you need to
figure that one out or you'll have trouble staying in business (if you
strike the wrong balance, your network will cost much more to maintain
than what the competition pays for therir own, or it will inadequate,
leading to poor service).

The other issue are ridiculously oversubscribed shared media networks on
the last mile.  This only works if there's a close-knit user community
that can police themselves.  ISPs who are in this situation need to
figure out how they ended up there, especially if there isn't cut-throat
competition.  In the end, it's probably a question of how you market
your products ("up to 25 Mbps of bandwidth" and stuff like that).

>> In my experience, a permanently congested network isn't fun to work
>> with, even if most of the flows are long-living and TCP-compatible.  The
>> lack of proper congestion control is kind of a red herring, IMHO.
>
> Why do you think so many network operators of all types are
> implementing controls on that traffic?

Because their users demand more bandwidth from the network than actually
available, and non-user-specific congestion occurs to a significant
degree.  (Is there a better term for that?  What I mean is that not just
the private link to the customer is saturated, but something that is not
under his or her direct control, so changing your own behavior doesn't
benefit you instantly; see self-policing above.)  Selectively degrading
traffic means that you can still market your service as "unmetered
25 Mbps", instead of "unmetered 1 Mbps".

One reason for degrading P2P traffic I haven't mentioned so far: P2P
applications have got the nice benefit that they are inherently
asynchronous, so cutting the speed to a fraction doesn't fatally impact
users.  (In that sense, there isn't strong user demand for additional
network capacity.)  But guess what happens if there's finally more
demand for streamed high-entropy content.  Then you'll have got not much
choice; you need to build a network with the necessary capacity,

Re: Can P2P applications learn to play fair on networks?

[Florian Weimer]

* Eric Spaeth:

> Of that group, only DSL doesn't have a common upstream bottleneck
> between the subscriber and head-end.

DSL has got that, too, but it's much more statically allocated and
oversubscription results in different symptoms.

If you've got a cable with 50 wire pairs, and you can run ADSL2+ at 16
Mbps downstream on one pair, you can't expect to get full 800 Mbps
across the whole cable, at least not with run-of-the-mill ADSL2+.
(Actual numbers may be different, but there's a significant problem with
interference when you get closer to theoretical channel limits.)

Re: Can P2P applications learn to play fair on networks?

[Florian Weimer]

* Sean Donelan:

> On Sun, 21 Oct 2007, Mikael Abrahamsson wrote:
>> If your network cannot handle the traffic, don't offer the services.
>
> So your recommendation is that universities, enterprises and ISPs
> simply stop offering all Internet service because a few particular
> application protocols are badly behaved?

I think a lot of companies implement OOB controls to curb P2P traffic,
and those controls remain in place even without congestion on the
network.  It's like making sure that nobody uses the company plotter to
print posters.

In my experience, a permanently congested network isn't fun to work
with, even if most of the flows are long-living and TCP-compatible.  The
lack of proper congestion control is kind of a red herring, IMHO.

Re: Can P2P applications learn to play fair on networks?

[Florian Weimer]

* Sean Donelan:

> If its not the content, why are network engineers at many university
> networks, enterprise networks, public networks concerned about the
> impact particular P2P protocols have on network operations?  If it was
> just a single network, maybe they are evil.  But when many different
> networks all start responding, then maybe something else is the
> problem.

Uhm, what about civil liability?  It's not necessarily a technical issue
that motivates them, I think.

> The traditional assumption is that all end hosts and applications
> cooperate and fairly share network resources.  NNTP is usually
> considered a very well-behaved network protocol.  Big bandwidth, but
> sharing network resources.  HTTP is a little less behaved, but still
> roughly seems to share network resources equally with other users. P2P
> applications seem to be extremely disruptive to other users of shared
> networks, and causes problems for other "polite" network applications.

So is Sun RPC.  I don't think the original implementation performs
exponential back-off.

If there is a technical reason, it's mostly that the network as deployed
is not sufficient to meet user demands.  Instead of providing more
resources, lack of funds may force some operators to discriminate
against certain traffic classes.  In such a scenario, it doesn't even
matter much that the targeted traffic class transports content of
questionable legaility.  It's more important that the measures applied
to it have actual impact (Amdahl's law dictates that you target popular
traffic), and that you can get away with it (this is where the legality
comes into play).

Re: 240/4

[Florian Weimer]

* Pekka Savola:

> Do we need to classify anything (yet)?
>
> I say the proof is in the pudding.  Once some major user decides
> they'll need 240/4 for something, they'll end up knocking their
> vendors' (probably dozens) and their own ops folks' doors.

If there's risk that we'll see end user assignments from 240/4 at any
time in the future, this certainly reduces the set of possible
experiments even further.  So I think it makes sense to designate part
of it as "private use, not subject to allocation" if anybody sees any
benefit from encouraging experimentation.

Re: How to Handle ISPs Who Turn a Blind Eye to Criminal Activity?

[Florian Weimer]

* Steve Bertrand:

>> Anyway, if you've got a customer account that was created with a stolen
>> credit card, and you get complaints about activity on that account from
>> various parties, and you still don't act, this shows a rather
>> significant level of carelessness.  
>
> Further to carelessness, this may be pushing the boundary in many places
> of guilt by act of omission.

I'm not familiar with the finer points of the US criminal code.  I'm
rather skeptical that such a risk actually exists (Foonet/CSI
notwithstanding).  If people actually cared about compromises, I would
be more concerned that not handling abuse complaints would expose ISPs
to liability from their own customers, who would have learnt earlier
about their compromise if the ISP told them.

Part of the reason why this discussion is somewhat heated is that
there's zero incentive in most markets to deal with customer
compromises.  Otherwise, people would just lean back and think, "yeah,
right, let them try and see how it works for them".

Re: How to Handle ISPs Who Turn a Blind Eye to Criminal Activity?

[Florian Weimer]

* Mike Lewinski:

> Florian Weimer wrote:
>
>> I don't know what case prompted Ferg to post his message to NANOG, but I
>> know that there are cases where failing to act is comparable to ignoring
>> the screams for help of an "alleged" rape victim during the "alleged"
>> crime.
>
> I'm reminded of this story from earlier this year:
>
> http://www.jsonline.com/story/index.aspx?id=568400
>
> "For his effort, Van Iveren was charged with criminal trespass while
> using a dangerous weapon, criminal damage to property while using a
> dangerous weapon and disorderly conduct while using a dangerous
> weapon, all criminal misdemeanors that carry a maximum total penalty
> of 33 months in jail."

That guy was no foreigner to the local police, apparently.  I couldn't
find anything regarding the outcome of his court appearance.  Of course,
if you run to the help of those in apparent need, you always risk
looking very stupid.

Anyway, if you've got a customer account that was created with a stolen
credit card, and you get complaints about activity on that account from
various parties, and you still don't act, this shows a rather
significant level of carelessness.  The other side of the story is that
it takes months to get local police to forward the criminal complaint to
state police, and state police to issue an order for seizure, even in
areas of Germany where I thought we had pretty good LE coverage.

Re: Content Delivery Networks

[Florian Weimer]

* Rodney Joffe:

> Do you have any real examples of significant recursive servers doing
> this?

nscd in GNU libc has issues related to cache expiry.  I'm not sure if
it is general brokenness, or some TTL-related issue.  It's use is not
terribly widespread, and it's a host-specific cache only, but there's
a certain installation base.

-- 
Florian Weimer<[EMAIL PROTECTED]>
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: Questions about populating RIR with customer information.

[Florian Weimer]

* Drew Weaver:

> Up until recently, we were only providing the RIR database with
> information about our larger allocations /24 or larger. We have
> noticed however that many anti-spam organizations such as Spamhaus,
> and Fiveten will use the lack of information regarding an IP
> allocation as a blank check to blacklist entire /24s when they are
> really targeting a single /30 or a /29.

I don't know how this translates to actual blacklist entries, but for
submitting complaints, blacklist operators ignore the smaller
networks, whether they are in WHOIS or not.  I would also expect that
if you've got a significant spamming problem, some blacklists will try
to entice *you* to do something about it proactively.  Overblocking is
often used for that purpose.

Re: Port 587 vs. 25

[Florian Weimer]

* Patrick W. Gilmore:

> IOW: ISPs have no real reason to stop port 587, they do have a reason
> (whether you agree it is sufficient or not) to filter port 25.

Sorry for being unclear: If I block 25/TCP to *my* *own* servers for a
*customer*, I will make sure that I block 587/TCP as well.
(Legitimate reasons would be infrastructure protection, for instance.)

This subthread started by someone who reported that someone else had
been prevent from accessing their ISP's smarthosts over 25/TCP.  This
is not a 25 vs 587 issue, AFAICT.

Re: DNS Hijacking by Cox

[Florian Weimer]

* Sean Donelan:

> On Sun, 22 Jul 2007, William Allen Simpson wrote:
>> Comcast still blocks port 25.  And last week, a locally well-known person
>> was blocked from sending outgoing port 25 email to their servers from her
>> home Comcast service.
>
> MSA port 587 is only 9 years old.  I guess it takes some people longer
> than others to update their practices.

You missed the "to their servers" part (I don't think it's singular
"they" 8-).  At the intra-ISP level, submission vs. SMTP does not
really matter because it's all local policy.  If they block her on
25/TCP on their own servers, they can easily block her on 587/TCP,
too.

Should I worry about bogus route registry entries?

[Florian Weimer]

Recent events prompted me to look at a few routing registries for
information on prefixes dear to me.  I have to admit that I don't like
what I see.  There are quite a few RRs which publish illegitimate
shorter prefixes which cover the ones I'm interested in.  A few months
ago, I looked into this issue for other reasons, and had one or two of
them removed, but this is a bit tedious -- especially since some of
the databases are not public and are only revealed by other RRs.

Should I care about this on-paper prefix hijacking?  Is it worthwhile
to set up some kind of monitoring?  Is there a blacklist of RRs which
are known to deliver mostly bogus data to other RRs?

-- 
Florian Weimer<[EMAIL PROTECTED]>
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: Network Level Content Blocking (UK)

[Florian Weimer]

* Jeroen Massar:

> I wonder how this solves the, from what I found out, common situation
> that people rent cheap "root servers" in a country like Germany where
> they VPN into and thus have full access to everything.

In Germany, the legal framework for filtering transit traffic already
exists, so if the UK precedent shows that it's technically and
economically feasible, this will be implemented over here, too.  I
doubt the situation is much different in most European countries.

Of course, when the blocking is pretty much universal, I don't really
see how the list maintainer verifies that the reason for blocking
still exists.  On the other hand, this might also provide an
opportunity to shut down some of the most egregious malware
distributors and controllers.

Re: Whois and the DoD

[Florian Weimer]

* Hank Nussbacher:

> Based on http://www.iana.org/assignments/ipv4-address-space I would
> assume IANA might be interested in mandating that any organization
> having IP space from them must operate an accessible whois server.

For new address space, I agree.  I'm not sure if it's worth the
trouble to create a policy for this.  Presumably, this is all about
legacy allocations which hardly change, so anyone could compile a
machine-readable list and have them put into the popular clients.

(I assume you mean information such as "this netblock has been given
to that organization", not meaningful WHOIS for sub-allocations.)

Re: Broadband routers and botnets - being proactive

[Florian Weimer]

* Suresh Ramasubramanian:

> As frequent as Gadi is with his botnet posts, insecure and wide open
> CPE getting deployed across a large provider is definitely
> operational.

And if Gadi's examples are not scary enoug for you, there are far more
relevant vulnerabilities.

It seems that the organization that assembles most of the firmware on
those CPEs just takes the Sourceforge project with the smallest
footprint they can find to implement a particular task.  Not even a
cursory code review takes place.  As most of the software is GPLed,
not just the firmware provider, but also the hardware manufacturer and
the ISP itself could stop the deployment until the most egregious bugs
have been fixed.  Of course, you could argue that if Microsoft and
Debian don't do this, why should ISPs?  To me, the answer is that
shipping vulnerable software is state of the art, but only if there is
some kind of patch management appendix.

Fortunately, there is a simple solution to this kind of problem: ISPs
are very likely liable if they fail to alert customers about security
problems, and do not provide updates in a timely manner.  After a few
painful incidents, the ISPs will learn, and either ship better
software (unlikely) or implement some kind of patch management.  With
a bit of luck, the latter does not just shift back liability back to
the customer, but also helps to parly solve the problem (in the sense
that CPE attacks are less attractive).

Re: Question on 7.0.0.0/8

[Florian Weimer]

* Rene Huizinga:

> Well, at least is is still somehow with the same party...

Not quite.  The organization formerly known as "debis" is now called
"T-Systems".

> Arin states 'Mercedes Benz AG', RIPE 'Daimler Chrysler'... One would
> think this would/should actually be just the other way around, but
> never mind :)

"Daimler Benz AG" would have been more appropriate.  Mercedes Benz was
just the car manufacturer--but I'm not sure if the split was there in
1992.

Until about a year ago, T-Systems actually used parts of the netblock
for some hosted servers (Deutsche Post, for instance).  But in the
meantime, they've got non-legacy address space and are no longer in
the "extra-small" category as far as their RIPE membership is
concerned.

Re: Question on 7.0.0.0/8

[Florian Weimer]

* Iljitsch van Beijnum:

> Ok, I wasn't clear: the problem here is that both ARIN and RIPE claim
> net 25.0.0.0/8 as "their own".

This is pretty standard for European /8.  53/8 is yet another example
(Germany has moved to five-digit zip codes since that entry was last
updated).

At a previous job, I tried to fix our netblocks in the ARIN database.
It turned out that legal representation in the U.S. was necessary, so
it wasn't worth the trouble.  Fortunately, ERX cleaned it up for us a
few years later.

Looks like the legacy /8s still need to be ERXed.

Re: Thoughts on increasing MTUs on the internet

[Florian Weimer]

* 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 just wanted to point out that the main reason why this couldn't be
done without breaking backwards compatibility is gone (shared physical
medium with unknown and unforeseeable receiver capabilities).

> I'll also note that the IETF is very unlikely to challenge IEEE on
> this.

It's certainly unwise to do so before PMTUD works without ICMP
support. 8-)

Re: Thoughts on increasing MTUs on the internet

[Florian Weimer]

* 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.

Re: On-going Internet Emergency and Domain Names

[Florian Weimer]

* Paul Vixie:

> since malware isn't breaking dns, and since dns not a vector per se,
> the idea of changing dns in any way to try to control malware
> strikes me as a way to get dns to be broken in more places more
> often.

Well, once more people learn about DLV (especially the NS override
extension that has been requested by zone operators), more and more
questions will pop up why we can't do this for NS records they don't
like for some reason.  The genie is out of the bottle, I'm afraid.

> in practical terms, and i've said this to you before, you'll get as
> much traction by getting people to switch from windows to linux as
> you'd get by trying to poison dns.  that is, neither solution would
> be anything close to universal.  that rules it out as an
> "alternative we can use today".

The legal details for operating and using a lookaside zone are rather
interesting, which strongly suggests that this isn't a solution that
can be rolled out in a reasonable time frame.  On the more technical
side, some very large operators have mostly out-sourced their DNS
operation, so they can't easily deploy an upgrade from ISC even if it
were available today.

> at the other end, authority servers which means registries and
> registrars ought, as you've oft said, be more responsible about
> ripping down domains used by bad people.  whether phish, malware,
> whatever.  what we need is some kind of public shaming mechanism, a
> registrar wall of sheep if you will, to put some business pressure
> on the companies who enable this kind of evil.

I fear that many registrars make most of their money with trademark
violations of their customers.  If that is indeed true, showing any
sign of responsibility could be suicidal.

Re: On-going Internet Emergency and Domain Names

[Florian Weimer]

* Fergie:

> While the 0-day exploit is the ANI vulnerability, there are many,
> many compromised websites (remember the MiamiDolhins.com embedded
> javascript iframe redirect?) that are using similar embedded .js
> redirects to malware hosted sites which fancy this exploit.
>
> And some of them have vast audiences, increasing the potential
> for a major "issue" -- TBD.

In today's world of ubiquitous advertising, vast audiences equal lots
of money.  That's why this is a problem which a few class-action suits
can and will fix.

The hard problem is repeated damage done by many small incidents.

Re: [cacti-announce] Cacti 0.8.6j Released (fwd)

[Florian Weimer]

* Ray Burkholder:

> How about something like:
> http://www.hdfgroup.org/whatishdf5.html

I don't think they support transactional updates, which makes it hard
to use for live data.  (A simple crash, and you need to recover from
backup.)

-- 
Florian Weimer<[EMAIL PROTECTED]>
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: Google wants to be your Internet

[Florian Weimer]

* Rodrick Brown:

> "Right now somewhat more than half of all Internet bandwidth is being
> used for BitTorrent traffic, which is mainly video. Yet if you
> surveyed your neighbors you'd find that few of them are BitTorrent
> users. Less than 5 percent of all Internet users are presently
> consuming more than 50 percent of all bandwidth."

s/BitTtorrent/porn, and we've been there all along.

I think the real issue here is that Google's video traffic does *not*
clog the network, but would be distributed through private networks
(sometimes Google's own, or through another company's CDN) and
injected into the Internet very close to the consumer.  No one is able
to charge for that traffic because if they did, Google would simply
inject it someplace else.  At best your, one of your peerings would go
out of balance, or at worst, *you* would have to pay for Google's
traffic.

Re: Phishing and BGP Blackholing

[Florian Weimer]

* Neil J. McRae:

> I didn't see the original post but the topic came
> up in 2005 here in the UK as the banks here wanted to
> use BGP filtering in the same light. The LINX prepared
> a paper on the issues with BGP blackholing and recommended
> that if the banks want to trade on the Internet that
> they should introduce authentication systems that are fit
> for purpose (SecureID for example (many banks had already
> done this)).

Banks have deployed much more secure systems than SecureID, and there
have been successful attacks against them.

SecureID might be helpful if you want to differentiate your product
between automatic and manual use, but it doesn't do anything to
authenticate the party you are relaying information to.  But it's
useless in a phishing context.  If you want a token solution, at least
use something that factors in transaction-related data.

Re: would you run this little script, please

[Florian Weimer]

* Randy Bush:

>> 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.

Ah, thanks, I've saved your message and its signature.  It could prove
useful in the future for some kind of social engineering attack. 8-P

Re: Bogon Filter - Please check for 77/8 78/8 79/8

[Florian Weimer]

* Jared Mauch:

>   My recommendation is to write a letter (in german) and fax it
> over to their fax# with the urls clearly written out (eg: iana vs
> their url) showing the problem with the address space.  it'll likely
> sufficently confuse someone that they'll be curious and research it
> and solve the problem.

Isn't completewhois.com William's project?  I doubt he cares about
German letters if he doesn't even notice the peer pressure on NANOG.

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

[Florian Weimer]

* Chris L. Morrow:

>> | 6. Transition
>> |
>> |The scheme described in this document allows a gradual transition
>> |from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one
>> |Autonomous System or one BGP speaker at a time.
>>
>> Routers on stub ASs don't need upgrading at all, for instance.
>
> but filter lists and such I imagine might :(

Only if you want to keep your fine-grained filters, which shouldn't be
a problem over the next few years.  From a purely BGP 4 perspective,
the transition looks like a new tier 1 ISP entering the stage.

(But if more than one of your peers switch, you better upgrade as
well.)

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

[Florian Weimer]

* Chris L. Morrow:

> So, all of the current devices need to get upgraded before 'day one' of
> 32-bit ASN use... that'll be fun :)

| 6. Transition
| 
|The scheme described in this document allows a gradual transition
|from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one
|Autonomous System or one BGP speaker at a time.

Routers on stub ASs don't need upgrading at all, for instance.

Re: rbnnetwork.org

[Florian Weimer]

* Alexander Harrowell:

>66.36.240.2 AS14361
> HOPONE-DCA   c-vl102-d1.acc.dca2.hopone.net.255
> US  Unix: 14:38:16.496
> 2   0   2   6   0.6 ms [+0ms]

Uhm, are you a Hop One customer?  In this case, it's a bit ... strange
that you complain about malicious services hosted on other people's
networks.

Re: BCP38 thread 93,871,738,435 + SPF

[Florian Weimer]

* Douglas Otis:

> Spam being sent through Bot farms has already set the stage for
> untraceable DNS attacks based upon SPF.  In addition to taking out major
> interconnects, these attacks can:
>
>  a) inundate authoritative DNS;
>
>  b) requests A records from anywhere;
>
>  c) probe IP address, port, and the transaction IDs of resolvers;

(b) and (c) are not new developments because lots of MTAs already
perform A lookups on HELO arguments, and MX lookups on sender domains.

> While not as bad as eavesdropping, it still places the network and the
> integrity of DNS at risk.  All of this while the spam is still being
> delivered.  What a productivity tool!

The purpose of SPF, as it is deployed, is to facilitate routing
solicited bulk email around spam filters.  Look at email.bn.com/IN/TXT
to get the idea.  This application requires some of the indirection
features offered by SPF.

Re: ICMP & PathMTU

[Florian Weimer]

* Jim Popovitch:

> Two questions for everybody...(any and all responses appreciated, even
> if the reply mentions botnets or hammers ;-) )
>
> 1) What value is ICMP if everybody pretty much considers it's accuracy
> suspect?

The problem with ICMP-based traceroutes is that it doesn't necessarily
test the path you are interested in.  Use tcptraceroute or traceproto
instead.

Of course, this doesn't solve the problem that TTL Exceeded messages
might be generated with very low priority, which is in generally a
very good idea.

> 2) How does ICMP's suspect nature affect Path MTU?

In this case, you're interested in the ICMP payload, not the fact
whether an ICMP packet goes through or not.  (You lose if someone
filters ICMP, though.)

Re: BCP38 thread 93,871,738,435

[Florian Weimer]

* 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.

(But I have to admit that we recently ran into filters at an
upstream's upstream, so there's at least some BCP 38 adoption.)

HostRocket contact

[Florian Weimer]

Has anybody got a working HostRocket contact?  They (or their
customers) seem to have a larger security incident. 8-(

Alternatively, someone at Time Warner Telecom who can get in touch
with them would be helpful.

Re: Spain was offline

[Florian Weimer]

* Michael Dillon:

> The volume of data cached would be so small in todays terms that
> it only needs a low-end 1U (or single blade) server to handle 
> this.

The working set is larger than you think, I fear.  I've been running
something like this since summer 2004, and the gigabytes pile up
rather quickly if you start with an empty database.  If you restrict
yourself to A records for plain SLDs and SLDs prefixed with "www.",
the task becomes somewhat easier (because you get rid of all that
PTR-related stuff, and the NS RRs take their share, too).  Of course,
you can squeeze quite a bit of RAM into one rack unit, so your comment
probably isn't that far off in the end. 8-)

> Since nothing like this exists on the market, the only way
> for ISPs to do this is to roll their own. Of course, it is
> likely that eventually someone will productize this and then
> you simply buy the box and plug it in. But for now, this is the
> type of thing that an ISP has to set up on their own.

Well, the data I collect is not authoritative enough for that purpose.
My intent was to capture everything that could be served to some host
on the network, while taking the possibility of broken resolvers into
account.  That's why I store the data without verifying its
authenticity (which is generally very hard to do because DNS is not
globally consistent).  Plugging things directly into the caching
resolver would give you access to its verification logic, but ISPs
aren't really fond of doing this to their resolvers.

Re: ISP wants to stop outgoing web based spam

[Florian Weimer]

* Hank Nussbacher:

> Please show me which virus scanner scans html pages for the words like
> V I A G R A, or Free M O R T G A G E, as it is going outbound.

I assumed your Internet cafe example was the concrete scenario you
were trying to address.  There are quite a few scaners which contain
signatures for spam-sending software, but it might be necessary to
roll your own stuff.  In that scenario, it's simply more effective to
look for the software (and accompanying anomalies) than for some web
application traffic.

> The big boys know what to do.  The smaller ones like walla.co.il,
> jumpy.it and mail.ru to name just 3 out of about 300 I have seen, do
> not have all those bells and whistles and therefore, in order to
> protect an ISPs IP address space from not getting burned by spammers,
> the ISP has to take proactive measures.

I still don't understand why you think this has to be solved at the
network level, specifically targeting web-based email services.

There are hugely different two scenarios:

  1. Spammers buy your Internet service and use it to send spam.

  2. Regular customers catch some piece of malware and their computers
 send spam.

In the first case, you get rid of the customers (possibly involving
law enforcement because many of the advertised products and services
are illegal).  In the second case, you need a general anti-malware
strategy, and webmailers are the least of your problems.

Re: ISP wants to stop outgoing web based spam

[Florian Weimer]

* Suresh Ramasubramanian:

> Yes, Sean - they are.  But it is far, far more productive for the
> source of this abuse to be choked off.  Call it the difference between
> using mosquito repellant and draining a huge pool of stagnant water
> just outside your home.

How can I, as an ISP, stop abuse that is carried out over HTTPS?

There are technological solutions for intercepting HTTPS traffic, but
I don't think we want to put them to even wider use.

Re: ISP wants to stop outgoing web based spam

[Florian Weimer]

* Hank Nussbacher:

> I guess I wasn't clear enough in my first posting.  I am not
> interested in smtp (port 25 spam).  We have that covered.  I am only
> interested in blocking outgoing web based spam.  A user sits and sends
> out spam via automated tools via Hotmail, Yahoo, Gmail, or whatever
> Webmail system where they have set up thousands of throwaway users.
> An antispam proxy (that I want to install and manage) has to be able
> to come between the user on his/her PC and the Hotmail system and scan
> the http posts and page templates for things like number of receipents
> and other tricks like keeping track of the number of http posts.  It
> has to maintain a list of known free webmail systems that are abused.

Your are tackling this from the completely wrong angle, I think.

You should look after the automated tools (probably using a virus
scanner or something like this) and trigger a covert alert once they
are detected.  If the spam sent out is of the right kind, you can
phone the police and have the guy arrested.

This assumes that the miscreants actually visit the Internet cafe.  If
the spamming is purely malware-based and non-targeted, the spamming
problem simply disappears once you get rid of the malware problem.

Re: ISP wants to stop outgoing web based spam

[Florian Weimer]

* Hank Nussbacher:

> Back in 2002 I asked if anyone had a solution to block or rate limit
> outgoing web based spam.

What is web-based spam?  Comment spam?  Wiki defacements?  Or do you
want to stop spam sent via web mailers?  That's their job.  They know
more about their customers than you, and quite a few of them use HTTPS
anyway.

If Yahoo hasn't got rate limits on their "I've got a new email
address" feature, for example, they need to fix it, not you or anybody
else.

Re: Detecting parked domains

[Florian Weimer]

* Jeremy Chadwick:

> On Wed, Aug 02, 2006 at 09:10:31PM +0200, Florian Weimer wrote:
>> > Has anyone come up with a quick method for detecting if a domain
>> > name is parked, but is not being used except displaying ads?
>> 
>> AFAICT, the main challenge is to define what "parked" means in the
>> context of your application.
>
> It seemed quite obvious to me: he's talking about domain squatting.

I've heard suggestions to treat "parked" domains less threatening than
other types of domain squatting.  This approach is somewhat dubious,
based on a few things we've seen.

Re: Detecting parked domains

[Florian Weimer]

* Sean Donelan:

> Has anyone come up with a quick method for detecting if a domain
> name is parked, but is not being used except displaying ads?

AFAICT, the main challenge is to define what "parked" means in the
context of your application.

Re: Net Neutrality Legislative Proposal

[Florian Weimer]

* Fergie:

> I disagree with your statement on NAT end-points not being "publicly
> accessible" -- that's certainly not true, and a myth that needs to be
> finally killed.

>From a security point of view, they are still accessible.  From an
operational point of view, they are not, at least not on the original
IP layer, and if you aren't using 1:1 NAT.

Nevertheless, I think that the "publicly accessible" criterion is
flawed because it is too murky.  But something similar is necessary to
implement the corporate networks exception.

Re: Net Neutrality Legislative Proposal

[Florian Weimer]

* Mark Newton:

> I think you're missing the point, Florian.  Regardless of any 
> retail restrictions, the fact still remains that your local 
> Cable company is selling connectivity to other peoples' 
> autonomous systems.

Then why do the ads promote their new chat service, instead the
ever-growing number of ASNs on the Internet? 8-) I don't think the
majority of consumers cares about this IP transit things as long as
their usual applications keep working.

Anyway, I suppose I can tell apart all these different types of
Internet access quite easily, but I can't come up with a generally
applicable set of criteria to categorize them properly.

Re: Net Neutrality Legislative Proposal

[Florian Weimer]

* Mark Newton:

> On Tue, Jul 11, 2006 at 09:39:50AM +0200, Florian Weimer wrote:
>
>  > * Mark Newton:
>  > > On Tue, Jul 11, 2006 at 07:58:48AM +0200, Florian Weimer wrote:
>  > >  > (I've wondered for quite some time if "net neutrality" implies that
>  > >  > Ebay or Google must carry third party traffic on their corporate
>  > >  > networks, by the way.)
>  > > eBay and Google aren't selling transit.
>  > 
>  > Neither is your local cable company. 8-)
>
> Eh?  Of course they are.  They're selling transit to their cable
> modem customers, surely?

Quote from a typical terms of service agreement:

| (b) Subscriber will not resell the Service, or any portion thereof, or
| otherwise charge others to use the Service, or any portion
| thereof. The Service is for personal use only, and Subscriber agrees
| not to use the Service for operation as an Internet Service Provider,
| to host web sites for other parties or for any other business
| enterprise or to connect the Cable modem to any server or to any
| computer outside of the Subscriber's premises.
|
| (c) Without Time Warner Cable 's prior written approval, Subscriber
| shall not post or transmit through the Service any material that
| constitutes or contains advertising or any solicitation with respect
| to products or services, nor shall Subscriber transmit bulk e-mail
| without prior written permission from Time Warner Cable.

IP transit has no such restrictions.

Re: Net Neutrality Legislative Proposal

[Florian Weimer]

* Mark Newton:

> On Tue, Jul 11, 2006 at 07:58:48AM +0200, Florian Weimer wrote:
>  
>  > (I've wondered for quite some time if "net neutrality" implies that
>  > Ebay or Google must carry third party traffic on their corporate
>  > networks, by the way.)
>
> eBay and Google aren't selling transit.

Neither is your local cable company. 8-)

Re: Sitefinder II, the sequel...

[Florian Weimer]

* Steven M. Bellovin:

> The second is the precedent that's set -- who gets to decide what zones
> are excluded from the tree?  OpenDNS?  Sure -- and to whom do they
> listen?  Are any sites to be ruled out on political grounds?
> Ideological?  Not today, sure, and (I assume) not by OpenDNS -- but what
> if some misguided legislature passes some law?

And how is real DNS any different?  Even in Western democracies, ISPs
can be forced to suppress zones on their resolvers.

There are profound privacy issues with centralized, opt-in DNS
resolvers, but they can probably be resolved satisfactorily.  But I'm
definitely the wrong guy to argue in favor of DNS-related privacy
(although I try very hard to make it impossible to link DNS queries
and responses to particular users).

Apart from that, I hope that services like this one (coupled with
tactical null routes) becomes more important to consumers.  More
competition on network-based security measures will help to protect
them from (technically) harmful content.  In some collapsed consmer
markets, it might enable ISPs to charge extra fees and compete on
these additional services, avoiding a complete meltdown of the market
and a return to an oligopoly.

Re: Net Neutrality Legislative Proposal

[Florian Weimer]

* Seth Johnson:

>  (A) Internet.— The term “Internet” means the worldwide, 
>  publicly accessible system of interconnected 
>  computer networks that transmit data by packet 
>  switching using the standard Internet Protocol (IP), 
>  some characteristics of which include:

So I put all my customers behind a NAT device (or just a stateful
packet filter).  They are no longer publicly accessible, and hence not
subject to the provisions of this section.  Fixing that would probably
require companies to open up their corporate networks, which is a
non-starter.

(I've wondered for quite some time if "net neutrality" implies that
Ebay or Google must carry third party traffic on their corporate
networks, by the way.)

Re: Best practices inquiry: filtering 128/1

[Florian Weimer]

* Patrick W. Gilmore:

> Actually, I take that back.  Why wouldn't you just get a feed from
> Cymru  ??

I don't think Team Cymru offers a "feed" of what is supposed to be in
the routing table.  128/1 isn't a bogon.  It's not even that useful
for hijacking adress space.

The correct approach would be to verify prefixes using somewhat
indepedent. more static data, such as RPSL data from RIRs.  The old
blacklist vs. whitelist discussoin.  (I know that creating a useful
whitelist is a huge tsak.)

Re: Fanless x86 Server Recommendations

[Florian Weimer]

* Mike Tancsa:

>> > Many mini-itx boxes dont have 2 PCI slots.  You might be better going
>> > with a mini-itx solution and then use a small switch and trunk the NIC
>> > to act as a VLAN router.
>>
>>Are there any fanless routers with proper 802.1Q support (with ingress
>>VLAN tag filtering, for instance)?
>
> Not sure exactly what you mean by vlan tag filtering and if you mean
> OSes based on i386 mini-itx boxes or all fanless routers in
> general.

Uhm, I should really clarify that I should have written "switches"
instead of "routers".  I hope the tag filtering make more sense in
this context. 8-)

I'd be interested in something that offers more than four Ethernet
plugs per PCI slot, and the only way I know to get that are switches.
But those with 802.1Q tagging and proper VLAN separation are all
rather noisy.

Re: Fanless x86 Server Recommendations

[Florian Weimer]

* Mike Tancsa:

> Many mini-itx boxes dont have 2 PCI slots.  You might be better going
> with a mini-itx solution and then use a small switch and trunk the NIC
> to act as a VLAN router.

Are there any fanless routers with proper 802.1Q support (with ingress
VLAN tag filtering, for instance)?

Re: Interesting new spam technique - getting a lot more popular.

[Florian Weimer]

* Christopher L. Morrow:

> is it really that hard to make your foudry/extreme/cisco l3 switch vlan
> and subnet??? Is this a education thing or a laziness thing?

You need those L3 switches before you can do this.  Obviously, L2 gear
is much cheaper, and will work equally well until it is attacked.

Even with L3 switches, adressing it is a bit tricky.  Not all vendors
support point-to-point adressing on Ethernet interfaces (certainly
some host software doesn't).  There are universal subscriber gateways
that simply override all network configuration on the host, but they
aren't marketed at datacenters AFAIK.  After all, who would think that
a datacenter needs a network security policy similar to that of a
hotel offering Internet access in its rooms?

Re: Interesting new spam technique - getting a lot more popular.

[Florian Weimer]

* Christopher L. Morrow:

> On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote:
>>
>> http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html
>>
>> * Monitor your local network for interfaces transmitting ARP
>> responses they shouldn't be.
>
> how about just mac security on switch ports? limit the number of mac's at
> each port to 1 or some number 'valid' ?

The attack is not visible at layer 2, so this won't help.  You need
static ARP tables on relevant hosts, but even that is only a stopgag
measure.  Better invest into one (virtual) router port per customer
host. 8-/

Re: Black Frog - the botnets keep coming

[Florian Weimer]

* Gadi Evron:

> Ignoring is the high-road. How long are we going to cry about the
> Internet being a battle-ground, the wild west, or whatever else if
> we legitimize DDoS?

The project needs to gather supporters before they can do any real
damage.  Reports exposing their nefarious practices are probably the
best kind of publicity they can get.

Re: Black Frog - the botnets keep coming

[Florian Weimer]

* Gadi Evron:

> http://news.google.com/news?q=black+frog
>
> How do we make this folly stop?

Ignore it?  It's an inactive Sourceforge project (with some Google
forums attached), and news reports seem to be based on a Slashdot
diary entry announcing it:

  

There are far more dangerous Sourceforge projects out there. 8-/

Re: DNS Amplification Attacks

[Florian Weimer]

* Peter Dambier:

>> This is not true.  There has been some questionable advice by a
>> regulatory body, though.  Most damage is done by ISPs which simply do
>> not adjust the filters to the moving target and run them as-is since
>> 2001 or so.  Null routes tend to filter a different customer after
>> such a long time.
>> 
>
> Here it is documented. Sorry it is in german only:

Yeah, sure, but your summary is misleading (convenient it's "german
only", is it?).  The actual damage was done by ISPs, that body only
gave questionable advice.  Afterwards, most ISPs simply didn't care,
in the sense that they didn't maintain the filters.

> Several sites where censored and could only escape by changeing
> providers.

It's more interesting if you can't do this.  A null route on a router
in Frankfurt sometimes does wonders.  It's also fairly effective to
null-route what is logically a downstream customer, even if it's
outside your network (by a few AS hops) and somewhere in Asia.

Such things happen all the time, and not just for DDoS prevention
purposes or malware containment.  Some of the filters are clearly
targeted at specific content which is deemed unsuitable for
consumption by Germans.  Such cases are not well-publicized.  Often,
you can't tell them from genuine routing problems (and if you've got
insider information, you typically can't publish).  I don't think this
is just a German or Chinese problem, by the way.

> Nevertheless I could see the site "http://www.enyo/";
> after adding "212.9.189.164 www.enyo enyo" to my /etc/hosts
> Maybe even could send you emails?

No, because I don't actually use ENYO. 8->

Re: DNS Amplification Attacks

[Florian Weimer]

* Andy Davidson:

> DNS looking glasses, in much the same way that we use web-form based
> BGP or traceroute looking glasses today.

Open resolvers are far better then looking glasses to assess the state
of DNS, and we are campaigning against them.  You can't have it both
ways. 8-(

Re: DNS Amplification Attacks

[Florian Weimer]

* Peter Dambier:

> In germany censoring is commonplace. You have to use foraign resolvers
> to escape it. There is a lot collateral dammage too - governement has
> provided the tools.

This is not true.  There has been some questionable advice by a
regulatory body, though.  Most damage is done by ISPs which simply do
not adjust the filters to the moving target and run them as-is since
2001 or so.  Null routes tend to filter a different customer after
such a long time.

> How about alternative roots? ICANN does censor "XN--55QX5D.", "XN--FIQS8S."
> and "XN--IO0A7I." already. You must use alternative roots to exchange emails
> with people living in those domains.

Unfortunately, they also censor "ENYO.".

Re: Security problem in PPPoE connection

[Florian Weimer]

* Steven M. Bellovin:

> CHAP can be bidirectional.

I stand corrected.

However, the value of this type of authentication is rather
questionable if the underlying communication channel is so horribly
insecure.

Re: Security problem in PPPoE connection

[Florian Weimer]

* Joe Shen:

> What's your method to deal with such problem? Will
> CHAP in PPPoE help?

AFAIK, CHAP does not authenticate the terminal server, either, so it
won't stop all attacks.

Re: Security problem in PPPoE connection

[Florian Weimer]

* Peter Dambier:

> I am connected through this one:
>
> Access-Concentrator: DARX41-erx
> AC-Ethernet-Address: 00:90:1a:a0:01:46
> --
>
> I guess dtag.de has got some 8 of them. Everybody
> (almost) offering dsl in germany goes through their
> infrastructure. The ip address range 84.167.0.0/16
> seems to be shared by all of them.

But you've got an ATM PVC to them, haven't you?  This is a completely
different setup.

Imagine you haven't got a DSL modem, but just an RJ45 plug in the wall
which leads into a stupid cloud of L2 Ethernet switches, and you still
talk PPPoE to your ISP.  AFAICS, this is the kind of network setup the
OP is talking about.

Re: Disaster recovery using as-prepend?

[Florian Weimer]

* Christopher J. Pilkington:

> We have a disaster recovery site which will have a clone of the myriad
> production servers.  We'd like to fail over to that site
> automagically.
>
> I'm thinking advertising the same prefix and just doing several
> as-prepends.  However, now I'm not sure if this is a polite thing to
> do or not.

Can your backup servers run in parallel to your primary servers?  How
do you handle conflicting updates (assuming that the services are not
completely stateless)?

Re: Fed Bill Would Restrict Web Server Logs

[Florian Weimer]

* Frank Louwers:

> Strange thing is that we have exact the opposite here in Europe. There
> is a new bill that has been passed that forces us to keep al logs (mail
> and web) for at least 1 or 2 years.

It's not a bill, it's a EU directive which still has to be implemented
in national law.  Nothing in the directive requires that operators of
non-interactive web sites (the vast majority) retain any data.  Only
if you identify your users, you might be required to keep some logs.
Implementation in national law might change that, especially since the
directive is remarkably unclear about the selection criteria used for
mapping communication events to individuals.

Re: ml hacks for goodmail

[Florian Weimer]

* Randy Bush:

> so, anyone working on the majordomo and mailman hacks for goodmail?
> "i am sorry, but you can not subscribe to this list from an aol.com
> address.  don't ask us to explain, ask [EMAIL PROTECTED]"
>
> or am i missing something here?  clue-bat if so, please.

I don't expect the existing filters will change significantly.  If
you've got problems routing mail to AOL customers, you are just
offered another option.  I would be surprised if AOL intends to make
money off that service; it's probably just an experiment if this helps
to curb misuse of the bypass facilities (which have already existed).

What's the response of the solicited bulk mailers?  Do they welcome
this move?  If they are too happy about it, maybe we should be
worried. 8-)

As far as I can tell, the filters at AOL are far less problematic than
crude filters at smaller sites which simply use SORBS or
bl.spamcop.net.

Re: AW: Odd policy question.

[Florian Weimer]

* Randy Bush:

>> it is a best practice to separate authoritative and recursive servers.
>
> why?
>
> e.g. a small isp has a hundred auth zones (secondaried far
> away and off-net, of course) and runs cache.  why should
> they separate auth from cache?

Some registrars require that you begin to serve the domain before it's
actually delegated to you.  If you don't run a split setup, it might
happen that you hijack someone else's domain.  For example, some ISPs
already serve .EU domains on their resolvers, although they haven't
been delegated to them yet.  A unified setup also means that customers
can hijack domains (intentionally or not) if your registratry checks
go wrong.  And you don't notice if the delegation goes astray for some
reason.

The upside of a unified setup is that DNS continues to work even if
you're disconnected from the Internet.  It is somewhat easier to
configure.  And you aren't subject to DNS spoofing attacks for your
own domains.

Re: AW: Odd policy question.

[Florian Weimer]

* Jeffrey I. Schiller:

> Let me attempt to bring this back to the policy question.
>
> Does someone have the *right* to put one of your IP addresses as an NS
> record for their domain even if you do not agree?

I don't think it's allowed (and it shouldn't be), but without a
cluestick from legal, you won't find anyone who will force the
offender to fix it.

If this were okay, certainly you wouldn't have objected to someone
pointing the A RR of kimble.org to your company web servers, back when
Blaster.E was at its height, would you? 8-)

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

[Florian Weimer]

>> If there is a new user account, or if the enable and access passwords
>> have changed, look out!  The miscreants love to scan and find routers
>> with "cisco" as the access and enable passwords.
>
> I thought everyone sensible put ACLs on vtys. Guess I was wrong.

I've seen ACL-less VTYs because someone copied a config from a router
with fewer VTYs. 8-(

Re: do bogon filters still help?

[Florian Weimer]

* Pim van Pelt:

> Hi Florian, others,
>  
> | You should move 192.88.99.0/24 from SPECIAL to YES (although you
> | shouldn't see source addresses from that prefix, no matter what the
> | folks at bit.nl think).  169.254.0.0/16 should be NO (otherwise it
> | wouldn't be link-local).

> Hi, here's a member of 'the folks at bit.nl'.  Just a quick note to
> say that we have been sourcing IPv4 packets from 192.88.99.1 at a rate
> of 2.000 to 10.000 packets per second since early 2003, so I'm guessing 
> we have sent some 750.000 billion packets by now.

And this is just so wrong.  You should use an address you own as a
source address.  Otherwise, packets tend to get dropped by filters.

And no, "anyone should be able to spoof from 192.88.99.0/24" is not
the answer to this kind of problem.

Re: do bogon filters still help?

[Florian Weimer]

* william elan net:

>> You should move 192.88.99.0/24 from SPECIAL to YES (although you
>> shouldn't see source addresses from that prefix, no matter what the
>> folks at bit.nl think).  169.254.0.0/16 should be NO (otherwise it
>> wouldn't be link-local).
>
> I think you just explained it yourself why this is "SPECIAL", i.e.
> routing of it depends on local policies and setup. Anything where it
> is not clear from RFCs if it should be routable or not and where it 
> depends on local decisions & policy is what I called SPECIAL.

Uhm, no.  6to4 anycast only works without hickups when the prefix is
NOT treated in any special way. 8-) That's part of its charm.  If
operators start to install special filters, they break this
functionality for no real gain.

>> I haven't looked at RFC 3330, but another RFC reserves 192.0.2.0/24
>> for examples in documentation.  In practice, this prefix is used for
>> distributing fake null routes over BGP, so it's a rather strong NO.
>
> If you know which RFC it is, I'll update the reference table.

Uhm, looks like I was mistaken.  Each time the topic comes up, I
confuse this with RFC 2606 (domain names).  No such RFC exists for
IPv4 addresses.

Re: do bogon filters still help?

[Florian Weimer]

* Martin Hannigan:

>> You should move 192.88.99.0/24 from SPECIAL to YES (although you
>> shouldn't see source addresses from that prefix, no matter what the
>> folks at bit.nl think).  169.254.0.0/16 should be NO (otherwise it
>> wouldn't be link-local).

> Good example as to why to use authoratative sources only. 

But most authoritative sources are too shy to make explicit
operational recommendations. 8-)

Re: do bogon filters still help?

[Florian Weimer]

* william elan net:

> For those doing similar exercise, you might want to look at rephrased 
> version of rfc330 listed blocks:
>  http://www.completewhois.com/iana-ipv4-specialuse.txt

You should move 192.88.99.0/24 from SPECIAL to YES (although you
shouldn't see source addresses from that prefix, no matter what the
folks at bit.nl think).  169.254.0.0/16 should be NO (otherwise it
wouldn't be link-local).

to make the list more future-proof, listing 128.0.0.0/16,
191.255.0.0/16, 192.0.0.0/24 and 223.255.255.0/24 as YES might be a
good idea.  I'm not sure what to do with 39/8.

I haven't looked at RFC 3330, but another RFC reserves 192.0.2.0/24
for examples in documentation.  In practice, this prefix is used for
distributing fake null routes over BGP, so it's a rather strong NO.

Re: Compromised machines liable for damage?

[Florian Weimer]

* Martin Hannigan:

> Dave, RIAA wins almost 100pct vs p2p'ers ir sues. Its an interesting 
> dichotomy.

Sure, but copyright law is a bit out of proportion.  Maybe you could
hunt down the bad guys if they packeted you with Celine Dion

Re: Infected list

[Florian Weimer]

* Scott Morris:

> Not to mention that many IP's may be set to one device, yet there are
> multiple things NAT'd behind it. 

Are there any devices which perform non-static NAT and can forward
significant DoS traffic? 8-) Perhaps if it's just a single flow, but
this kind of DoS traffic would be rather unusual.

Re: Infected list

[Florian Weimer]

* Barrett G. Lyon:

> Here is a list of the compromised machines used in this new botnet we  
> found in California.  These are all web servers connected to good  
> bandwidth and they are attacking us, so as a nice little holiday gift  
> to me, please clean your network up if these are on your network.  :)

It's usually better not to run DNS resolution on the IP addresses you
have because DNS is so volatile[1].  Mapping host names to IP address
is rather expensive, too, and the casual bot-hunter may not have the
necessary tools.  (And I doubt that many bot hunters work at
web-hosting companies...)

Timestamps are usually required to pin-point an attack, but if the
compromised hosts are mostly largish web servers, they should have
static IP addresses and some kind of accounting where you can see that
something went terribly wrong.

[1] I assume you have verified those host names using a forward
lookup.  Relying on PTR records alone is not a good idea.

Re: The Qos PipeDream

[Florian Weimer]

* Sean Donelan:

> AT&T, Global Crossing, Level3, MCI, Savvis, Sprint, etc have sold
> QOS services for years. Level3 says 20% of the traffic over its
> backbone is "better than Best-Effort."

Well, are you sure these traffic classes are actually enforced at the
router level?  Maybe it's just a difference in the SLA, and the
packets are still treated the same across the network.

> Internet2 gave up on premium QOS and deployed "less-than Best
> Effort" scavenger class.

I doubt that utilization on Abilene is high enough for QoS to make any
difference. 8-)

Re: Clueless anti-virus products/vendors

[Florian Weimer]

* Steven M. Bellovin:

> A-V companies are in the business of analyzing viruses.

Many offer analysis services, but this is done upon special request,
and only if you pay extra.

> They should *know* how a particular virus behaves.

You don't need to know what the virus does in order to detect it with
a file-based signature.  Analysis stops as soon as detection is
possible with sufficient accuracy.  Timebombs and other hidden
functionality go unnoticed (unless the malware is form a well-known
strain which has such features).

Re: Sober

[Florian Weimer]

* Dennis Dayman:

> Interested, but I see many Sober postings and outages on other lists
> and not here...has anyone been having issues? I know the ISP's are
> fighting the living out of the virus.

As far as I know. mainly webmail providers were affected, and their
issues are traditionally not discussed on this list.

Re: IP Prefixes are allocated ..

[Florian Weimer]

* Christopher L. Morrow:

>> asn.routeviews.org doesn't do longest-prefix matching, so you need a
>> short Perl script to get the correct ASN, attached below.  However,
>
> which means host -t txt  will return more than one record, yes?

Exactly.

> so he can just scan for the longest length in the return? 

This is what the Perl script does, yes.

Re: IP Prefixes are allocated ..

[Florian Weimer]

* Christopher L. Morrow:

> he might be satisfied with:
>
> mail.pch.net.   86400   IN  A   206.220.231.1
>
> :~> host -W 6 -R 10 -t txt  1.231.220.206.asn.routeviews.org
> 1.231.220.206.asn.routeviews.org text "3856" "206.220.228.0" "22"
>
> which is AS 3856 routing 206.220.228.0/22 ... which contains the /32
> above.

asn.routeviews.org doesn't do longest-prefix matching, so you need a
short Perl script to get the correct ASN, attached below.  However,
this is a bit slow thanks to the overhead of loading Net::DNS, see
 (German).

#!/usr/bin/perl

use warnings;
use strict;
use Net::DNS;

if (@ARGV != 1 && $ARGV[0] !~ /^\d+\.\d+\.\d+\.\d+$/) {
print STDERR "usage: ip2asn A.B.C.D\n";
exit 1;
}

my $suffix = 'asn.routeviews.org';
my $name = join '.', (reverse split /\./, $ARGV[0]), $suffix;

my $res = Net::DNS::Resolver->new;
my $packet = $res->query($name, 'TXT');
my @txt;
@txt = $packet->answer if $packet;

my ($longest_net, $longest_length, $longest_asn);
for my $rr (@txt) {
my ($asn, $net, $length) = $rr->char_str_list;
if ((! defined $longest_length) || $length > $longest_length) {
$longest_net = $net;
$longest_length = $length;
$longest_asn = $asn;
}
}

if (defined $longest_asn && $longest_asn < 64511) {
print "$longest_asn\n";
} else {
print "0\n";
}

Re: BGP Security and PKI Hierarchies

[Florian Weimer]

* Valdis Kletnieks:

> On Thu, 24 Nov 2005 20:26:56 +0100, Florian Weimer said:
>
>> Wouldn't this provide significant economic incentive towards gaining a
>> high value on this metric?  I'm not sure if this a good idea because
>> even if you call it a "trust metric", it does not have to correspond
>> to ethical behavior.
>
> Wrong concept of "trust".  There exist vendors that I *expect* will
> treat me in an unethical way, while being totally open as to their
> identity.

But ensuring identity is a good measure of trust, either.  Identity
only matters if you want to do something to the perpetrator in the
real world.  This seems to be the rare exception, not the norm.  I
expect people just to tweak their filters and move on.

(It would be more interesting if each real-world entity could only
have one digital entity, but this is impossible to achieve, especially
in context of IP routing.)

Re: BGP Security and PKI Hierarchies

[Florian Weimer]

* Michael Dillon:

>> > How would you feel about having the registries serve as the root of
>> > a hierarchical certificate system?
>> 
>> What about the swamp space?
>
> Presumably if the users of class C blocks in the swamp

The class B assignments are even more interesting because some of them
have been split (with or without the consent of the original
assignee).

> want to use the certficate services that the registry provides then
> the registries would sell that service for some reasonable fee.

Which registry?  In many cases, there are two natural choices.

> Some people labor under the misunderstanding that users of swamp
> space actually "own" IP addresses and therefore have the right to
> not pay anybody for anything at anytime. However, since "ownership"
> is a legal concept and since IP address ownership has never been
> tested in the courts, it is a moot point.

I can't follow your argument.  You seem to be saying that we should
not worry *because* we enter uncharted legal terrain.  This attitude
is completely alien to me.

> Do you suppose that if a Microsoft salesman had given me a free copy
> of Windows back in 1990, I would have a right to use any version of
> Windows for free forever?

I guess I had the right to use that version of Windows forever.
Software is not a good example because life cycles are so much
shorter.  But no one is really comfortable with retroactively revoking
software licenses, and it's often impossible because of first sales
doctrine, special copyright regulations (especially in European
countries), antitrust regulations etc.

Re: BGP Security and PKI Hierarchies

[Florian Weimer]

* Bill Woodcock:

> Right.  The idea was to lock down things which were in the legacy space, 
> unless people were prepared to undergo the full scrutiny of having them 
> transferred into an RIR (basically dampen the rash of hijackings),

In the end, this boils down to disappropriation.  Early address space
is owned, not assigned, as far as I can tell.

Re: BGP Security and PKI Hierarchies

[Florian Weimer]

* Steven M. Bellovin:

> Furthermore, given that a trust algebra may yield a trust value, rather 
> than a simple 0/1, is it reasonable to use that assessment as a BGP 
> preference selector?  That would tie the security very deeply -- too 
> deeply? -- into BGP's guts.

Wouldn't this provide significant economic incentive towards gaining a
high value on this metric?  I'm not sure if this a good idea because
even if you call it a "trust metric", it does not have to correspond
to ethical behavior.

Re: BGP Security and PKI Hierarchies

[Florian Weimer]

* Sandy Murphy:

> How would you feel about having the registries serve as the root of
> a hierarchical certificate system?

What about the swamp space?

>>So an institution would have its "certificate" signed
>>by its upstream (or one of its upstream) providers.

(Don't know where that quote comes from.)

Why is this significantly better than ISP filters which prevent bogus
announcements from reaching wide propagation?

I've seen bogus annoucements for which big ISPs have created
corresponding RADB entries.  Wouldn't they just create certificates in
the new "secure BGP", and nothing is won?

Re: cogent+ Level(3) are ok now

[Florian Weimer]

* John Payne:

> That is something that has always confused me about ratio based  
> peering disputes.

I don't understand them, either.  However, if you define incoming
traffic as "bad", it encourages depeering by the receiving side if the
incoming/outgoing ratio exceeds a certain value, especially among
close-to-tier-1 carriers: the traffic does not automatically disappear
just because you depeer.  Now suppose that the sending side doesn't
want to play games and buys transit from one of your other peers.
Given the tier-1 status, there is some chance that this has a
measurable impact on the traffic ratio with that other peer.
Essentially, this is a self-fulfilling prophecy, and it works equally
well if you define outgoing traffic as "bad".

Re: ICANN and Verisign settle over SiteFinder

[Florian Weimer]

* william elan net:

> They get to continue to be .COM registry forever as new agreement
> would extend to 2012 and then automatically extended further without 
> formal process as it happened recently for .NET. They also are going
> to be able to increase registry fees for .COM by 7% per year which to
> put it in perspective can potentially be $2 increase 4 years from now.

So the deal makes indeed sense from a business perspective.  Thanks.

>> Two possible explanations:
>
> 2+2=5, right? :)

Oops. 8-)

Re: ICANN and Verisign settle over SiteFinder

[Florian Weimer]

* Chris Woodfield:

> Said the flowerpot: "Oh no, not again..."
>
> http://www.businessweek.com/ap/financialnews/D8DEL2TO7.htm? 
> campaign_id=apn_tech_down&chan=tc

I don't understand what VeriSign receives in return for their kowtow
(under the agreement, they basically waive any right to criticize
ICANN's role).

Two possible explanations:

  * ICANN signalled a positive outcome of a future Sitefinder review
under the new process.

  * ICANN promised to grant VeriSign the DNSSEC root and .ARPA
maintenance without tender (the "Root Server Management Transition
Agreement" goes into that direction; actually, the .ARPA stuff is
the interesting one).

  * VeriSign has recognized that they couldn't win in court, and
suddenly want to play nice.

Re: Level 3 RFO

[Florian Weimer]

* Daniel Roesen:

> On Mon, Oct 24, 2005 at 01:25:23PM +0200, Florian Weimer wrote:
>> >> Are there any configuration tweaks which can locally confine such an
>> >> event?  Something like the hard prefix limit for BGP, perhaps.
>> >
>> > JunOS:
>> > set protocols ospf prefix-export-limit 
>> > set protocols isis level  prefix-export-limit 
>> 
>> Wouldn't an import limit be better?
>
> We're talking link-state protocols here... they need to have the same
> view everywhere. The only thing you can limit is what you inject into
> the (IGP-)global view.

What a pity.  There isn't an ugly workaround, either?  There has to be
something that can be done, given the operational risk that is
involved.

Certainly, this adds a new dimension to the "distributed single point
of failure" concept. 8-(

>> If you've got a almost-fully-meshed MPLS core, export limits won't
>> really work, will they?
>
> I don't understand this question. What has MPLS to do with IGP route
> filtering?!?

It's the "almost fully-meshed" part.  In such a setup, a single router
which exceeds the limit can affect a large part of the the network,
even if other routers do not propagate the bogus data.

But as you say, if the limit you mentioned is just a local limit on
redistribution to the IGP for a single router, my point is moot--if
it's in the IGP, you lose because the limit does not apply to routes
which are received over the IGP.

Re: Level 3 RFO

[Florian Weimer]

* Daniel Roesen:

> On Sun, Oct 23, 2005 at 09:48:58PM +0200, Florian Weimer wrote:
>> This isn't the first time this has happened to an ISP. 8-(
>
> Indeed.
>
>> Are there any configuration tweaks which can locally confine such an
>> event?  Something like the hard prefix limit for BGP, perhaps.
>
> JunOS:
> set protocols ospf prefix-export-limit 
> set protocols isis level  prefix-export-limit 

Wouldn't an import limit be better?  If you've got a
almost-fully-meshed MPLS core, export limits won't really work, will
they?

In more traditional networks, I can imagine that it helps to confine
anomalies.  Has anybody tried that on a real network? 8-)

Re: Level 3 RFO

[Florian Weimer]

> However, due to the number of flooded LSAs, other devices in the
> Level 3 network had difficulty fully loading the OSPF tables and
> processing the volume of updates.  This caused abnormal conditions
> within portions of the Level 3 network.  Manual intervention on
> specific routers was required to allow a number of routers to return
> to a normal routing state.

This isn't the first time this has happened to an ISP. 8-(

Are there any configuration tweaks which can locally confine such an
event?  Something like the hard prefix limit for BGP, perhaps.  (I'm
not an OSPF expert, and understand that things are generally more
difficult with link-state protocols.)

Re: h-root-servers.net (Level3 Question)

[Florian Weimer]

* Daniel Roesen:

> On Sun, Oct 23, 2005 at 11:59:15AM +0200, Peter Dambier wrote:
>> I means, here in germany we cannot see h.root-servers.net
>
> Nonsense. There is nothing like "geopolitical routing".

I wouldn't call it "geopolitical routing", "routing according to local
policy" is more appropriate.  And it's quite common (especially in
Germany, for quite a few reasons).

> DREN seems to have a problem there.

Not clear to me.  A traceroute with the wrong protocol (i.e. not
53/UDP nor 53/TCP) is not particularly enlightening.

> I can see absolutely NO connection to any L3/Cogent dispute.

This is something I can agree with. 8-)

Re: IPv6 news

[Florian Weimer]

* Daniel Roesen:

> On Wed, Oct 12, 2005 at 11:13:12AM -1000, Randy Bush wrote:
>> also to be noted is that rir statistics on who has what space are
>> not in the best of shape, ripe's being particularly obfuscated.
>
> *raising an eyebrow*
>
> Would you care to elaborate on that?

AFAIK, the status of EARLY-REGISTRATION space is still somewhat murky
(my favorite topic 8-).