- Test - lists.nanog.org

Registration -- NANOG 19 -- Albuquerque
by Carol Wadsworth 17 Apr '00

17 Apr '00

Greetings, This is just a reminder that registration is now open for the Spring NANOG 19 meeting, June 11-13, 2000, at the Hyatt Regency Albuquerque in New Mexico. You can register online via the NANOG web page and make your hotel reservation online too. For your convenience, here are the direct URL's: Meeting Registration: https://www.merit.edu/nanog/registration.form.html Hotel Reservations: http://www.hyatt.com/albuq/g-nano/index.html Hotel Note: The special, negotiated group rate for NANOG 19 is $139. Room upgrades are also available, at an increased rate. For rates and options, see details online. Also, if you are interested in presenting at the meeting, details regarding the "Call for Presentations" can be found at: http://www.nanog.org/mtg-0006/call19.html -or- http://www.nanog.org/mtg-0006/call19.pdf Hope to see in Albuquerque! Carol Wadsworth Merit Network, Inc.

1 0

dsau-02
by Bill Manning 17 Apr '00

17 Apr '00

a bit late but here is #2 ---------------------------------------------------- INTERNET-DRAFT draft-manning-dsua-02.txt Bill Manning ISI 17 April 2000 Documenting Special Use IPv4 Address Blocks that have been registered with IANA 1. Status of this Memo This draft, file name draft-manning-dsua-02.txt, is intended to become something that might be of use to those who are interested in the operational requirements of an IPv4 based network. Distribution of this document is unlimited. Comments should be sent to the author. This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. PREAMBLE: This document lists the existent special use prefixes from the IPv4 space that have been registered with the IANA and provides some suggestions for operational procedures when these prefixes are encountered. This document does not address IPv4 space that is reserved for future delegation in the operational Internet. The current list of special use prefixes: 0.0.0.0/8 127.0.0.0/8 192.0.2.0/24 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16 all D/E space 2.1 Prefix Discussion: 0.0.0.0/8 has a number of unique properties, many of which were built into the protocol stacks used throughout the Internet. 0.0.0.0/32 or the all-zeros address has been used and is still recognized as the historical broadcast address. This use or restriction is deprecated and modern code will treat broadcast correctly as an all-ones value within the subnet. It is fairly common practice to use 0.0.0.0 to encode the idea of "default". Also, many stacks will allow the system administrator to encode IP addresses of the form 0.0.160.57, with the presumption that historical, "natural" masks apply and so this would represent a host that carries the local value of x.x.160.57 within the /16 net-block that is in use on that media. These properties suggest that a prudent network manager & system admin will treat 0.0.0.0/8 as a special use net-block. Router and Host requirements documents and implementations treat this range with special use constraints. 127.0.0.0/8 is earmarked for what is called "loop-back". This construct is to allow a node to test/validate its IP stack. Most software only uses a single value from this range, 127.0.0.1/32 for loop-back purposes. It is treated with the same levels of restriction by router and host requirements and implementations so it is difficult to use any other addresses within this block for anything other than node specific applications, generally bootstrapping. All in all a tremendous waste of IP space. Good thing we'll not likely need it. 192.0.2.0/24 is listed as the TEST-NET. This prefix is earmarked for use in documentation and example code. Network operations and End System administrators should ensure that this prefix is not coded into systems or routed through any infrastructure. Since it has the appearance of a "normal" prefix, special precautions should be taken to ensure that this prefix is not propagated in either the Internet or any private networks that use the IP protocols. Often used in conjunction with example.com or example.net in vendor and protocol documentation. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 are the prefixes called out in RFC 1918. They are only for use in private networks that wish to use the IP protocols. Network operations and End System administrators should ensure that applications do not use these ranges as source or destination addresses for any packets that traverse the Internet infrastructure. Since they have the appearance of "normal" prefixes, special precautions should be taken to ensure that they are not propagated in the Internet. 169.254.0.0/16 has been ear-marked as the IP range to use for end node auto-configuration when a DHCP server may not be found. As such, network operations and administrators should be VERY aggressive in ensuring that neither route advertisements nor packet forwarding should occur across any media boundaries. This is true for the Internet as well as any private networks that use the IP protocols. End node administrators should be aware that some vendors will auto-configure and add this prefix to the nodes forwarding table. This will cause problems with sites that run router discovery or deprecated routing protocols such as RIP. Class D & E space. These are parts of the IPv4 space that retain some context of class-fullness. They are used for identification of multicast and a range left unspecified. This extract from RFC 1166 covers these ranges. The fourth type of address, class D, is used as a multicast address [13]. The four highest-order bits are set to 1-1-1-0. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0| multicast address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class D Address Note: No addresses are allowed with the four highest-order bits set to 1-1-1-1. These addresses, called "class E", are reserved. As a side note, at least one vendor has hijacked an address range for use by its printservers. That range is 192.0.0.0/24 and the specific address that they use is 192.0.0.192/32. This is not a valid delegation to this vendor and its use argues for re-constitution of this service into the link-local range or configurable with site delegated space. 3. DNS considerations: None of these address prefixes is to be used or visible on the public Internet. In fact, some of these prefixes must not appear outside the machine. To encourage honesty, most of these prefixes have been mapped to authoritative servers in the DNS. This encourages people to ensure that when used, these prefixes are coded with local-scope DNS and there will be no "leakage" to the global Internet. 4. Access Control suggestions: In todays network, it is prudent to control access. In the case of these special use prefixes, it is generally a good idea to filter them so they do not propagate. After all, you don't want someone else's use of these prefixes to taint your environment. All of these address classes should be invalid as source addresses (except where negotiated in advance), and very few should be permitted as destination addresses (Multicast for example, should be permitted as a designation, just not as a source). An example of one form of access control is listed below: ... access-list 100 deny ip host 0.0.0.0 any access-list 100 deny ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 100 deny ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 100 deny ip 172.16.0.0 0.15.255.255 255.240.0.0 0.15.255.255 access-list 100 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 100 deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 100 deny ip 169.254.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 100 deny ip 240.0.0.0 7.255.255.255 any access-list 100 permit ip any any ... 5. Security Considerations: Use of most of these special use prefixes open up significant opportunities for anonymity and ambiguity. People, being what they are, will hide behind ambiguous or nebulous identities to do things that are antisocial and downright hostile. It would be nice to have better authentication methods in play than an IP address which has lost its global uniqueness. 6. References: [DHC-IPV4-AUTOCONFIG] - R. Troll, Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network, Internet draft, draft-ietf-dhc-ipv4-autoconfig-04.txt, October 1998 [RFC1918] Y. Rekhter et.al., Address Allocation for Private Internets, February 1996, RFC 1918 [RFC1122] R. Braden, Requirements for Internet Hosts -- Communication Layers, October 1989, RFC 1122 [RFC1166] S.Kirkpatrick et.al, INTERNET NUMBERS, July 1990, RFC 1166 [RFC1812] F. Baker, Requirements for IP Version 4 Routers, June 1995, RFC 1812 [RFC2267] P. Ferguson, D. Senie, Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, January 1998, RFC 2267 [NET-TEST] Netname: IANA, Netnumber: 192.0.2.0, Coordinator: Internet Assigned Numbers Authority, 1993 [LOOPBACK] Netname: LOOPBACK, Netnumber: 127.0.0.0, Coordinator: Internet Assigned Numbers Authority, 1972 [RESERVED-1] Netname RESERVED-1, Netblock: 0.0.0.0 - 0.255.255.255, Coordinator: Internet Assigned Numbers Authority, 1972 8. Author's Address Bill Manning USC/ISI 4676 Admiralty Way, #1001 Marina del Rey, CA. 90292 USA bmanning(a)isi.edu 310.822.1511 -- "When in doubt, Twirl..." -anon

1 0

Making money from both sides
by Sean Donelan 17 Apr '00

17 Apr '00

It really is a net. Both the International Monetary Fund (IMF.INT) and Mobilization for Global Justice (A16.ORG) go through the backbone Internet via Cable&Wireless.

1 0

Re: NetSol screwing the pooch?
by Vadim Antonov 15 Apr '00

15 Apr '00

> NSI's been screwing the pooch so long, it's surprising we're not all > knee deep in puppies! I find it amusing that large ISPs tolerate NSI for so long despite the enormous costs its incompetence imposes on their businesses. Now the bunch of self-proclaimed rule-setters called "ICANN" is going to screw them even more. I would think that these large ISPs should form the consortium and finally build a normal registry database; they already have infrastructure for customer service, and offer their customers assistance with domain registration. There is no need for independent registries. Customers wishing to register a domain should simply talk to their ISPs whose personnel can then go and update the consortium-owned database. Oh, and BTW, they _already_ have the contact info for their customers, so they do not depend on the NSI-claimed "ownership" of that information. And, unlike NSI or other registries, they can actually verify that information - and they have a pretty simple method of dealing with abusive customers. This approach scales, it can improve domain-related customer service by an order of magnitude, and it does not require any political games. Despite the cut-throat competition in the market, ISPs managed to maintain a coherent and functioning global routing infrastructure. The DNS is as essential for their customers as the actual packet transport; so i think it is time for competent people to take over it, too. Now, the question is when the ISP managers will wake up and get a clue. --vadim

6 8

RE: NetSol screwing the pooch?
by Sean Donelan 15 Apr '00

15 Apr '00

Sorry, I mushed the two together. I was thinking of the .COM, .NET, .ORG gTLDs moving to identical servers operated solely by NSI technicians. On Sat, 15 April 2000, Daniel Karrenberg wrote: > At 05:04 15-4-00 , Sean Donelan wrote: > >I'm a bit concerned when I read about a plan to install identical > >servers, with identical configurations, with identical software, > >connected to identical routers also with identical software and > >configurations, operated by a single human point of contact. > > I am not aware of any such plans for the DNS root servers. > Diversity is good in this area.

1 0

Serbian spoof of NSI
by Henry R. Linneweh 15 Apr '00

15 Apr '00

NSI Serbian 'hack' is simple email spoof http://www.theregister.co.uk/000414-000021.html -- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

1 0

RE: NetSol screwing the pooch?
by Sean Donelan 15 Apr '00

15 Apr '00

> So in every case where NSI operates the host NS for COM, you > should see that the serialization is correct. In those cases > where a traditional root server still serves COM, should > they get out of synch, our NOC contacts them to encourage > resolution. However, as the host is not an NS operated by NSI, > beyond encouraging them to fix the problem, there is little we > can do. This is part of the reason for moving COM off of the > traditional roots in just the same fashion as other first > level delegations are managed today. If we use history as a guide, the network-wide problems with DNS have usually been related to problems at the central source which were then copied out to the slaves. Problems with the slaves, although perhaps more frequent than we would like, have generally affected different slaves in different ways at different times. I'm a bit concerned when I read about a plan to install identical servers, with identical configurations, with identical software, connected to identical routers also with identical software and configurations, operated by a single human point of contact. Its bad enough all the roots use BIND. The lack of genetic diversity makes things very vulnerable to common errors.

1 0

AT&T national cable outage
by Sean Donelan 15 Apr '00

15 Apr '00

According to AT&T's cable service recording, AT&T Cable Services is experiencing a national outage with their digital cable service. Since I don't have cable @Home, I can't tell if it is only affecting the video services or also the Internet service.

3 2

Re: NSI's registrar db hacked
by Rodney Joffe 15 Apr '00

15 Apr '00

bill(a)daze.net wrote: > Nothing new here. Network Solutions has known about the MAIL-FROM problem > for years, yet they refuse to do anything about it. Doh. Didn't realize it was the same old thing. This seems like such a trivial problem to solve... a) force guardian (crypt-pw seems the most reliable) on all new domain registrations b) with NSI's next spam to their customer database, lead people forcibly to guardian (crypt-pw again) c) use a mail system that scales, so that 1 week delays don't happen. One good thing I've noticed in the last week or so - if someone attempts to register a domain, or modify a domain, to use your nameservers, your nameserver contacts get an email. Of course, in typical NSI style, the email is non-intuitive. And in typical NSI style, although it says you must "ack" for it to go through, it goes through anyway. But it's a start... at least you know that someone is trying to use your dns. -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(SM)

5 5

Re: DVWSSR.dll Vulnerability in Microsoft IIS 4.0 Web Servers (fwd)
by Vincent Power 14 Apr '00

14 Apr '00

-- +---------------------------------+-----------------------+ | Vincent Power | mailto:vince@mha.ca | | Senior System Administrator | Cell: +1 604 817 4284 | | Macdonald Harris and Associates | http://www.mha.ca/ | +---------------------------------+-----------------------+ ---------- Forwarded message ---------- Date: Fri, 14 Apr 2000 15:32:52 -0400 From: Russ <Russ.Cooper(a)RC.ON.CA> To: NTBUGTRAQ(a)LISTSERV.NTBUGTRAQ.COM Subject: Re: DVWSSR.dll Vulnerability in Microsoft IIS 4.0 Web Servers Ok, here's a breaking update. Latest reports say that there is NO VULNERABILITY IN DVWSSR.DLL Yup, that's right, different again from what I said earlier, and even more different than what I said yesterday to WSJ. Please accept that I have followed the story published elsewhere and tried to keep you abreast of everything I knew. Also appreciate that the amount of time given to verify and research the claims made by others has been extremely short. I've had probably 30 interviews today by orgs pressing for information on the story as the feeding frenzy occurs after the first one goes to press (WSJ in this case). MS have had people working on this thing like madmen, trying to verify the claims and investigate all of the possible pieces of code that may be affected. As that research progressed, different observations were made and so the story came out in various stages (with varying levels of "correctness"). Had they been given a reasonable amount of time to respond, nobody would have been in a tizzy about anything (i.e. the press would not have cared to run this story anywhere). Decide for yourself whether we were better served by (more) immediate disclosure or not. I've stood where I stand for a reason, despite the loathing of others for my stance... In the end, it turns out that unless you actually have permissions for the file you are requesting, you'll get an error message when you follow the procedures outlined by RFP in his RFP2K02 advisory. That said, understand that sites that allow connections by Front Page may very well provide you with source asp if you request it. BUT THAT WILL HAPPEN with or without the .dll. Without proper and full permissions applied across virtual servers on a given box, site leakage or manipulation by others will always be possible in myriad ways. >From what I've heard/seen/been told, permissions on the test servers must have either been non-existent, incorrectly applied, or permissioned the user across multiple virtual sites (i.e. incorrectly applied). I had someone claim that they could get into an FP98 site using "Netscapeengineersareweenies!" as a userID and no password...making them think it was a backdoor userID. Fact is they could get into the same sites using "TomDickandHarry" as a userID too. If the permissions aren't set correctly, anything is possible. This info may change again before its finalized. It may well be that there is some way to use this .dll in a way that's not intended...it just doesn't appear to be this one. On a box where multiple sites have not been individually permissions, or permissions are lax or non-existent...anyone permissioned to execute the .dll in the first place would have the ability to simply open the other sites and manipulate them directly (i.e. no need to do this junk with the dvwssr.dll) Finally, to my point out the string not being a password. Elias Levy of SecurityFocus.com and Mark Edwards of NTSecurity.net have both correctly pointed out that using the term password to apply to that string is not beyond the realm of understanding. The client component mtd2lv.dll and the server component dvwssr.dll both need to know this value, and use it correctly, for communications to work. If you try and talk directly to dvwssr.dll and don't obfuscate your communication with the correct "key", it won't understand you. Of course if you don't already have permissions, knowing this value gets you nothing...hence my observation that its not a password. Whatever it is, it appears to be meaningless junk text used as data. Cheers, Russ - NTBugtraq Editor "dot-age" (as in "we're in the dot-age") = senility (source Webster's)

1 0