Bericht zur 34. DFN Betriebstagung
(6.-7.2.2001)

Inhalt

Allgemeine Bemerkungen

• Überdurchschnittliche Teilnehmerzahl
• In den Plenumsvorträgen zum GWin wurde sehr wenig über Finanzen und Vertragsabschlüsse berichtet
• Die Plenumsvorträge waren überdurchschnittlich gut
• Das Forum Informationsdienste fiel aus.

Dienstag, 6.2.2001 Plenum

1. Ipv6 im G-Win?

• Stadien und Möglichkeiten des Transfers V4 - V6
• V6 hat Henne-Ei-Problem (Applikationen-Hardwareunterstützung) überwunden
• Relativ großer V6 backbone (~700 Sites)
• 6 to 4 Tunnel:  6 over 4 für einzelne Host in Intranet
• Wichtig: Translatoren
• NAT-PT
• TCP-Relay
• ALG

DSTM
• Zwei IETF-Gruppen:
• ng trans
• ipng
• Sonst.:
• MPLS
• DTI (Dynamic tunnel Interface)= V4 to V6 tunnel

2. Mobilität für das Internet

2.1. Allgemeine Bemerkungen

• Mobilität gibt es auf 3 Schichten:

• Verbindungsschicht: Handover
• Netzwerkschicht: Mobile IP, Multicast
• Applikationsschicht: Session Initiation (SIP), Service Location (SLP), web Mail
• Projekt MIRIAM
• www. Darmstadt.gmd.de/mobile/projects/MIRIAM
• Kooperation zwischen DFN und GMD

2.2. Mobile IP

• Adress-Vergabe: care-of-Adresse oder care-of-other-location-Adresse
• Architektur:




1. Anmeldung in Foreign Network
2. Authentifizierung
3. IP-Adressenvergabe
4. Nutzung
5. Reaktionen entweder a) ins Foreign network oder  b) ins Home Network
 
 

• Mobile  IP Implementationen: (beide für Linux neuer Kernel 2.2.X)
• Mosquito Net
• Stanford Universität
• verwendet Mobile Policy Table
• HUT
• Helsinki Universität
• hat hierarchisches MIP

2.3. Sonstiges

• UMTS wird eventuell Mobile Ipv6 verwenden
• SIP Location Server, Redirect-Server
• Siehe Elin Wedlund, Henning Schulzrinne: Mobility Support Using SIP. WOWMOM 1999: 76-82
• 3 IETF Gruppen:
• SIP
• SLP
• Mobile IP

2.4 Kommentare

• Service Location via DNS SRV RR einfacher als SLP
• Konfigurationsdefinitionen via LDAP
• Integration von IETF-ACAP

3. Videokonferenzdienst im DFN

• Zukunft: IP mit H.323
• benötigt MCU Multipost Controll Unit
• IP/ISDN/ATM
• Video>384Kb/s pro Nutzer
• Audio:G.722
• T.120 für Application Sharing
• Projekt: Videokonferenz der Rechenzentrumsleiter in Niedersachsen und Bayern
• continuos presence
• EU: Jet Projekt
• Konfiguration für :
• gatekeeper für H.323,
• Firewall/Proxies,
• T.120
• www Schnittstelle für Kunden/Nutzerdatenbank
• Adressbuch
• Accounting / Billing
• Monitoring
• Gatekeeper (H.323) im Netz verteilt in den Einrichtungen, die H.323 Zonen verwalten
• Dienstmodell und Entgelte
• Zusatzvertrag über Nutzung von MCU Ports gegen kleines Entgelt (ad on zum G-Win)
• Nutzungsabhängig aber pauschalisiert

 
• Architektur
• Nutzer kommt über ein Gatekeeper/MCU oder aber
• über ein Web-Interface, das Reservierung über MCU vornehmen kann
• DFN Betreibt Gateway und Directory
• ISDN über H.320

 
• Etwa 20.000 Nutzer im DFN
• bisher größte Nutzergemeinde
• MCU Hardware:
• Accord MGC-100
• RAD Vision MCU 323 / via IP-400 (RAD Vision von CISCO genutzt)
• Dresden Beratungszentrum für Video
• Reservierung
• QoS
• Firewall,
• Erfassung der nutzungsabhängigen Daten
• Management
• Probleme
• funktionale Mängel der MCUs
• betriebliche Mängel bei according/Billung, Monitoring, GK, FW, T.120
• Start Pilotierung Sommer 2001 ohne Reservierung
• Mbone auch noch seine Berechtigung v.a. für 1 zu n Verbindungen

 

4. Status G-WiN - Aufbau, Migration, Dienste, Betrieb

• Nichts wirklich neues und interessantes

5. CNM für das G-Win

• www.cnm.dfu.de
• Customer Network Management CNM+
• Okt. 99-Sept. 2001
• CNM für G-Win
• beim LRZ
• Leistungen
• Aufbereitung der SDH Monitoringdaten
• Bestellsystem für DFN Connect Dienste SDH und ATM
• CNM für IP im G-Win
• Stellt dar:
• Topologie
• Zustand
• Durchsatz/Auslastung,
• History Funktion
• IP-Accounting: X, x-y, Top n
• Architektur
• Java applets sind mittlerweile sicher (z.b. Sunbox)
• Probleme
• inkompatible Browser
• lange Downloadzeit (Applet>2MB)
• Implementierungen
• Neu Java Web Start
• Referenzimplementierung von Sun browser plugin für Java
• Solaris, Windows, Linux
• Browser unabhängig
• Caching Mechanismus
• XML Mechanismus für Versionsupdate
• B-win Authentifizierung war zu administrier aufwendig
• G-win Rollenkonzept

 

6. DFN Zugang @home

• Ersatz für derzeitiges System uni@home der DTAG
• Ziel technische Dienstspezifikation weitgehend erhalten, insbesondere IP-Adresse aus Adressraum des Anwenders
• Zuschlag an Talkline
• Preis:
• Bundesweiter Einwahlzugang direct 2,48 Pf/Min (werbefrei)
• später möglischerweise < 2 Pf/Minute mit Werbung
• Rechnungsstellung durch Talkline
• Tunnelrouter von Talkline betrieben
• Nutzung des Peerings zunächst an zwei Übergabepunkte - damit Nutzung der G-Win-Infrastruktur
• Authentifizierung der Nutzer mit Daten der Anwender (in der Regel RZ)
• VPDN (Virtual Private Dial-up Network) über L2TP (Lager 2 Tunneling Protocol)
• Start Pilot März 2001
• Lifebetrieb ab April 2001



 
 

7. Neues in G-Win

• Interkontinentalverbindung:
• 2 * 622 Mb nach NY von Frankfurt und von Hannover
• 60% Nutzung
• kein echtes load balancing
• Europa
• 1+622 zu Abilene (mit Dante)
• Transit über Abilene zum STARTAP
• Noch keine Verbindung zu Geant
• 80 Mio Euro von Eu in 4 Jahren
• =30-40% der Betriebskosten
• Upgrade auf 622 noch nicht erfolgt
• 2 mal 155 zu Ten 155 (1 mal B-Win, 1 mal G-Win)
• Peering mit vielen Providern an Frankfurter Knoten

Dienstag, 6.2. Security Forum

8. Aktuelles aus dem DFN-CERT

• DFN Cert GmbH
• 100% Tochter des DFN Vereins
• gemeinnützig
• Sollstärke=7
• Stellen-Finanzierung der nächsten Jahre sichergestellt (BMBF)

9. DFN-CERT Workshop im Mai 2001

• 8. Workshop DFN-Cert/DFN-PCA
• 15.-16. Mai 2001 Kongresszentrum Hamburg CCH
• call for papers: www.cert.dfn.de/events/cfp.html
• infos: workshop@cert.dfn.de

10. Europäische CERT-Entwicklung

• TF.CSIRT
• Cert-Kooperation in Europa
• Seit Sept. 1999 Nachfolger von Eurocert
• Europäisches Pendent des Cert Coordinationscenters (CCC)
• Kein Ersatz für CCC
• Keine Übernahme der Aufgaben für kleine Länder ohne eigenes CERT
• Offene Arbeitsgruppe
• Academia, Regierungen, Kommerzielle Firmen
• Regelmäßiges Treffen ca. alle 4 Monate
• www.terena.nl/cert
• Ziele:
• Forum zum Erfahrungsaustausch
• Pilotdienste (z.b. tusted user)
• Standardisierung IODF (Incident Object Definition)
• Hilfe bei Gründung neuer Incident Response Teams
• allgemeine Koordination
• Trusted Introducer (TI)
• Zusammenarbeit auf Vertrauensbasis
• Vertrauliche Daten: wo wurde wie eingebrochen
• Web of Trust (WoT)
• Problem: wie neue integrieren
• woher weiß die Gemeinde von der Existenz neuer Teams
• Man muß jemanden in WoT kennen
• skaliert schlecht
• erschwert durch Personalfluktuation
• TI ist ein formaler Dienst
• vertrauenswürdiger dritter für WoT
• sammelt infos über Teams
• Nach Art der Infos werden Teams in Grade eingeteilt
• Level 0 Existenz bekannt
• Level 1 Übergangsstadium (Einladung) 3 Mon.
• Level 2 erfüllt feste Kriterien Access; Policy (z.b. RFC 2053)
• Einjährige Pilot mit Firma Stelvio von TERENA finanziert
• Gebührenpflichtig: 600 Euro pro Jahr
• DFN Cert derzeit Level 0
• Bewerbung 2Q2001-03-01
• www.ti.terena.nl
• Ripe IRT Object
• Security Kontakt in RIPE DB
• Irt-c Objekt (Instance Response Team Contact) analog zu tech-c und admin-c
• Mehr Info als e-mail Adresse (RFC 2140):
• Optionaler Zusatz in inetnum, autnum, domain Objekte
• Irt: Name des Teams
• Signature: mehrerer Schlüssel z.B. jedes Teammitglied
• Encryption
• e-mail
• fax-no
• phone
• Support Objekte notify-changed
• Direktsuche nach e-mail und irt
• Vorschlag eingereicht und beim nächsten RIPE Meeting diskutiert
• IODEF Incident Object definition
• Wachsende Anzahl der Vorfälle
• 1999:511
• 2000:1046
• Bisher freies Format
• Tools zur automatischen Bearbeitung
• automatischer Informationsaustausch
• Incident Taxonomy
• einheitliche Klassifikation
• incident-taxonomy@terena.nl
• Incident Object Format
• iodef@terena.nl draft bei IETF eingereicht
• ersetzt nicht intrusion detection WG
• draft-terena-iodef
• Sonstiges:

• Workshop für neue Teams
• DFN-Cert macht technisches Modul
• Zusammenarbeit mit EU
• Actionplan eEurope 2000
• Informationsangebot:
• Juristische Info
• Tools für Incident Response

11. Open SSL und Smartcards?

• DFN-Projekt UVsec (sicher vernetzte Universitätsverwaltung und Dezentralisierung)
• http://www.hu-berlin.de/rz/projekte/uvsec/uvsec.html
• Zertifikatsspeicher
• Netscape communicator:
• Key 3.db Nutzerschlüssel auch privater Schlüssel
• auf Harddisk:
• cert 7.db CA Zertifikate
• bei Ortswechsel: Schlüsselpaarexport PKCS#12
• Smartcard
• ortsunabhängig
• Smartcard und PIN/Passphrase
• private keys, Zertifikate, PIN sicher auf Smartcard
• sicherer als Harddisk
• Formate
• PKCS 7 S/MIME
• PKCS 12 Certexport
• PKCS 11
• cryphographische Token
• also auch Smartcard
• dennoch funktioniert es nicht
• Applikation -> PKCS#11 -> PC / Smartcard-Leser -> Smartcard
• Unix
• M.U.S.C.L.E.
• Hardware für Linux, Solaris
• PS/CS lite
• GPKCS#11
• Schlumberger Cyberflex
• Win 32
• Treiber
• Hardware
• PC/SC
• PKCS#11
• Applikationen:
• NS communicator
• Internet Explorer
• Eudora (plugin)
• Schlüsselgenerierung auf Smartcard oder mit Open SSL
• Smartcard
• Schlüsselpaar generiert
• SPKAC-Request
• Import
• OpenSSL
• alles in CA oder:
• SC: Schlüsselpaar ersetzt
• BR: SPKAC Request <keygen> tag
• CA: signiert mit OpenSSL
• BR: Download des Zertifikats
• SC: Zertifikat auf die SC
• Probleme:
• Mehrere Schlüsselpaare für Authentifizierung, Signatur und Verschlüsselung
• erforderet serial number ins Zert zu integrieren
• Zertifikats-Management
• OCSP
• NS Security Manager 1.4.
• Cert Management OpenSSL
• mächtiges Kommandozeichen orientiertes Tool;
• Fazit:
• generell machbar
• Win 32 Treiber und Applikationen sind vorhanden
• CA: Unix ist besser in Sicherheit und Management
• VPN zwischen RA und CA
• Links:
• www.pca.dfn.de/dfn/berichte/db089
• www.openssl.org
• www.gemplus.com
• (Karte ~ DM 20, PCMIA-Leser ~ DM 150,-)
• www.gemsafe.com
• www.datakey.com
• (Leser+Karte ~ DM 300,-)

Dienstag, 6.2. Directory Forum

12. Einsatzmöglichkeiten für Directory-Anwendungen im DFN-Umfeld

Peter Gietz, DAASI International

Siehe http://www.daasi.de/pub/DFN-BT-34-Dateien/v3_document.htm
 

13. Metadirectory-Planung an der FH Nürnberg

Franziska Staedler, FH Nürnberg

Es wurde nur folgende Übersicht erklärt:


 

14. Chipkartenprojekt an der Universität Giessen

Falko Fock, Universität Giessen
 
• DFG Kommission unterstützt Chipkartenprojekte an Unis für Studentenverwaltung und Prüfungsverwaltung
• Hochschulkonferenzbeschluß zur Förderung von Chipkarten
• Uni Giessen stellt HBFG Antrag
• Prüfungsverwaltungssystem
• Multifunktionale Chipkarte
• Studentenverwaltungssystem mit Chipkarten
• TU Darmstadt hat bereits eigenen CA Server (DM 50.000)
• CA mit Chipkarten für Rückmeldung und Prüfungssystem
• Druckerhersteller Ulrich in Graz: 1 Drucker zum Beschriften von Chipkarten DM 15.000
• Gegner von Chipkartenprojekten Fachschaften in
• Darmstadt
• Dresden
• Bremen
• Karte kostet 30 DM, Studentenwerk trägt 10 DM davon
• TU-Berlin macht ein ähnliches Projekt