- Test - lists.nanog.org

RE: OT: BGP questions
by Pete Templin 19 Nov '03

19 Nov '03

It's not a dispute, it's a dollar$ decision on behalf of Sprint and/or MFN. "Hmmm, I'm getting paid by 6939 but not by 3356. I'll send my traffic through 6939 by increasing my local preference to them." Pete Templin Senior Staff Engineer TexLink Communications (210) 892-4183 pete.templin(a)texlink.com -----Original Message----- From: Charles Sprickman [mailto:spork@inch.com] Sent: Wednesday, November 19, 2003 1:24 AM To: nanog(a)merit.edu Subject: Re: OT: BGP questions > On Sat, 15 Nov 2003, Charles Sprickman wrote: > > > (just look at AS8059, which is still sucking down most traffic via 6939 > > rather than 3356, even with all that silly prepending)... Found an interesting one. Sprint no longer has a "full" looking glass, just this: http://oxide.sprintlink.net/cgi-bin/glass.pl But it shows Sprint reaching 8059 via MFN, even with the prepends. Is there a Sprint/Level3 peering dispute that I'm not aware of? Might someone from Sprint comment on this privately? Thanks, Charles

1 0

Re: New IANA IPv4 Allocations
by Brandon Butterworth 19 Nov '03

19 Nov '03

> > I'd just check the web site or directly if it was important to know > > What makes you think that the answer you get when you look up > www.iana.org is what the real IANA wanted you to get? "or directly if it was important to know", choose channel by degree of certainty you desire. > This is not a Grand Paranoid Call-to-Arms, necessarily, but it seems > odd to distrust a non-signed email but at the same time trust an HTTP > url. It'd be a simple cross check rather than just trusting either, the chances of both being compromised should be lower. Chances of the RIPE site also being compromised are even lower unless there was an ARIN/RIPE conspiracy in which case we have bigger problems </xfiles> brandon

1 0

Re: New IANA IPv4 Allocations
by Brandon Butterworth 19 Nov '03

19 Nov '03

> It would be good for them to sign such posts with > a well known PGP key... I see no point, if someone was trying to spoof this announcement they may already have the iana key X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 17 Nov 2003 20:54:45 -0800 From: Steve Conte <conte(a)iana.org> I believe there is an exploit for that version, the other common client regularly has similar problems I wonder if people use such signing, usually out of band verification is easier and safer. > > For a full list of IANA allocations please see > > : http://www.iana.org/assignments/ipv4-address-space I'd just check the web site or directly if it was important to know brandon

2 1

OT: BGP questions
by Charles Sprickman 19 Nov '03

19 Nov '03

Hi, Where's the best place these days to ask some "simple" BGP questions? I don't want to bother *-nsp@puck, but inet-access scares me. Any suggestions? I'm good with the basics, but I've got a perplexing issue (just look at AS8059, which is still sucking down most traffic via 6939 rather than 3356, even with all that silly prepending)... Thanks, Charles -- Charles Sprickman spork(a)inch.com

1 2

Cisco, Anti-virus Vendors Team on Network Security
by Sean Donelan 19 Nov '03

19 Nov '03

As part of Cisco's Self-Defending Network Initiave Cisco has announced a new product which relies on "the Cisco Network Admission Control program is innovative software developed by Cisco called the Cisco Trust Agent which resides on an endpoint system and communicates with the Cisco network. The Cisco Trust Agent collects security state information from multiple security software clients, such as anti-virus clients, and communicates this information to the connected Cisco network where access control decisions are made and enforced. Cisco has licensed its Cisco Trust Agent technology to Network Associates, Symantec and Trend Micro so it can be integrated with their security software client products." Currently the Cisco NAC software only works with Cisco network equipment and Microsoft Windows NT, XP and 2000 operating systems. Without the secret handshake Mac OS, Linux, Solaris and other operating systems will not be able to connect to a Cisco Self-Defending Network which limits its usefullness for ISPs.

6 6

RE: Cisco, Anti-virus Vendors Team on Network Security
by Brennan_Murphy＠NAI.com 19 Nov '03

19 Nov '03

I think port security is what determines whether or not a box is allowed onto the network. If you know that all of your conference room jacks are patched into switch X blades Y-Z, then you apply security to those ports. If you have a *NIX box in a server room, you obviously drop the mcafee security requirement for that port. I havent read through the documentation but that's my guess. The corporate network security market is looking for a way to ensure that only machines with up to date security policies (AV, FW, IPS) are allowed on the network...with ways to distinguish printers, from workstations/servers... etc... -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Sean Donelan Sent: Tuesday, November 18, 2003 3:48 PM To: Valdis.Kletnieks(a)vt.edu Cc: nanog(a)merit.edu Subject: Re: Cisco, Anti-virus Vendors Team on Network Security On Tue, 18 Nov 2003 Valdis.Kletnieks(a)vt.edu wrote: > > Without the secret handshake Mac OS, Linux, Solaris and other > > operating systems will not be able to connect to a Cisco > > Self-Defending Network which limits its usefullness for ISPs. > > A *nix without a secret handshake is like a fish without a bicycle. > > Yes, viruses *are* theoretically possible on these platforms, but > let's be honest here - even if you included all of the platforms, > you'd only intercept another 1% or so viruses, tops. Well, if you let systems on the network without the secret handshake, what's to stop people from connecting Windows boxes with the "security" software disabled so it doesn't answer the "I'm Infected" question? Or the next virus can take over the Cisco secret handshake port and always answer "I'm Ok" when ever the network asks it a question. How does the Self-Protecting Network tell the difference between a non-infected Mac or Unix machine from a Typhod Mary Windows bo if you are depending on software on the system to answer the question? Yes, some level of security works when every obeys the rules. But the current problem ISPs have is not everyone obeys the rules.

1 0

Re: Cisco, Anti-virus Vendors Team on Network Security
by Brandon Butterworth 18 Nov '03

18 Nov '03

Duh. Make that the OS that can use it seem to be more usually wormed/virused than the OS that can't

1 0

Re: Cisco, Anti-virus Vendors Team on Network Security
by Brandon Butterworth 18 Nov '03

18 Nov '03

> Cisco has licensed its Cisco > Trust Agent technology to Network Associates, Symantec and Trend Micro so > > Currently the Cisco NAC software only works with Cisco network equipment > and Microsoft Windows NT, XP and 2000 operating systems. > > Without the secret handshake Mac OS, Linux, Solaris and other operating > systems will not be able to connect to a Cisco Self-Defending Network > which limits its usefullness for ISPs. Sounds of limited use anyway, the OS that can use it seem to be more usually wormed/virused that the OS than can't (regardless of the add on security products). brandon

1 0

uRPF-based Blackhole Routing System Overview
by Robert A. Hayden 18 Nov '03

18 Nov '03

I posted earlier mentioning that I was using uRPF to facilitate a blackhole routing system on our campus. I went off to lunch and came back to 38 private emails from people asking how I'm doing it. Rather than respond individually, I figured I'd post an informal synopsis here. First, I'm a network engineer at the University of Wisconsin Madison (I read NANOG from my personal email account). We have a large ethernet-based network that runs primarily on Cisco 6500s for core routing and switching, and 3550/3750 switches for edge aggregation. 802.1q is used for layer 2 networking, with each department network getting a unique .1q VLAN ID. uRPF was designed primarily to block spoofed IPs. However, you can trick it into blocking non-spoofed IPs by making the routing table think the IP address should legitimately be located somewhere else. So, the first step is to turn on strict uRPF checking on to the interface. We use the following as an example interface setup on an MSFC2 running 12.1.(19)E1: interface Vlan645 description Department of Nuclear Basketweaving LAN ip address 192.168.1.0 255.255.255.0 secondary ip address 10.0.0.1 255.255.255.0 ip verify unicast source reachable-via rx allow-self-ping ... end Second, we set up a small router and make sure it speaks OSPF with the rest of our backbone mesh. Any size router will do since it doesn't need to handle a lot of traffic. Heck, grab an old 2501 out of your suplus closet. Make sure that this router is set up to redistribute static routes. We use a 3550-12 switch because we forward certain traffic into a server for analysis so we wanted something with a little horsepower to handle it. In most cases, anything small will work. Now, let's pretend that the IP address of 192.168.1.100 is Nachi compromised and we want to blackhole it. That is, we want to make sure that it neither receives nor sends traffic beyond its router interface. On the blackhole router I can enter: ip route 192.168.1.100 255.255.255.255 null 0 OSPF will inject this /32 route into the backbone mesh. Back on the actual interface, uRPF will see in the routing table that the route belongs "somewhere else" and conclude that it must spoofed and dump it. In addition, traffic destined TO that IP address will follow the most-specific route and end up in the BH router. As soon as the nachi virus is removed, I do: no ip route 192.168.1.100 255.255.255.255 null 0 on the blackhole router and in a few seconds traffic to and from that IP flows properly because the /32 is no longer seen by the router interface. Note that if you don't use uRPF on that interface, or if you use loose-source uRPF, than this system won't work for outgoing traffic, only for packets destined TO the BHed IP address. Now, we also have a web-based front end we custom developed. It takes the IP address we want to manipulate and executes the 'ip route' command on the router by proxy. It also saves additional information into a historical database about who entered/removed the IP, any Clarify tracking case associated with it (our internal ticketing system), and any other relevant information. For notification, it checks against our WHOIS-based customer tracking database that associates people records with the vlan number, and send them a notification that the IP was blackholed, and then reminders every few days until the IP is removed. Unfortunately, this was also all custom developed. As a whole, the system works REALLY well and we can sugically remove IPs from the backbone without having to kill entire subnets, and then just as easily enable them again. One final note. This system is pretty useless for modem pools, VPN concentrators, and many DHCP implementations. The dynamic IP nature of these setups means you will just kill legitimate traffic next time someone gets the IP. You can attempt to correlate your detection with the time they were handed out, of course, in the hopes you find them. - Robert Network Guy @ UW Madison

5 4

C&W Euro NOC contact
by Thomas Kernen 18 Nov '03

18 Nov '03

If someone from the C&W European NOC can contact me offline I would appreciate it. I have an issue that can't be escalated because the person that answers the phone in Munich doesn't seem to understand what on earth I'm talking about. Thx Thomas

1 0