- ripe-list - mailman.ripe.net

RIPE25: Hotels
by RIPE NCC Staff 26 Jul '96

26 Jul '96

Hotel information Rooms have to be reserved by the participants themselves. Below you find a list of hotels you can contact to find a room. You can also: - for more information, look at http://www.nbt.nl/holland/hotels/ho-pa - contact: National Reservations Centre P.O. Box 404 NL-2260 AK LEIDSCHENDAM tel. +31 70 320 2500 fax +31 70 320 2611 -------------- <> All phone numbers below require the prefix 31 20 <quoted number>. <> All tram connections are from central station. <> Data are subject to change, please check first Low budget hotels (price range 90-120 Hfl): Name Adress Phone Fax Tram Barbacan Plantage Muidergracht 89 6236241 6272041 9 Lancaster Plantage Middenlaan 48 6266544 6226628 9 Somewhat more expensive but located near the Central Railway Station (price range 185-210 Hfl): Hotel Ibis Stationsplein 49 6383080 6200156 Recommended by Chris Jones: Mercure Arthur Frommer Noorderstraat 46 6220328 6203208 16/24/25 The following hotels can be booked at: AMS Booking Center P.O.Box 60011 1005 GA Amsterdam The Netherlands phone: 6831811 fax: 6160320 telex: 14275 single/ Phone Fax Tram double Museum *** 170/244 P.C. Hooftstraat 2 6621402 6733918 5 Trianon *** 170/244 J.W. Brouwerstraat 3-7 6732073 6738868 16 Terdam *** 170/244 Tesselschadestraat 23 6126876 6838313 5 Holland *** 170/244 P.C. Hooftstraat 162 6764253 6765956 5 Beethoven **** 190/280 Beethovenstraat 43 6644816 6621240 24 Lairesse **** 240/280 De Lairessestraat 5-7 6719596 6711756 16 Karena Hotels Group (all centrally located) ------------------- Doelen ) Caransa ) -- Central Reservation number 626 2922 626 6831 Rembrandt ) Schiller ) If RIPE people want to benefit from the cheap rate of NLG 170 at any of those four hotels, then they have to ask the TERENA Secretariat to make the reservation for them. The TERENA secretariat is reachable at : E-mail: secretariat(a)terena.nl tel: +31206391131

1 0

European Cache Coordination
by martin＠terena.nl 26 Jul '96

26 Jul '96

Apologies in advance for cross-posting. Analysis of network traffic on the Internet has shown that significant savings can be made if local caches are introduced and these are linked to form a "caching hierarchy". Much work has been carried out on the development of caching software and many institutions and networks already implement caching at various levels. It is vitally important to coordinate the construction and maintenance of these caching hierarchies and, after being approached by various bodies, TERENA has decided to investigate the possibility of setting up a caching task force. Note that the technology for caching is being developed elsewhere and is therefore not the subject of this initiative. Rather, TERENA intends to promote the usage and coordination of caching at the local, national and international level to produce a more efficient, cost-effective and above all reliable service for the users of research networks in Europe. The objectives of this task force are therefore initially: i promote and coordinate the deployment of caching hierarchies in Europe ii linking these with initiatives in the US (NLANR) iii coordination with other work on caching in Europe (DESIRE, INSIGHT, etc) iv providing documentation, information and assistance for those wishing to start a caching service though these are, of course, subject to change if the task force so decides. As a kick off, we have created a task force mailing list for those interested. If you would like to join, send a message to: mailserver(a)terena.nl containing only the text: subscribe tf-cache Your Real Name replacing "Your Real Name" as appropriate. Alternatively, if you already have a national-level mailing list and would prefer to add this, please send a message to tf-cache-request(a)terena.nl. TERENA task forces and working groups are open to all. Please contact me if you have any queries/comments or see http://www.terena.nl/tech/projects/choc/ for more details. Feel free to forward this to any parties you think might be interested. Regards, John Martin TERENA

1 0

New Document available: ripe-139
by RIPE NCC Document Annoucement Service 26 Jul '96

26 Jul '96

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-139 Title: RIPE Network Coordination Centre Annual Report 1995 Author: C. Orange Date: 25 July 1996 Format: PS=94820 TXT=17716 bytes Obsoletes: Obsoleted by: Updates: Updated by: See also: ripe-113 Short content description ------------------------- The RIPE NCC Annual Report for 1995 has now been published. In this report, we provide a summary of our income, activities and expenditure during the 1995 calendar year. Carol Orange RIPE NCC 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-139.txt for the ASCII version ripe-139.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-139.txt

1 0

IAB/IESG Statement on Cryptography
by Daniel Karrenberg 25 Jul '96

25 Jul '96

Dear Colleagues, security and the use of cryptography is a major issue for further development of the Internet. The statement below is very well done and quite comprehensive. It should be distributed widely and especially to any policymaker you know. I also propose that RIPE formally endorse this statement as soon as possible. Daniel ------- Forwarded Message Date: Wed, 24 Jul 1996 08:21:59 +0200 (MET DST) From: Brian Carpenter CERN-CN <brian(a)dxcoms.cern.ch> Sender: ietf-request(a)ietf.org To: ietf(a)ietf.org Subject: IAB/IESG statement on cryptography IETF, FYI, the IAB and IESG have just requested the Internet Society to release the attached statement to the press on our behalf. (The copyright tag at the end is purely to protect the text against misuse.) We intend to publish this as an informational RFC for the record. Brian Carpenter - --- IAB and IESG statement on cryptographic technology and the Internet - ------------------------------------------------------------------- July 24, 1996 The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. Security mechanisms being developed in the Internet Engineering Task Force to meet these needs require and depend on the international use of adequate cryptographic technology. Ready access to such technology is therefore a key factor in the future growth of the Internet as a motor for international commerce and communication. The IAB and IESG are therefore disturbed to note that various governments have actual or proposed policies on access to cryptographic technology that either: (a) impose restrictions by implementing export controls; and/or (b) restrict commercial and private users to weak and inadequate mechanisms such as short cryptographic keys; and/or (c) mandate that private decryption keys should be in the hands of the government or of some other third party; and/or (d) prohibit the use of cryptology entirely, or permit it only to specially authorized organizations. We believe that such policies are against the interests of consumers and the business community, are largely irrelevant to issues of military security, and provide only a marginal or illusory benefit to law enforcement agencies, as discussed below. The IAB and IESG would like to encourage policies that allow ready access to uniform strong cryptographic technology for all Internet users in all countries. The IAB and IESG claim: The Internet is becoming the predominant vehicle for electronic commerce and information exchange. It is essential that the support structure for these activities can be trusted. Encryption is not a secret technology monopolized by any one country, such that export controls can hope to contain its deployment. Any hobbyist can program a PC to do powerful encryption. Many algorithms are well documented, some with source code available in textbooks. Export controls on encryption place companies in that country at a competitive disadvantage. Their competitors from countries without export restrictions can sell systems whose only design constraint is being secure, and easy to use. Usage controls on encryption will also place companies in that country at a competitive disadvantage because these companies cannot securely and easily engage in electronic commerce. Escrow mechanisms inevitably weaken the security of the overall cryptographic system, by creating new points of vulnerability that can and will be attacked. Export controls and usage controls are slowing the deployment of security at the same time as the Internet is exponentially increasing in size and attackers are increasing in sophistication. This puts users in a dangerous position as they are forced to rely on insecure electronic communication. TECHNICAL ANALYSIS - -------------------------- KEY SIZE It is not acceptable to restrict the use or export of cryptosystems based on their key size. Systems that are breakable by one country will be breakable by others, possibly unfriendly ones. Large corporations and even criminal enterprises have the resources to break many cryptosystems. Furthermore, conversations often need to be protected for years to come; as computers increase in speed, key sizes that were once out of reach of cryptanalysis will become insecure. PUBLIC KEY INFRASTRUCTURE Use of public key cryptography often requires the existence of a "certification authority". That is, some third party must sign a string containing the user's identity and public key. In turn, the third party's key is often signed by a higher-level certification authority. Such a structure is legitimate and necessary. Indeed, many governments will and should run their own CAs, if only to protect citizens' transactions with their governments. But certification authorities should not be confused with escrow centers. Escrow centers are repositories for private keys, while certification authorities deal with public keys. Indeed, sound cryptographic practice dictates that users never reveal their private keys to anyone, even the certification authority. KEYS SHOULD NOT BE REVEALABLE The security of a modern cryptosystem rests entirely on the secrecy of the keys. Accordingly, it is a major principle of system design that to the extent possible, secret keys should never leave their user's secure environment. Key escrow implies that keys must be disclosed in some fashion, a flat-out contradiction of this principle. Any such disclosure weakens the total security of the system. DATA RECOVERY Sometimes escrow systems are touted as being good for the customer because they allow data recovery in the case of lost keys. However, it should be up to the customer to decide whether they would prefer the more secure system in which lost keys mean lost data, or one in which keys are escrowed to be recovered when necessary. Similarly, keys used only for conversations (as opposed to file storage) need never be escrowed. And a system in which the secret key is stored by a government and not by the data owner is certainly not practical for data recovery. SIGNATURE KEYS Keys used for signatures and authentication must never be escrowed. Any third party with access to such keys could impersonate the legitimate owner, creating new opportunities for fraud and deceit. Indeed, a user who wished to repudiate a transaction could claim that his or her escrowed key was used, putting the onus on that party. If a government escrowed the keys, a defendant could claim that the evidence had been forged by the government, thereby making prosecution much more difficult. For electronic commerce, non-repudiation is one of the most important uses for cryptography; and non-repudiation depends on the assumption that only the user has access to the private key. PROTECTION OF THE EXISTING INFRASTRUCTURE In some cases, it is technically feasible to use cryptographic operations that do not involve secrecy. While this may suffice in some cases, much of the existing technical and commercial infrastructure cannot be protected in this way. For example, conventional passwords, credit card numbers, and the like must be protected by strong encryption, even though some day more sophisticated techniques may replace them. Encryption can be added on quite easily; wholesale changes to diverse systems cannot. CONFLICTING INTERNATIONAL POLICIES Conflicting restrictions on encryption often force an international company to use a weak encryption system, in order to satisfy legal requirements in two or more different countries. Ironically, in such cases either nation might consider the other an adversary against whom commercial enterprises should use strong cryptography. Clearly, key escrow is not a suitable compromise, since neither country would want to disclose keys to the other. MULTIPLE ENCRYPTION Even if escrowed encryption schemes are used, there is nothing to prevent someone from using another encryption scheme first. Certainly, any serious malefactors would do this; the outer encryption layer, which would use an escrowed scheme, would be used to divert suspicion. ESCROW OF PRIVATE KEYS WON'T NECESSARILY ALLOW DATA DECRYPTION A major threat to users of cryptographic systems is the theft of long-term keys (perhaps by a hacker), either before or after a sensitive conversation. To counter this threat, schemes with "perfect forward secrecy" are often employed. If PFS is used, the attacker must be in control of the machine during the actual conversation. But PFS is generally incompatible with schemes involving escrow of private keys. (This is an oversimplification, but a full analysis would be too lengthy for this document.) CONCLUSIONS - -------------------------- As more and more companies connect to the Internet, and as more and more commerce takes place there, security is becoming more and more critical. Cryptography is the most powerful single tool that users can use to secure the Internet. Knowingly making that tool weaker threatens their ability to do so, and has no proven benefit. - ---- The Internet Architecture Board is described at http://www.iab.org/iab The Internet Engineering Task Force and the Internet Engineering Steering Group are described at http://www.ietf.org - ---- (C) Internet Society 1996. Reproduction or translation of the complete document, but not of extracts, including this notice, is freely permitted. (ends) ------- End of Forwarded Message

1 0

Re: Bit tax
by Dave Morton 24 Jul '96

24 Jul '96

Hmm - in the Group of Experts this Soete character is associated with - guess who..... Mr. Luc Soete MERIT Must be a different organistation that the MERIT we know :-) Dave

2 1

Bit tax
by Michael Walsh 24 Jul '96

24 Jul '96

The bit tax is not just evidence of Belgian ministerial sense of humour. Refer to the EU ISPO server for information on the recent advice to the EU on the matter. The report is at http://www.ispo.cec.be/hleg/hleg.html A recent edition of New Scientist did a 2 page spread on the subject, referencing European and US thinking, and noting some existing practices in the US, Canada and Germany. Regards, Michael Walsh. http://www.ispo.cec.be/hleg/bittax.html > Internet and its taxation > > Question: > > Dear Soete > my name Gabriel and I come from Italy. If you know the Italian > situation about Internet's phoenomenon, you'll comprehend the reason I > have had to write you. I think it isn't only a problem regarding our > Italians but even all the others and the same Internet. I have heard > you want to tax Internet providers and the eletronic mail. With all > honesty, I had imagined this thing; You'll have thought:" If people > use more fax and Internet e-mail to mail their letters and what must > be sent, we must tax Internet". I don't know if you'll have thought in > this way, but, even if it's true or false, this decision of taxing > Internet, is mistaken. > > Look at Internet and think about it; it's our future; a future made by > the digital era. Internet has grown for three reasons: its freedom, > its cheapness; and its confort. The most important factor is the > second; in fact it's enough if we must pay a provider and the phone; > if you'll tax Internet, there will be not many to have this privilege. > > If you'll tax e-mail there will be less people, and less letters, and, > on this way, less initiatives; Without these initiatives, at the end, > Internet will die and I don't think you want this. > > I want you think about your decision, because, even if you don't > believe it, Internet destiny is on your hands. > > Gabriel alopex(a)iol.it > > ---------------------------------------------------------------------- > > Asnwer: > > Dear Gabriele, > Thanks for your message. Obviously, I fully understand your concerns. > Let me simply explain what we are suggesting. First, we are not > proposing that a bit tax be introduced, only that one would study the > feasability of such a tax, the impact it would have on e.g. INTERNET > use, on competitiveness, etc. If having studied it, it looks as if any > form of bit tax would dramatically reduce use as you suggest is the > case, then of course one should refrain from introducing such taxing > system. In other words, we are keeping a completely open mind about > it, however, I cannot imagine why people would be against the idea of > studying its feasability and possible impact. > > Second, the reason why a bit tax might be an interesting new tax > concept is in the first instance based on the fact that more and more > economic activity is taking place through electronic transmission of > bits. In other words if society is moving into the direction of an > Information Society, the tax basis of society should also shift in > that direction. Otherwise we would have ended up today with only the > "corn tax" of 150 years ago to pay for all government expenditures. > > Third, as in the case of the environment (e.g. free clean air), there > will be in the case of "free" information, "negative externalities > under the form of "information pollution". Forcing the provider or > user of information to pay a small tax per bit, will force them to > generate at least some value, which might consequently reduce the > amount of overinformation. > > Fourth our proposal is to use the income generated through the bit tax > to reduce the cost of labour in the economy, e.g. through reducing the > employers social security contributions. The impact on growth and > employment will in all likelihood be substantial, which is at the > moment what frustrates us most, i.e. that the emerging Information > Society is creating so little value in our economies and so few jobs. > > Finally, let me add that with respect to education establishments, > hospitals, community services, etc., one could easily imagine that > those would all be excluded from having to pay a bit tax or > alternatively would get the amount back on the basis of some new > concept of unversal "community" service. In other words, the desire of > many users to use Internet to communicate cheaply would still be > maintained. However, they wouldn't be able to do this from their work, > home or commercial surroundings, but would have to go to their local > community service. > > I hope this clarifies my position, > with best regards, > Luc Soete

2 1

Re: Tools for managing IP address space
by Willi Huber 20 Jul '96

20 Jul '96

> >does anybody of you use some tool to managed IP address space in a classless > >environment for a bigger organization? > > Willi > have you seen Nigel Titley's 'tree' programme - it might > be what you want. Find it at > > ftp://ftp.bt.net/networking/tools/tree/tree-2.1.5.tar.Z > > Cheers. > > Mike Many thanks to all, that answered. I will have a look at Tree. Regards, Willi

1 0

Tools for managing IP address space
by Willi Huber 19 Jul '96

19 Jul '96

Hallo, does anybody of you use some tool to managed IP address space in a classless environment for a bigger organization? Any tips welcome. Regards, Willi Huber

4 3

The NCC Web Site
by Carol Orange 16 Jul '96

16 Jul '96

We'd like to take a minute to respond to the comments posted in the last few days about the new Web site. Some of the comments were not sent to the ripe-list, only to one or two people here. First of all, we want to thank those of you who have sent in comments for your interest in the site. We are sorry for the teething troubles and appreciative of your patience. 1. Access Although we chose to use frames in the browsers that support them, the web site was designed from the outset to be accessible by simple browsers such as Lynx. Unfortunately, the automatic selection had a flaw that prevented access by browsers which did not allow one to load another page directly. For those of you who could not reach the site because there was no support for no-frame browsers during the weekend, you might like to know that immediately following the launch, we were fair and impartial :-). Our web site was inaccessible regardless of your browser. At this point, the web site should be accessible with whatever browser you are using. Certainly there was never an intention to prevent access to the site with non-Netscape browsers. If at any point, you find you can't access our web site with an arbitrary browser, please let us know. It is most definitely not by design. 2. Content We are glad to hear that most people find the information available on the web site to be of use. We hope to keep it that way and hope that you won't hesitate to inform us when new information would be useful. 2.1 List of documents We've been asked to put titles next to the list of ripe-xxx document names. We've also been asked to list the documents in a table, so the entire list can be viewed without scrolling. Both of these views will be supported in the near future. 2.2 RFC Access There's been a suggestion that the RFCs should be accessible from our web site. While the RFC's are still accessible via our ftp server, we've not put pointers to them on our web site. This should not be difficult and we will be happy to do so if there is sufficient interest. Please send a note to webmaster(a)ripe.net if this service would be of use to you. 3. Frames/No Frames Controversy That is the question. The decision to incorporate the use of frames in the design of the RIPE NCC web site was based on carefully weighted user interface design principles. It was influenced by the response to the survey posted on our old web site in which the vast majority of respondents indicated that they would happily wait a little longer if it would result in a more easily navigated web site. Except for the trouble with moving between frames which works differently than moving between pages, we believed that using frames would enable easy navigation. Another principle applied throughout the design of the site was "keep it simple". The graphics are minimal and consistent throughout. This was so the web page would load quickly. The graphics that appear beyond the home page are the same as those on the home page, and are therefore only loaded when the site is first accessed. We also consider it essential that important information stand out rather than that our site be "glossy". Because the discussions on the ripe list in the last couple of days indicate that a number of people who access the site would greatly appreciate a more minimal design (e.g. the text only version), we will take steps to ease access to the no-frames version. In addition to a (to-be-included) no-frames button on the menubar of the site, the no-frames version of the site is now also available in: http://www.ripe.net/noframes.html This is for those who want the no-frames version when the automatic selection process would give them the framed version by default. As stated by Daniel in an earlier message: There were basically three choices we could make: 1) Determine the browser's capabilities and choose a version accordingly. 2) Always show a selection page for the user before showing the home page. 3) Always show the non-fancy home page with a selection button to choose the fancy version. In the coming months we will examine access statistics to find out how much different pages are accessed. In general, the results will be used to determine what modifications might make the site more useful. If the no-frames version of the home page is sufficiently popular, we will make it the default, and make the framed version accessible via a button on the home page and another URL. Anyone with views on this subject is encouraged to send them to webmaster(a)ripe.net. They will be collected and considered together with the statistics in the next couple of months. 4. Navigating in Frames As noted in other mails, the right mouse button can be used to move back in frames. As also noted, this does not work 100% of the time. 5. The Documents Currently we are still smoothing out some minor formatting problems in the document pages. Moreover, it seems the Reference section has been stripped off ripe-136. Both problems are being pursued at this time. That's it for now. Please keep us informed of any problems you have. Kind regards, Carol Orange - RIPE NCC Web Site Coordinator Lee Wilmot - RIPE NCC Web Master

1 0

Re: Web Site Launch
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 16 Jul '96

16 Jul '96

>Date: Mon, 15 Jul 1996 10:23:05 +0200 >From: Berthold Paffrath <bp(a)nic.dtag.de> > >My problem is, as with all these new frame-based web sites: If I follow >some links up to "Registries ordered by country code", then select one >of these - how do I go "one page back" to the overview? The "<-" button >of netscape just leads me to the previous non-framed web site... >This might be a netscape bug, but it seems that explicit "back" buttons >would be helpful until the bug gets fixed :-) My problem is, as with all these flame-based web sites ... Even http://www.netscape.com/ shows its home-page to poor man's browsers, why can't the RIPE-NCC ? I always thought the RIPE-NCC is a technical network coordination centre whose info's should be accessible as broadly as possible and not a shopping-mall for Netscape shareholders (sorry for this one ;-} Please make your info-site "Lynx"able again, and make all Java/Frames and other "kinky" features optional ! My personal opinion, anyway, always interested in others of course ! Christian

8 10