Re: Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[jdupuy-list]

> Alas, as anyone who has ever watched Internap when they go flappy flappy 
> can attest, BGP does not handle an excessive number of transit paths 
very 
> well. I'd really hate to picture the size of the boom that would happen 
if 
> people WERE to exchange transit paths with each other on anything other 
> than a rare and isolated basis.

True. And I fully support the common practice of heavy filtering on both 
ends of most BGP sessions to prevent route leakage. Nothing upsets an 
upstream more than announcing a major network via a smaller connection. 

Perhaps things have changed a lot in the last six years, which is the last 
time I got much face-to-face time with other BGP admins. Back then it 
seemed that the larger networks horse-traded transit pretty regularly. I 
do not know if was partly automated or case-by-case for each route. (And I 
suspect it was not always with corporate knowledge.) Especially since some 
networks (foreign government networks, etc.) were not as "flexible" as one 
would hope about peering. 

Again, I'd be interested in hearing from one of the bigger ones on this: 
UUNet, AT&T, Sprint, Level3, QWest If you can't say anything, I 
understand. 

John

Re: DNS cache poisoning attacks -- are they real?

[Joe Maimon]

Brad,
I suspect and google confirms, that you know a whole lot more about this 
than I do, so please have a little patience explaining this to me.

Brad Knowles wrote:
At 8:49 AM -0500 2005-03-29, Joe Maimon wrote:
 1) Registrars being required to verify Authority in delegated to
 nameservers (will this break any appreciated valid models?) before
 activating/changing delegation for zone.

Okay, so the spammers make the data appear valid just long enough to 
pass the test, then they go back to their wily ways.  Not a real fix.

Why would this not work against the procedure as originaly described?
Step 1) Spammers register Domain and delegate it to nameserver that 
respond with AA set for domain.
Step 2) Registrar activated delegation due to Authority response from 
nameservers
Step 3) Spammers seed recursive resolvers
Step 4) Spammers change delegation by registrar to seeded resolvers
Step 5) Change fails because Registrar check Authority from seeded 
resolvers and does not get it.

How do spammers make step 5 succeed?
 2) Stricter settings as regards to all lame delegations -- SERVFAIL by
 default without recursion/caching attempts?

You'd have the caching server check the name of the zone to see if 
it is claimed as an NS record, even when it's just caching/recursive?  
Now, tell me how they'd do this at all the sites on the Internet, since 
we assume that the data advertised may change at any moment?
What I meant is that when a server attempts to seed its cache and it 
encounters lameness it should not attempt to obtain it from any other 
servers. Perhaps it should return the answer but not cache it (or cache 
with forced small TTL).

Now lameness is something that the server SHOULD see when it attempts to 
recursively resolve the name without extra effort.

In terms of running a caching/recursive server, I don't think 
there's any way to reliably detect that someone has aimed an NS record 
at you.  That would be like asking how you know, a prior, whether or not 
www.youareadamnedbloodyfool.com is a now CNAME record for your webserver.
I am suggesting that the server can semi-reliably detect that the parent 
soa hasnt aimed the ns record for the subzone at it. It would verify its 
cache contents every X before sending on the answers it has. It should 
purge from cache anytime the check reveals that the parent zone has an 
NS aimed at it for the cache contents -- which should be a clear 
indication of cache hijacking.

Or perhaps servers should check periodicaly for all kinds of lameness of 
the cached contents. This would prevent practical usage of a technique 
where spammers spray-seed all resolvers they can with large TTL's so 
that the resolvers users see them for quite some time irregardless of 
registrars/parent zone's actions.


 3) Paranoid checking for situations such as these by having recursing
 nameservers attempt to periodically check for suspicous NS and glue from
 the parent zone's POV and compare it to cache, trashing cached records
 if they do not like result.

How do they know who their claimed "parent" is, when someone aims a 
totally bogus NS record at them?  Do you ask them to walk the entire DNS 
tree throughout the entire Internet?

And thats so hard? Servers do this all the time fairly often.
An open recursive/caching nameserver is like an open mail relay. 
There may be some people who stubbornly insist that they are a necessary 
evil -- feel free to become the next toad.com if you like. There may be 
a lot of people who have one but don't know it.

But they are evil, and I believe that they should be eliminated.
So far nobody here has said that they are either neccessary or evil -- 
'cept for you and chris on the evil part.

As to that, I cant credit the resulting evilness you paint as evil as 
open mail servers became, not because open mail-relay servers were 
intrinsically so but because they become so very attractive to all the 
evil users out there.

For a real life example of an open-relay mail server, walk to your 
nearest corner and see the maildrop that takes mail from anybody and 
delivers it to anyone else.

A commandeered open-relay server is spewing garbage to its victims.
A commandeered open-recursion server, while not a good thing, is hardly 
doing the same - in most cases described here its simply perpetuating a 
domain name far longer than POLICY reasons would like. This was probably 
a designed for feature, for example keeping panix.com going strong for 
the lucky one due to cached large NS TTLS would have been viewed as a 
good thing at the time.

Furthermore, as others have pointed out, eliminating the openness of 
these resolvers would simply force a push to have spammers trojan armies 
seek 'n' seed the resolvers they can recurse from.

Due to the nature of this game, the larger client base the resolver 
serves, the better the chances of it getting seeded. These would be the 
same resolvers targetted were they open. And as others have p

Re: Telcordia report on ICANN .net RFP Evaluation

[Suresh Ramasubramanian]

On Tue, 29 Mar 2005 09:24:52 -0500, Eric Brunner-Williams in Portland
Maine <[EMAIL PROTECTED]> wrote:
> 
> A summary of the report and a link to the full report can be found at:
> 
> http://www.icann.org/announcements/announcement-28mar05.htm
> 
> So now you know. VGRS, NS+, AF, ranked 1, 2, 3; DE and CORE ranked 4 & 5.
> 

I do believe that study is open to peer review?
Telcordia ranking VRSN way ahead does seem to be raising some hackles here

-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: Telcordia report on ICANN .net RFP Evaluation

[Richard Cox]

On Tue, 29 Mar 2005 19:51:52 -0500
"Patrick W Gilmore" <[EMAIL PROTECTED]> wrote:

> Would that ICANN had the integrity to avoid not just impropriety,
> but the appearance of impropriety. :(

Would that ICANN had some *incentive* to avoid both of those.

-- 
Richard

Re: ICANN on the panix.com theft

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James Galvin wrote:
> 
> 
> --On Saturday, March 26, 2005 4:58 PM -0500 David Lesher <[EMAIL PROTECTED]>
> wrote:
> 
>>
>> ICANN Blames Melbourne IT for Panix Domain Hijacking
> 
> 
> Unfortunately, the agenda for the next ICANN meeting:
> 
>
> 
> Still does not yet show that the SSAC
> 
>
> 
> Will be having a public meeting on Tuesday, from 6:30-7:30pm, during
> which it will present its preliminary results and recommendations from
> its review of the incident.

That agenda has now been updated. As I understand it, the final version of
the agenda had to wait on some coordination with the local host, which has
now been completed.

FYI,

Doug

- --
Doug Barton
General Manager, The Internet Assigned Numbers Authority
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCSgrKwtDPyTesBYwRArktAJ9KI2XQIHpBc53M2pr6Pmw642pJqwCcDC2c
P4zfNeqK6ny4o6mfzDXQDlQ=
=sFS8
-END PGP SIGNATURE-

Re: Telcordia report on ICANN .net RFP Evaluation

[Patrick W Gilmore]

On Mar 29, 2005, at 9:24 AM, Eric Brunner-Williams in Portland Maine 
wrote:

Oki all,
A summary of the report and a link to the full report can be found at:
http://www.icann.org/announcements/announcement-28mar05.htm
So now you know. VGRS, NS+, AF, ranked 1, 2, 3; DE and CORE ranked 4 & 
5.
Given the "independence" of Telcordia WRT VGRS, this is somehow not 
surprising.

It is surprising that ICANN did not pick someone who was _actually_ 
independent to do the ranking.  Wish I had the time to actually 
investigate, but like so many things which look suspicious, they will 
"get away with it" because others are busy.

Would that ICANN had the integrity to avoid not just impropriety, but 
the appearance of impropriety. :(

--
TTFN,
patrick

FYI/OT: AV8 zombie listing in SORBS & the rantings of Dean A

[Matthew Sullivan]

Dean Anderson wrote:
Hi folks. A few points about Sorbs (I've also started a web site
www.iadl.org to track abuse of the internet for defamation purposes. The
web site isn't finished, yet.)
1) Someone said Sorbs is just Matthew Sullivan.
Well, _Sullivan_ said it isn't just him. Yeah, sure, that has
credibilty...
However, my own experience with Sorbs has revealed that it is also Alan
Brown (formerly of ORBS) and Kai Schlicting. We all remember Alan from the 
ORBS shutdown, I hope. Alan was found by three courts in separate cases to 
be defaming people (two by using a blacklist). 

 

Dean, this is so far off topic its not funny.  I am not going to discuss 
this further on NANOG, should you wish to discuss it you are welcome to 
join [EMAIL PROTECTED] and make your case there (as anyone 
interested is welcome to subscribe and take a look).

My information is that you did not apply for the address space in 
question for AV8, and that you took the address space from your former 
employers when you left by virtue of being the admin and technical 
contact for the netspace.  That information has come from multiple 
reputable sources.  I have repeatedly asked you for proof that you are 
the rightful owner of the netspace, and am still waiting for that proof 
- I'll be happy to delist any Zombie/Hijacked listings as soon as the 
rightful owners have the netspace in their possession and where they 
think they are the rightful owners and the information suggests 
otherwise (your case), a small piece of evidence is required for the 
delisting (eg a copy of a letter from the OSF stating that they gave you 
the netspace as a leaving 'present')

 and some facts that you seem to be lacking:
SORBS was created by me and I along with 18 other volunteers run it.
Neither Alan nor Kia have anything to do with SORBS (neither past or 
present).

My sites have not been, nor have ever been, booted from XO netspace 
(ns1.sorbs.net and http://www.isux.com/ ).

I have never been a student of The University of Queensland.
Regards,
Matthew
PS: If you reply in NANOG, don't expect a reply from me this is OFF TOPIC!

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[Richard A Steenbergen]

On Tue, Mar 29, 2005 at 03:57:51PM -0500, Dorian Kim wrote:
> 
> If they exchanged full routes, wouldn't that be mutual transit, not peering?

Settlement free transit? Sounds like the wave of the future to me. Oh wait 
it's only March 29th, we're still 3 days away. :)

Alas, as anyone who has ever watched Internap when they go flappy flappy 
can attest, BGP does not handle an excessive number of transit paths very 
well. I'd really hate to picture the size of the boom that would happen if 
people WERE to exchange transit paths with each other on anything other 
than a rare and isolated basis.

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: OT: Chasing spam.

[Bill Nash]

Thanks for the speedy responses, gang. All my suspicions are confirmed, 
and I'm putting an edge on my cudgel. =)

- billn
On Tue, 29 Mar 2005, Bill Nash wrote:

I'm chasing after some spam that appears to have been built from a nanog post 
culling, and am looking for anyone else who may have recieved some mail a few 
weeks back, relevent info looks like:

Date: Tue,  8 Mar 2005 12:01:59 -0800
From: Steve Gladstone <[EMAIL PROTECTED]>
Subject: Register for the VoIP Deployment, Diagnostics & Monitoring Webinar
Sniffing about the opt-out functions gave me:
You have already been opted-in to the system
Email Address:  [EMAIL PROTECTED]
Email Type: not specified, defaulted to MIME
Date and time signed up:March 03, 2005 at 07:16:16 PST
A description of how your email address was obtained:   Internal Sources
From Empirix
A discussion with the VP running the division responsible for the mailing has 
met with.. a door in the face, basically.

Anyone with time (and a log trail), would you mind checking to see if you 
recieved it as well, and contact me offlist?

Thanks!
- billn

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[Dorian Kim]

On Tue, Mar 29, 2005 at 02:27:56PM -0600, John Dupuy wrote:
> I was looking at it from a route announcement point of view. Transit is 
> where AS A advertises full routes to AS B. Thus, AS B is getting transit 
> from A. Peering is where A & B only advertise their network and, possibly, 
> the networks that stub or purchase transit from them.
> 
> It is my understanding that the top ISPs "trade transit". They provide full 
> routes to each other without payment, regardless of how or where the route 
> was learned from. They are willing to pass some traffic without 
> compensation because it makes for better connectivity. From an announcement 
> POV they are not peering.
>
> I am still curious: do any of the larger ISPs on this list want to 
> confirm/deny the previous paragraph?

ISPs formerly known as tier1s in general peer with each other, not trade 
transit. 
If one of the peers started sending us full routes, that would quickly result 
in a 
NOC to NOC chat about route leaks.

If they exchanged full routes, wouldn't that be mutual transit, not peering?

This isn't meant to imply that networks don't play kinky games with each other
at various times that can confuse outside observers, but peering is peering
and transit is transit, most of the time.

-dorian

OT: Chasing spam.

[Bill Nash]

I'm chasing after some spam that appears to have been built from a nanog 
post culling, and am looking for anyone else who may have recieved some 
mail a few weeks back, relevent info looks like:

Date: Tue,  8 Mar 2005 12:01:59 -0800
From: Steve Gladstone <[EMAIL PROTECTED]>
Subject: Register for the VoIP Deployment, Diagnostics & Monitoring Webinar
Sniffing about the opt-out functions gave me:
You have already been opted-in to the system
Email Address:  [EMAIL PROTECTED]
Email Type: not specified, defaulted to MIME
Date and time signed up:March 03, 2005 at 07:16:16 PST
A description of how your email address was obtained:   Internal Sources
From Empirix
A discussion with the VP running the division responsible for the mailing 
has met with.. a door in the face, basically.

Anyone with time (and a log trail), would you mind checking to see if you 
recieved it as well, and contact me offlist?

Thanks!
- billn

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[Patrick W Gilmore]

On Mar 29, 2005, at 3:27 PM, John Dupuy wrote:
I guess I'm looking at this too much from the point of view of a BGP 
Admin.

Yes, if you are looking at this from the point of view of payment, 
then the top ISPs do not pay each other.

I was looking at it from a route announcement point of view. Transit 
is where AS A advertises full routes to AS B. Thus, AS B is getting 
transit from A. Peering is where A & B only advertise their network 
and, possibly, the networks that stub or purchase transit from them.

It is my understanding that the top ISPs "trade transit". They provide 
full routes to each other without payment, regardless of how or where 
the route was learned from. They are willing to pass some traffic 
without compensation because it makes for better connectivity. From an 
announcement POV they are not peering.

I am still curious: do any of the larger ISPs on this list want to 
confirm/deny the previous paragraph?
I would be AMAZINGLY interested if anyone confirms the above paragraph.
AFAIK, 701/1239/209/etc. do not give full tables to _anyone_ unless 
they are paid.

Someone care to correct me?
--
TTFN,
patrick

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[Stephen J. Wilcox]

On Tue, 29 Mar 2005, John Dupuy wrote:

> I was looking at it from a route announcement point of view. Transit is where
> AS A advertises full routes to AS B. Thus, AS B is getting transit from A.
> Peering is where A & B only advertise their network and, possibly, the
> networks that stub or purchase transit from them.

no, they MUST send their customer nets else their customers will not have 
global reachability

> It is my understanding that the top ISPs "trade transit". They provide full 
> routes to each other without payment, regardless of how or where the route 
> was learned from. They are willing to pass some traffic without 
> compensation because it makes for better connectivity. From an announcement 
> POV they are not peering.

ahhh. no, they send peering only between each other (approx 5 routes for 
each of the biggest providers - level3, sprint, uunet, at&t)

Steve

> I am still curious: do any of the larger ISPs on this list want to 
> confirm/deny the previous paragraph?
> 
> I think we are getting into "defining terms" territory. So, I will bow out 
> of the discussion.
> 
> John
> 
> At 01:56 PM 3/29/2005, David Barak wrote:
> 
> >--- John Dupuy <[EMAIL PROTECTED]> wrote:
> >
> > > But by the technical description of a "transit free
> > > zone", then 701 is not
> > > tier one, since I have encountered scenarios where
> > > many AS are transversed
> > > between 701 and other networks, not just a peer of a
> > > peer. Unless, by
> > > "transit free zone" you mean "transit trading" where
> > > large providers permit
> > > each other to transit for free. (Which gets back to
> > > my 'who hurts more'
> > > discussion.)
> > >
> >
> >
> >
> >Transit = being someone's customer
> >
> >Peering = permitting your customers to go to your
> >peer's customers or the peer's network, but not the
> >peer's peers, without exchange of money.
> >
> >Any other relationship != peering for my purposes
> >(although lots of subtly different relationships
> >exist, the largest networks tend to take a view which
> >is not too dissimilar to the one shown above)
> >
> >
> >
> >Are you implying that 701 is paying someone to carry
> >their prefixes?  While I'm not the peering coordinator
> >for 701, I would find that improbable.  I would expect
> >that money would flow the other direction (and thus
> >701 would become a more valuable peer for other
> >networks).
> >
> > > I'm willing to be wrong. If any of the large
> > > providers on the list will say
> > > that their network does not transit beyond the
> > > customer of a peer; and they
> > > still maintain full connectivity, I will gladly be
> > > corrected.
> >
> >oodles and oodles of people can say this (and already
> >have).  A paying customer of mine can readvertise
> >(with a non-munged AS_PATH) any of my prefixes which
> >they want, and thus provide transit for other people
> >to reach me.  That does not change the fact that I'm
> >not paying for transit.
> >
> >So in short, I would say that T1 vs T2 etc is a
> >"follow the money":
> >
> >T1 => doesn't pay anyone else to carry their prefixes,
> >and runs a default-free network.
> >
> >T2 => pays one or more T1 providers to carry their
> >prefixes, may or may not run a default-free network.
> >
> >T3 => leaf node, pays one or more T1/T2 providers to
> >carry their traffic, probably uses default route.
> >
> >YMMV, blah blah blah
> >
> >
> >David Barak
> >Need Geek Rock?  Try The Franchise:
> >http://www.listentothefranchise.com
> >
> >
> >
> >__
> >Do you Yahoo!?
> >Yahoo! Sports - Sign up for Fantasy Baseball.
> >http://baseball.fantasysports.yahoo.com/
> 
> 

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[John Dupuy]

I guess I'm looking at this too much from the point of view of a BGP Admin.
Yes, if you are looking at this from the point of view of payment, then the 
top ISPs do not pay each other.

I was looking at it from a route announcement point of view. Transit is 
where AS A advertises full routes to AS B. Thus, AS B is getting transit 
from A. Peering is where A & B only advertise their network and, possibly, 
the networks that stub or purchase transit from them.

It is my understanding that the top ISPs "trade transit". They provide full 
routes to each other without payment, regardless of how or where the route 
was learned from. They are willing to pass some traffic without 
compensation because it makes for better connectivity. From an announcement 
POV they are not peering.

I am still curious: do any of the larger ISPs on this list want to 
confirm/deny the previous paragraph?

I think we are getting into "defining terms" territory. So, I will bow out 
of the discussion.

John
At 01:56 PM 3/29/2005, David Barak wrote:
--- John Dupuy <[EMAIL PROTECTED]> wrote:
> But by the technical description of a "transit free
> zone", then 701 is not
> tier one, since I have encountered scenarios where
> many AS are transversed
> between 701 and other networks, not just a peer of a
> peer. Unless, by
> "transit free zone" you mean "transit trading" where
> large providers permit
> each other to transit for free. (Which gets back to
> my 'who hurts more'
> discussion.)
>

Transit = being someone's customer
Peering = permitting your customers to go to your
peer's customers or the peer's network, but not the
peer's peers, without exchange of money.
Any other relationship != peering for my purposes
(although lots of subtly different relationships
exist, the largest networks tend to take a view which
is not too dissimilar to the one shown above)

Are you implying that 701 is paying someone to carry
their prefixes?  While I'm not the peering coordinator
for 701, I would find that improbable.  I would expect
that money would flow the other direction (and thus
701 would become a more valuable peer for other
networks).
> I'm willing to be wrong. If any of the large
> providers on the list will say
> that their network does not transit beyond the
> customer of a peer; and they
> still maintain full connectivity, I will gladly be
> corrected.
oodles and oodles of people can say this (and already
have).  A paying customer of mine can readvertise
(with a non-munged AS_PATH) any of my prefixes which
they want, and thus provide transit for other people
to reach me.  That does not change the fact that I'm
not paying for transit.
So in short, I would say that T1 vs T2 etc is a
"follow the money":
T1 => doesn't pay anyone else to carry their prefixes,
and runs a default-free network.
T2 => pays one or more T1 providers to carry their
prefixes, may or may not run a default-free network.
T3 => leaf node, pays one or more T1/T2 providers to
carry their traffic, probably uses default route.
YMMV, blah blah blah
David Barak
Need Geek Rock?  Try The Franchise:
http://www.listentothefranchise.com

__
Do you Yahoo!?
Yahoo! Sports - Sign up for Fantasy Baseball.
http://baseball.fantasysports.yahoo.com/

Re: phishing sites report - March/2005

[Daniel Golding]

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

- Dan

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

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

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[David Barak]

--- John Dupuy <[EMAIL PROTECTED]> wrote:

> But by the technical description of a "transit free
> zone", then 701 is not 
> tier one, since I have encountered scenarios where
> many AS are transversed 
> between 701 and other networks, not just a peer of a
> peer. Unless, by 
> "transit free zone" you mean "transit trading" where
> large providers permit 
> each other to transit for free. (Which gets back to
> my 'who hurts more' 
> discussion.)
> 



Transit = being someone's customer

Peering = permitting your customers to go to your
peer's customers or the peer's network, but not the
peer's peers, without exchange of money.

Any other relationship != peering for my purposes
(although lots of subtly different relationships
exist, the largest networks tend to take a view which
is not too dissimilar to the one shown above)



Are you implying that 701 is paying someone to carry
their prefixes?  While I'm not the peering coordinator
for 701, I would find that improbable.  I would expect
that money would flow the other direction (and thus
701 would become a more valuable peer for other
networks).

> I'm willing to be wrong. If any of the large
> providers on the list will say 
> that their network does not transit beyond the
> customer of a peer; and they 
> still maintain full connectivity, I will gladly be
> corrected.

oodles and oodles of people can say this (and already
have).  A paying customer of mine can readvertise
(with a non-munged AS_PATH) any of my prefixes which
they want, and thus provide transit for other people
to reach me.  That does not change the fact that I'm
not paying for transit.

So in short, I would say that T1 vs T2 etc is a
"follow the money":

T1 => doesn't pay anyone else to carry their prefixes,
and runs a default-free network.

T2 => pays one or more T1 providers to carry their
prefixes, may or may not run a default-free network.

T3 => leaf node, pays one or more T1/T2 providers to
carry their traffic, probably uses default route.

YMMV, blah blah blah


David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com



__ 
Do you Yahoo!? 
Yahoo! Sports - Sign up for Fantasy Baseball. 
http://baseball.fantasysports.yahoo.com/

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[John Dupuy]

My apologies to UUNet/MCI, I'm not trying to pick on you, but you are 
useful to the discussion.

But by the technical description of a "transit free zone", then 701 is not 
tier one, since I have encountered scenarios where many AS are transversed 
between 701 and other networks, not just a peer of a peer. Unless, by 
"transit free zone" you mean "transit trading" where large providers permit 
each other to transit for free. (Which gets back to my 'who hurts more' 
discussion.)

I'm willing to be wrong. If any of the large providers on the list will say 
that their network does not transit beyond the customer of a peer; and they 
still maintain full connectivity, I will gladly be corrected.

John
At 07:23 PM 3/28/2005, you wrote:
On Mon, 28 Mar 2005, John Dupuy wrote:
> I'll be brief, but I do want to perhaps word Alex's definition in a 
different way
> that might be more useful.
>
> Even "tier 1" providers regularly trade transit. They must since no single
> network is connected to all the other ones. Not even close. Even UUNet (ASN
> 701), arguably the most-connected network on the planet, only connects to a
> fraction of the possible peerings.

701 is not the most connected, it has only customers and a restrictive set of
peers?
you dont need to peer with all networks tho, if all networks are buying 
from 701
or one of its peers then it will get those routes via peering not transit or
transit trades... you seem to be forgetting what peering is.

and if you peer with all networks in the 'transit free zone' then you too 
become
transit free also.

> The true definition is more vague: if a peering or transit circuit 
between A or B
> is taken down, who will be hurt the most: A or B? If it predominantly 
B, and much
> less A, then A is "more Tier 1" and B is of a "lesser Tier". If they 
are equally
> hurt, they the are of equal status. Essentially, "Tier 1" is whatever 
the other
> "Tier 1" providers believe at the moment is "Tier 1". It is 
self-referential and
> not distinct at all.

i believe the distinction exists as shown above ie transit free.. as to 
why this
might be considered a goal i'm not sure, its not obvious that transit free is
cheaper than buying transit!

this thing about 'who hurts most' is an entirely different topic and has 
nothing
to do with who is in the transit free zone. altho destructive depeering does
seem to be common practice within that zone :)

> This is, frustratingly, a very non-technical definition. But it seems 
to map
> with what I've actually seen the industry do.

thats because non-technical definitions mean anyone can call themselves 
anything
they like.. wiltel recently spammed me to buy their 'tier1 transit'.. 
presumably
they are tier1 within their own definition of tier1.

if you want to be technical tho, and aiui we are a technical forum, then 
tier1
means transit free.

i reaffirm my earlier point - but why care, isnt it about cost and 
reliability,
and as peering and transit are about the same cost who cares who you dont 
peer
with

Steve
>
> John
>
> At 09:17 AM 3/28/2005, Stephen J. Wilcox wrote:
>
>   On Mon, 28 Mar 2005, Randy Bush wrote:
>
>   > > Firstly, peering isn't binary. Is peering vs transit a 
distinction
>   based on
>   > > routes taken / accepted & readvertised, or on cost? Does 
"paid for
>   peering"
>   > > count as peering or transit? If you pay by volume? If you pay for
>   "more than
>   > > your fair share" of the interconnect pipes? (if the latter, I am
>   guessing
>   > > there are actually no Tier 1s as everyone reckons they pay 
for more
>   than
>   > > their fair share...).
>   >
>   > pay?  did i say pay?  i discussed announcement and receipt of
>   prefixes.  this
>   > was not an accident.  it is measurable.
>
>   i also avoided money.. i dont think its that relevant, everyone is
>   paying for
>   peering or transit in one form or another, i dont think any 
peering is
>   free
>   (free != settlement free)
>
>   > > Secondly, it doesn't cover scenarios that have have happened 
in the
>   past.
>   > > For instance, the route swap. EG Imagine networks X1, X2, X3, X4
>   are "Tier
>   > > 1" as Randy describes them. Network Y peers with all the above
>   except X1.
>   > > Network Z peers with all the above except X2. Y & Z peer. To 
avoid
>   Y or Z
>   > > needing to take transit, Y sends Z X2's routes (and sends Z's
>   routes to X2
>   > > routes marked "no export" to X2's peers), and Z sends Y X1's 
routes
>   (and
>   > > sends Y's routes to X1 marked "no export" to X1's peers). Perhaps
>   they do
>   > > this for free. Perhaps they charge eachother for it and settle up
>   at the end
>   > > of each month. Perhaps it's one company that's just bought 
another.
>
>   "transit (n). The act of passing over, across, or through; passage."
>
>   whether it is a settlement

Re: DNS cache poisoning attacks -- are they real?

[Sam Hayes Merritt, III]

When I reported this the bug/feature was changed but I noticed a while
back (late 8.x maybe 9.0) that it is back. So if the purp can get you to
the wrong server only once it may be possible to keep you there.
It was actually fixed in 9.2.3rc1.
1429.   [bug]   Prevent the cache getting locked to old servers.
See this thread: http://marc.theaimsgroup.com/?t=11105723064&r=1&w=4
Of course I still don't think its a bug, and it forced  people to remember 
to actually finish the job when they moved their DNS around. But whatever, 
its easier than doing a rndc flushname name (which finally got put in).


sam

Re: The U.N. thinks about tomorrow's cyberspace

[Suresh Ramasubramanian]

On Tue, 29 Mar 2005 14:35:55 GMT, Fergie (Paul Ferguson)
<[EMAIL PROTECTED]> wrote:
> 
> 
> An interesting article & interview with Houlin Zhao,
> director of the ITU's Telecommunication Standardization
> Bureau (who would like very much for the UN to become
> more involved in "Internet Governance").
> 

Actually, this got discussed extensively on [EMAIL PROTECTED] -
with lots of clued operators participating

For a context on the zhao proposals - and how they impact you - see
http://www.nro.net/archive/index.html

Sounds dangerously like ITU is trying to apply a telephone numbering
paradigm to IP allocation policies, and various people are latching
ont o it to start their very own "lets all dump the RIRs and reserve
IP space and its management, policy etc on a per country basis" -
rather unlike the current setup where LIRs like CNNIC, JPNIC etc work
under the APNIC framework to allocate IPs in a particular country

Where igov entities such as the ITU WGIG process and the OECD WILL
come in useful is that gray and ugly area where there's crossover with
actual  law and order issues - particularly enforcement of antispam
and other computer crime laws across countries, particularly useful
when a phisher or spammer has a domain up in one country, a payment
gateway in some other country, spams out of abused cablemodems in a
third country and then sets up a shell company with multiple levels of
obfuscation in a completely different country.

Oh, add to it that these two organizations are listened to by telecom
regulators, and guess who is the only entity that runs the internet in
several countries .. none other than the incumbent telco that also has
a substantial ISP business and govt sanctioned monopolies in some
cases ... ITU / OECD have a far better chance of reaching tham than
most network operators have.

--srs (opinions from having attended and spoken at ITU / OECD conferences)

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[Tom Vest]

On Mar 29, 2005, at 12:24 PM, Tom Vest wrote:
On Mar 29, 2005, at 12:08 PM, Stephen J. Wilcox wrote:
Maybe I'm wrong, i checked with renesys and their data has 701 with 
5200
adjacencies followed by 1239 with 3500 anyway i care enough to have 
snipped the
data.
Does anyone know how many of these adjacencies are with single-homed 
ASNs, i.e., ASNs that are out-of-spec and likely artifacts of previous 
M&A transactions?

Tom

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[Valdis . Kletnieks]

On Mon, 28 Mar 2005 16:17:21 +0100, "Stephen J. Wilcox" said:
> however alex, you do highlight an excellent point - things are not as simple 
> as
> 'tier1, tier2', there are complicated routing and financial arrangements in
> operation, which brings me back to my earlier point: does it matter what a
> network is paying for some connectivity providing they deliver to you the 
> connectivity you need at the quality you desire?

As long as their price point for their connectivity is set such that they
can remain a viable ongoing business concern while fulfilling the requirements
of my contract, it doesn't really matter, except at contract renegotiation time.
At that point, if I know they're making money off selling others transit to
my packets, I may try to negotiate a price concession


pgpgmbrpKY1Mn.pgp
Description: PGP signature

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[Stephen J. Wilcox]

On Tue, 29 Mar 2005, Richard A Steenbergen wrote:

> On Tue, Mar 29, 2005 at 02:23:06AM +0100, Stephen J. Wilcox wrote:
> > 
> > 701 is not the most connected, it has only customers and a restrictive 
> > set of peers?
> 
> Ok, I'm just bored enough to bite. 

but not as bored as bill, randy or patrick it would seem :)

> If we're talking about a contest to see who has the most number of directly
> connected ASNs, I think UU might still win, even with a restrictive set of
> peers.

I didnt think we were, kinda happened.. if peering partners is a compensation 
for something else its pretty sad ;)

Maybe I'm wrong, i checked with renesys and their data has 701 with 5200
adjacencies followed by 1239 with 3500 anyway i care enough to have snipped the
data. 

> Which begs the question, what is the largest number of ASNs that someone peers
> with? Patrick? :) Somehow I suspect that 701's customer base (702 and 703
> aren't included in the above count BTW) overpower even the most aggressively
> open of peering policies, in this particular random pointless and arbitrary
> contest at any rate.

so what are we debating again? :)


Steve

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[Stephen J. Wilcox]

On Tue, 29 Mar 2005, [EMAIL PROTECTED] wrote:

> > and if you peer with all networks in the 'transit free zone' then you too 
> > become 
> > transit free also.
> > 
> 
>   er.. hate to rain on your parade but if I peer with everyone 

these are not the words of someone hating to rain on me!

>   i need/want to exchange traffic with, i am transit-free, even
>   if I -NEVER- touch any other part of the commercial Internet...

mmm yeah but in the context we have here of ISPs providing connectivity to 
other 
ISPs or enterprises this isnt very realistic so i dont see the point of arguing 
the technicality. 

>   my packets get to where they need to go and all packets I want
>   get to me.  my life is good ... even if I only appear as vestigal
>   to the commercial Internet, if I appear at all.

sounds more like an enterprise with specific requirements to connect to a 
limited part of the internet.. this is not the sort of ISP operation that i am 
working in.

>   how would you classify such a network?  T1, T2, ODDBALL-0, 
>   non-Internet-265, ???  

enterprise

Steve

MCI Accepts Verizon's $7.6 Billion Offer

[Fergie (Paul Ferguson)]

MCI Accepts Verizon's $7.6 Billion Offer
Tue Mar 29, 2005 10:48 AM ET 

WASHINGTON (Reuters) - MCI Inc. said on Tuesday it accepted a revised takeover 
bid from Verizon Communications Inc. worth about $7.6 billion, rejecting a 
$8.45 billion offer from Qwest Communications International Inc.

MCI said Verizon's revised offer includes $8.75 per MCI share in cash and 
$14.75 per MCI share in Verizon stock. Of the $8.75, up to $5.60 would be paid 
to MCI shareholders when the deal closes.

The two companies also increased the termination fee Verizon would be owed if 
the deal falls through to $240 million. 

© Reuters 2005. All Rights Reserved.

Re: DNS cache poisoning attacks -- are they real?

[Chris Brenton]

On Tue, 2005-03-29 at 08:49, Joe Maimon wrote:
>
> TIC: Apparently DNS was designed to be TOO reliable and failure resistant.

Ya, sometimes security and functionality don't mix all that well. ;-)

> As I understand from reading the referenced cert thread, there is the
> workaround which is disabling open recursion and then there are the
> potential fixes.

>From an admin perspective, this is the way to go. This is a real easy
fix with Bind via "allow-recursion". I don't play with MS DNS that
often, but the last time I looked recursion was an on/off switch. So of
the MS DNS box is Internet accessible, you are kind of hosed.

> 1) Registrars being required to verify Authority in delegated to
> nameservers (will this break any appreciated valid models?) before
> activating/changing delegation for zone.

Back in the InterNIC days this was SOP. This security check got lost
when things went commercial. Not sure if it would be possible to get it
back at this point. Too many registrars out there to try and enforce it.

IMHO lack of verification is only part of the problem (that has been
going on for years). What has made this more of an issue is registrars
that offer immediate response time to changes. This makes it far easier
to spammers to move to other stolen resources as required.

> Is it possible/practical to perpertrate this kind of hijak without
> registrar cooperation by first seeding resolver's caches and then
> changing NS on authoritative so that future caches will resolve from
> seeded resolvers? Is it possible to not even need to change the zone
> served NS/SOA and to use the hijaking values from the get-go?

Possibly. I ran into a bug/feature with Bind back in the 8.x days which
causes the resolver to go back to the last know authoritative server
when a TTL expires. On this plus side, this helps to reduce traffic on
the root name servers. On the down side, if the remote name server still
claims authority you will never find the new resource. I ran into the
problem moving a client from one ISP to another while the old ISP was
acting vindictive and refused to remove the old records. This of course
caused problems for their clients because when the TTLs expired they
kept going back to the old resource. Only way to clear it is a name
server restart at every domain looking up your info.

When I reported this the bug/feature was changed but I noticed a while
back (late 8.x maybe 9.0) that it is back. So if the purp can get you to
the wrong server only once it may be possible to keep you there.

> 2) Stricter settings as regards to all lame delegations -- SERVFAIL by
> default without recursion/caching attempts?

See my last post. IMHO there are too many broken but legitimate name
servers out there for this to be functional for most environments.

> Is all the local limitations on TTL values a good thing?

In this case, absolutely! With the default Bind setting, a TTL of
360 will get quietly truncated to a week. This means a trashed cache
will fix itself in one week rather than six.

HTH,
Chris

Re: The U.N. thinks about tomorrow's cyberspace

[Jim Popovitch]

I love how Zhao thinks the ITU could be involved with SPAM issues.  I
say they fix the telemarketers first.  ;-) 

-Jim P.

On Tue, 2005-03-29 at 14:35 +, Fergie (Paul Ferguson) wrote:
> 
> An interesting article & interview with Houlin Zhao,
> director of the ITU's Telecommunication Standardization
> Bureau (who would like very much for the UN to become
> more involved in "Internet Governance").
> 
> http://news.com.com/The+U.N.+thinks+about+tomorrows+cyberspace/2008-1028_3-5643972.html?tag=nefd.lede
> 
> - ferg
> 
> --
> "Fergie", a.k.a. Paul Ferguson
>  Engineering Architecture for the Internet
>  [EMAIL PROTECTED] or [EMAIL PROTECTED]

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[Patrick W Gilmore]

On Mar 29, 2005, at 1:24 AM, Richard A Steenbergen wrote:
On Tue, Mar 29, 2005 at 02:23:06AM +0100, Stephen J. Wilcox wrote:
701 is not the most connected, it has only customers and a restrictive
set of peers?
Ok, I'm just bored enough to bite. If we're talking about a contest to 
see
who has the most number of directly connected ASNs, I think UU might 
still
win, even with a restrictive set of peers.

Taking a look at a count of customer ASNs behind some specific 
networks of
note, I come up with the following (some data a couple weeks out of 
date,
but the gist is the same):

Network ASN Count
--- -
701 2298
70181889
12391700
33561184
209 1086
174 736
3549584
3561566
2914532
2828427
6461301
1299243
Which begs the question, what is the largest number of ASNs that 
someone
peers with? Patrick? :) Somehow I suspect that 701's customer base (702
and 703 aren't included in the above count BTW) overpower even the most
aggressively open of peering policies, in this particular random 
pointless
and arbitrary contest at any rate.
Of course.  There is a difference between "most peers" and "most 
adjacent ASes".

But it is non-trivial to see which of those adjacencies are transit and 
which are peering.  (Nearly impossible if you define such things on 
Layer 8, but not impossible if you only include which ASes are 
propagated to which other ASes.)

At the end of the day, an AS with a LOT of downstream ASes can always 
beat a well peered AS - there just aren't that many ASes which peer.

--
TTFN,
patrick

Re: DNS cache poisoning attacks -- are they real?

[Florian Weimer]

* Chris Brenton:

> In a perfect world, this might be a viable solution. The problem is
> there are far too many legitimate but "broken" name servers out there.
> On an average day I log well over 100 lame servers. If I broke this
> functionality, my helpdesk would get flooded pretty quickly with angry
> users.

Assuming BIND 9:

/*
 * Is the server lame?
 */
if (fctx->res->lame_ttl != 0 && !ISFORWARDER(query->addrinfo) &&
is_lame(fctx)) {
log_lame(fctx, query->addrinfo);
result = dns_adb_marklame(fctx->adb, query->addrinfo,
  &fctx->domain,
  now + fctx->res->lame_ttl);
if (result != ISC_R_SUCCESS)
isc_log_write(dns_lctx, DNS_LOGCATEGORY_RESOLVER,
  DNS_LOGMODULE_RESOLVER, ISC_LOG_ERROR,
  "could not mark server as lame: %s",
  isc_result_totext(result));
broken_server = DNS_R_LAME;
keep_trying = ISC_TRUE;
goto done;
}

So if you see something in the logs, it is already broken. 8-)

The discussion in this part of the thread focuses on flagging more
servers as lame (which are currently not detected by BIND or even
logged).

Re: DNS cache poisoning attacks -- are they real?

[Chris Brenton]

On Tue, 2005-03-29 at 05:37, Simon Waters wrote:
>
> The answers from a recursive servers won't be marked authoritative (AA bit 
> not 
> set), and so correct behaviour is to discard (BIND will log a lame server 
> message as well by default) these records.
> 
> If your recursive resolver doesn't discard these records, suggest you get one 
> that works ;)

In a perfect world, this might be a viable solution. The problem is
there are far too many legitimate but "broken" name servers out there.
On an average day I log well over 100 lame servers. If I broke this
functionality, my helpdesk would get flooded pretty quickly with angry
users.

HTH,
Chris

Re: The U.N. thinks about tomorrow's cyberspace

[Fergie (Paul Ferguson)]

Like I said, interesting article.  ;-)

- ferg


-- Eric Brunner-Williams in Portland Maine <[EMAIL PROTECTED]> wrote:

Paul,

I worked with Houlin Zhao extensively during 2001, and met with him again
at the Rome ICANN meeting. He's a smart guy.

Eric

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 [EMAIL PROTECTED] or [EMAIL PROTECTED]

Re: The U.N. thinks about tomorrow's cyberspace

[Eric Brunner-Williams in Portland Maine]

Paul,

I worked with Houlin Zhao extensively during 2001, and met with him again
at the Rome ICANN meeting. He's a smart guy.

Eric

The U.N. thinks about tomorrow's cyberspace

[Fergie (Paul Ferguson)]

An interesting article & interview with Houlin Zhao,
director of the ITU's Telecommunication Standardization
Bureau (who would like very much for the UN to become
more involved in "Internet Governance").

http://news.com.com/The+U.N.+thinks+about+tomorrows+cyberspace/2008-1028_3-5643972.html?tag=nefd.lede

- ferg

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 [EMAIL PROTECTED] or [EMAIL PROTECTED]

Telcordia report on ICANN .net RFP Evaluation

[Eric Brunner-Williams in Portland Maine]

Oki all,

A summary of the report and a link to the full report can be found at:

http://www.icann.org/announcements/announcement-28mar05.htm

So now you know. VGRS, NS+, AF, ranked 1, 2, 3; DE and CORE ranked 4 & 5.

Eric

ICANN Publishes Telcordia Report on their Findings and Rankings for .N ET

[Fergie (Paul Ferguson)]

FYI,

ICANN has published an update on the selection of a
successor operator for the .NET registry:

http://www.icann.org/announcements/announcement-28mar05.htm

- ferg

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 [EMAIL PROTECTED] or [EMAIL PROTECTED]

Re: DNS cache poisoning attacks -- are they real?

[Joe Maimon]

Chris Brenton wrote:
On Mon, 2005-03-28 at 01:04, John Payne wrote:
And to Randy's point about problems with open recursive nameservers... 
abusers have been known to cache "hijack".  Register a domain, 
configure an authority with very large TTLs, seed it onto known open 
recursive nameservers, update domain record to point to the open 
recursive servers rather than their own.  Wammo, "bullet proof" dns 
hosting.

I posted a note to Bugtraq on this process about a year and a half ago
as at the time I noticed a few spammers using this technique. Seems they
were doing this to protect their NS from retaliatory attacks. 
http://cert.uni-stuttgart.de/archive/bugtraq/2003/09/msg00164.html

Large TTLs only get you so far. All depends on the default setting of
max-cache-ttl. For Bind this is 7 days. MS DNS is 24 hours. Obviously
spammers can do a lot of damage in 7 days. :(
HTH,
Chris
TIC: Apparently DNS was designed to be TOO reliable and failure resistant.
As I understand from reading the referenced cert thread, there is the
workaround which is disabling open recursion and then there are the
potential fixes.
1) Registrars being required to verify Authority in delegated to
nameservers (will this break any appreciated valid models?) before
activating/changing delegation for zone.
If this is all there is to it, than I see no reason why Registrar
laziness and desire for profit$ should take precedence over ops changes
across the board.
Is it possible/practical to perpertrate this kind of hijak without
registrar cooperation by first seeding resolver's caches and then
changing NS on authoritative so that future caches will resolve from
seeded resolvers? Is it possible to not even need to change the zone
served NS/SOA and to use the hijaking values from the get-go?
2) Stricter settings as regards to all lame delegations -- SERVFAIL by
default without recursion/caching attempts?
3) Paranoid checking for situations such as these by having recursing
nameservers attempt to periodically check for suspicous NS and glue from
the parent zone's POV and compare it to cache, trashing cached records
if they do not like result.
4) Rate limiting?
Since at this point I am out of my depth, I think I'll stop here after a
simple question.
Is all the local limitations on TTL values a good thing?

Re: Ironcore foundry

[Issam Hakimi [ Killix ]]

Le mardi 29 Mars 2005 14:37, vous avez écrit :
> Issam Hakimi [ Killix ] wrote:
> > I am in the search of documentation on the ironcore generation of the
> > routers foundry. All the urls are the welcomes.
>
> http://www.foundrynet.com/services/documentation/index.html
>
Thanks, but one does not find on foundry website a documentation for ironcore 
architecture (netiron) like 
http://www.foundrynet.com/solutions/appNotes/JetCore.html (this is for 
jetcore architecture)

regards,
Issam Hakimi

Re: phishing sites report - March/2005

[Gadi Evron]

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

Gadi.

RE: Ironcore foundry

[David Hubbard]

Issam Hakimi [ Killix ] wrote:
> I am in the search of documentation on the ironcore generation of the
> routers foundry. All the urls are the welcomes.
> Thanks.
> 
> Regards,
> Issam Hakimi

http://www.foundrynet.com/services/documentation/index.html

David

abuse & security issues > Israel

[Gadi Evron]

Hello.
Back in the mid 90th, it has become a fact that Israel was one of the
main focal points of Internet abuse in the world, and reaching abuse
contacts was very difficult.
Today, we no longer hold that title. Also, some of the ISP's in Israel
are now very responsive to abuse, it is not true with most others.
Still, a lot of abuse originates from Israeli net space and finding
working abuse contacts in meat space remains difficult.
We at CERT.gov.il are responsible for the Government's net space [AS8867
/ gov.il] and are available to help with any problems originating from
our networks if such exist.
We are also aiming to help clue up Israeli ISP's in general to Internet
abuse, but for now, if anyone has abuse and security issues that need
resolving, and yet find it difficult to find who to contact and/or get
response/action, feel free to ping me personally here at CERT.gov.il. We
will do our best to connect you with the right people, and follow up.
Aside to that, I am pleased to announce IL-ops. An active Israeli
network operators group that discusses mainly security and spam issues
between Israeli ISP's.
We here in Israel are making an effort - let us help you.
Yours,
--
Gadi Evron,
Information Security Manager, Project Tehila -
Israeli Government Internet Security.
Ministry of Finance, Israel.
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Office: +972-2-5317890
Fax: +972-2-5317801
http://www.tehila.gov.il

Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]

[Michael . Dillon]

> And how, pray tell, does one actually "measure" T1 vs. T2 networks? 

That's easy. You define a set of criteria by which you can measure
the networks on some scale, and then set two thresholds. Networks
which exceed the higher threshold are Tier 1, those which only
exceed the lower threshold are Tier 2.

I have seen people do this by counting the number of ASes that
a network connects to. And I have seen this done with nodes by
summing up the bandwidth of all circuits connected to a node.

Even though the network is a dynamic partial mesh, researchers
can learn a lot about the behavior by imposing various types
measurement hierachy on the network.

Thus, Tier 1 and Tier 2 are not inherent characteristics of
the Internet; rather they are characteristics of a particular
view of the network at a particular point in time. There are
probably people who are trying to measure a hierarchy of latency
or a hierarchy of jitter. The more views, the merrier.

--Michael Dillon

Re: DNS cache poisoning attacks -- are they real?

[Florian Weimer]

* Simon Waters:

>> This is _nothing_ to do with what you're running on the recursive
>> nameserver.  It is doing _exactly_ what it is supposed to do.  Get
>> answers, store in cache, respond to queries from cache if TTL isn't
>> expired.
>
> The answers from a recursive servers won't be marked authoritative (AA bit 
> not 
> set), and so correct behaviour is to discard (BIND will log a lame server 
> message as well by default) these records.

Unfortunately, this is not quite true.  Brad and Chris are right.  I
couldn't believe it either, but after a long stare at BIND's is_lame
function, I have to agree with them.

BIND accepts non-authoritative answers if their additional section
looks a bit like a referral.  I don't tink that this check is
deliberately lax, but stricter checks are simply harder to do on this
particular code path.

> If your recursive resolver doesn't discard these records, suggest
> you get one that works ;)

Which one would?  Keep in mind that referrals do not have the AA bit
set, so a simple filter wouldn't work.

Re: DNS cache poisoning attacks -- are they real?

[Florian Weimer]

* Brad Knowles:

> At 12:09 AM +0200 2005-03-28, Florian Weimer wrote:
>
>>  I doubt this will work on a large scale.
>
>   It's already been done on a large scale.
>
>>At least recent BIND
>>  resolvers would discard replies from the abused caching resolvers
>>  because they lack the AA bit, so only clients using the resolvers as
>>  actual resolvers are affected.
>
>   Incorrect.

Indeed.

> The resolver requiring that the AA bit be set would prohibit anyone
> from forwarding queries to another server, which might be answering
> from cache.

Would you point me to such a configuration?  I don't think it will
work reliably for this purpose because BIND 9 only waives the
requirement for the AA bit if the authority section of the response
remotely looks like a referral.  I doubt that this is the case if you
simply redirect to a cache.

Re: DNS cache poisoning attacks -- are they real?

[Simon Waters]

On Monday 28 Mar 2005 4:54 pm, John Payne wrote:
>
> This is _nothing_ to do with what you're running on the recursive
> nameserver.  It is doing _exactly_ what it is supposed to do.  Get
> answers, store in cache, respond to queries from cache if TTL isn't
> expired.

The answers from a recursive servers won't be marked authoritative (AA bit not 
set), and so correct behaviour is to discard (BIND will log a lame server 
message as well by default) these records.

If your recursive resolver doesn't discard these records, suggest you get one 
that works ;)

I assumed the reason open recursive servers are a "bad idea" are that you can 
guess to within a second when they will rerequest a record from the 
authoritative servers, so you know when to try and send a spoofed answer for 
a domain you are trying to poison. Thus it makes brute force poisoning 
attacks less obvious because you don't have to send thousands of packets till 
you hit the right time and client id, you just have to guess the right client 
id, as you can guess the "right time" (for busy domains at least) by asking 
when will this record expire.

I've never seen a malicious attack of this type in anger, but it is 
theoretically possible (although much harder again DJB dnscache because it 
opens a new port per request), and well documented as a vulnerability of the 
DNS protocol.

For large ISPs I would have thought this was a legitimate concern, but being 
able to poison one cache, at one small ISP, one time in so many thousand, is 
a limited result for a lot of effort. Still if you have a "botnet" spare and 
no spam runs to process I guess the effort is writing the software to try.

Ironcore foundry

[Issam Hakimi [ Killix ]]

I am in the search of documentation on the ironcore generation of the routers 
foundry. All the urls are the welcomes.
Thanks.

Regards,
Issam Hakimi