- Test - lists.nanog.org

Emerging Threats SNORT [Was: Re: Exploit for DNS Cache Poisoning - REL EASED]
by Paul Ferguson 24 Jul '08

24 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Paul Ferguson" <fergdawg(a)netzero.net> wrote: >-- Jared Mauch <jared(a)puck.nether.net> wrote: > >>If your nameservers have not been upgraded or you did >>not enable the proper flags, eg: dnssec-enable and/or dnssec-validation >>as applicable, I hope you will take another look. > >Let's hope some very large service providers get their act together >real soon now. > >http://www.hackerfactor.com/blog/index.php?/archives/204-Poor-DNS.html Sorry to respond to my own post, but I thought this might be of interest to the list. Matt Jonkman, over at Emerging Threats (previously known as Bleeding Threats) has a 'prototype' SNORT sig for these attacks -- try it out and provide feedback, if you are so inclined. http://www.emergingthreats.net/content/view/87/9/ - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIiASRq1pz9mNUZTMRAmjnAKDYOmtUbm+er2OBUfjxcGdNWggOlgCfYbkn V8pibFdRpbHul2PrZu0oBg0= =QPWh -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: Exploit for DNS Cache Poisoning - RELEASED
by Paul Ferguson 24 Jul '08

24 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Joe Abley <jabley(a)ca.afilias.info> wrote: >It's a good job users are not conditioned to click "OK" when >told "the certificate for this site is invalid". I appreciate your sense of humor. ;-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIh9n2q1pz9mNUZTMRAq5cAKCEx/4G+FJb6XSQyZu1IOvd9UBixgCfbZUk nDISb0J+YuIJlLYkVIKkLBo= =1Swd -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Pretty Good BGP on Quagga
by Josh Karlin 22 Jul '08

22 Jul '08

All, We just wanted to let you know that Pretty Good BGP (PGBGP) is now available for Quagga. The Internet Alert Registry (IAR) has been running it stably for a few months now and we wanted to open it up to early adopters. Overview: PGBGP is a distributed security mechanism for BGP that attempts to avoid prefix hijacks, sub-prefix hijacks, and spoofed paths. Each router individually computes its own idea of the origin ASes for each prefix based on the past few days of routing announcements. Routes for prefixes with new origin ASes are labeled as anomalous and are depreferenced for 24 hours, using the more trusted (stable) routes where possible. New links are also considered anomalous, as well as new sub-prefixes. New sub-prefixes are dealt with by choosing paths to the trusted less specific when possible for 24 hours. Opt-in emails are sent to operators to inform them of anomalies, to help them identify and fix the problem (if any) within the 24 hours. Hardware overhead: Running PGBGP requires roughly ~20MB of extra RAM. Adding additional BGP sessions does not significantly affect PGBGP memory usage. CPU requirements are minimal. Routing performance: Sometimes, PGBGP will select an inferior path in order to avoid an anomalous route. Our studies have shown that typically, anomalous routes are short lived (e.g. due to convergence churn). On the IAR, of the available 1,546,996 routes in the RIB, 5,111 of them are anomalous at the time of writing this email. There are corner cases in which PGBGP could cause loss of reachability, and they are discussed in the papers. Documentation, papers, links to NANOG presentations, and the patch itself are available at the project's webpage: http://cs.unm.edu/~karlinjf/pgbgp/ If you're interested in PGBGP or would like to help further BGP security research, please give it a try and let us know that you're running it. We'd be happy to entertain suggestions, discuss the protocol, and provide support. Thanks for your time, Josh

1 0

OIX Routeviews
by Jason Lewis 22 Jul '08

22 Jul '08

Excuse the OT post, I can't seem to send mail to routeviews.org and this is a last resort. A while ago, David Meyer asked if anyone was still using the "sho ip bgp" format rib on routeviews.org. For a few months the rib dump process has been broken. Are the "sho ip bgp" ribs gone for good? jas

2 1

virtual aggregation in IETF
by Paul Francis 22 Jul '08

22 Jul '08

Gang, I have submitted an internet-draft to the IDR group on virtual aggregation (VA) (http://www.ietf.org/internet-drafts/draft-francis-idr-intra-va-00.txt) This draft suggests a few changes to routers that allow operators to control the size of their FIBs, shrinking them by 5x or 10x quite easily. This would extend the lifetime of routers that are constrained by FIB size. There has been a lively discussion of this on the IDR mailing list, including a suggestion that FIB reduction is more important for lower tier ISPs (tier 2, tier 3...) than for tier 1 ISPs. Unfortunately I don't think that people from smaller ISPs pay much attention to the IDR mailing list, so they are not being represented in this discussion. So I'm looking for input from folks who think that FIB reduction helps them, so as to better understand their requirements. Any help is much appreciated. Thanks, PF

5 11

weirdness with Extreme
by Andy Grosser 22 Jul '08

22 Jul '08

Has anyone else seen this kind of thing before? 2 Extreme Black Diamond 6804s (ExtremeWare 7.2.0b37) at the core (active/standby) start to fight over which of them is master for a particular VLAN. They go back and forth for maybe a minute, and for a brief period, the master switch seems to fight with itself over which will cede master status. The log messages indicate either high/low port count, or high/low priority, for that particular vlan. ESRP then forces access switches hanging off the cores to flush their forwarding databases. All activity takes place within a span of just over a minute, then dies. Extreme doesn't have anything to report yet. Just wondering if anyone has seen behavior like this in an Extreme environment. Thanks, Andy --- Andy Grosser andy [at] meniscus {dot} org ---

7 7

Re: connectivity to MSN
by Nick Shank 21 Jul '08

21 Jul '08

Everything should be up and running, and I haven't gotten a ticket to the contrary. A tracert works for me, but I'm behind the firewall, so it's of no use to anyone else. ~Nick -----Original Message----- >From: Matt Liotta <mliotta(a)r337.com> >Sent: Jul 21, 2008 7:56 AM >To: nanog(a)nanog.org >Subject: connectivity to MSN > >Anyone having problems with MSN? Depending on which AS I use the >traceroute dies in different places, but most of the time it dies in >AS 8075. However, MSN does seem accessible from XO and Comcast. > >-Matt >

1 0

connectivity to MSN
by Matt Liotta 21 Jul '08

21 Jul '08

Anyone having problems with MSN? Depending on which AS I use the traceroute dies in different places, but most of the time it dies in AS 8075. However, MSN does seem accessible from XO and Comcast. -Matt

2 1

Re: Force10 E300 vs. Juniper MX480
by Keith O'neill 21 Jul '08

21 Jul '08

Force 10 is fine. I do suggest he go with the dual cam cards over the regular cards. I am not sure what Chris is talking about but I have used Force 10 for a long time, E, C and S series and have found it very stable. It will do everything you want and then some. The E300 is a good bang for the buck. Sure Foundry might be cheaper but I hear more complaining about Foundry than any other platform. Chris you want to share what issues you have seen with Force 10. Keith ----- Original Message ----- From: "Chris Marlatt" <cmarlatt(a)rxsec.com> To: "Joe Abley" <jabley(a)ca.afilias.info> Cc: "nanog" <nanog(a)merit.edu> Sent: Friday, July 18, 2008 7:43:33 AM (GMT-0500) America/New_York Subject: Re: Force10 E300 vs. Juniper MX480 Joe Abley wrote: > Hi all, > > An acquaintance who runs an ISP with an M7i on its border is looking to > upgrade, because the M7i is starting to creak from all the flesh-tone > MPEGs his customers are sharing. (How times have changed. Back when I > was chasing packets, it was flesh-tone JPEGs.) > > He's looking at the MX480 and the E300. > > The MX480 is attractive because the M7i has been stable as a rock, and > he's familiar with JUNOS. > > The E300 is attractive because it's half the price of the MX480, and has > the potential to hold layer-2 cards as well as layer-3 ports which makes > the price per port much more reasonable than the MX480. But he has no > experience with Force10 at any ISO layer higher than 2. > > He doesn't have any exotic requirements beyond OSPF, OSPFv3, BGP, IP and > IPv6. There's no MPLS in the picture, for example. However, he's going > to want four or five full tables plus a moderate load of peering routes > in there. And maybe VRRP. > > Thoughts from people who have tried one or the other, or both? Or who > have faced this kind of problem, and came up with a different answer? > > Feel free to send mail off-list; I can summarise if there is interest. > > > Joe > I would avoid Force10 if at all possible. In the network I managed I've had some fairly surprising stability problems with their S series switches and feature problems (or lack there of) on their E series. Things you kind of scratch your head at and wonder what they were thinking. Juniper on the other hand is indeed a bit pricier but quite a stable platform. If he has to look at alternatives I would suggest Foundry, either the RX-8, MLX-8, or XMR-8000 (depending on requirements) for comparable models to the MX480. Regards, Chris

7 9

NMS for Carriers
by Adam Armstrong 21 Jul '08

21 Jul '08

Hi All, We're kicking off a project to find a new NMS and I thought you guys might have some helpful advice. We're a smallish telco (on an island, infact) so we have a very wide range of kit to monitor, from servers to routers to dslams and all that dirty voice stuff. Which software are you guys using? Any obvious gotchas with the various solutions? We're looking at EMC Smarts first. Anyone got any comments to make on that? Thanks in advance! adam.

2 1