RE: New Draft Document: De-boganising New Address Blocks

[william(at)elan.net]

BTW - in the email it meant to be just stand DOS (Original IBM PC Operating
System based on CP/M), I automaticly write small "o" now when using this 
word because of how I've used it in the last sevaral years

On Tue, 24 Feb 2004, william(at)elan.net wrote:

> 
> On Tue, 24 Feb 2004, Michel Py wrote:
> 
> > 
> > William,
> > 
> > > william(at)elan.net wrote:
> > > [http://www.cymru.com/BGP/bogon-rs.html]
> > > Unfortunetly this is kind-of a bgp hack and as has
> > > been already mentioned it needs very carefull
> > > implemention
> > 
> > This is not positive thinking. I don't consider this a hack (if it is,
> > then the draft that proposes to re-use ORF mechanisms is even worse).
> Quite a bit of difference I think, ORF is almost perfect fit for it.
> 
> You seem to think that when I say its a hack it necessarily means its a 
> very bad thing. Not at all, I use(d) hacks in DoS, Windows, PalmOS, Linux,
> etc. all the time. Hacks often lead to real feature in the OS or program 
> in the future, which is hopefully what will happen here.
> 
> > I'm not interested in what things were designed to do, I'm interested in
> > what things _can_ do.
> > 
> > I use [Cymru] myself as I am within the applicability domain. I use your
> > stuff too. However, you might be borderline to abusing co-author
> > privileges here; Team Cymru has lead the route-server project for long,
> Nobody is disputing their longterm efforts in this area. 
> 
> > and although the bogon list is by nature a lot less controversial than
> > what you do the bottom line is the acceptance of Cymru's feed is far
> > greater than Completewhois.
> There is no feed from completewhois to even try to compare at this time.
> (you can compare dns feed, but that is slightly different). And when 
> there is it might different purpose and one might better in one situation 
> or the other.
> 
> > Please don't use draft-py-idr-redisfilter-01.txt as a platform to
> > compete with other co-authors; collaborative competition is sound,
> > please stay within its borders.
> I dont really compete with other authors at all, in fact its not even 
> easily possible as completewhois does not even provide production BGP feed 
> at this time. And I don't intend to make this into some kind or race 
> in the future either - the lists are different and have slightly different
> levels of activity they are trying to protect from. 
> 
> And going OT here, I really do not see a problem with two or more
> implementations, we have this at many levels and reality is that it
> actually leads to highier degree of innovation. As an example I'm quite
> happy that there is both FreeBSD and Linux or both Gnome and K-Desktop.
> (although wars between proponents of one of the other can sometimes be a 
> bit disturbing). Its too bad on the other hand we only have one "Windows".

Re: 168.0.0.0/6

[Randy Bush]

> I have previously contacted Swisscom about it back in 9/2003 and
> received the following response:
>> we are filtering on RIR minimal allocation boundaries. This
>> creates some routing holes which we fill by these semi-default
>> routes (towards our upstreams) for our customers' perusal.

luckily, things like this are never leaked into the open internet
by multi-homed customers and weak filtering policies.


randy

Re: 168.0.0.0/6

[Hank Nussbacher]

At 07:39 AM 25-02-04 +0800, Randy Bush wrote:

> Isn't that something to notify AS3303 aka SWISSCOM about rather
> than NANOG?
perhaps because this path has been taken in the past and failed?

> Especially since it does not look like it is spreading very
> widely.
hard to tell, isn't it.  and hard to say the effect on the places
to which it has spread.
I have previously contacted Swisscom about it back in 9/2003 and received 
the following response:
we are filtering on RIR minimal allocation boundaries. This creates some 
routing holes which we fill by these semi-default routes (towards our 
upstreams) for our customers' perusal.
Fixedorbit had to special case Swisscom since they came out in their IP 
table as the #1 IP holder.  That honor is now held by DISO.

-Hank

RE: Proposal: De-boganising New Address Blocks

[william(at)elan.net]

On Tue, 24 Feb 2004 [EMAIL PROTECTED] wrote:

> Assuming the pilot program does some form of reachability testing and then 
> some effort is made to notify those with bad filters (good luck), then at 
> least this notifies them before it's a real inconvenience for anyone.  
> They may or may not choose to react, but at least this puts them on notice 
> that they have a problem that will be real in the near future.

It would be good that the statistics be provided how many locations tested
failed routability of previously bogon space. And after end of the testing
and efforts to contact network admins, the retesting should be done and 
again similar statistics provided as well as directly list of ips where 
at the end the blocks were still not working.

-- 
William Leibzon
Elan Networks
[EMAIL PROTECTED]

RE: New Draft Document: De-boganising New Address Blocks

[william(at)elan.net]

On Tue, 24 Feb 2004, Michel Py wrote:

> Hint: all this bogon or related filtering is not a long-term solution.
> We need it now, but the long term solution is some kind of
> authentication that will allow only the rightful owner of a block to
> announce it.

This I completely agree with. The correct future solution is authentication of
network ownership of ip block with proper digital signatures (in fact I
think I put on completewhois website). Its too bad S-BGP does not seem to 
be have futher development and more support. And I reject the idea that 
not enough memory is a big problem for deployment - the memory on PCs is 
really cheap now and the router vendors can easily develop routers with 
1GB or RAM or more when needed and protocol can be done in a way that 
signatures are complimentary/optional and not required so as to support 
slow deployment. 

PS. I have lots of ideas in this area, I'd love to know where to send them
all, I don't see any discussion on any public mailing list about S-BGP.

-- 
William Leibzon
Elan Networks
[EMAIL PROTECTED]

RE: Proposal: De-boganising New Address Blocks

[jlewis]

On Tue, 24 Feb 2004, Michel Py wrote:

> Good idea, no contest. Now, the devil's advocate asks: what makes you
> think that operators/ISPs are going to react faster to your pilot stuff
> being bogonized than they would to real traffic being bogonized, as if
> it's a pilot project it's by definition not urgent and can wait
> tomorrow?
> 
> Although I salute the effort, I am concerned that this will not change
> current reactive behavior which is to wait for the shit to hit the fan
> to update bogon lists. Might sound sad, but I think the way to

Assuming the pilot program does some form of reachability testing and then 
some effort is made to notify those with bad filters (good luck), then at 
least this notifies them before it's a real inconvenience for anyone.  
They may or may not choose to react, but at least this puts them on notice 
that they have a problem that will be real in the near future.

--
 Jon Lewis [EMAIL PROTECTED]|  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|  
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

RE: New Draft Document: De-boganising New Address Blocks

[william(at)elan.net]

On Tue, 24 Feb 2004, Michel Py wrote:

> 
> William,
> 
> > william(at)elan.net wrote:
> > [http://www.cymru.com/BGP/bogon-rs.html]
> > Unfortunetly this is kind-of a bgp hack and as has
> > been already mentioned it needs very carefull
> > implemention
> 
> This is not positive thinking. I don't consider this a hack (if it is,
> then the draft that proposes to re-use ORF mechanisms is even worse).
Quite a bit of difference I think, ORF is almost perfect fit for it.

You seem to think that when I say its a hack it necessarily means its a 
very bad thing. Not at all, I use(d) hacks in DoS, Windows, PalmOS, Linux,
etc. all the time. Hacks often lead to real feature in the OS or program 
in the future, which is hopefully what will happen here.

> I'm not interested in what things were designed to do, I'm interested in
> what things _can_ do.
> 
> I use [Cymru] myself as I am within the applicability domain. I use your
> stuff too. However, you might be borderline to abusing co-author
> privileges here; Team Cymru has lead the route-server project for long,
Nobody is disputing their longterm efforts in this area. 

> and although the bogon list is by nature a lot less controversial than
> what you do the bottom line is the acceptance of Cymru's feed is far
> greater than Completewhois.
There is no feed from completewhois to even try to compare at this time.
(you can compare dns feed, but that is slightly different). And when 
there is it might different purpose and one might better in one situation 
or the other.

> Please don't use draft-py-idr-redisfilter-01.txt as a platform to
> compete with other co-authors; collaborative competition is sound,
> please stay within its borders.
I dont really compete with other authors at all, in fact its not even 
easily possible as completewhois does not even provide production BGP feed 
at this time. And I don't intend to make this into some kind or race 
in the future either - the lists are different and have slightly different
levels of activity they are trying to protect from. 

And going OT here, I really do not see a problem with two or more
implementations, we have this at many levels and reality is that it
actually leads to highier degree of innovation. As an example I'm quite
happy that there is both FreeBSD and Linux or both Gnome and K-Desktop.
(although wars between proponents of one of the other can sometimes be a 
bit disturbing). Its too bad on the other hand we only have one "Windows".

-- 
William Leibzon
Elan Networks
[EMAIL PROTECTED]

RE: Proposal: De-boganising New Address Blocks

[Michel Py]

Daniel,

[me puts the Devil's advocate suit on]

If I read this correctly, the way I summarize it is:

"Instead of waiting for people that get real delegations in a newly
allocated /8 to have real problems, we delegate parts of this new /8 to
pilot projects before hand, knowing that there will be issues, which
allows us to contact operators that are still bogonizing the new block.
The idea being that the inconvenience caused by a pilot project being
bogonized is of little consequence where the inconvenience of a real
delegation being bogonized is real."

Good idea, no contest. Now, the devil's advocate asks: what makes you
think that operators/ISPs are going to react faster to your pilot stuff
being bogonized than they would to real traffic being bogonized, as if
it's a pilot project it's by definition not urgent and can wait
tomorrow?

Although I salute the effort, I am concerned that this will not change
current reactive behavior which is to wait for the shit to hit the fan
to update bogon lists. Might sound sad, but I think the way to
de-bogonize new blocks is to automate the de-bogonization process, as
the idea to de-bogonize ahead of time will not cut it as a priority,
IMHO.

My $0.02, and let me stress that I did not intend to sound negative as
the idea is good; I'm just a little skeptical.

Michel.

Re: New Draft Document: De-boganising New Address Blocks

[william(at)elan.net]

On Tue, 24 Feb 2004, Timothy Brown wrote:

> > Completewhois bogon ip lists provide data on ip blocks that are not allocated
> > by RIRs to ISPs (rather then just list of /8 blocks not allocated by IANA 
> > to RIRs as for example cymru does). The list can be used for anti-spam 
> > filtering through dns using rbl-like feed at
> >  bogons.dnsiplists.completewhois.com
> 
> As you say, you could use your "bogon ip lists" DNS feed for anti-spam
> purposes, but that wasn't the original subject of this discussion and has
> no relevance here. 
That its not the original subject does not mean it has no relevence as has 
been quickly shown by the first reply to the original message (which was 
then the message I replied to).

> With regards to using your lists for the filtering of
> invalid space, your own service has been proven to be little more than 
> unreliable and incorrect in the case of the hijacked IP blocks.  
If I were you, I'd not listen to rumors spread by certain very unhappy NY
networkadmin group or use the word "proven" when its almost the other way 
around. Not one of the blocks listed can be shown to be wrong and those 
that are suspicious but not easily shown as hijacked or confirmed in that 
way by RIRs are not put in list used for active filtering. 

However, its true I'm little behind on adding new found hijacked blocks to 
the webpage as unless the block is a big problem I prefer to do it together 
with full file about that block including info about real ip block owner
and there is also necessity to wait for answer from that owner. For those 
new blocks, you can check spamhaus zombie list (their files are brief but 
they will list most important data).

In any case, how matters with hijacked ip list are handled is completely 
different then what is done with bogons as creating bogon list is 
completely automated and based only on RIR data.

> Most people appear to trust the Cymru effort for this data. I think tracking 
> the blocks that are allocated by RIRs to ISPs is a little unwieldy at 
> this time, and i'd rather not trust a third party source of this data 
> without some verifiability, which to date, you have not been proven 
> capable of.  Even the RIRs have accuracy problems.
Completewhois publishes data for each day separately and keep archives 
from the beginning feel free to check/verify. Errors do happen from time 
to time, today there was a problem due to data that I got from RIR (first 
problem in two months BTW) which I'm reporting to them as it was almost 
certainly a bug on their side (in general I like to doublecheck the data 
with both whois and statistical files - unfortunetly for legacy blocks as 
already mentioned statistical files are not very reliable at this time and 
this is where most of the errors happen). 

As for using only IANA bogon data - it is good to to filter on engress but
(i.e. spoofed packets) but offers very limited protection against those 
purposely trying to announce/use invalid blocks (with so much data space not
allocated to ISPs within ip block allocated to RIRs, its no more difficult for
bad guy to use ip block in say 70/8 then it is for them to use one in 71/8)

> > > Uh, bogon route server, hello?
> > > 
> > > http://www.cymru.com/BGP/bogon-rs.html
> > Unfortunetly this is kind-of a bgp hack and as has been already mentioned 
> > it needs very carefull implemention and if not done right it leads to 
> > leaks like we saw in the today's "168.0.0.0/6" thread on nanog-l. 
> 
> I disagree with the view that it is a hack.
Most others who tried it do not disagree. But using hacks is not necessarily
bad and it maybe the only way to go until correct solution is developed. 
You just have to be carefull to know exactly what you do.

> It's no more a hack than using a DNS feed; 
Serves different purpose and not easily comparable. BGP feed is filtering 
on network level in network core and/or edge. DNS feed is great for 
filtering at the end and at specific service level. Yet another case
also exist for filtering specificaly at edge level through the firewall.

> as with any solution, everything depends on your
> cluefulness during implementation and your awareness of what you're doing
> to your network.  
Correct. But "hacks" tend to require a lot more cluefullness even from 
people who are otherwise quite good at something.

> The reality is that I agree with you when it comes to more features from 
> vendors in order to support involved external filtering changes,
> but the practical side shows that the way to do this today is via a prefix
> update via the routing protocol,  unless you go the route of other providers 
> who have implemented a strict regime for the management of configuations and
> their nightly updates.  Then again, we can debate functions of the control 
> plane and the desire to reduce reliance on external systems in a routing 
> product.
That maybe subject for another list, like IETF IDR.

-- 
William Leibzon
Elan Networks
[EMAIL P

RE: New Draft Document: De-boganising New Address Blocks

[Michel Py]

> Timothy Brown wrote:
> I disagree with the view that it is a hack.
> It's no more a hack than using a DNS feed;

I concur with this. Besides, from the pragmatic side of the "consumer",
if it does solve a problem (albeit short or medium term) I don't care
much if it's a "hack".

Hint: all this bogon or related filtering is not a long-term solution.
We need it now, but the long term solution is some kind of
authentication that will allow only the rightful owner of a block to
announce it.

Michel.

RE: New Draft Document: De-boganising New Address Blocks

[Michel Py]

William,

> william(at)elan.net wrote:
> [http://www.cymru.com/BGP/bogon-rs.html]
> Unfortunetly this is kind-of a bgp hack and as has
> been already mentioned it needs very carefull
> implemention

This is not positive thinking. I don't consider this a hack (if it is,
then the draft that proposes to re-use ORF mechanisms is even worse).

I'm not interested in what things were designed to do, I'm interested in
what things _can_ do.

I use [Cymru] myself as I am within the applicability domain. I use your
stuff too. However, you might be borderline to abusing co-author
privileges here; Team Cymru has lead the route-server project for long,
and although the bogon list is by nature a lot less controversial than
what you do the bottom line is the acceptance of Cymru's feed is far
greater than Completewhois.

Please don't use draft-py-idr-redisfilter-01.txt as a platform to
compete with other co-authors; collaborative competition is sound,
please stay within its borders.

Thanks
Michel.

Re: New Draft Document: De-boganising New Address Blocks

[Timothy Brown]

> Completewhois bogon ip lists provide data on ip blocks that are not allocated
> by RIRs to ISPs (rather then just list of /8 blocks not allocated by IANA 
> to RIRs as for example cymru does). The list can be used for anti-spam 
> filtering through dns using rbl-like feed at
>  bogons.dnsiplists.completewhois.com

As you say, you could use your "bogon ip lists" DNS feed for anti-spam
purposes, but that wasn't the original subject of this discussion and has
no relevance here.  With regards to using your lists for the filtering of
invalid space, your own service has been proven to be little more than 
unreliable and incorrect in the case of the hijacked IP blocks.   Most 
people appear to trust the Cymru effort for this data.   I think tracking 
the blocks that are allocated by RIRs to ISPs is a little unwieldy at 
this time, and i'd rather not trust a third party source of this data 
without some verifiability, which to date, you have not been proven 
capable of.  Even the RIRs have accuracy problems.

> > Uh, bogon route server, hello?
> > 
> > http://www.cymru.com/BGP/bogon-rs.html
> Unfortunetly this is kind-of a bgp hack and as has been already mentioned 
> it needs very carefull implemention and if not done right it leads to 
> leaks like we saw in the today's "168.0.0.0/6" thread on nanog-l. 

I disagree with the view that it is a hack.  It's no more a hack
than using a DNS feed; as with any solution, everything depends on your
cluefulness during implementation and your awareness of what you're doing
to your network.  

The reality is that I agree with you when it comes to more features from 
vendors in order to support involved external filtering changes,
but the practical side shows that the way to do this today is via a prefix
update via the routing protocol,  unless you go the route of other providers 
who have implemented a strict regime for the management of configuations and
their nightly updates.  Then again, we can debate functions of the control 
plane and the desire to reduce reliance on external systems in a routing 
product.

Tim

SIGCOMM Workshop on Network Troubleshooting

[jon bennett]

(Recent messages on the list suggest this announcement to be quite timely)

We hope that this workshop will be of interest to NANOG members and that 
many of you will participate and/or submit material to it.

Jon Bennett and Mark Allman   ( [EMAIL PROTECTED] )

http://www.acm.org/sigcomm/sigcomm2004/netts.html

---
To be held in conjunction with SIGCOMM '04
Network Troubleshooting:
 Research Theory and Operations Practice Meet Malfunctioning Reality
Call For Papers

Network monitoring and measurement has received a great deal of attention 
in the research community recently.  While some research to-date has been 
focused on finding problems, failures and anomalies in networks this 
workshop endeavors to focus specifically on such topics.  The workshop 
seeks papers exploring several themes:

DETECTION: Mechanisms and techniques for detecting failures, imminent 
failures and other anomalies in real time.  The focus of this workshop is 
research that can be used operationally to help the network in the 
short-term.  Techniques that require heavyweight off-line analysis to find 
problems provide the community with an understanding of and an insight into 
the dynamics and potential long-term solutions for network issues, but are 
not the main focus of this workshop.

CORRECTION: While detecting problems (or imminent problems) and alerting 
network operators is a good first step, techniques for automatically 
mitigating problems as they occur are also sought.

COORDINATION: Detecting and solving problems in a multi-provider 
environment inevitably involves communicating between distinct autonomous 
entities.  Mechanisms and facilities to streamline and automate such 
communication are sought.

EXPERIENCE: Insight from network operators into network problems they 
cannot easily detect (or, detect far too late) and tools that would make 
network management much easier.  Input from network operators on 
non-obvious or non-technical considerations which impact technical 
solutions are also sought.

This workshop invites two kinds of submissions:

Original papers on any area of network measurement, monitoring or 
management specifically directed towards one or more of the above themes.

Poster presentation proposals.  While posters on any of the above themes 
will be accepted, posters on operational experience are highly sought.

Note: For this workshop, "networks" includes both physical networks and 
virtual networks (CDNs, overlays, etc.).

Some of the specific problems of interest, include:
Protocol failures - link, routing, management
Detecting mis-configuration of network elements
Partial hardware failures - intermittent, unreported
Traffic engineering for overload control
Security - DDoS attacks, detecting compromised network elements, intrusion 
detection (especially for non-edge networks since a large body of work 
already tackles the problems at the network edge)

Submissions:

Submissions ranging from presentations of specific research to position 
papers are welcome. Papers presenting interesting and novel ideas at an 
early stage of development are preferred over completed journal-style 
results. Selected papers will be forward-looking, with impact and 
implications for both operational networks and ongoing or future research.

Original papers should be 3-6 standard SIGCOMM formatted pages (with the 
expectation that position papers will be shorter and research papers longer).

Poster proposals should be sent in the form of 1-page abstracts.

The submission process and specific guidelines will be posted at a later date.

Important Dates:

Submission registration: April 8, 2004
Submission deadline: April 15, 2004
Notification deadline: May 15, 2004
Camera ready deadline: June 15, 2004
Workshop Co-Chairs ([EMAIL PROTECTED])

 Jon C.R. Bennett, Harvard University
 Mark Allman, ICIR
Program Committee:

 TBD 

Re: eBGP, iBGP, injecting networks- Thanks!

['[EMAIL PROTECTED]']

greetings all,
  
wanted to send a mail and say thanks to all who responded on and off
list. 

there were a lot of great suggestions given.

for now, we achieved prefix announcement redundancy (i shouldn't 
have called it router redundancy in the first post) in AS 1 by 
duplicating our network statements in bgp and also our 'pull up', 
static routes to Null0 254 in our routing table in another router in  
AS1.  It runs iBGP in ASN1 to our border router that talks to 
Above.net

we still need to achieve prefix announcement redundancy in ASN 2 
tho.  it looks like we are going to do this by putting network 
statements and null0 254 routes into a router in ASN1.  We only have  
one router in ASN2, whereas we have 5 routers in ASN1.

this will lead to an inconsistent AS origin for the routes from ASN2  
but that seems like the best, temp. workaround for now until we merge
AS's.

thanks again.

l8r- 
jg

Quoting Fowlie, Colin <[EMAIL PROTECTED]>:
> 
> I think the main concern you have here is the advertisement of the networks from two 
> different ASN's to two different upstream providers.  You'll have to set it up with 
> your upstream ISP's to allow you to advertise all of the networks, but typically 
> it's not a problem.  You won't have an issue with routing loops as BGP speaker will 
> drop a prefix that has its own ASN in the path-list.  If you prepend properly to the 
> AS path things will behave the way you want them to.  This will provide your
> inbound redundancy.
> 
> HTH
> 
> Colin Fowlie
> 
> -Original Message-
> From: Curtis Maurand [mailto:[EMAIL PROTECTED] 
> Sent: Monday, February 23, 2004 11:49 AM
> To: Ing. Hans L. Reyes
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: eBGP, iBGP, injecting networks
> 
> 
> 
> 
> He might try:
> 
> http://www.cisco.com/en/US/tech/tk365/tk80/technologies_configuration_example09186a0080093f2c.shtml
> 
> This one shows how to  setup HSRP on the inside for the automatic failover 
> that he's looking for.
> 
> Curtis
> 
> On Fri, 20 Feb 2004, Ing. Hans L. Reyes wrote:
> 
> > 
> > 
> > Hi
> > 
> > Your problem may be is similar when one ISP buy to another ISP, sometimes
> > is easy to modify the IGP like in this case (OSPF) because it is something
> > inside of your company and you have the control over all the devices but
> > you still have the problem outside of the company; client, others ISP, etc
> > 
> > Check the feature of BGP "Local-AS" for routers Cisco if yours routers
> > aren't Cisco, check for someone similar with your vendor. May be you need
> > to do something else.
> > 
> > This is the url where explain how it works.
> > 
> > http://www.cisco.com/en/US/tech/tk365/tk80/technologies_configuration_example09186a00800949cd.shtml
> > 
> > I hope it help you
> > -Hans
> > 
> > On Fri, 20 Feb 2004 [EMAIL PROTECTED] wrote:
> > 
> > > 
> > > greetings list,
> > > 
> > > hoping someone can hook me up on the right way to do this.
> > > 
> > > ---
> > > 
> > > we have two ASN's we control.
> > > 
> > > we have two border/edge routers (1 in each ASN) that talks to a
> > > different backbone provider.
> > > 
> > > the two border routers peer with eachother over eBGP and also are in
> > > the same OSPF process.  (we are working to merge them into the same
> > > BGP ASN)
> > > 
> > > my question is this:
> > > 
> > > how do we achieve router redundancy between these two routers?
> > > 
> > > currently if we lose a transit link, the traffic will flow fine out
> > > the other pipe.
> > > 
> > > but we don't have BGP network statements in router 2 that exist in
> > > router 1 and we don't have BGP network statements in router 1 that
> > > exist in router 2.
> > > 
> > > so the routes injected into BGP from router 1 will get withdrawn right
> > > if router 1 dies?
> > > 
> > > is it a problem to announce the same networks from two different eBGP
> > > peers to two different upstreams?
> > > 
> > > --
> > > 
> > > if you are still reading, thanks!
> > > 
> > > to clearify some more-
> > > 
> > > current setup:
> > > 
> > > current setup:
> > > 
> > > ASN 1 (we're not Genu!ty- just using for an example)
> > > 
> > > :)
> > > 
> > > ASN 1 injects all of its own space and announces this space to
> > > Above.net and ASN 2
> > > 
> > > ASN 2 injects all of its own space and announces this space to Savvis
> > > and ASN 1.
> > > 
> > > so stuff out on the net looks like:
> > > 
> > > 1 6461 etc etc
> > > 
> > > and
> > > 
> > > 1 2 6347
> > > 
> > > ---
> > > 
> > > 2 6347 etc etc
> > > 
> > > and
> > > 
> > > 2 1 6461 etc etc
> > > 
> > > ---
> > > 
> > > so, you see we are prepending on of our AS's on the way out.
> > > 
> > > the problem is tho, we only have 1 router in each respective Autonmous
> > > System injecting address space.  if we lose that router, we lose
> > > announcing that ASN's space.
> > > 
> > > is it totally going to cause probs to have routes originating from two
> > > different AS's?  routing loops would be a real dr

Re: Level 3 statement concerning 2/23 events (nothing to see, move along)

[Colin Neeson]

Because, in the the grand scale scheme of things, it's really not that 
important.

No one died because of it, the normal, everyday events of the world 
went on,
unaffected by a Level 3 outage...

Might be nice to know what happened, but my life will certainly not be 
less interesting by not having that knowledge...

-colin.

On 25 Feb 2004, at 4:13 AM, Alex Rubenstein wrote:



And we, the general Internet public, tends to just accept this and 
forget
about it.

Why do we do this?

RE: 168.0.0.0/6

[Jeroen Massar]

-BEGIN PGP SIGNED MESSAGE-

william(at)elan.net wrote:

> This has been mentioned on nanog maillist before, it appears several months 
> after notification swisscom still has not fixed this problem(when similar 
> leak came from he, I think they fixed it in 48 hours!). Here are pointers 
> to previous thread:
>  http://www.merit.edu/mail.archives/nanog/2003-11/msg00626.html
>  http://www.merit.edu/mail.archives/nanog/2003-11/msg00636.html

I guess SWISSCOM (AS3303) has a nice trackrecord to uphold:
http://mailman.isi.edu/pipermail/6bone/2002-December/006924.html

Added the persons who where able to fix that problem that time,
maybe it helps this time too ;)

Greets,
 Jeroen

-BEGIN PGP SIGNATURE-
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / http://unfix.org/~jeroen

iQA/AwUBQDvhUCmqKFIzPnwjEQJjoQCeKEEnysAMLazSQvmvbgVk/3VzpC0AoKo0
FfK/Yg1TKAFJGbt1AyjR+5Jh
=DtY/
-END PGP SIGNATURE-

Re: 168.0.0.0/6

[Randy Bush]

> Isn't that something to notify AS3303 aka SWISSCOM about rather
> than NANOG?

perhaps because this path has been taken in the past and failed?

> Especially since it does not look like it is spreading very
> widely.

hard to tell, isn't it.  and hard to say the effect on the places
to which it has spread.

randy

Re: 168.0.0.0/6

[william(at)elan.net]

This has been mentioned on nanog maillist before, it appears several months 
after notification swisscom still has not fixed this problem (when similar 
leak came from he, I think they fixed it in 48 hours!). Here are pointers 
to previous thread:
 http://www.merit.edu/mail.archives/nanog/2003-11/msg00626.html
 http://www.merit.edu/mail.archives/nanog/2003-11/msg00636.html

On Wed, 25 Feb 2004, Randy Bush wrote:

> >> route-views.oregon-ix.net>sh ip bgp 169.223.0.0
> >> BGP routing table entry for 168.0.0.0/6, version 7688303
> >> Paths: (1 available, best #1, table Default-IP-Routing-Table)
> >>   Not advertised to any peer
> >>   3277 13062 20485 20485 20485 8437 3303
> >> 194.85.4.249 from 194.85.4.249 (194.85.4.249)
> >>   Origin IGP, localpref 100, valid, external, best
> >
> > *> 24.0.0.0  194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 60.0.0.0/7194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 62.0.0.0  194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 63.0.0.0  194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 64.0.0.0/6194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 68.0.0.0/7194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 70.0.0.0  194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 80.0.0.0/6194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 84.0.0.0  194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 128.0.0.0/3   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 160.0.0.0/5   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 168.0.0.0/6   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 199.0.0.0/8   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 200.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 202.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 204.0.0.0/6   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 208.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 210.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 212.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 216.0.0.0/8   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 217.0.0.0/8   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 218.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 220.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> > *> 222.0.0.0/8   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> 
> this seems to cause some strangeness when one's block is having various
> announcement problems and falls within swisscom's imperialistic reach.  is
> cousin george doing their routing policy? :-)
> 
> randy
> 

Re: New Draft Document: De-boganising New Address Blocks

[william(at)elan.net]

On Tue, 24 Feb 2004, Timothy Brown wrote:

> On Tue, Feb 24, 2004 at 04:32:46PM +, [EMAIL PROTECTED] wrote:
> > 
> > >The RIPE NCC has prepared a draft document titled "De-Bogonising New
> > >Address Blocks":
> > 
> > That is a misleading title.
I agree, consindering the block is still a bogon until it has been allocated
by RIPE to ISP, but advanced notification is still good. And its especially 
good that RIRs are actively trying to get involved in things like this.

> > The problem is that ISPs cannot react quickly enough
> > to open filters when new ranges are allocated. The proposed
> > solution is to provide advance notification. I suppose this
> > could allow ISPs to open filters before the new addresses
> > are actually in use officially.
> > 
> > However, it will also allow spammers to announce this
> > space and get it through bogon filters.

Completewhois bogon ip lists provide data on ip blocks that are not allocated
by RIRs to ISPs (rather then just list of /8 blocks not allocated by IANA 
to RIRs as for example cymru does). The list can be used for anti-spam 
filtering through dns using rbl-like feed at
 bogons.dnsiplists.completewhois.com

The actual list of all such RIR unallocated blocks is at:
 http://www.completewhois.com/bogons/data/bogons-cidr-all.txt

Similar list can also be created based on RIR ip statistics file (not right
now as they still have serious problems with not listing some legacy blocks,
but hopefully RIRs will finish the ERX and fix it all in the next year).

> > The real solution to this problem is to make it 
> > possible for ISPs to closely track RIR allocations
> > in their filters in a semi-automated way. There may
> > still be a few days of delay before a new allocation
> > is fully routable but ISPs can compensate for that
> > with internal processes. 
Yes, 24-36 hours delay exists before new allocations are cleared from 
bogon list when done in automated way. But I found that < 1% of the blocks are 
routed within first 24 hours of allocated (in fact 30% are still not 
routed 2 months after allocated).

> > Why can't ISPs subscribe to a feed of all new 
> > RIPE allocations in near real-time?
> 
> Uh, bogon route server, hello?
> 
> http://www.cymru.com/BGP/bogon-rs.html
Unfortunetly this is kind-of a bgp hack and as has been already mentioned 
it needs very carefull implemention and if not done right it leads to 
leaks like we saw in the today's "168.0.0.0/6" thread on nanog-l. 

What we do need is for ISPs and other organizations to urge vendors to
implement router software changes for distributed bgp filtering as has been
detailed in this draft (already mentioned quite extensively on other threads):
http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-01.txt

-- 
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: 168.0.0.0/6

[Randy Bush]

>>> BGP routing table entry for 168.0.0.0/6, version 7688303
>>> ...
>>>   3277 13062 20485 20485 20485 8437 3303
>>> 194.85.4.249 from 194.85.4.249 (194.85.4.249)
>>>   Origin IGP, localpref 100, valid, external, best
>>> 
>>> ripe is being overgenerous to the swiss!
>> 
>> Not so. They are pretending to be over-endowed to some peers
>> only.
> 
> Not so, as has been re-re-re-hashed, 3303 is sending bogon 
> feeds to some parties [presumably their customers] and those 
> are getting regurgitated to route-views.  route-views is a 
> varied slice of different kinds of announcement sets (full 
> tables, partial, internal deaggs, ect etc); looking-glass 
> comparison shopping is the only way to get meaningful data.

the problem is that those getting the over-reaching data have
a view of the internet which can cause them and some destinations
problems.  this is very analogous to seeing 0/0 with a six hop
path in route-views, as you say, we don't really know the reach
of the bad data.

randy

Re: 168.0.0.0/6

[Randy Bush]

>> route-views.oregon-ix.net>sh ip bgp 169.223.0.0
>> BGP routing table entry for 168.0.0.0/6, version 7688303
>> Paths: (1 available, best #1, table Default-IP-Routing-Table)
>>   Not advertised to any peer
>>   3277 13062 20485 20485 20485 8437 3303
>> 194.85.4.249 from 194.85.4.249 (194.85.4.249)
>>   Origin IGP, localpref 100, valid, external, best
>
> *> 24.0.0.0  194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 60.0.0.0/7194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 62.0.0.0  194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 63.0.0.0  194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 64.0.0.0/6194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 68.0.0.0/7194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 70.0.0.0  194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 80.0.0.0/6194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 84.0.0.0  194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 128.0.0.0/3   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 160.0.0.0/5   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 168.0.0.0/6   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 199.0.0.0/8   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 200.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 202.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 204.0.0.0/6   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 208.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 210.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 212.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 216.0.0.0/8   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 217.0.0.0/8   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 218.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 220.0.0.0/7   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i
> *> 222.0.0.0/8   194.85.4.249  0 3277 13062 20485 20485 20485 8437 3303 i

this seems to cause some strangeness when one's block is having various
announcement problems and falls within swisscom's imperialistic reach.  is
cousin george doing their routing policy? :-)

randy

Re: 168.0.0.0/6

[Joe Provo]

On Tue, Feb 24, 2004 at 04:36:03PM +0100, Daniel Karrenberg wrote:
> 
> On 24.02 23:20, Randy Bush wrote:
> > 
> > BGP routing table entry for 168.0.0.0/6, version 7688303
> > ...
> >   3277 13062 20485 20485 20485 8437 3303
> > 194.85.4.249 from 194.85.4.249 (194.85.4.249)
> >   Origin IGP, localpref 100, valid, external, best
> > 
> > ripe is being overgenerous to the swiss!
> 
> Not so. They are pretending to be over-endowed to some peers
> only.

Not so, as has been re-re-re-hashed, 3303 is sending bogon 
feeds to some parties [presumably their customers] and those 
are getting regurgitated to route-views.  route-views is a 
varied slice of different kinds of announcement sets (full 
tables, partial, internal deaggs, ect etc); looking-glass 
comparison shopping is the only way to get meaningful data.

-- 
 RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

REMINDER: ARIN to allocate from 70.0.0.0/8

[Leslie Nobile]

Hello-

This is a reminder that ARIN will begin allocating IP address space from
70.0.0.0/8 in the immediate future.  This will include allocations of /20
and shorter prefixes, according to ARIN's minimum allocation policy. 

You may wish to adjust any filters you have in place accordingly.

For informational purposes, a list of ARIN's currently
administered IP blocks can be found under "CIDR Blocks" at:

http://www.arin.net/statistics/index.html


Regards,

Leslie Nobile
Director, Registration Services
American Registry for Internet Numbers (ARIN)

Sprint and AT&T backbone engineer

[alex]

Hello,

If any Sprint and AT&T backbone engineer with visibility into live
capacity issues in North East could drop me a message of list, I would
greatly appreciate it.  

Thanks,
Alex

Re: [IP] VeriSign prepares to relaunch "Site Finder" -- calls

[Dan Hollis]

On Tue, 24 Feb 2004, Paul Vixie wrote:
> > Unlaterally forcing it upon everyone and breaking non www based apps is 
> > the wrong way to do it.
> if you have well founded views on this topic and you have not yet shared
> them with ICANN's SSAC, please do so.  see .

There is nothing I can say that hasn't already been said explicitly and 
clearly and multiple times already.

I can only speak as a network engineer, and Verisign has already made it 
abundantly clear they dismiss engineering views entirely, they see us as a 
bunch of whiny anti-business geeks with no grip on reality.

Does SSAC have any authority over what Verisign does? If SSAC recommends 
something contrary to Verisign's designs, what's stopping Verisign from 
going ahead and doing it anyway? My questions to SSAC are not what they're 
currently asking for input for (according to their page, they are only 
looking for security and stability input at the moment).

If you know the proper ICANN committee for these questions, I'm all ears.

-Dan

Re: [IP] VeriSign prepares to relaunch "Site Finder" -- calls

[Jason Nealis]

One other item is that some ISP's like us can't do the browser plug in option because
of the "dial-up accelerator" products already embedded to the browser , installing
paxfires technology on top of our accelerator plug in would just chew IE and its tcp 
stack.   

Also they state they only proxy A record lookups thus no mx lookups.  Either way, 
it seems scary to me. But I do agree this is a revenue stream that Mickeysoft
is probably making a ton off of. 


--
Jason Nealis
RCN (NASDAQ) RCNC
~
~

On Tue, Feb 24, 2004 at 12:09:56PM -0800, Dan Hollis stated
> On Tue, 24 Feb 2004, Jason Nealis wrote:
> > It's a module plug-in into bind and if you prefer to try and do this in a
> > opt-in basis they have a client program that you download and it gets hooked
> > into the users browser.
> 
> This is the right way to do it, end user opt in, and browser only.
> 
> Unlaterally forcing it upon everyone and breaking non www based apps is 
> the wrong way to do it.
> 
> -Dan

-- 

Re: [IP] VeriSign prepares to relaunch "Site Finder" -- calls

[Brian Bruns]

On Tuesday, February 24, 2004 3:09 PM [EST], Dan Hollis <[EMAIL PROTECTED]>
wrote:

> On Tue, 24 Feb 2004, Jason Nealis wrote:
>> It's a module plug-in into bind and if you prefer to try and do this in a
>> opt-in basis they have a client program that you download and it gets
>> hooked into the users browser.
>
> This is the right way to do it, end user opt in, and browser only.
>
> Unlaterally forcing it upon everyone and breaking non www based apps is
> the wrong way to do it.
>
> -Dan

Also means less profit. We already know for a fact that Verisign/Netsol could
give a damn about whats right and wrong, and whats a good way to do something
and whats a bad way to do something.  Anything that cuts into their profit
they will kick and scream bloody murder until they get their way.

Remember what happened when they were forced to allow other registars access
to their database?  I remember specifically service quality go horribly
through the floor, requests getting screwed up, almost on purpose, billing
messups that never happened before, etc.  And this suddenly happened right
around the same time that their monopoly was forcefully taken away.

I dont even want to ponder what kind of outages and other issues we will have
if they don't get their way.


I have a feeling that I'm going to get whacked for violating the AUP of the
list, but oh well.  Truth hurts.

-- 
Brian Bruns
The Summit Open Source Development Group
Open Solutions For A Closed World / Anti-Spam Resources
http://www.sosdg.org

The Abusive Hosts Blocking List
http://www.ahbl.org

Re: [IP] VeriSign prepares to relaunch "Site Finder" -- calls

[Paul Vixie]

> > It's a module plug-in into bind and if you prefer to try and do this
> > in a opt-in basis they have a client program that you download and
> > it gets hooked into the users browser.
> 
> This is the right way to do it, end user opt in, and browser only.

i'm a little bit worried about the idea of doing this inside BIND, since
DNS is supposed to be coherent, and answers are supposed to be based on
fact rather than value.  but the larger point of this reply is:

> Unlaterally forcing it upon everyone and breaking non www based apps is 
> the wrong way to do it.

if you have well founded views on this topic and you have not yet shared
them with ICANN's SSAC, please do so.  see .

Re: [IP] VeriSign prepares to relaunch "Site Finder" -- calls

[Dan Hollis]

On Tue, 24 Feb 2004, Jason Nealis wrote:
> It's a module plug-in into bind and if you prefer to try and do this in a
> opt-in basis they have a client program that you download and it gets hooked
> into the users browser.

This is the right way to do it, end user opt in, and browser only.

Unlaterally forcing it upon everyone and breaking non www based apps is 
the wrong way to do it.

-Dan

Re: Level 3 statement concerning 2/23 events (nothing to see, move along)

[Niels Bakker]

* [EMAIL PROTECTED] (Alex Rubenstein) [Tue 24 Feb 2004, 18:13 CET]:
> On Tue, 24 Feb 2004, Sean Donelan wrote:
>> http://news.com.com/2100-1038_3-5163931.html?tag=nefd_top
>> A Level 3 spokesman would not confirm or deny that hardware was the source
>> of the problem, nor would he elaborate on the nature of the issue.
> And we, the general Internet public, tends to just accept this and forget
> about it.
> 
> Why do we do this?

I can't speak for others, but in my case it's because I'm not a customer.


-- Niels.

-- 
Today's subliminal thought is: 

Re: T1 Customer CPE Replacement?

[Curtis Maurand]

I had excellent luck with OpenRoute (formerly Proteon) GT90's.  They 
handle dual ethernet or T1/E1.  They need an external CSU/DSU, but they 
get the job done and they're very stable.  They will do NAT and most of 
the other goodies that you can think about.  They also have gt900 firewall 
and they have a model with a hardware accelerator to handle cryptographic 
calculations.  I installed one of the latter into a customer about 4 years 
ago and I've not had any trouble with it, except to upgrade the OS once to 
fix some wierd packet length issues surrounding IPSEC tunnels.  

http://www.openroute.com

Curtis


On Mon, 23 Feb 2004, Brian Bruns wrote:

> 
> On Monday, February 23, 2004 3:37 PM [EST], Claydon, Tom
> <[EMAIL PROTECTED]> wrote:
> 
> > Hello,
> >
> > We're looking for a good replacement for fractional T1 customers with Cisco
> > 1600-  & 1700-series routers as their CPE. They are good routers, but the
> > ongoing support costs are an issue, and we need to replace them ASAP.
> >
> > Someone had mentioned several CPE vendors, such as Adtran and Netopia. Are
> > there any others, and does anyone have any pros/cons of what they're
> > familiar with?
> >
> >
> 
> I'm quite familiar with the Netopia R53xx series T1 routers.  Excellent little
> routers for deplyoing to customers.  Very reliable, and if you are familiar
> with the DSL routers, you'll be right at home.  They have built in
> PPTP/ATMP/IPSec VPN support (both client and server), basic routing features,
> filtering, NAT, one-to-one IP mapping, remote syslog logging, as well as
> everything you'd expect in a T1 router (fractional T1 support, HDLC, PPP,
> FrameRelay, etc).  Theres also a 56k dialup backup module which is handy.
> 
> 

-- 
--
Curtis Maurand
mailto:[EMAIL PROTECTED]
http://www.maurand.com

Re: New Draft Document: De-boganising New Address Blocks

[Petri Helenius]

Daniel Karrenberg wrote:

Correct, but only in the absence of more specific filtering.
the problem this proposal aims to correct is the increasing number of
false positives caused by the apparent *serious* lag in relatively
static bogon filtering. 

 

Do you think this can be fixed after vendors started putting in bogon 
lists into their SME and SOHO products and let loose the consultants 
promoting them as "plug-and-play security for small office"? There is 
probably hundreds of  thousands of these devices out there.

Pete

Re: 168.0.0.0/6

[Andre Chapuis]

Hi Randy,
Actually  you only discovered the emerged part of the iceberg ...

Cheers,
André

*> 24.0.0.0 194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 60.0.0.0/7   194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 62.0.0.0 194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 63.0.0.0 194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 64.0.0.0/6   194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 68.0.0.0/7   194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 70.0.0.0 194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 80.0.0.0/6   194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 84.0.0.0 194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 128.0.0.0/3  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 160.0.0.0/5  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 168.0.0.0/6  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 199.0.0.0/8  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 200.0.0.0/7  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 202.0.0.0/7  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 204.0.0.0/6  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 208.0.0.0/7  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 210.0.0.0/7  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 212.0.0.0/7  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 216.0.0.0/8  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 217.0.0.0/8  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 218.0.0.0/7  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 220.0.0.0/7  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
*> 222.0.0.0/8  194.85.4.249   0 3277 13062 20485 20485 
20485 8437 3303 i
- Original Message - 
From: "Randy Bush" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 24, 2004 4:20 PM
Subject: 168.0.0.0/6



route-views.oregon-ix.net>sh ip bgp 169.223.0.0
BGP routing table entry for 168.0.0.0/6, version 7688303
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  3277 13062 20485 20485 20485 8437 3303
194.85.4.249 from 194.85.4.249 (194.85.4.249)
  Origin IGP, localpref 100, valid, external, best

ripe is being overgenerous to the swiss!

Re: New Draft Document: De-boganising New Address Blocks

[Daniel Karrenberg]

On 24.02 16:32, [EMAIL PROTECTED] wrote:
> 
> That is a misleading title.

I thought it was to the point and rather cute ;-).
> 
> The problem is that ISPs cannot react quickly enough
> to open filters when new ranges are allocated. The proposed
> solution is to provide advance notification. I suppose this
> could allow ISPs to open filters before the new addresses
> are actually in use officially.

This is the status quo, aka best *current* practise.

> However, it will also allow spammers to announce this
> space and get it through bogon filters.

Correct, but only in the absence of more specific filtering.
the problem this proposal aims to correct is the increasing number of
false positives caused by the apparent *serious* lag in relatively
static bogon filtering. 

> The real solution to this problem is to make it 
> possible for ISPs to closely track RIR allocations
> in their filters in a semi-automated way. There may
> still be a few days of delay before a new allocation
> is fully routable but ISPs can compensate for that
> with internal processes. 
> 
> Why can't ISPs subscribe to a feed of all new 
> RIPE allocations in near real-time?

Personally I think this is a great idea and if we hear from a lot of
operators actually willing to take such feeds it may become reality
beyond volunteer efforts like the Team CYMRU one.  However there are a
number of serious issues with something like this, not the least of
which are the liability issues in case this goes wrong very dynamically
and semi-automatedly. 

It is certainly something to progress if there is enough interest.

However I think the current proposal shold go ahead too because the false
positives are a real problem that needs to be addressed quickly.

Daniel

Re: Level 3 statement concerning 2/23 events (nothing to see, move along)

[Alex Rubenstein]

And we, the general Internet public, tends to just accept this and forget
about it.

Why do we do this?



On Tue, 24 Feb 2004, Sean Donelan wrote:

>
>
>
> http://news.com.com/2100-1038_3-5163931.html?tag=nefd_top
>
> A Level 3 spokesman would not confirm or deny that hardware was the source
> of the problem, nor would he elaborate on the nature of the issue.
>
> "We are investigating the cause of the problem, which is fully resolved at
> this time," said Arthur Hodges, the spokesman. He declined to offer
> additional information.
>

-- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben --
--Net Access Corporation, 800-NET-ME-36, http://www.nac.net   --

Re: New Draft Document: De-boganising New Address Blocks

[Timothy Brown]

On Tue, Feb 24, 2004 at 04:32:46PM +, [EMAIL PROTECTED] wrote:
> 
> >The RIPE NCC has prepared a draft document titled "De-Bogonising New
> >Address Blocks":
> 
> That is a misleading title.
> 
> The problem is that ISPs cannot react quickly enough
> to open filters when new ranges are allocated. The proposed
> solution is to provide advance notification. I suppose this
> could allow ISPs to open filters before the new addresses
> are actually in use officially.
> 
> However, it will also allow spammers to announce this
> space and get it through bogon filters.
> 
> The real solution to this problem is to make it 
> possible for ISPs to closely track RIR allocations
> in their filters in a semi-automated way. There may
> still be a few days of delay before a new allocation
> is fully routable but ISPs can compensate for that
> with internal processes. 
> 
> Why can't ISPs subscribe to a feed of all new 
> RIPE allocations in near real-time?

Uh, bogon route server, hello?

http://www.cymru.com/BGP/bogon-rs.html

Tim

Level 3 statement concerning 2/23 events (nothing to see, move along)

[Sean Donelan]

http://news.com.com/2100-1038_3-5163931.html?tag=nefd_top

A Level 3 spokesman would not confirm or deny that hardware was the source
of the problem, nor would he elaborate on the nature of the issue.

"We are investigating the cause of the problem, which is fully resolved at
this time," said Arthur Hodges, the spokesman. He declined to offer
additional information.

Re: New Draft Document: De-boganising New Address Blocks

[Michael . Dillon]

>The RIPE NCC has prepared a draft document titled "De-Bogonising New
>Address Blocks":

That is a misleading title.

The problem is that ISPs cannot react quickly enough
to open filters when new ranges are allocated. The proposed
solution is to provide advance notification. I suppose this
could allow ISPs to open filters before the new addresses
are actually in use officially.

However, it will also allow spammers to announce this
space and get it through bogon filters.

The real solution to this problem is to make it 
possible for ISPs to closely track RIR allocations
in their filters in a semi-automated way. There may
still be a few days of delay before a new allocation
is fully routable but ISPs can compensate for that
with internal processes. 

Why can't ISPs subscribe to a feed of all new 
RIPE allocations in near real-time?

--Michael Dillon

Re: [IP] VeriSign prepares to relaunch "Site Finder" -- calls

[Michael . Dillon]

>Okay, they are lying here.

That's a bit strong. If you had looked at the Paxfire website
it doesn't take long to realize they are completely clueless.
They are an Internet traffic broker but the traffic that they
deal in is web page views which illustrates a certain level
of technical cluelessness. But then when you read their "about"
pages and see the long lists of trivial accomplishments of the
principals in the company, you have to wonder about their
business acumen as well.

Let's face it, these guys just don't really understand what
they are doing.

--Michael Dillon

Proposal: De-boganising New Address Blocks

[Daniel Karrenberg]

[Apologies for duplicate messages]

This is of interet to all operators worldwide.  Operators
who do not participate in RIPE are invited to send comments
and suggestions directly to the author.

"De-Bogonising New Address Blocks"



Abstract

"This document describes an improvement in the notification process
about new blocks of address space being distributed by the RIRs. It is
a draft at this stage and your comments are solicited. However to gain
experience before finalising the procedures, the RIPE NCC will shortly
start announcing the routes from 84/8 described in the document under
"84/8 Pilot"."  

Re: [IP] VeriSign prepares to relaunch "Site Finder" -- calls

[ken emery]

On Tue, 24 Feb 2004, Jason Nealis wrote:

> FWIW,  We had PAXFIRE in over here last week and heard their dog and pony
> on the product, basically they make money by using your customer base and
> diverting them to a search page that they developed with their "partners".  Of
> course they only divert them on failed www lookups.

Okay, they are lying here.  There is no way for them to tell if something
is a "web lookup" or some other type of lookup at this point.  Unless
of course they only divert www.*, and even then other types of services
may be provided by a host with a name of www.*.  So they really can't
make this work without breaking sometihng.

bye,
ken emery
> It's a module plug-in into bind and if you prefer to try and do this in a
> opt-in basis they have a client program that you download and it gets hooked
> into the users browser.
>
> They claim that the embedded MSN search page that you get diverted to by IE
> is making MSN millions and millions of dollars and they want the ISP's to
> get some of that revenue share.
>
>
> Jason Nealis
> RCN INTERNET
>
>
>
> On Mon, Feb 23, 2004 at 04:54:51PM -0500, Stephen J. Wilcox stated
> >
> > > > I am curious what the operational impact would be to network operators
> > > > if, instead of Verisign using SiteFinder over all com and net, Verisign
> > > > or their technology partner for SiteFinder began coercing a large number
> > > > of independent ISPs and network operators to install their form of DNS
> > > > redirection at the ISP-level, until all or most of the end-users out
> > > > there were getting redirected.
> > >
> > > It would be no worse than NEW.NET or any other form of DNS pollution/piracy
> > > (like the alternate root whackos), as long as it was clearly labelled.  As
> >
> > Sorry my threading is screwed, something to do with the headers so I missed half
> > the replies.
> >
> > Anyway I just sent an email, I dont think this is the same as the new.net thing,
> > in that case you have an unstable situation of competing roots arising which as
> > it grows or collides the operator community is left to pick up the pieces and
> > complaints.
> >
> > With a local redirection you get to choose that you want it, you dont impose it
> > on other parts of the Internet and given enough clue level your customers can
> > run their own DNS if they object.
> >
> > So with that in mind this is no worse that http caching/smtp redirection or
> > other local forms of subversion..
> >
> > Steve
> >
> > > an occasional operator of infrastructure, I wouldn't like the complaint load
> > > I'd see if the customers of such ISP's thought that *I* was inserting the
> > > garbage they were seeing.  So I guess my hope is, it'll be "opt-in" with an
> > > explicitly held permission for every affected IP address (perhaps using some
> > > kind of service discount or enhancement as the carrot.)
> > >
>

Re: 168.0.0.0/6

[Valdis . Kletnieks]

On Tue, 24 Feb 2004 23:20:30 +0800, Randy Bush <[EMAIL PROTECTED]>  said:
> route-views.oregon-ix.net>sh ip bgp 169.223.0.0
> BGP routing table entry for 168.0.0.0/6, version 7688303

OK, any bets on how much improperly ingress/egress filtered traffic
to 169.254/16 this is going to attract? ;)


pgp0.pgp
Description: PGP signature

Re: [IP] VeriSign prepares to relaunch "Site Finder" -- calls

[Valdis . Kletnieks]

On Tue, 24 Feb 2004 09:01:05 EST, Jason Nealis said:

> They claim that the embedded MSN search page that you get diverted to by IE
> is making MSN millions and millions of dollars and they want the ISP's to 
> get some of that revenue share.

Of course, if all the ISPs do it, that will dry up MSN's millions and millions of
dollars.  A quick analogy here:

Microsoft is to revenue stream as mother bear is to cubs...

To misquote Randy, I encourage my competitors to step between either pair. ;)


pgp0.pgp
Description: PGP signature

Re: 168.0.0.0/6

[Daniel Karrenberg]

On 24.02 23:20, Randy Bush wrote:
> 
> BGP routing table entry for 168.0.0.0/6, version 7688303
> ...
>   3277 13062 20485 20485 20485 8437 3303
> 194.85.4.249 from 194.85.4.249 (194.85.4.249)
>   Origin IGP, localpref 100, valid, external, best
> 
> ripe is being overgenerous to the swiss!

Not so. They are pretending to be over-endowed to some peers
only.

Isn't that something to notify AS3303 aka SWISSCOM about rather than NANOG?
Especially since it does not look like it is spreading very widely.

Daniel

168.0.0.0/6

[Randy Bush]

route-views.oregon-ix.net>sh ip bgp 169.223.0.0
BGP routing table entry for 168.0.0.0/6, version 7688303
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  3277 13062 20485 20485 20485 8437 3303
194.85.4.249 from 194.85.4.249 (194.85.4.249)
  Origin IGP, localpref 100, valid, external, best

ripe is being overgenerous to the swiss!

Re: [IP] VeriSign prepares to relaunch "Site Finder" -- calls

[Jason Nealis]

FWIW,  We had PAXFIRE in over here last week and heard their dog and pony
on the product, basically they make money by using your customer base and
diverting them to a search page that they developed with their "partners".  Of
course they only divert them on failed www lookups. 

It's a module plug-in into bind and if you prefer to try and do this in a
opt-in basis they have a client program that you download and it gets hooked
into the users browser. 

They claim that the embedded MSN search page that you get diverted to by IE
is making MSN millions and millions of dollars and they want the ISP's to 
get some of that revenue share.


Jason Nealis
RCN INTERNET 



On Mon, Feb 23, 2004 at 04:54:51PM -0500, Stephen J. Wilcox stated
> 
> > > I am curious what the operational impact would be to network operators
> > > if, instead of Verisign using SiteFinder over all com and net, Verisign
> > > or their technology partner for SiteFinder began coercing a large number
> > > of independent ISPs and network operators to install their form of DNS
> > > redirection at the ISP-level, until all or most of the end-users out
> > > there were getting redirected.
> > 
> > It would be no worse than NEW.NET or any other form of DNS pollution/piracy
> > (like the alternate root whackos), as long as it was clearly labelled.  As
> 
> Sorry my threading is screwed, something to do with the headers so I missed half 
> the replies.
> 
> Anyway I just sent an email, I dont think this is the same as the new.net thing, 
> in that case you have an unstable situation of competing roots arising which as 
> it grows or collides the operator community is left to pick up the pieces and 
> complaints.
> 
> With a local redirection you get to choose that you want it, you dont impose it 
> on other parts of the Internet and given enough clue level your customers can 
> run their own DNS if they object.
> 
> So with that in mind this is no worse that http caching/smtp redirection or 
> other local forms of subversion..
> 
> Steve
> 
> > an occasional operator of infrastructure, I wouldn't like the complaint load
> > I'd see if the customers of such ISP's thought that *I* was inserting the
> > garbage they were seeing.  So I guess my hope is, it'll be "opt-in" with an
> > explicitly held permission for every affected IP address (perhaps using some
> > kind of service discount or enhancement as the carrot.)
> > 

RE: possible L3 issues

[Erik Haagsman]

C&W seems to be doing fine towards Microsoft, are you still experiencing
problems...?

Cheers,

Erik

On Tue, 2004-02-24 at 00:23, Arjan Lugtenberg wrote:
> Here at planet (AS8737) we also having problems reaching
> msn/hotmail/messenger.
> 
> Seems that C&W are also having problems reaching microsoft??
> 
> regards,
> 
> Arjan
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> [EMAIL PROTECTED]
> Sent: maandag 23 februari 2004 23:53
> To: [EMAIL PROTECTED]
> Subject: possible L3 issues
> 
> 
> 
> anyone else seeing high latency via L3 , especially the west coast ?
> - Keith
-- 
Erik Haagsman
Network Architect
We Dare BV
tel: +31(0)10-7507008
fax: +31(0)10-7507005
http://www.we-dare.nl

FCC rulemaking for mandatory outage reporting

[Sean Donelan]

Communication providers of all sizes, which may include Internet
service providers, may want to review

http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-04-30A1.pdf

This is the FCC's notice of proposed rulemaking concerning
communication provider outage reporting.  The definitions are
very expansive.