- ripe-list - mailman.ripe.net

IMPROTANT: RIPE22 date change
by RIPE NCC Staff 04 Jul '95

04 Jul '95

Due to accomodation problems, the date of the 22nd RIPE meeting had to be changed from 2-4 October to 11-13 October. We apalogise for any inconvenience this may cause. There is no official announcement for RIPE22 out yet, but this seemed important enough to note already. Kind regards, Roderik Muit RIPE NCC

1 0

Re: New Document available: ripe-127
by christian.huitema＠sophia.inria.fr 03 Jul '95

03 Jul '95

A (At) 11:39 AM 30/6/95 +0200, RIPE NCC Document Annoucement Service ecrivait (wrote): >Content-Type: text/plain; charset="us-ascii" >Content-Description: Document Announcement > > >New/Revised RIPE Document Announcement >-------------------------------------- >A revised/new document is available from the RIPE document store. > >Ref: ripe-127 > >Short content description >------------------------- > >The RIPE NCC receives an increasing amount of questions >about the protability or provider independence >of address space. This document provides guidance to European Internet >registries concerning these issues. > Given that interest for these matters spreads well outside Europe, could you please consider submitting this as an informational RFC? Christian Huitema

2 1

New Document available: ripe-127
by RIPE NCC Document Annoucement Service 30 Jun '95

30 Jun '95

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-127 Title: Provider Independent vs Provider Aggregatable Address Space Author: Daniel Karrenberg, RIPE NCC Date: 30 Jun 1995 Format: PS=91858 TXT=17620 Obsoletes: Obsoleted by: Updates: ripe-126 Updated by: Old: Short content description ------------------------- The RIPE NCC receives an increasing amount of questions about the protability or provider independence of address space. This document provides guidance to European Internet registries concerning these issues. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-127.txt for the ASCII version ripe-127.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-127.txt

1 0

Heads-Up! (INFO#95.16723)
by Thomas Longstaff 29 Jun '95

29 Jun '95

-----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii ============================================================================= Heads-Up to Network Service Providers - IP Spoofing Attacks CERT Coordination Center June 29, 1995 ============================================================================== Over the past few weeks, we have received reports of 170 IP spoofing attacks against Internet sites internationally. We are sending you this "heads-up" because you are a likely target. At least 80 of the targets we know of are name servers, routers, and other network operation systems. The attacks have been largely successful, we continue to receive reports, and we are concerned that more attacks are going undetected. We urge you to check your systems and routers for any signs of compromise and to use the information in CERT advisory CA-95:01, "IP Spoofing Attacks and Hijacked Terminal Connections," to help protect yourself, detect IP spoofing attacks, and recover from root compromises. The advisory is available by anonymous FTP from ftp://info.cert.org/pub/cert_advisories This "heads-up" contains additional information about what you can do, as well as issues to consider before taking action. Please feel free to forward this to other providers of Internet services. Communicating with us - ---------------------- Warning: For sensitive information, use encrypted email. You will find the CERT public PGP key at the end of this document. We would appreciate it if you would let us know whether you are watching for IP spoofed packets on your networks (or plan to do so). If you see spoofed packets, we'd like to learn how many you see and from how many different sites; this will help us determine the scope and pattern of the attacks. We will keep all detailed information and the identity of organizations confidential. Because of our workload, we must ask you not to send log files of activity, but we would be happy to work with you as needed on how to interpret data that you may collect. If you see activity that indicates an attack is in progress, we encourage you to contact your customer, or other involved sites or their service provider. We have some general information on IP spoofing and on recovering from a compromise that we can make available to you for your customers' use. We would also be happy to provide guidance and advice, if needed, on how to handle incidents and work with law enforcement. ............................................................................. Some things you can do - ---------------------- It is possible to check network traffic for indications of the type of attack we are currently seeing. Before doing so, please look at the next section, "Issues to consider before taking action." There are several classes of packets that you could watch for. The most basic is any TCP packet where the network portion (Class A, B, or C or a prefix and length as specified by CIDR, the Classless Inter-Domain Routing specification) of the source and destination addresses are the same but neither are from your local network. These packets would not normally go outside the source network unless there is a routing problem, worthy of additional investigation, or the packets actually originated outside your network. The latter may occur with Mobile IP testing, but an attacker spoofing the source address is a more likely cause. For a NAP or NSP, the interface into which a packet arrived indicates the direction of the source of the attack. The packet's destination address indicates the "trusted" host involved in an attack. That information suggests which hosts may be under attack. There are public domain and vendor provided tools available for checking your networks for IP spoofed packets. Among them are Argus, tcpdump, and snoop. Argus 1.5 - --------- Argus is an IP network transaction-auditing tool developed at the Software Engineering Institute of Carnegie Mellon University. The Argus 1.5 distribution includes scripts that perform simple network administrative tasks, one of which is IP spoofing detection. The data that Argus generates makes it possible to analyze network activity and performance in ways that have not been possible before. For example, you can answer questions such as, "Were there any IP spoofing attempts into our firewall network over the past 8 hours?" The developers of Argus have made the tools available from ftp://ftp.sei.cmu.edu/pub/argus-1.5 If you have any questions, comments, or suggestions, please send mail to argus(a)sei.cmu.edu. Scripts - ------- At the end of this document ("Attachment A") are scripts you may want to use to check your network. We are aware that the Internet is now "classless," meaning that the old notion of class A, B, and C addresses is being replaced with a prefix and length notation, also known as CIDR. Even so, the scripts, which are based on classes, may be useful to some service providers. In all the IP spoofing incidents reported to us to date, we believe that the scripts would have shown the spoofed packets. (The problem here is that these scripts may either show other packets labeled as spoofed or not show true spoofed packets due to CIDR.) A standalone machine running tcpdump or equivalent should be able to run these scripts without affecting the performance of the local net. It may be possible to configure routers to do this check directly but we are not currently aware of any systems on which this is possible. .............................................................................. Issues to consider before taking action - --------------------------------------- Before writing this "heads-up," we consulted colleagues on other response teams, several network service providers, and other technical experts. They raised the following issues, and there surely are others you should consider before taking action. Technical and performance issues: - There may be too many "false positives." Two causes are mobile IP and misconfigurations; there may be other causes as well. - The feasibility of installing network monitors may depend on network topology. - It is not clear how many monitoring machines you would need to pinpoint the problem. - When the tcpdump and snoop scripts were tested on a dedicated Sun IPX connected to a T1, the impact on performance was only marginal. Long-haul tests with similar scripts do not have performance problems either. - Anything above a T1 is going to cause some performance problems (applications like tcpdump and snoop do not work very well at all on DS3 or FDDI interfaces). Legal issues: - - Some service providers believe that checking your network as we suggest is all right; others believe that there may be a problem. We urge you to check with your legal advisors about analyzing packet header information, analyzing traffic content to detect unauthorized activity, and analyzing internal traffic and customer-bound traffic. - - For US service providers, the Digital Telephony Bill of 1994 is relevant; in particular, check the amended provision found at 18 U.S.C. 2511(2) (a) (i), which permits an electronic communications service and its employees to ...intercept, disclose, or use that communication in the normal course of...employment while engaged in any activity which is a necessary incident to the rendition of...service or to the protection of the rights or property of the provider of that service.... .............................................................................. Attachment - Scripts for Checking Networks - -------------------------------------------- We have tested the following scripts on a recent version of tcpdump and snoop (192.9.200.0 would be replaced by the site's local net, of course): --- script for tcpdump --- #!/bin/sh tcpdump 'tcp and not dst net 192.9.200.0 and ( (ip[12]&0x80=0 and ip[12]=ip[16]) or (ip[12]&0xc0=0x80 and ip[12]=ip[16] and ip[13]=ip[17]) or (ip[12]&0xe0=0xc0 and ip[12]=ip[16] and ip[13]=ip[17] and ip[14]=ip[18]) )' (Note this only seems to work with tcpdump-3.0.2 and libpcap-0.0.6 currently.) --- script for snoop --- #!/bin/sh snoop 'tcp and not net 192.9.200.0 and ((ip[12]&0x80=0 and ip[12]=ip[16]) or (ip[12]&0xc0=0x80 and ip[12]=ip[16] and ip[13]=ip[17]) or (ip[12]&0xe0=0xc0 and ip[12]=ip[16] and ip[13]=ip[17] and ip[14]=ip[18]))' (Note that this does not appear to work with Solaris 2.3 machines.) To more accurately analyze network traffic, it is useful to first describe the network topology; for example: ---------------- | INTERNET | ---------------- | ---------- | | NETWORK | ---------------- | MONITOR | | ROUTER | ---------- ---------------- | | | | ----------------------------------------------------------------- |MAC-A |MAC-B |MAC-C --------- --------- --------- |ROUTER | |ROUTER | |ROUTER | --------- --------- --------- | | | | | | | | | | | | | | | | | | | | | | | | | | | Ca Cb Cc Cd Ce Cf Cg Ch Ci (MAC-A, MAC-B, and MAC-C refer to the ethernet addresses of the router interfaces attached to the same network as the network monitor machine.) In this case, the machine used to check network traffic could be any machine capable of running tcpdump, snoop, or any other packet capture and analysis software. This machine could be programmed so that any packets that match the following expression are displayed. tcp and ( not ether src MAC-A and ( src net Ca or src net Cb or src net Cc ) not ether src MAC-B and ( src net Cd or src net Ce or src net Cf ) not ether src MAC-C and ( src net Cg or src net Ch or src net Ci ) ) This expression looks at the source address of each packet and identifies those that did not originate from the correct interface. This example should be extensible to take CIDR into account. For example, if the CIDR specification of network Ca is 192.9.200/21, then the sub-expression: src net Ca should be replaced with: ip[12:4]&0xfffff800=192.9.200.0 .............................................................................. CERT Public Key - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAi2a4WoAAAEEAN0IPkqCmoGRud0Kts3g4ZGgZ4zyqY8C5VTOgUcqU+D2U1so 21K6dxj/lewKFduXtNpqDeg6C0wR6GIMJ2jWLU4GUEq0xHohioWGGg5O3QTvCpN3 rnLIKO9urv4Wjgkp1n1ys7xcOYl5jb7kuhdlXs3kNgKi4zBB5XVP+x0t4w7BAAUR tChDRVJUIENvb3JkaW5hdGlvbiBDZW50ZXIgPGNlcnRAY2VydC5vcmc+iQCVAgUQ LZrkOXVP+x0t4w7BAQEI3QP/d9gl7GD52Pd8KbsBMb0hiploigL8kZW1Q1fVsIm1 cO9xumU89CLf2jrN+IdrIMpVWAO3DyJjZooZTaJBg/9jjv3HltHTq/XFD5c+WYlM G+fQZVuR8qu8+D8P8pPbNVm94wxj9fyKO39/dnub1UfjDedJBtt+zgMJmstADkOv QBM= =N6E5 - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBL/MOmHVP+x0t4w7BAQF7+QQAp8mm5Bnu+/wiQK2trEn1JtzV6Ls3Z/gP 1SgZe85eTEGzKvRPKb+G3W7HAFn56B6X6JCgixl0Xgj/zcYlOvraug16/DfAd6i0 dkZXcrTQn+GRSHbi6oXPs5FRCE0eE5tFkhouVnROECBLoKJOR9/0dE4NuLzCkm3Q Uf+x64RmkIs= =RBqe -----END PGP SIGNATURE-----

1 0

hostcount for May 1995
by Mirjam Kuehne 02 Jun '95

02 Jun '95

Dear all, Here comes the hostcount for May 1995. The table shows an increase since last month of more than 80,000 hosts (6.4%) to a total of more than 1,400,000 hosts in the DNS in Europe. I wonder if we will hit the 1.5 million boundary next month :-) The UK shows the highest increase for May with almost 40,000 hosts more than the month before. This is almost half of the total increase. The hostcount can also be found under ftp.ripe.net/ripe/hostcount. Kind regards, Mirjam Kuehne RIPE NCC RIPE DNS Hostcount Previous Count : Sun Apr 30 1995 This Count : Wed May 31 1995 CY SOA COUNTED DUPL REAL CHANGE ============================================================ al 3 0 0 0 0 am 2 25 1 24 0 at 727 38198 829 37369 + 2292 az 3 16 0 16 0 be 494 21206 830 20376 + 197 bg 43 625 37 588 + 182 by 1 2 0 2 0 ch 457 58925 466 58459 0 cy 11 87 4 83 - 46 cz 252 15022 242 14780 + 477 de 3521 340024 12024 328000 +14656 dk 371 32746 528 32218 + 1240 dz 2 13 0 13 + 2 ee 91 2112 23 2089 + 295 eg 6 170 2 168 0 es 675 37913 604 37309 + 2858 fi 787 105358 2084 103274 - 307 fo 13 470 0 470 + 32 fr 1606 110920 1885 109035 +12223 gb 1 28 0 28 0 ge 1 0 0 0 0 gr 220 5193 469 4724 - 88 hr 101 2430 591 1839 + 86 hu 135 9324 48 9276 - 701 ie 143 8710 126 8584 + 101 il 337 17539 614 16925 + 956 is 113 6255 68 6187 + 295 it 1354 46325 3147 43178 + 3077 li 5 17 0 17 + 1 lt 26 247 2 245 + 16 lu 68 1227 13 1214 + 49 lv 28 892 19 873 + 88 ma 1 0 0 0 0 mk 3 2 0 2 + 2 mt 1 0 0 0 0 nl 905 117196 1791 115405 + 2936 no 1086 66465 2912 63553 + 6617 pl 537 15593 1236 14357 + 54 pt 192 7497 90 7407 - 10 ro 27 704 17 687 + 135 ru 192 3482 244 3238 + 438 se 1351 97917 2997 94920 - 1068 si 145 2983 100 2883 + 292 sk 92 2010 33 1977 + 262 su 311 7555 418 7137 + 432 tn 3 65 6 59 + 2 tr 101 3355 68 3287 + 543 ua 106 1399 219 1180 + 155 uk 4245 337203 26842 310361 +39125 va 0 0 0 0 0 yu 3 0 0 0 0 ============================================================ 20898 1525445 61629 1463816 +87896

1 0

New Document available: ripe-126
by RIPE NCC Document Annoucement Service 19 May '95

19 May '95

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-126 Title: RIPE handles and the 'status' attribute in the RIPE-database Author: RIPE NCC Date: 19 May 1995 Format: TXT=6896 Obsoletes: Obsoleted by: Updates: Updated by: Old: (newer RIPE-documents are numbered ripe-126 and up) Short content description ------------------------- This document describes two additions to the RIPE database, which were implemented during the last weeks that Marten Terpstra maintained the RIPE database software: RIPE-handles, and the status-attribute. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-126.txt for the ASCII version ripe-126.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-126.txt

1 0

IPv6-WG mailing list
by k13＠nikhef.nl 12 May '95

12 May '95

Dear RIPErs, As announced during RIPE-21, the new established ipv6 working group has a mailing list: ipv6-wg(a)ripe.net. To subscribe, please send a message with 'subscribe ipv6-wg' in the body to majordomo(a)ripe.net. Majordomo provides help by sending 'help' in the body of the message instead. The mailing list is archived at ftp://ftp.ripe.net/ripe/archives/ipv6-wg. Keep them messages coming :-) Rob Blokzijl

1 0

hostcount April 1995
by Mirjam Kuehne 04 May '95

04 May '95

Dear all, Here is the hostcount for April 1995. The table shows an increase since last month of almost 50,000 hosts (3.7%) to a total of almost 1,400,000 hosts in the DNS in Europe. This seems a bit low compared to the increase over the last two months. But remember the incident in the german domain in February. This domain is now stable and shows a reasonable increase in April. The nl domain with an increase of more than 15,000 hosts has the highest increase for April. The numbers for tr are quite high this month compared with the amount of hosts usually listed for this zone. The maintainer of the local hostcount for Turkey informed me about a major problem in this zone in March (the table listed a decrease of 890 hosts in March). The problems with this zone were fixed after I published the March hostcount. Therefore the hostcount was repeated. The figures for April illustrate the increase over the last two months now. I have included the March hostcount for Turkey in addition to the files for April in the ftp directory. Also Israel had connectivity problems in March (increase of 0 in). The current table contains the increase for March and April. The hostcount can also be found under ftp.ripe.net/ripe/hostcount. Regards, Mirjam Kuehne RIPE NCC RIPE DNS Hostcount Previous Count : Fri Mar 31 1995 This Count : Sun Apr 30 1995 CY SOA COUNTED DUPL REAL CHANGE ============================================================ al 3 0 0 0 0 am 2 25 1 24 0 at 684 35773 696 35077 + 1435 az 3 16 0 16 0 be 470 20560 381 20179 + 550 bg 28 438 32 406 - 30 by 1 2 0 2 0 ch 457 58925 466 58459 + 1019 cy 14 135 6 129 + 124 cz 241 14538 235 14303 + 541 de 3268 326215 12871 313344 + 9552 dk 346 31505 527 30978 + 1452 dz 2 11 0 11 0 ee 76 1807 13 1794 + 87 eg 6 170 2 168 0 es 635 35056 605 34451 + 1731 fi 854 105390 1809 103581 + 6758 fo 13 438 0 438 0 fr 1385 98519 1707 96812 - 5986 gb 1 28 0 28 + 1 ge 1 0 0 0 0 gr 210 5203 391 4812 + 760 hr 95 2196 443 1753 + 386 hu 132 10029 52 9977 + 360 ie 137 8598 115 8483 + 970 il 296 16555 586 15969 + 1898 is 107 5952 60 5892 + 847 it 1235 42848 2747 40101 + 2284 li 4 16 0 16 0 lt 26 229 0 229 + 42 lu 64 1179 14 1165 + 232 lv 29 805 20 785 + 22 ma 1 0 0 0 0 mk 2 0 0 0 0 mt 1 0 0 0 0 nl 831 114205 1736 112469 +15929 no 1001 59313 2377 56936 + 1441 pl 528 15478 1175 14303 + 850 pt 167 7500 83 7417 + 564 ro 28 589 37 552 + 33 ru 268 3121 321 2800 - 477 se 1275 99000 3012 95988 + 2631 si 95 2675 84 2591 + 137 sk 87 1747 32 1715 + 35 su 315 7107 402 6705 + 618 tn 3 63 6 57 0 tr 97 2804 60 2744 + 2696 ua 97 1203 178 1025 + 63 uk 2605 294774 23538 271236 + 250 va 0 0 0 0 0 yu 3 0 0 0 0 ============================================================ 18229 1432740 56820 1375921 +49805

1 0

NIDUS Working Group
by Nandor Horvath 04 May '95

04 May '95

Dear friends, About two years ago it seemed to be a good idea to form a working group which would deal with subjects of the network information/user services area (NIDUS WG). Since then the working group met several times, but not on all RIPE meetings, only if we found some topics to discuss. At start-up we decided that we did not want to start concurrent activities to the other existing groups in this field. There were very few people coming to the WG sessions, probably because there were much more important tasks to do, like PRIDE, etc. I think, that the only useful thing this WG did was, that we kept an eye on the activitis of the other groups in this field, like Joyce's reports about the IETF User Services Area. If the RIPE community hasn't got any strong objection against it, I'll suggest to quit the NIDUS WG, as it is now. We could resereve some time during the plenary session for reports of other groups/activities in the network information/user services area though, as many of us found such reports quite useful and interesting. Best regards, Nandor Horvath

1 0

Informal IETF Report
by Jill.Foster＠newcastle.ac.uk 04 May '95

04 May '95

Apologies if you receive more than one copy of this message. IETF - Danvers: April 3rd - April 7th, 1995 ============================================ Trip Report: Jill Foster - Newcastle University, UK UK Mailbase Manager Abstract ======== The IETF (Internet Engineering Task Force) met in Danvers near Boston. An informal report is available which deals mainly with the areas of User Support and Networked Information Retrieval. (It is shorter than my previous reports and contains fewer URLs due to a change in my own work roles. I no longer work for TERENA on a part time basis and my own "volunteer" effort is now committed elsewhere.) This report is stored on the UK Mailbase Server. To retrieve a copy, email to Mailbase(a)mailbase.ac.uk with the following command in the body of the message: send wg-isus ietf.04.95 Alternatively use anonymous ftp to: mailbase.ac.uk ftp://mailbase.ac.uk/pub/lists/wg-isus/files/ietf.04.95 Jill

1 0