- NANOG - lists.nanog.org

Internet Route Filtering
by Robert Malally 21 Aug '97

21 Aug '97

Hello, Does any one truely know what the current route filtering polices are for Sprint and MCI. The following rules are some that I have heard : Sprint currently filters announcements from its non-customers as follows: RFC 1597 reserved space: accept nothing (**) In the classical "A" space: accept nothing longer than /8 In the classical "B" space: accept nothing longer than /16 in 24/8 space: accept nothing longer than /19 (*) in 195/8: accept nothing longer than /19 in 206/8 - 223/8: accept nothing longer than /19 in 192/8 - 205/8: accept nothing longer than /24 (*) in-line with the IP registries allocation (**) RFC 1597> Private Address Space RFC 1597> The Internet Assigned Numbers Authority (IANA) has reserved RFC 1597> the following three blocks of the IP address space for private RFC 1597> networks: RFC 1597> 10.0.0.0 - 10.255.255.255 RFC 1597> 172.16.0.0 - 172.31.255.255 RFC 1597> 192.168.0.0 - 192.168.255.255 How are MCI and Sprint going to adjust their routing polices when the reclaimed class A's are given out. Thanks Robert Malally

1 0

RE: Trans-Atlantic Traffic
by Thomas P. Koltai 20 Aug '97

20 Aug '97

--- On Wed, 13 Aug 1997 23:46:56 +1000 Stuart Bryant <stuartb(a)ourworld.net> wrote: >Hi, > Does anyone know the kind/amount of data currently being moved either >way over the Atlantic links ? About 11,520,000,000 bit per hour. Tom -------------------------------------------------- Thomas P. Koltai Mobile: +61-419-333331 187 Liverpool Street, Sydney NSW Australia 2000 --------------------------------------------------

5 4

THENET update
by sob＠academ.com 20 Aug '97

20 Aug '97

It appears things have returned to normal with THENET. I am seeing their service machines and UT Austin from the major peering points now. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

THENET outage
by sob＠academ.com 20 Aug '97

20 Aug '97

FYI, I understand that there has been a significant power problem at UT Austin that has affected THENET connectivity. I observe that the MAEs don't have routes to either UT-AUSTIN or the THENET service machines. I don't know much more than this about it. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

[NON-Operational Issue]: Paul Vixie is a Vigilante?
by Chris A. Icide 19 Aug '97

19 Aug '97

List, First, sorry for the non-operational issue. They said it, I read it.... Here it is. http://www4.zdnet.com/anchordesk/story/story_1170.html Comments concerning a spam "black hole" list maintained by Paul that makes the spammers "disappear".... Chris

2 1

Re: ICMP Attacks???????
by Vadim Antonov 18 Aug '97

18 Aug '97

Just for the record -- the first description of such mechanism is in Sep 95 draft for TRAP ICMP: "Trace Back messages allow to locate the source of a stream of packets even if they carry incorrect or forged source address. Trace Back message causes a gateway to install a "trap" route to the specified desti- nation, to catch the incoming packet to that destination. Once the packet is received, the gateway reports it to the trace initiator, removes the trap, and sends the Trace Back message to the neighbour gateway the message came from. A trap expires (thus terminating the trace) if no packet addressed to the destination is received." --vadim "Alex.Bligh" writes: > > The other nice solution would be an inverse traceroute that went > back to each router in turn, passing it a bit of BPF saying "where > are you getting packets like this from please?". If such a protocol > existed...

2 1

Re: ICMP Attacks???????
by Danny McPherson 17 Aug '97

17 Aug '97

[ Note: To those that (strongly) dislike Cisco, admittedly or not, you don't have to read the non-intuitive examples included below, really ;-)] > It would be nice, but for now logging the hardware addresses along > with the ip addresses would be cool. After speaking with some Cisco folks, I've found that you can already do this on Ciscos .. as I believe someone mentioned here before. I tried it on our MAE-East router (w/RSP2) and found that no significant amount of CPU was wasted logging the packets. Given, I didn't leave the ACL applied to our NAP FDDI interface for any substantial amount of time, but there was really no need to, per all I wanted was enough data to verify the source router/network of the attack. Consider the following: Someone, somewhere, is using smurf.c (or any spoofing-type-program, for that matter) to launch a DoS attack on one of your customers. All you know is that the attacker is "pinging" the broadcast address of a few of the public exchanges, with a source IP address of a customer's server(s). Finding the destination IP address isn't that difficult (at least for your customer ;-), it's the "real" source that's the problem. You can build an ACL on your NAP router that logs all ICMP-type (or whatever) traffic bound to the IP address of the customer's server, as such (assuming you're customer's server ip address is 1.1.1.1): access-list 199 permit icmp host 1.1.1.1 any log-input access-list 199 permit ip any any You then apply the access-list inbound to the NAP interface. Then, assuming matches occur, you should receive something similar to: Aug 15 20:04:45.087 MST: %SEC-6-IPACCESSLOGDP: list 199 permitted icmp 1.1.1.1 (Fddi6/0 0060.7017.a188) -> 192.41.177.255 (0/0), 1 packet The MAC address listed after the interface identifier is that of the router's interface on the ring from which you received the spoofed packet. You can then match the MAC address to the IP address of the interface (via "sh arp", or other ways) .. and you've just identified the router/network from which the attack is being sourced. Now comes the fun part, cooridinating with the Operations/Security folks from the corresponding network(s) to track the attack, hop-by-hop, through their network. If the attacker is using multiple public exchange subnets to source the echo replies, you may consider identifying the source router/network at another exchange as well, before pointing fingers. Hope I haven't overlooked something obvious here .. but I'm sure that if a did someone will "enlighten" me ;-) Of course, the one obvious thing I didn't mention is that if everyone were to deploy ingress filtering, this would be much, much easier to control. -danny

6 5

Re: US Domestic line costs?
by Jim Warner 16 Aug '97

16 Aug '97

On 14 Aug 1997 Josh Beck said: > Not relevant to East Coast, but PacBell DS1: > > $350 + $25/mile. > > MFS is signifigantly cheaper, but I don't know their formula. PacBell has two tariff rates for point-to-point T-1 service. The rate quoted above is their "California" CPUC rate. The other rate is the FCC128 tariff. If more than 10 percent of the data on the line originates or terminates across LATA boundries the customer can request the FCC rate which is $15 per mile. There may be uses of T-1 lines which would never qualify for the lower FCC rate. This is speculation since none of this applies to government, but a T-1 connecting two PBXs in the same city together would probably not qualify for the FCC rate. But consistantly in many discussions with many PacBell service representatives, the only requirement for getting the "good" rate for a T-1 used for networking is that you know enough to ask for it. Not clear from Beck's brief quote, the $350 fixed charge covers the cost of the lines from the serving wire centers to the customer premises. The "milage" is the distance between the serving wire centers. The milage charge can be zero if both ends are served from the same central office. When the milage is not zero, there is an additional charge of about $100/month which covers the capital cost of using PacBell DACS to get in and out of their interoffice network. For "trade show" applications (pull T-1 to convention center for 1 week and then disconnect), the CPUC rate may be overall lower cost than the FCC128 rate because of lower one-time charges. As should be clear from my email address, the interpretations of PB rates are mine and not pacbell's or the University's.

1 0

Re: ICMP Attacks???????
by Danny McPherson 16 Aug '97

16 Aug '97

[snip] From: "Paul G. Donner" <pdonner(a)cisco.com> log-input was added in 011.002(002.002) 11.2(02.02)F 11.2(02.02)P 11.1(08)CA. -danny > I'm pretty sure this is a new feature. Wow. Useful. That's exactly > what I wanted. Given you are doing this I take it it's in 11.1.11CA1.

1 0

[CISCO] directed-broadcast, ip classless
by rja＠corp.home.net 15 Aug '97

15 Aug '97

In case others are engaged in lobbying with cisco, here are my case numbers with the cisco TAC on this topic: ----------------------------------------------------- CASE: H87031 OPENED: 05-AUG-97 DESCRIPTION: turn off IP packet directed broadcast by default ----------------------------------------------------- CASE: H87037 OPENED: 05-AUG-97 DESCRIPTION: make "ip classless" default for ISP IOS images ----------------------------------------------------- The "ip classless" is important since various folks have chunks of former class A address space but do not have the entire former class A. For example, @Home has a small slice of 24.x.x.x, but several other providers are also in 24.x.x.x. Ran rja(a)home.net

9 13