February 2000 - Test - lists.nanog.org

RE: Cisco - ip verify unicast reverse-path
by Paul Ferguson 14 Feb '00

14 Feb '00

At 09:58 AM 02/14/2000 -0800, Owen DeLong wrote: > Does ip verify unicast reverse path accept packets for which > the inbound interface is not the preferred outbound interface, but > is a valid outbound interface? This feature looks up the source address in FIB, and if the source address is reachable via the source interface, the packet is forwarded. If it is not, it is punted. Yes, it can occasionally pose problems in situations where the FIB associates the forwarding path for a particular prefix to an interface which is not the one on which the packet was received. This feature is not a panacea, just another tool. - paul

1 0

ARIN Database
by Richard Jimmerson 14 Feb '00

14 Feb '00

Over the last week, an individual faked mail headers and successfully changed the email addresses on the POC records associated with a handful of Class A records in ARIN's database. After successfully modifying the POC records, he modified the inverse mapping servers listed on those Class A network records. Once identified, corrections were made to the records in question. We have spoken with the individual who appeared to have made the unauthorized changes, however, he claims to have been hacked himself and is not responsible for submitting the bogus modification requests. He said his mailboxes looked fake and utmp entries had been tampered with on his machine. Prior to this incident, the ARIN engineering staff had been looking into adding security mechanisms to our database. We would like to invite the community to discuss possible security mechanisms that may be implemented using the following mailing list: Database Implementation Working Group dbwg(a)arin.net To join this mailing list, visit http://www.arin.net/members/mailing.htm This mailing list is open to the public. Regards, American Registry for Internet Numbers (ARIN)

2 1

Re: What would you tell the White House?
by Martin Cooper 14 Feb '00

14 Feb '00

Dan Hollis <goemon(a)sasami.anime.net> wrote: > Recently called the NOC of a tier1 provider who hadn't responded to my > emails about repeated cracking attempts originating from their network. > > They told me point blank, they bin ALL abuse emails and only act on phone > reports. (Whats the point of maintaining an abuse mailbox then? Boggle.) Which Tier1 is that please? (ATT Worldnet perhaps?) Interested parties wish to know... M.

1 0

Cisco says attacks are due to operational practices
by Sean Donelan 14 Feb '00

14 Feb '00

In an InteractiveWeek article the head of Cisco's security products group says the attacks are an operational problem not a technical problem. >Routers from Cisco and other vendors have the ability to detect the signature >patterns of a denial-of-service attack, and the routers can filter out that >traffic, Farnsworth said. > >"The router knows which sources are legitimate or not and drops on the floor >anything suspicious," Farnsworth said. "Generally speaking, ingress filtering >and committed rates are effective in terms of preventing [malicious] traffic >from ever showing up, or filtering it to a reasonable rate."

16 22

Re: ARIN Database
by brandon＠rd.bbc.co.uk 14 Feb '00

14 Feb '00

> the ARIN engineering staff had been looking > into adding security mechanisms to our database. We would like to > invite the community to discuss possible security mechanisms that may > be implemented using the following mailing list: > > Database Implementation Working Group > dbwg(a)arin.net that's fine for just ARIN but we really need this sorting out for NSI too. As an example of how to do it check out the UK registry (http://www.nominet.org.uk/) who have a fine PGP based solution. I'd love NSI to operate as simply and reliably. brandon

1 0

Re: What would you tell the White House?
by David Lesher 14 Feb '00

14 Feb '00

[many tales of the same ilk read but unquoted..] Warning: Un P. C. statements follow... A) I submit that getting the F B of I to investigate anything that won't get them good coverage on the nightly news is as impossible as patenting perpetual motion machines. Ask Cliff Stoll. B) From events over the last 4+ years, even if A) were not the case, it appears the current White House has little or now control over the folks in the ugliest building in The District. Better look for help elsewhere.... -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

2 1

NANOG List SW and Y2K
by Eric Germann 13 Feb '00

13 Feb '00

In updating my search engine tonight, I noticed the latest NANOG historical archives at merit are archived as nanog.100.01 and nanog.100.02 The cobblers children have no shoes? Though it was interesting and a break from theories on DDOS. :) Eric ========================================================================== Eric Germann Inacom Info Systems egermann(a)inacomlima.com Lima, OH 45801 Ph: 419 331 9050 ICQ: 41927048 Fax: 419 331 9302 "It is so easy to miss pretty trivial solutions to problems deemed complicated. The goal of a scientist is to find an interesting problem, and live off it for a while. The goal of an engineer is to evade interesting problems :)" -- Vadim Antonov <avg(a)kotovnik.com> on NANOG

1 0

Blech!
by Paul Ferguson 13 Feb '00

13 Feb '00

I hate to ask this, but can't bite my lip, given the fact that people are throwing lawyers at this stuff now. Is it within the realm of possibility that ISP's will start to craft SLA's, peering & transit agreements, to include who is responsible for ingress filtering? I would think so. Also, if so, do you think that this would technically be effcient, given that the filters would actually be applied? Feel free to be silent, - paul

7 8

RE: Cisco - ip verify unicast reverse-path
by Paul Ferguson 13 Feb '00

13 Feb '00

At 02:06 PM 02/13/2000 +0100, Erik-Jan Bos wrote: > >There's always RFC2267. > >Nice RFC, IMO, who wrote that piece of fine work? :-). Some trouble maker... ;-) - paul

1 0

Cisco - ip verify unicast reverse-path
by trall＠almaden.ibm.com 13 Feb '00

13 Feb '00

This command has been mentioned numerous times during the DDoS discussion. I, for one, don't have a good idea of how it works. Perhaps someone can enlighten us? Cisco's web site certainly doesn't do much to help the situation. I found it mentioned in the guide (not the reference) for the Cat 6000 (http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/ios127xe/config…) - no description of syntax, let alone what it does. And then there is http://www.cisco.com/warp/public/707/newsflash.html. It says that the RPF check is based on CEF. I'm not familiar with CEF and want to clarify something about unicast RPF. If the source address of a packet arrived on an interface that would not be the preferred route for that address but is one of the less-preferred routes would the packet get dropped? If, as I hope, it would not, I don't understand the argument that it doesn't work for multi-homed connections. Such systems should be advertising their routes over all connections - thus the routes should appear on all paths outbound from the multi-homed systems (less any long prefix filtering being done by the upstreams). Another issue is why has Cisco made this such a stealth feature? Is it still buggy? Are the side-effects of using it so negative that hardly anyone can use it? If any such speculation is true, the folks advocating the use of this feature should also be pointing out the downside. Tony Rall

4 3