- Test - lists.nanog.org

Re: whois.internic.net
by Gerald Andrew Winters 21 Nov '97

21 Nov '97

Hi William, try: whois -h rs.internic.net as1234 Schickentanz, Alfred (AS1234) alfred(a)WELL.COM Immortality Systems 13 Main Dock Sausalito, CA 94965 (415) 332-1266 [snip...] or you're welcome to try our server for internet routing information: whois -h whois.ra.net as4557 aut-num: AS4557 as-name: TEXAS-GIGAPOP descr: Texas GigaPOP AS as-in: from AS145 10 accept ANY AND NOT {0.0.0.0/0} as-in: from AS8 10 accept AS8 as-in: from AS7276 10 accept AS7276 as-out: to AS145 announce AS-TEXASGIGAPOP as-out: to AS8 announce ALL as-out: to AS7276 announce ALL admin-c: FG50 tech-c: SB98 notify: sob(a)academ.com mnt-by: MAINT-AS4557 changed: sob(a)academ.com 971114 source: RADB --Gerald (merit)

2 1

Re: Geographic v. topological address allocation
by Sean Doran 21 Nov '97

21 Nov '97

"Kent W. England" <kwe(a)geo.net> writes: > This is true, but the definition of the top of the hierarchy is arbitrary > and is the nexus of the debate about "topological" versus geographical > addressing, which I interpret as "ISP at top" versus "exchange point at > top" hierarchies. Both are valid topological hierarchies. As tli pointed out the top of the hierarchy is not arbitrary, it must be default free. In a hierarchical routing system there are three forwarding directions to consider: intra-area ("lateral"), default ("upwards") and sub-area ("aggregate" or "downwards"). At the top of a hierarchy you cannot have an upwards forwarding direction, therefore the entire address space must be intra-area or presented as an aggreagate. If you consider an addressing structure that looks like this: level-3-area-id:level-2-area-id:level-1-area-id:final-flat-id and in an internetwork with three levels of hierarchy, this pattern is easy to consider. A level-2 router may have some things directly attached to its level-2 area, including its peer routers, and it would carry routes towards them, which probably would be in a flat routing table. Among the reasons it needs these routes is that it has to know where to send traffic towards each of the level-1 areas that are attached to its own area, and it has to know where to send "default" traffic towards one or more of its in-area peers that have level-3 connections. Each such level-3 router would have to know how to foward to any given level-2 area, and therefore would need to carry routes for each level-3/level-2 gateway. Each level-1 router, by contrast, only needs to know how to route towards all the things in its area, and how to reach at least one level-2 router. (One can be a little tricky and have a single level-1 area connected to multiple level-2 routers in different level-2 areas, in which case better routing optimality may be obtained by the level-1 router carrying some level-2 routing information. This would be analogous to Yakov Rekhter's "route pull".) However, the minimum set of routes to carry is that which can cause traffic to be forwarded along a strict single-path tree-like hierarchy. This requires that each area be fully contiguous at all times. Other routes may be introduced in various places to alter this behaviour if that is desirable, or to effect IS-IS style partition repair. In order for the hierarchical routing system to scale the number of entities known in any given area must be small enough to route on in what is conceptually a flat manner. That means that there are bounds on the number of level-n to level-n-minus-one areas, and this in turn requires that the addressing scheme allow for a deep enough hierarchy. Consequently, the number of things in the top, default-free hierarchy is always going to be limited, no matter what "type" of hierarchical allocation scheme is proposed. The further requirement that any given area be fully contiguous means that the "top" of the hierarchy must be self-repairing. In other words, as tli pointed out, if you have a switch in some convenient geographical location, like the Grenwich Observatory or the UN building or MAE-EAST, your entire routing system fails if that switch or that location fails. Consequently, to avoid the single point of failure, there would be a desire to have several diverse geographical locations to act as the top of the hierarchy. The problem, again, is that any given area must be fully contiguous, and this implies that any level-n router connecting to one of these diverse locations would have connectivity to every other level-n router, so that this top level n area would be contiguous. One could propose to implement this as a big bridged network. The original DGIX proposal was along these lines. Operational experience with much smaller but still big bridged exchange points has demonstrated pretty much conclusively that this is a Really Really Bad Idea. One could propose to implement this using the native protocol, effectively connecting all of these exchange points into a level-n-plus-one area of its own. As long as the level-n-plus-one area could route to all the level-n areas at all times, this would work just nicely, on a technical basis. The difference therefore between your "ISP at top" option and your "exchange point at top" option is that in a hierarchical addressing system, which is the only way we currently know how to scale a global internetwork, is merely in the choice of words. Whatever is at the top has to connect reliably and continuously all the things that are one step down from the top, and simple belt-and-suspenders implies geographical diversity. Thus, the top of the hierarchy may be expressed as a big, geographically diverse bridged network connecting all the "next-level-down" routers, a single big geographically diverse routed network comprising a single area, or a meshed concatenation of the "next-level-down" routers in such a way that robust interconnectivity among them is maintained at all times. The choice is probably best made on the basis of reliability and cost, but experience shows that it is likelier made on the basis of politics, autonomy/mistrust of other operators, marketing goals, and possibly cost. If it were possible for two routing areas to cleanly synthesize a next-level-up area, which probably implies the use of variable length addresses, then it strikes me intuitively that better routing hierarchy than is likely to be cobbled together through the deployment of physical infrastructure can be enjoyed, keeping the number of routing entries needed by any given router anywhere in such an Internet to a minimum. With a variable length addressing scheme, in other words, one can consider a set of operations which can be summarized as "make-hierarchical" or "make-lateral". The obvious and increasingly important first baby step in an evolutionary path towards a scalable Internet is, to quote Noel Chiappa, "to make the world safe for NAT, by making all end-to-end functions use the DNS name; e.g. for authentication, pseudo-headers for checksums, etc, etc." As he continued, this can be justified solely on the basis of working better with NAT, which solves some real-world problems now, and which is being used now. There is lots more to discuss. Is big-internet still in post-Bass trauma? If not, let's discuss it there, or privately. However, to tie in some tiny degree of NANOG relevance, and to emphasise through repetition, the idea of using a large bridged network has been broken through the history of exchange points, particularly since the lovely days when people didn't learn from Milo's FIX upgrade path and began doing multimedia bridging. Single exchange points fail, so avoiding the large briged network by having a single exchange point be the "top" of a hierarchy won't work. Therefore, the current hierarchy implemented in provider-based addressing with some coordination to preserve some degree of geographic alignment of addresses (through ARIN, RIPE and APNIC, and large-ISP allocation strategies), is almost certainly the most appropriate one. That is to say, we got CIDR pretty much right. Sean.

2 1

whois.internic.net
by William Duncanson 21 Nov '97

21 Nov '97

This is most annoying: fire /usr/home/caesar $ whois starkreality.com whois: connect: Connection refused And this: D:\users\Caesar>whois starkreality.com host "whois.internic.net" does not support "whois" queries Anybody know anyplace else that has up-to-date whois infomration? -- _________________ _ _ _________________________ William S. Duncanson |_| Collective |_| http://www.colltech.com Page:800-495-1005 |_ Technologies _| wduncanson(a)colltech.com caesar(a)starkreality.com [] [] "The Power Of Many Minds"

1 0

Re: Land Protection for Cisco
by Jim Shankland 21 Nov '97

21 Nov '97

Paul D. Robertson <root(a)gannett.com> writes: > Has anyone tried [the "land" attack] sourced and destined for > different interfaces on the same box? My test gear is all tied > up right now, and I'd rather not test on a production box. It is highly unlikely that this would work. The essence of the attack is creating a TCP connection in which (src-ip, src-port) is equal to (dst-ip, dst-port), so that the box's responses on that TCP circuit reappear as input from the "peer". This won't happen if src-ip != dst-ip, even if both ip's are associated with the same box. Jim Shankland Flying Fox Computer Systems, Inc.

1 0

Re: Geographic v. topological address allocation
by Tony Li 21 Nov '97

21 Nov '97

> This is true, but the definition of the top of the hierarchy is arbitrary Not at all true. The top of the hierarchy must be default free. > and is the nexus of the debate about "topological" versus geographical > addressing, which I interpret as "ISP at top" versus "exchange point at > top" hierarchies. Both are valid topological hierarchies. True, however, geographic addressing has some rather severe practical problems. The exchange point at the top becomes a single point of failure. So it needs replication. But then, there needs to be interconnect between the exchange points. Who provides it? All this and more has been beaten to death. If you start with the premise of geographic addressing and try to beat it into working, you end up with an ISPAC. See ftp://ftp.juniper.net/pub/users/tli/ispac.txt. Tony

2 2

Field Notice: TCP loopback DoS Attack (land.c) and Cisco Devices
by John Bashinski 21 Nov '97

21 Nov '97

-----BEGIN PGP SIGNED MESSAGE----- Field Notice: TCP loopback DoS Attack (land.c) and Cisco Devices November 21, 1997, 14:00 AM US/Pacific, Revision 1 - -------------------------------------------------- Summary - ----- Somebody has released a program, known as land.c, which can be used to launch denial of service attacks against various TCP implementations. The program sends a TCP SYN packet (a connection initiation), giving the target host's address as both source and destination, and using the same port on the target host as both source and destination. Classic IOS software (used on Cisco routers with product numbers greater than 1000, on the CGS/MGS/AGS+, and on the CS-500) is moderately vulnerable to this attack. For some IOS versions, if the attack is launched against a TCP port that is actually listening (say the TELNET port), then invalid connection data will be created, preventing further legitimate connections for approximately 30 seconds. High CPU loads may result on some IOS versions. We observed a complete hang on one 11.5 system, but have been unable to reproduce that failure. Based on very preliminary data, the router's packet forwarding functions are not generally affected. IOS/700 (used on Cisco 7xx routers) is also vulnerable. The 7xx vulnerability is more devastating than the classic IOS vulnerability, but probably less dangerous for most customers, since firewalls separate most 7xx routers from the Internet. The PIX firewall appears does not appear to be affected. Initial testing of the Centri firewall tends to indicate that it is not affected. We're working on characterizing other products' vulnerability to attack. Updates will be issued as information becomes available. Who is Affected - ------------- All IOS and IOS/700 systems that can be reached via TCP from untrusted hosts are affected, provided that the reachable TCP ports are ports on which IOS ordinarily provides service. The attack requires spoofing the targets's own address, so systems behind effective anti-spoofing firewalls are safe. Impact - ---- Classic IOS systems may experience slowdowns while under active attack. On IOS software versions earlier than 11.2(4), new TCP connections will fail for a period of about 30 seconds after any attack packet is received. IOS versions later than 11.2(4), or that contain the fix for bug ID CSCdi87533, may experience slowdowns, but should continue to accept new TCP connections . Most IOS versions appear to recover completely within a few minutes of the attack stopping, but we have not yet fully characterized the effect on all IOS versions. One complete failure was observed; the version was 11.1(5). A configuration workaround for classic IOS can prevent the problem entirely, subject to performance restrictions. IOS/700 systems subjected to the attack will hang indefinitely and must be physically reset. A configuration workaround for IOS/700 can prevent the problem entirely. Initial tests indicate that the PIX firewall is not vulnerable to this attack. Tests have been conducted with version 4.1.3.245 and 4.0.7. Initial tests indicate that the Centri firewall (build 4.110) is not vulnerable to this attack with no exposed service configured. We have not yet tested the Centri product with exposed services. Workaround for Classic IOS - ------------------------ Classic IOS users can use input access lists on their interfaces to prevent the attack packets from entering their TCP stacks. This will prevent the attack entirely, but may have unacceptable performance impacts on heavily loaded high-end routers. Traffic will still be fast-switched, but higher-speed switching modes may be disabled. It should be tried with care. If you have no existing input access lists, create a new IP extended access list. Use a presently-unused number between 100 and 199. The access list must have an entry for each of the IP address configured on the system. Deny packets from each address to itself. For example: access-list 101 deny tcp 1.2.3.4 0.0.0.0 1.2.3.4 0.0.0.0 access-list 101 deny tcp 5.6.7.8 0.0.0.0 5.6.7.8 0.0.0.0 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 If you have existing access lists, you'll need to merge the new entries in an appropriate way, generally at the top of the list. The access list should be applied incoming on all interfaces, so a fragment of a total router configuration might look like this: interface ethernet 0 ip address 1.2.3.4 255.255.255.0 ip access-group 101 in ! interface ethernet 1 ip address 5.6.7.8 ip access-group 101 in ! access-list 101 deny tcp 1.2.3.4 0.0.0.0 1.2.3.4 0.0.0.0 access-list 101 deny tcp 5.6.7.8 0.0.0.0 5.6.7.8 0.0.0.0 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 Workaround for IOS/700 - -------------------- Add the following configuration command to any profile that may be active when connected to potentially hostile network: set ip filter tcp in source <7xx IP address> destination <7xx IP address> block Using Cisco Products to Protect Other Systems - ------------------------------------------- We do not believe that this attack can be used against systems behind our dedicated firewall products, the PIX and Centri firewalls, unless general-purpose tunnels have been enabled through the firewalls. Properly designed anti-spoofing access lists at border routers can be used to prevent the attack from entering a private network from the Internet. Use the access lists to filter out packets whose IP source addresses are on your internal net, but which are arriving from interfaces connected to the outside Internet. Exploitation and Public Announcements - ----------------------------------- Cisco has had multiple reports of this vulnerability. Most exploitation seems to be using the original program, which sends one packet at a time. Floods of invalid packets have not been reported. This issue has been widely discussed in a variety of Internet fora. Cisco first heard of this problem on the morning of Friday, November 21. Distribution of this Notice - ------------------------- This notice is being sent to the following Internet mailing lists and newsgroups: * cisco(a)spot.colorado.edu * comp.dcom.sys.cisco * bugtraq(a)netspace.org * first-teams(a)first.org (includes CERT/CC) * nanog(a)merit.edu Updates will be sent to some or all of these, as appropriate. This notice will be posted in the "Field Notices" section of Cisco's Worldwide Web site, which can be found under "Technical Tips" in the "Service and Support" section. The URL will be http://www.cisco.com/warp/public/770/land-pub.shtml The copy on the Worldwide Web will be updated as appropriate. Cisco Security Procedures - ----------------------- Please report security issues with Cisco products to security-alert(a)cisco.com. This notice is copyright 1997 by Cisco Systems, Inc. This notice may be redistributed freely provided that redistributed copies are complete and unmodified, including all date and version information. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNHYMogyPsuGbHvEpAQHojQgAtU3nEwtn+2Xg8W8jLTcCIiF+q0oFhmMS Z54T67xooTmsWbLzv409AYR73G/TbsNgflzQZa8amAXbz6EIUlzaYqJdHB2B7FsH GFh8c7VFZZ7zp9r9UVJJYjSYwRENLpDaKb5kx//zOFF/9eh4G95cJ6zMMLukSreJ MAA+5xc23SV+fpk+AmxEzWifAYoIz9KRsK0/GTHA93F17MZEvTIauVf3VxD8DSHV zA7ndUNuxH0rg2oGOok4XbiBSSXK3glkkCAkJ0OzGEPt7RZ1EcJ+TpTJpETu+F7z 0XyJXF25TxoMAu8MmmM4IQvRtZzM0PGCA6X3XErg6wiUFJL1JFpejQ== =SkPH -----END PGP SIGNATURE-----

1 0

RE: OPS: SECURITY new packet of death
by Darin Fisher 21 Nov '97

21 Nov '97

Other vulnerabilities: Cisco PIX NOT vulnerable Wellfleet NOT vulnerable NPI EIFO vulnerable (doesn't shut the system down, but you can no longer monitor from telnet) IRIX 5.3 vulnerable IRIX 6.4 NOT vulnerable SunOS 4.1.3 vulnerable Solaris 2.4 NOT vulnerable Solaris 2.5.1 NOT vulnerable Ultrix (all) vulnerable HPUX 9.x vulnerable HPUX 10.x NOT vulnerable AIX 3.2.5 NOT vulnerable AIX 4.1 NOT vulnerable WinNT (w/ service pack 3) a little vulnerable (slows the system 'till SYN timeout) Win95 (w/ service pack 1) NOT vulnerable ( NCDware 3.3.2 vulnerable Linux 2.0.30 NOT vulnerable Novell 3.11 NOT vulneralbe Novell 3.12 NOT vulnerable Novell 4.10 NOT vulnerable Motorola SVR5 3.0 NOT vulnerable > -----Original Message----- > From: Michael Behrens [SMTP:michael@gothmog.kingston.net] > Sent: Friday, November 21, 1997 12:51 PM > To: nanog(a)merit.edu > Subject: Re: OPS: SECURITY new packet of death > > On Fri, 21 Nov 1997, Stan Barber wrote: > > > BugTraq has a note that version 10.3(7) is vunerable. I don't know > which > > version of Cisco the IOS was running on. > > version 11.1(5) is vulnerable. > > Michael > > |InterNet Kingston #177 Wellington St. Ste #302| > |Kingston, Ontario K7L3E3, Canada | > |http://www.kingston.net Bigger, Better, Local |

1 0

Important: NANOG List Changes
by William B. Norton 21 Nov '97

21 Nov '97

Hi all - We have turned on a couple of MajorDomo features to alleviate a couple of problems we have seen recently and put in place a batch queueing mechanism to improve the delivery speed. Specifically... 1) WHO turned off ----------------- We turned off the WHO command on majordomo so folks can't find out who is on the nanog list. In the past at least one spammer harvested nanog addresses for individualized spam. 2) New Posting Process: nanog-post(a)merit.edu list ------------------------------------------------- Starting next week, majordomo will restrict posting to the nanog list to those subscribed to the nanog-post(a)merit.edu list. To subscribe to the nanog-post list, send e-mail to majordomo(a)merit.edu with subscribe nanog-post in the BODY. You will receive a confirmation request, and once answered, you will be able to post to the nanog mailing list. This should reduce the subscribe lists to lists problem (e.g. Marilyn Monroe) and requires only a one-time subscription to nanog-post for those contributing content to the group. *You need not do anything if you don't plan on posting to the nanog list.* 3) Batch queuing of e-mail messages ----------------------------------- We are currently piping it through bulk_mailer which forks off multiple sendmail processes for the delivery. This helps quite a bit. I checked the delivery times a while ago and the worst case I saw was about 2-3 hours. This is not really that bad for a list of nanog's size. There is some additional tuning possible to improve things further (have bulk_mailer fork additional sendmails, and tuning some of sendmail's timeouts for hosts that are being un-responsive). We are also looking at qmail which can internally parallelize deliveries as is done with bulk_mailer and sendmail, but without the overhead of having a separate processes. Note that even with qmail, there will also need to be a certain amount of serialization necessary (to avoid depleting certain resources such as file descriptors) and thus there will always be a certain amount of delay for large lists. Hope this helps. Thanks to Larry Blunk (ljb(a)merit.edu) for getting all this stuff in place. Let me know if you have questions, problems, concerns. Cheers - Bill

1 0

FW: Notification: Inbound Mail Failure
by Postmaster 21 Nov '97

21 Nov '97

> ---------- > From: Postmaster > Sent: Friday, November 21, 1997 15:05 > To: Postmaster > Subject: Notification: Inbound Mail Failure > > The following recipients did not receive the attached mail. Reasons > are listed with each recipient: > > <nrm1838(a)crcc.disa.mil> nrm1838(a)crcc.disa.mil > MSEXCH:IMS:DOD:CRCC:CRCCNT04 0 (000C05A6) Unknown Recipient > <nrm0865(a)crcc.disa.mil> nrm0865(a)crcc.disa.mil > MSEXCH:IMS:DOD:CRCC:CRCCNT04 0 (000C05A6) Unknown Recipient > > The message that caused this notification was: > > > ----- Message-ID: <3.0.1.32.19971121135920.00917df0(a)mail.ctel.net> From: Sheryl Chapin <schapin(a)ctel.net> To: nanog(a)merit.edu Subject: CERT mailing list Date: Fri, 21 Nov 1997 13:59:20 -0500 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Hi all, Does anyone know how I would subscribe to the CERT mailing list? Thanks, Sheryl Chapin CommTel Internet 207.377.3508 schapin(a)ctel.net

1 0

The Cidr Report
by Tony Bates 21 Nov '97

21 Nov '97

1 0