Skip to main content

You're viewing an archived page. It is no longer being updated.


RIPE Meeting:


Working Group:




Revision Number:


Please mail comments/suggestions on:

Minutes of Techsec-WG meeting at RIPE42

Chair: Ted Lindgreen
Scribe: Rene Wilhelm
Date: 1 May 2002, 14:00


1st slot:
0. Administrativia
1. Minutes of previous meeting
2. DISI status update
3. NLnet Labs reports on securing .nl
4. TF-CSIRT update, news about IODEF development,
5. IRT object in the RIPE Database: current status

2nd slot
6. Hugh Daniel reports on FreeS/WAN and
issues around authentication/privacy and
user perceptions.
7. A.O.B.

1. Minutes of previous meeting

... were approved.

2. Olaf DISI update

Olaf presented an update on the work done in the framework of the DISI project.

Comment from Daniel Karrenberg: the idea behind deploying DNSSEC
in the the RIPE NCC, the in-addr tree, is to set an example,
write up how its done.

3. Miek Gieben experiment

Miek presented experience with implementing DNSSEC in the .nl zone.
The tests were done with a shadow name server, not listed as an
official server for the .nl zone.

Question: do you sign zones once a day?
Answer: signature validity time is one or two days;
parent needs to sign often.

Randy Bush: should not be so short that operational problems cause key
and data to go invalid; make lifetime 3-4 times longer in the beginning

4. Yuri Demchenko TF-CSIRT update

Yuri presented an updated of Terena's TF-CSIRT activity.

5. Andreii Robachesky IRT object in RIPE Database

Andreii reported support for the IRT object has been added to RIPE Database

6. Hugh Daniel Free/SWAN


General security on the internet:

IP and related protocols (DNS, BGP, Snmp, etc.) are _still_ not
secured in very meaningfull ways.

To secure someting you need to make a set of links from
some known axiom to something that gets work done;

Currently the known axiom a is a text name typed in to a
browser or hard coded into a script, table program etc.
On the net we need to start with a DNS name , link that
to an IP then link to each packet of data. If either of
the links is broken, you do not have security.

In Free/SWAN:

Use emerging tools dnssec and ipsec to secure tcp/ip packets;
dnssec secures name to resource record lookups, ipsec secures
the packets from the address that dsnsec returned. Your layer
of the infrastructure thus gets secured.

Opportunistic Encryption (OE); automatically setup IPsec connections
between any two machines on the net when they start talking to
each other. whenever an OE host is about to send a packet to a new
host it has not talked to recently, it first checks the reverse DNS
entry for that IP address; if there is a key there use it to
setup an IPSec session.

OE works with both DNS and DNSsec,
with DNS you are now protected from passive listening attacks
with DNSSEC you are protected from active attacks.
(protected as best as things can be designed this week
and only as well as people run their hosts ...)


Q You are using key recoreds?

A. Yes, though not perfect; complexity comes whith hosts that do
IPsec or OE for themselvev or for a subnet, gateway PCs, security
for all stuff behing id. Would need equivalent of MX recored, this
is my key, but this is the host who will do IPsec for me.
Missing in DNSSEC

Randy Bush: AT&T uses this technology internally, ~1000 hosts
couple of PCs talk to 500-1000 pcs at emplyoees homes
provide 16bit address from emplyoee to office and nothing
else. box @home doesn't talkk to anything but AT&T servers
gateways, etc. Can have machines @home inside and outside
at&t, but no need for leased line.
freeSwan running in VPM mode

Hugh asks: would it work you in your organisation?


- was considering Free/SWAN as frontend, need to encrypt the packets, wavesec

- could be interesting, we have two kinds of home users, techies, and
others who even with a recipe don't know if they can do it correctly.
OE soltuion for AT&T, sigaret size box to do OE

7. A.O.B.