[more accurate subject line]
On Mar 14, 2008, at 1:33 PM, Felix Bako wrote:
Hello,
There is a routing loop while accesing my network 194.9.82.0/24 from
some networks on the Internet.
| This is a test done from lg.above.net looking glass.
1 ten-gige-2-2.mpr2.ams2.nl.above.net
A bit more analysis of this at the moment, and a few recommendations
and related pointers is available here:
http://tinyurl.com/2nqg2a
-danny
On Mar 15, 2008, at 4:49 PM, Florian Weimer wrote:
There's also somewhat odd data in RADB (look at the changed: line):
route: 194.9.64.0/19
descr: SES-Newskies Customer Prefix
origin:AS16422
remarks: SES-Newskies Customer Prefix
notify:[EMAIL PROTECTED]
On Mar 7, 2008, at 12:55 PM, Justin Shore wrote:
This question will probably get lost in the Friday afternoon lull
but we'll give it a try anyway.
What kind of customer-facing filtering do you do (ingress and
egress)? This of course is dependent on the type of customer, so
lets
On Feb 29, 2008, at 7:46 AM, David Ulevitch wrote:
The report states:
Sunday, 24 February 2008, 20:07 (UTC): AS36561 (YouTube) starts
announcing 208.65.153.0/24. With two identical prefixes in the
routing system, BGP policy rules, such as preferring the shortest
AS path, determine
On Feb 29, 2008, at 11:49 AM, David Ulevitch wrote:
Of course... In fact, wouldn't it even providers benefit from having
some logic that says don't ever accept a more specific of a
customer-announced prefix?
Sure, that'd suck less, I guess, although then you have to punch
holes for
On Feb 25, 2008, at 6:08 AM, Pekka Savola wrote:
In a lot of this dialogue, many say, you should prefix filter.
However, I'm not seeing how an ISP could easily adopt such filtering.
So, this is no excuse for not doing prefix filtering if you only do
business in the RIPE region, but
On Feb 25, 2008, at 12:51 PM, Alex Pilosov wrote:
** Nobody brought up the important point - the BGP announcement
filtering
are only as secure as the weakest link. No [few?] peers or transits
are
filtering large ISPs (ones announcing few hundred routes and up).
There
are a great many of
On Feb 25, 2008, at 1:22 PM, Alex Pilosov wrote:
Well, in this case, they *aren't* filtering! (unless I am
misunderstanding
what you are saying, due to repeated use of 'their').
What I'm saying is that best case today ISPs police routes
advertised by their customers, yet they accept
I'd hear to see who does it, and get them to present the operational
lessons at the next nanog!
On second thought, I guess one thing has changed considerably
since 15 years ago. Rather than ~5000 monkeys with keyboard
access to manipulate global routing tables, there are likely well
North of
On Feb 14, 2008, at 11:28 AM, Ben Butler wrote:
=191 and the session stays down.
Which is proper bizarre!
Is it necessary to configure this on both side for the session to
re-establish. Is this a Cisco bug?
You're missing the fundamentals of what protection this
mechanism is meat to
On Feb 14, 2008, at 11:28 AM, Ben Butler wrote:
I have validated via trace in both directions as being 1 hop.
I have read another article that implies the default behaviour at the
other end will to be send TTL 1 not 255 and consequently I need to
configure both ends to get the session to
On Feb 5, 2008, at 11:56 PM, Adhy wrote:
1. If the update is propagated from RR1 to RR2 then RR3, will the
ORIGINATOR_ID on the update mesg still RR1 ?
Yes, the originator ID is preserved, while the cluster
list would be additive.
2. and will the CLUSTER_LIST being used ? the cisco specs
On Feb 2, 2008, at 1:16 PM, Ben Butler wrote:
So, given we all now understand each other - why is no one doing the
above?
Some folks are doing this, just not via some third-party
route servers. For example, either via customer peering
sessions, or other BGP interconnections between peers.
On Dec 17, 2007, at 10:37 PM, Steven M. Bellovin wrote:
On Mon, 17 Dec 2007 15:29:21 -0800
Christopher Morrow [EMAIL PROTECTED] wrote:
how does it improve data security exactly?
Back in 1994, it was expected to be true because v6 would mandate
IPsec, and v6 would be deployed long before
On May 24, 2007, at 4:58 PM, Bill Woodcock wrote:
First of it's kind that it targeted a country.
No, at the very least, Moonlight Maze and Titan Rain came before.
But by
today's standards, Moonlight Maze would have been trivially small. I
don't have any numbers for Titan Rain.
Folks,
It's time for the Infrastructure Security Survey again, figured
I'd include all of nanog@ in the query for respondents this
time around (per request[s]).
If you're willing to complete the survey please go here to
receive a token (which will be mailed to you with a URL
for response
Folks,
Can you please try to slot the ISP security BOF into the
first day (Monday) of the agenda? Something has come
up and I have to leave late Monday night.
Thanks for your consideration!
-danny
Folks,
Kevin Lanning (ATT) and I will be moderating the ISP
Security BOF at NANOG 40 in Bellevue. As usual, if
there are security-related topics you'd like to hear about,
would rather not hear about, or would like like to present,
please drop us a line ASAP.
Thanks!
-danny kevin
On Apr 30, 2007, at 9:15 AM, Patrick W. Gilmore wrote:
On Apr 30, 2007, at 11:11 AM, Randy Bush wrote:
Collector: CIXP
Prefix: 128.0.0.0/2
Last update time: 2007-04-27 07:36:30Z
Peer: 192.65.185.140
Origin: 29222
My question is, why am I not seeing more issues because of the
On Feb 12, 2007, at 9:10 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
They are used for BUSINESS traffic. Also, since these controls make
routers work harder, there is no point in using them where there
are no
traffic problems.
I concur, it only matters when it matters (i.e., when
On Feb 16, 2007, at 10:12 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
You misunderstand. The problem of securing machines *IS* solved. It is
possible. It is regularly done with servers connected to the Internet.
There is no *COMPUTING* problem or technical problem.
The problem of the
On Feb 16, 2007, at 11:41 AM, J. Oquendo wrote:
After all these years, I'm still surprised a consortium of ISP's
haven't figured out a way to do something a-la Packet Fence for
their clients where - whenever an infected machine is detected
after logging in, that machine is thrown into
On Feb 17, 2007, at 6:42 PM, Sean Donelan wrote:
Is there a significant difference between the many ISPs implementing
walled gardens and other ISPs as far as infection rates?
One might presuppose infection rates are exactly the same, at
least until that ISPs user base upgrades, patches,
On Jan 28, 2007, at 9:06 AM, Joe Provo wrote:
Select the latter. Modifying networks statements for move/add/changes
invites trouble. Carefully constructed policies to redistribute
your connected or static routes into iBGP and tagged appropriately
are a win. At the very least, you can limit
Folks,
For some crazy reason I've agreed again to chair the ISP Security BOF
at NANOG 39 in Toronto. If you've got items you'd like to discuss, like
to see discussed, or would prefer not be presented, please let me
know ASAP.
The two agenda items for the moment are meant to be, in
On Aug 17, 2006, at 10:57 PM, Joe Maimon wrote:
If A tries to peer with B, and B sends a BGP capability 64 to A, if
A does not support that capability what would proper and/or
reasonable behavior for A be?
Speaker A MAY send a NOTIFICATION message with Open
Message Error/Error Subcode
On Aug 9, 2006, at 4:04 AM, Arjan Hulsebos wrote:
Maybe so, but that argument doesn't buy me more helpdesk folks. The
same holds true for the bandwidth argument, especially now that
bandwidth is dirt cheap.
On the other hand, it shouldn't be too difficult to come up with a
walled garden
On Aug 13, 2006, at 8:35 AM, Laurence F. Sheldon, Jr. wrote:
Danny McPherson wrote:
As importantly, broadband SPs are trying to move to triple (quad)
play services, how tolerant do you think your average subscriber is
to losing cable television services because their kid downloaded some
On Aug 13, 2006, at 1:02 PM, Paul Vixie wrote:
which is, please move these threads to a non-SP mailing list.
R [ 41: Danny McPherson ] Re: mitigating botnet CCs has
become useless
R [ 22: Laurence F. Sheldon]
R45: Danny McPherson
R [ 62: Laurence F
On Aug 4, 2006, at 12:00 AM, [EMAIL PROTECTED] wrote:
useless...
perhaps. i'm partly of the mind that botnets, p2p networks, manets,
and other self-organizing systems are the wave of the future (or
even the
present) and the technologies, per se, are not inherently evil or
even
On Aug 5, 2006, at 3:17 PM, Sean Donelan wrote:
Hopefully, by their nature SPs will always be a bit reactive. Unless
I want them to, I don't want SPs messing with my traffic. Its my
right
to connect anything I want, send anything I want, do anything I
want with
my Internet connection.
On Jul 30, 2006, at 10:37 AM, Gadi Evron wrote:
The few hundred *new* IRC-based CCs a month (and change), have been
around and static (somewhat) for a while now. At a steady rate of
change which
maintains the status quo, plus a bit of new blood.
In this post I ask the community about
On Aug 3, 2006, at 4:22 PM, Scott Weeks wrote:
But shutting them down, that's like the police arresting
all the informants. It doesn't stop the crime, it just
eradicates all your easy leads.
What're folk's thoughts on that?
I'm not sure I'd liken shutting CC infrastructure down to
On Jun 15, 2006, at 7:06 AM, Kristal, Jeremiah wrote:
I don't think it was Extreme that filed it, or at least they didn't
write it. It was the good folks at Qwest engineering who came up with
the idea, which was implemented (for some low value of implemented) by
Extreme. The authors had
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
FYI
- -danny
- --
Security BOF - NANOG 37
Moderators: Danny Roland
- ---
Probing Open Recursive Name Servers
John Kristoff
Analyzing the results of remote open recursive name server
probes. We look at
On Jan 3, 2006, at 1:03 AM, Daniel Roesen wrote:
So the spec is fuzzy about how no MED vs. MED=0 should be
treated, but
vendors seem to largely agree to no MED == MED 0. I know of no
deviation, except the old ERX bug which got fixed (ERX treated no
MED
as best, even better than MED=0 -
On Aug 23, 2005, at 4:36 AM, Abhishek Verma wrote:
I was looking at route-views.routeviews.org for the BGP routes and i
dont see any AS-Sets whatsoever. Are BGP routes with AS-SETs not
generally leaked into the wild?
Is this the case?
Not quite, see below..
I am under the impression
On Jun 2, 2004, at 9:25 AM, Jon R. Kibler wrote:
The sad fact is that simple ingress and egress filtering would
eliminate the majority of bogus traffic on the Internet -- including
(D)DoS attacks. If all ISPs would simply drop all outbound packets
whose source address is not a valid IP for the
On Jun 2, 2004, at 10:56 AM, Richard A Steenbergen wrote:
What people may being seeing is that poorly randomized source attacks
are
being automatically filtered by uRPF loose or other means before they
ever
reach the target. I keep track of my network border filter counters,
and
believe me
On Jun 2, 2004, at 12:36 PM, Richard A Steenbergen wrote:
If it walks like a duck, and it sounds like a duck, it is probably a
duck.
RFC1918 sourced space, most likely from misconfigured NATs and such,
account for only a very small amount of the bogon-source packets which
go
splat.
But worms,
On May 20, 2004, at 8:10 PM, Tim Wilde wrote:
Call your local branch of the US Secret Service, if you're in the
states,
and ask for their electronic crimes division. If you're not in the
states, contact your comprable local authority. They can work with
you to
coordinate with other
On May 12, 2004, at 2:41 PM, Mark Johnson wrote:
What if sessions were attacked without MD5 in place. We would just see
session resets. As these happen anyway frequently at peering points is
there
any straightforward way to determine if the vulnerability caused the
reset?
Depends on why it
Folks,
Merike I are chairing the NSP-SEC BOF at NANOG
in SF in a few weeks. Anyone with topics you'd
like to see discussed, or topics you'd like to discuss,
please let us know ASAP.
Thanks!
-danny merike
On Mar 3, 2004, at 11:24 AM, Stephen Perciballi wrote:
To the best of my knowledge, MCI/UUNET ~was~ the first to implement
this. I've
been using it for well over a year now.
Indeed. One could even get fancy and set of different community
sets to allow customers to drop traffic only on peering
On Feb 14, 2004, at 5:23 AM, Sven Huster wrote:
Dumb question:
If I apply a equal weight to all our transit/peers, will
that affect route announcements to iBGP or eBGP peers anyhow?
Yes, given that it's a local parameter (i.e., not BGP,
per se, though it does impact what's installed in the BGP
Not sure how many places you intend to post this or related
messages, but if you've got a problem vote with your money.
Whining to NANOG and a slew of other mailing lists and still
giving money to Qwest seems silly to me...
Likewise, the Qwest folks likely aren't quite as clueless as
you've
On Thursday, August 28, 2003, at 09:51 PM, John Brown wrote:
Given general operational nature, I posted to NANOG, so that:
1. money can talk, others will see one view of this provider
Don't talk with other peoples money, talk with your own. If
you plan to post to NANOG, it'd be a wise
On Monday, August 25, 2003, at 07:32 PM, Jared Mauch wrote:
You of course are correct with the trusting of the data, but
we are in a somewhat of a chicken and egg situation. If people don't
trust the IRR, they don't filter on it, and then the data is
allowed to get out of date. But
Again...
If folks were to implement explicit prefix filtering
*everywhere* it wouldn't be necessary to filter only
bogons and other miscellany explicitly. Something of
this sort would only lower the lazy bar (is it
possible?) for the clueless and/or lazy (those which
Rob's list currently
On Thursday, August 14, 2003, at 11:34 PM, Danny McPherson wrote:
Current_Total: 120,475
Max_Total: 123,814
Average_Total: 122,029
I failed to consider that today's average has been skewed by the outage
data being factored for the last 10 hours or so towards the Daily
Average.
I
*** ns2.nv.cox.net can't find www.windowsupdate.com: Non-existent
host/domain
Some news outlets are reporting this is actually Microsoft's plan,
Sure it was, and it's probably the best thing MS could have done (for
themselves AND the larger Internet) given the circumstances.
After all, infected
Here's some of what I've seen at this point:
[table format might be munged by some fonts]
PrefixDaily Daily
Length *Current Max Average
/24 65,900 68,497 67,259
/239,904 10,157 10,027
/229,053 9,211 9,110
On 6/6/03 10:05 AM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
I was wondering what are the choices made by Service Providers on the
loopback addressing.
The context is an IP/MPLS Backbone providing both Internet and BGP-VPN
services.
If the BGP Identifier, which is used for connection
Dampening is done on the eBGP router where the route enters the AS, and,
unless I'm mistaken, per route/path and not per prefix. So the flapping
that ISP A sees from ISP B is a completely seperate thing from the
flapping that ISP A sees from its customer's customer as far as the
dampening
Hrmm... Then care to take a stab at explaining the findings
in the document that Randy referenced earlier?
-danny
[EMAIL PROTECTED] (Danny McPherson) writes:
Dampening is done on the eBGP router where the route enters the AS, and,
unless I'm mistaken, per route/path and not per
Thus the application effect being talked about.
Sure, I understand that. I was making a different assumption...
That the sources of traffic were likely from downstream ASs, not
ISP A, or even B or C, and as such, the multiplication could
happen per prefix.
However, without knowing the
Yes, at iMCI (we) had our own registry, MCI-RR, but we only used it
(in addition to data from the other IRRs) to generate customer prefix
filters, not peers.
Cable Wireless still uses the RR, now know as CW-RR.
-danny
As I remember and I could be wrong, its been a few years now, when I
Who actually uses RADB to build filters other than Verio? While my
experience with other providers is limited Verio is the only one (of the
ones we have used) who used RADB entries for BGP peers.
Level3 do atleast. Most European providers do.
For customers, though not inter-provider.
as you say for customers only. Inter-provider we have basic bogon checking plus
maximum prefix. Its too unwieldy to build when you have peers exchanging
thousands of routes... theres a belief that the peer should be behaving
responsibly tho and this is a condition of most bilateral
You forgot the other one - expense. AFAIK all of the registries have fees
or require you to be a customer. If there is no operational value
First problem, you see no operational value.
for me why would I want to spend the money?
Money changing hands no longer makes the IRR a
RFC 3439 talks of coupling amplification and it's relation
to the Internet.
-danny
Sigh, there are differences between tightly coupled networks, such as
the electric power grid and loosely couple networks like the Internet.
But there are also some similarities, such as electric grids
If there is a magic solution, I would love to hear about it.
I strongly doubt any of the large providers perform dataplane source
address validation from peers. Heck, I doubt any perform explicit
route filtering on routes learned from peers at the control plane.
Ideally, one would first
install this on all your internal, upstream, downstream
interfaces (cisco router) [cef required]:
ip verify unicast source reachable-via any
This will drop all packets on the interface that do not
have a way to return them in your routing table.
Of course, this is the IP
reachable-via any means you're only going to drop the packet if you
don't have *ANY* route back to them.
What's a route? An IP RIB instance? A BGP Loc-RIB instance? An IGP LSDB
IP prefix entry? A BGP Adj-RIB-In instance?
I think you mean if you don't have *ANY* **FIB** entry for the
Yes, but if i continue in my ideal situation of people
(mostly) filter their bgp customers, so they won't announce the
1918 space, or similar. even the large peers filter out each other
so they don't pick up 1918 announcements. Plus people use Robs
Secure IOS Template to drop
I know of several incidents where invalid routing announcements
were maliciously employed in order to cause reachability problems
to the destination prefix network.
It still bugs me that router vendors don't provide the capability
to support inter-provider filters (read: 10s or 100s of
We have a similar situation (RR + always-compare-MED off), and the BGP table
version keeps changing at 1K/min (http://performance.cn.net:2003/). I
suspect some
route meet the criteria of IDR-oscillation draft. But in real world, it's
very hard to pick
up the pattern depicted in the
68 matches
Mail list logo
