Re: Word file
On Jan 30, 2006, at 10:25 PM, davidu wrote: WARNING: WinProxy has detected a virus in file attached to this e-mail message! I'm a mac/unix guy -- I promise. :-) That email did not come from me, but this one did. -david
Word file
Please see the file. ** ** WARNING: WinProxy has detected a virus in file attached to this e-mail message! The attachment has been automatically removed to protect your network. WinProxy Administrator: [EMAIL PROTECTED] 01/31/06 11:56:02 WinProxy (Version 6.0 R1c (6.0.21.0)) - http://www.WinProxy.com/ Antivirus Vendor: Panda Software Scan Engine Version: 4.7.0.201_4.1.6.408 Pattern File Version: 3.109873 (Timestamp: 2006/01/30 17:00:31) Machine name: SYS1 Machine IP address: 202.141.22.146 Server: 198.108.1.26 Client: 192.168.0.11 Protocol: SMTP Virus: "W32/Tearec.A.worm!CMÈ" found! Attachment: New_Document_file.pif ** **
Comcast contact
Looking for a Comcast contact. Please reply off-list. Jeff.
Re: CME-24 (BlackWorm) Users' FAQ
The FAQ can be found at: http://isc.sans.org/blackworm http://blogs.securiteam.org That's http://blogs.securiteam.com My apologies, and thanks to all those who notified me. Gadi.
CME-24 (BlackWorm) Users' FAQ
This FAQ was authored by members of the TISF BlackWorm task force (specifically the MWP / DA groups and the SANS ISC handlers). The purpose is both to provide with a resource for concerned users and network administrators, as well as to be a level-headed myth-free source on the subject. There seems to be excessive media hype as well as some "end-of-the-world" type predictions. The end of the world is not coming and most of us will still be here after February 3rd, but this is a serious issue for those who *are* infected and we didn't manage to get to. The FAQ can be found at: http://isc.sans.org/blackworm http://blogs.securiteam.org -- "300,000 infected users worldwide is not a terribly large amount when compared to previous worms like Sober or Mydoom. However, with this worm it isn't the quantity of infected users, it is the destructive payload which is most concerning." -- Joe Stewart, LURHQ (http://www.lurhq.com/blackworm-stats.html) Gadi.
Re: MPLS vs PTP
On Mon, 30 Jan 2006, Andrew Staples wrote: As we roll out a new network, on one of our links it is remarkably cheaper to run a T1 ptp vs. MPLS (running 66% data, 33% voice). Based on comments received from this list (much thanks, you know who you are) MPLS satisfaction seems to be determined by backbone noc competence, not the technology itself. So back to priceif I consider layer1 issues to be equal in either scenario, and aggregation/meshing/hardware is not a real concern, it seems to me that a correctly configured, directly connected pipe would work as well as mpls, with the benefit of local control of my routers and owning any incompetence. Also, the PTP T1 has fewer hops (probably lower latency), fewer points of failure, fewer ways to break, less complexity, etc. I can't think of any reason you'd want to go with an MPLS(VPN) solution over PTP solution if startup and MRC were equal. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
MPLS vs PTP
As we roll out a new network, on one of our links it is remarkably cheaper to run a T1 ptp vs. MPLS (running 66% data, 33% voice). Based on comments received from this list (much thanks, you know who you are) MPLS satisfaction seems to be determined by backbone noc competence, not the technology itself. So back to priceif I consider layer1 issues to be equal in either scenario, and aggregation/meshing/hardware is not a real concern, it seems to me that a correctly configured, directly connected pipe would work as well as mpls, with the benefit of local control of my routers and owning any incompetence. If anyone has enlightening experiences of ptp vs. mpls, I'd appreciate hearing about them. Thanks, Andrew
Re: So -- what did happen to Panix?
sandy, On Mon, Jan 30, 2006 at 08:29:45AM -0500, [EMAIL PROTECTED] wrote: > >the scheme that josh karlin has been advocating in pretty good bgp > >involved only supressing a doubtful announcement when you have a > >better, more trusted announcement. > > Not a doubtful announcement, a novel announcement. Not a better > announcement, a more usual announcement. The trust part, like beauty, > is in the eye of the beholder. i just don't think you're following along. i think we're talking about different things. read josh, stephanie forrest and jennifer rexford's paper: http://www.cs.unm.edu/~treport/tr/05-10/pgbgp.pdf > Don't get me wrong - I think basing decision on some "trusted" > summary of historical behavior is going to be important, unless and > until we get some approach that gives a more deterministic answer. > But I do believe that we need to consider carefully how this will > play with dynamic, particularly unplanned, changes in who is > announcing what. josh's scheme only comes into play when there are two, competing origination patterns. in this case the question is just which one to believe. agreed that we should be careful with anything that reduces the ability of people to change routing dynamically. but let's remember: that ability is already constrained by the fact that responsible providers use prefix filters and require some kind of out-of-band (IRR, letter, email) validation of prefix ownership. routing a new prefix with a new origination pattern is not especially dynamic now, so let's not worry about throwing out a baby that's not even in the bath. t. -- _ todd underwood chief of operations & security renesys - internet intelligence [EMAIL PROTECTED] www.renesys.com
Re: So -- what did happen to Panix?
>the scheme that josh karlin has been advocating in pretty good bgp >involved only supressing a doubtful announcement when you have a >better, more trusted announcement. Not a doubtful announcement, a novel announcement. Not a better announcement, a more usual announcement. The trust part, like beauty, is in the eye of the beholder. Don't get me wrong - I think basing decision on some "trusted" summary of historical behavior is going to be important, unless and until we get some approach that gives a more deterministic answer. But I do believe that we need to consider carefully how this will play with dynamic, particularly unplanned, changes in who is announcing what. If there turn out to be cases where dynamic, particularly unplanned, changes get rejected by this technique in favor of stale data, then there should be consideration given to how to amend the scheme to prevent that or suggest operational practices to get around it. --Sandy
Re: So -- what did happen to Panix?
> > Wouldn't a well-operated network of IRRs used by 95% of > > network operators be able to meet all three of your > > requirements? > > Maybe I missed something, but didn't Verio say the prefix was in > their internal registry, and that's why it was accepted. > > IOW: It didn't solve this problem. So I guess we're discussing the > other 5%? You missed the words "well-operated". Today there is no well-operated network of IRRs so there is bad data in the databases. In addition, there is the question of how to use the IRR data. Should you build filters from it? Should you use it to validate your own internal database with human beings chasing up the differences and fixing whichever database is wrong? --Michael Dillon
Re: So -- what did happen to Panix?
On Mon, Jan 30, 2006 at 09:48:13AM +, [EMAIL PROTECTED] wrote:
>
> > > Wouldn't a well-operated network of IRRs used by 95% of
> > > network operators be able to meet all three of your
> > > requirements?
> >
> > We have such a database (used by Verio and others), but the Panix
> incident
> > happened anyway due to bit rot. We've got to find a way to fix the
> layer 8
> > problems before we can make improvements at layer 3.
>
> If an IRR suffers from bit-rot, then I don't consider
> it to be "well-operated" and therefore it cannot be
> considered to be part of a well-operated network of
> IRRs.
>
> The point is that the tools exist. The failing is in
> how those tools are managed. In other words this is
> an operational problem on both the scale of a single
> IRR and on the scale of the IRR system. Is this
> what you mean by a "layer 8" problem?
Take it up with the people putting data into the system, not the IRR
operators. Anyone who is behind an IRR-based provider (like Verio) has
motivation to put data into the system ("hey look I do this and now
routing works"), but there is no motivation to take stale data OUT of the
system.
I can't even begin to count the number of networks I know who
theoretically "use" IRR who don't even know HOW to remove data, let alone
make any active attempt to do so when a customer leaves or a route is
returned. Combine this with the idiots who run around proxy registering
routes for other people based on everything they see in the table (gee
theres a good idea, define filters for what is allowed in the table based
on what we see people trying to put into the table, brilliant!) and you
quickly see how IRR data becomes stale and eventually worthless.
I'll save the rest of my rant for the presentation on the subject in
Dallas. :)
--
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: So -- what did happen to Panix?
> >Perhaps people should stop trying to have these > >operational discussions in the IETF and take the > >discussions to NANOG where network operators gather. > > We have tried, of course; see, for example, NANOG 28 (Salt Lake City). > There was no more consensus at NANOG than in the IETF... One attempt almost 3 years ago, doesn't sound very serious to me. And if the discussion is only concerned with seeking consensus on implementing a new flavor of BGP protocol then it isn't much of a discussion. In fact, there was a consensus at Salt Lake City that the issues of routing security could be adequately dealt with by existing tools and protocols. Not all problems require new protocols to solve them. --Michael Dillon
Re: So -- what did happen to Panix?
> > Wouldn't a well-operated network of IRRs used by 95% of > > network operators be able to meet all three of your > > requirements? > > We have such a database (used by Verio and others), but the Panix incident > happened anyway due to bit rot. We've got to find a way to fix the layer 8 > problems before we can make improvements at layer 3. If an IRR suffers from bit-rot, then I don't consider it to be "well-operated" and therefore it cannot be considered to be part of a well-operated network of IRRs. The point is that the tools exist. The failing is in how those tools are managed. In other words this is an operational problem on both the scale of a single IRR and on the scale of the IRR system. Is this what you mean by a "layer 8" problem? --Michael Dillon
