July 1996 - ripe-list - mailman.ripe.net

(no subject)
by Clizio Merli - 4U S.r.l. 30 Jul '96

30 Jul '96

subscribe Clizio Merli ********************************************* Master @ net4u.it (4U S.r.l. Vercelli) *********************************************

1 0

RIPE25: Announcement
by RIPE NCC Staff 29 Jul '96

29 Jul '96

(This is the only announcement that goes to <local-ir(a)ripe.net> as well. If you want to keep up to date with meeting information, please regularly check ftp.ripe.net/ripe/Next-Meeting, or subscribe to 'ripe-list' via <majordomo(a)ripe.net>. The meeting info is not yet available via the Web, but that will be worked on.) R I P E meeting announcement ============================ (This announcement can also be viewed using "finger meeting(a)ncc.ripe.net") This is to announce that the 25th RIPE meeting will take place: Dates: 23rd September, 1996 start: 10:00/14:00 (*) 24th September, 1996 25th September, 1996 end: 13:30/18:00 (*) * We're sorry not to be able to give better estimates until shortly before the meeting. Venue: CWI Kruislaan 413 1098 SJ Amsterdam The Netherlands Host: NIKHEF Registration: Please use the registration form (which will follow in a separate mail) to give notice of your coming as soon as possible. General meeting overview: ------------------------- - We assume that before the working group meetings, on Monday 23rd, there will be an EOF (European Operators Forum) meeting. The exact starting time will probably be known shortly before the RIPE meeting. It will end 12:30. - Monday 23rd, 14:00-18:00 and Tuesday 24th, 09:00-12:30, there will be various RIPE working groups sessions. The schedule of the previous meeting follows below for reference; the schedule of this meeting is not known yet. - Tuesday 24th, 14:00-18:00 and Wednesday 25th, 09:00- +/-15:30 (*), the plenary session will take place, with reports from the RIPE NCC, reports from the working group meetings and other presentations. General information: -------------------- Currency (checked 25 July 1996): 1 UK pound = Hfl 2.6 1 ECU = Hfl 2.1 1 US$ = Hfl 1.7 More information about Amsterdam: --------------------------------- Websurfers may take a look at: <> http://www.xxlink.nl/cities/amsterdam <> http://www.channels.nl/ Appended to this announcement: ------------------------------ <> directions to the meeting place Documents to follow (separate mail messages): --------------------------------------------- <> details of hotels in Amsterdam close to meeting venue <> registration form for attendance at the meeting <> getting visa for the meeting, if you need one ================================================================== Directions to meeting venue --------------------------- >From Amsterdam airport (Schiphol): o Take the train from the airport railway station to the Central Railway station. >From the Central Railway station: o Change to the stop train to Utrecht / Amersfoort / Lelystad. Next station is the 'Muiderpoort' railway station. or o Take bus 22 in the direction 'Indische Buurt' to the stop at the 'Muiderpoort Station'. or o Take tramway number 9 till the stop at the corner of Middenweg and Kruislaan (15 min ride) o Walk down the Kruislaan in the direction of the railway bridge. Cross under the bridge and continue. Take the 2nd entrance left and proceed to the RIPE meeting venue. (you'll see signs.) (15 min walk all together). >From the Muiderpoort Railway station: o Take bus 66 (5-10 minutes ride). At the exit of the railway station turn to the left, pass through the tunnel, turn left again and cross the street. The stop for bus 66 is there (behind the tram stop). The bus passes twice broad railway bridges. Get off at the second stop after the second passage, pass through the gate at the left, and proceed to the RIPE meeting venue. (you'll see signs.) Bus 66 is operated in conjunction with bus 61. Therefore the bus does not always show the correct linenumber. In case of doubt ask the driver or your fellow-passengers. Taxi from the airport: o 15 min ride o fl. 60 appr.

2 1

RIPE25: registration form
by RIPE NCC Staff 26 Jul '96

26 Jul '96

25th RIPE meeting Registration reservation form Amsterdam, The Netherlands September 23rd-25th, 1996 %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL meeting registrations is fully automated. To register for the meeting, please complete the registration form and send it to <meeting(a)ripe.net>. PLEASE FILL THIS OUT AS SPECIFIED. Please add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). Note this is what will be used for your badge if you have requested one and for the attendee list so please take care to fill it in correctly. You will receive a notification message that your request has been processed. If however, you have any questions about the meeting or your registration form, please send your completed form to <ncc(a)ripe.net>. ============================================================================== %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL (remember this is on list and badge) e.g. John Doe Mary-Beth Walton %NAME [ ] 2) I will need the RIPE NCC staff to come up with a badge for me (Fill in Y if you do not have a badge yet, or if you have given it to the NCC staff to keep until the next meeting. Fill in N if you will bring your old badge to the meeting yourself.) %BADGE [ ] 3) Your Organisation/Institution %ORG [ ] 4) Your e-mail address %EMAIL [ ] 5) Country code of organisation e.g. IT FR DE %CTRY [ ] %END

1 0

RIPE25: Visa
by RIPE NCC Staff 26 Jul '96

26 Jul '96

Dear RIPE meeting attendees, This letter is intended for all of you who need a visa to come to the Netherlands for the 25th RIPE meeting. Since getting visa takes generally more time than one expects, I would suggest you apply for a visum as fast as possible. On request, we can send you an invitation. If you want us to send an invitation, please tell us how many days and which days you are planning to stay. If, after the RIPE meeting, you want to stay some additional days we can invite you for some 'technical meetings' after the RIPE meeting ;-)). Furthermore, please give also your full name, birth date and passport number. If we mention these data in our invitation to you, it could facilitate getting visa. If you have any further questions, don't hesitate to contact us, preferrably at <ncc(a)ripe.net>.

1 0

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