Ausgewählte Kapitel der Rechnernetze

Transkript

1 Ausgewählte Kapitel der Rechnernetze Client-Server-Modell Socketprogrammierung Dienste in der Anwendungsschicht: DNS Kommunikationsmodelle P2P-Systeme

2 Client/Server-Modell (Internet) 2

3 Kommunikations-Modell zwischen Client und Server Die Kommunikation erfolgt in Form von Frage-Antwort-Paaren. Es besteht eine asymmetrische Kommunikationsbeziehung, die sich im Prozeßkonzept widerspiegelt. a) Der Client schickt eine Anforderung (Request) an einen Server. b) Der Server behandelt die Anforderung und schickt eine Antwort (Response) mit Ergebnis. Client Request Response Server Asymmetrie auch in der Kommunikationsform: a) Der Client überliefert asynchron (zu einem beliebigen Zeitpunkt) eine Anforderung an einen Server. b) Der Server antwortet synchron (in einem bestimmten Zeitintervall). 3

4 Berkeley-Socketinterface - API für verteilte Anwendungen zur Einordnung der Socket-API Applikation Anwendungsprotokolle Transport Socket-API Internet Protokoll Netzwerk Schnittstelle

5 Socket - API Die Netzwerkfunktionalität ist im allgemeinen in das UNIX-System integriert. Die Socket-API stellt entsprechende API-Funktionen bereit. Systemrufe Bibliotheksfunktionen Orientierung an Unix-Dateiarbeit Arbeit über Deskriptoren Ein-/Ausgabe über das Prinzip: create, open, read, write, close Ein-/Ausgabe über das Netz aber komplizierter als Datei-Ein-/Ausgabe, da Interaktion zwischen zwei getrennten Prozessen Unterstützung verbindungsloser und verbindungsorientierter Kommunikation 5

6 Socket API (II) Ein Socket ist ein Kommunikationsendpunkt innerhalb eines Kommunikationsbereiches. Ein Kommunikationsbereich spezifiziert eine Adreßstruktur und ein Protokoll. Adreßstruktur: z.b. Internet Host/Port Protokoll: z.b. TCP, UDP Die Kommunikationsverbindung zwischen zwei Sockets ist durch ein Socket- Paar gekennzeichnet. Ein Datenaustausch erfolgt zwischen zwei Sockets desselben Kommunikationsbereiches. Eine Kommunikationsbeziehung ist immer durch folgendes Fünfertupel definiert: (protocol, local-addr, local-process, foreign-addr, foreign-process)

7 Struktur der Socket-Systemaufrufe bei verbindungslosem Protokoll Server socket() Client socket() bind() bind() recvfrom() sendto() sendto() recvfrom() close() close()

8 Struktur der Socket-Systemaufrufe bei verbindungslosem Protokoll mit connect () Server socket() Client socket() bind() bind() connect() recvfrom() send() sendto() recv() close() close()

9 Struktur der Socket-Systemaufrufe bei verbindungsorientiertem Protokoll Server socket() Client socket() bind() listen() accept() read() write() connect() write() read() close()(accept) close()(socket) close()

10 Python Server Erklärungen (1) Einen Socket vom Betriebssystem anfordern AF_INET Adressfamilie Internet (IP...) SOCK_STREAM Stream, also TCP-Socket (2) Server an vorgegebenen Port (>1024!) binden (3) Auf eingehende Verbindung für den Socket warten (5) Eingegangenen Verbindungswunsch akzeptieren (7) Eingehende Daten einlesen (8) Daten zurückschicken (9) Verbindung schließen 10

11 Socketserver mit Python Ganz einfaches Beispiel... # # based on Python documentation chapter # import socket HOST = '' # Symbolischer Name für den localhost PORT = 8330 # beliebige Portnummer (über 1024!) s = socket.socket(socket.af_inet, socket.sock_stream) (1) s.bind((host, PORT)) (2) s.listen(1) (3) conn,addr = s.accept() (4) while 1: data = conn.recv(1024) (5) if not data: break conn.send(data) (6) conn.close() (7) 11

12 ...und der Client auch in Python, analog zum Server # # based on Python documentation chapter # import socket HOST = 'localhost' # Rechner, auf dem der Server läuft PORT = 8330 # Port, auf welchem Server lauscht s = socket.socket(socket.af_inet, socket.sock_stream) s.connect((host, PORT)) s.send('hello, world') data = s.recv(1024) s.close() print 'Received', data 12

13 Socket-Server mit Java etwas komplizierteres Beispiel, mit Exception-Handling... (1) Variablen vorbereiten (2) Server-Port festlegen (3) Mit Port verbinden und auf eingehende Verbindungswünsche warten (4) Eingehende Verbindung akzeptieren (5) BufferedReader an den eingehenden Datenstrom hängen (6) PrintWriter für die Ausgabe (7) Eingehende Nachricht auslesen (8) Bestätigung schicken (9) Socket wieder schließen 13

14 TCPSocketServer.java (1) Vorbereitungen... import java.io.*; import java.net.*; /** Einfache Server-Klasse, die einen Socket oeffnet, auf diesem lauscht, eingehende Pakete ausdruckt und eine Bestaetigung zuruecksendet */ class TCPSocketServer { public static void main(string[] args){ int serverport=0; ServerSocket serverstreamsocket = null; Socket streamsocket = null; BufferedReader bufreader = null; PrintWriter printwriter = null; String nachricht; String bestaetigung; // Port ist der erste beim Aufruf angegebene Parameter serverport = Integer.decode(args[0]).intValue(); (1) (2) 14

15 TCPSocketServer.java (2) Socket öffnen, Verbindung annehmen // Socket aufmachen und an Port binden: try { serverstreamsocket = new ServerSocket(serverPort); } catch (IOException e) { } System.err.println("TCPSocketServer: Fehler beim Binden"); System.err.println("ExceptionMessage: " + e.getmessage()); System.exit(1); (3) // Ankommende Verbindung annehmen try { streamsocket = serverstreamsocket.accept(); } catch (IOException e) { System.err.println("TCPSocketServer: Fehler beim.accept"); } System.err.println("ExceptionMessage: " + e.getmessage()); System.exit(1); (4) 15

16 TCPSocketServer.java (3) Socketoperationen durchführen... // einkommenden und ausgehenden Datenstrom vorbereiten try { bufreader = new BufferedReader( new InputStreamReader(streamSocket.getInputStream())); printwriter = new PrintWriter( new BufferedOutputStream(streamSocket.getOutputStream(), 256), false); (5) (6) // Einkommende Nachricht auslesen: nachricht = bufreader.readline(); System.out.println(nachricht); (7) // Bestaetigung senden: bestaetigung = "Nachricht: "+nachricht+" angekommen!"; printwriter.println(bestaetigung); printwriter.flush(); (8) 16

17 TCPSocketServer.java (4) Und alles wieder zumachen } } // aufraeumen printwriter.close(); bufreader.close(); streamsocket.close(); } catch (IOException e) { } System.err.println("TCPSocketServer: Fehler!"); System.err.println("ExceptionMessage: " + e.getmessage()); e.printstacktrace(); (9) 17

18 TCPSocketClient.java der zugehörige Client Variablen vorbereiten Server-Host, Server-Port und die zu versendende Nachricht aus den Aufrufparametern festlegen TCP-Socket zum TCPSocketServer öffnen Aus- (DataOutputStream [ Bytes!]) und Eingabedatenströme (BufferedReader) verknüpfen Nachricht Byteweise übermitteln Bestätigung annehmen und ausgeben Socket wieder schließen 18

19 TCPSocketClient.java (1) Variablen und Parameter festlegen... import java.io.*; import java.net.*; /** Einfache Client-Klasse, die einen Socket zu einem Server oeffnet, eine Nachricht sendet, eine Bestaetigung empfängt und diese ausgibt */ public class TCPSocketClient { public static void main(string[] args) { String serverhost = null; int serverport = 0; Socket streamsocket = null; DataOutputStream outstream = null; BufferedReader bufreader = null; String nachricht; serverhost = args[0]; serverport = Integer.decode(args[1]).intValue(); nachricht = args[2]; (1) (2) (3) (4) 19

20 TCPSocketClient.java (2) ServerSocket öffnen... // Socket zum TCPSocketServer aufmachen try { streamsocket = new Socket(serverHost, serverport); (5) //... und die Datenstroeme anbinden: outstream = new DataOutputStream(streamSocket.getOutputStream()); bufreader = new BufferedReader(new InputStreamReader(streamSocket.getInputStream())); } // Rechner des Servers unbekannt? catch (UnknownHostException e) { System.err.println("TCPSocketClient: " + "IP-Adresse konnte nicht aufgeloest werden: " + serverhost); System.err.println("Message: " + e.getmessage()); System.exit(1); // irgendein anderer Fehler } catch (IOException e) { System.err.println("TCPSocketClient: Fehler:"); System.err.println("Message: " + e.getmessage()); System.exit(1); } (6) (7) 20

21 TCPSocketClient.java (3) Senden, empfangen und alles zumachen... } try { } // Nachricht senden, diesmal direkt in den Bytestrom outstream.writebytes(nachricht); outstream.writebyte('\n'); // Bestaetigung empfangen System.out.println("Server: " + bufreader.readline()); outstream.close(); bufreader.close(); streamsocket.close(); } catch (IOException e) { } System.err.println("TCPSocketClient: " + "IOException: " + e.getmessage()); e.printstacktrace(); (8) (9) (10) 21

22 Was sind verteilte Anwendungen? (Modelle) application application presentation session UI App DB App.-protokolle Verteilte Anwendungen Plattformen für verteilte Anwendungen Middleware (Verteilte Systeme) transport internet Network interface transport network Data link physical Netzwerk Protokolle Betriebssystem Hardware TCP/IP ISO/OSI 3-Tier 22

23 Dienste in der Anwendungsschicht DNS The Domain Name System Naming Service for (almost all) Internet traffic Lookup of (resolve) Host-Addresses Mail-Servers Alias Names Alternative Name Servers Distributed Database consisting of multitude of servers 23

24 DNS: Domain Name System People: many identifiers: SSN, name, passport # Internet hosts, routers: IP address (32 bit) - used for addressing datagrams Name, e.g., - used by humans Q: Map between IP addresses and name? Domain Name System: Distributed database implemented in hierarchy of many name servers Application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation) Note: core Internet function, implemented as application-layer protocol Complexity at network s edge 24

25 DNS DNS services Hostname to IP address translation Host aliasing Canonical and alias names Mail server aliasing Load distribution Replicated Web servers: set of IP addresses for one canonical name Why not centralize DNS? Single point of failure Traffic volume Distant centralized database Maintenance does not scale! 25

26 DNS Data Organization: Domains / Zones. com org edu google bbc mit caltech Structured Namespace Hierarchical organization in sub domains/zones Sourced at root zone (. ) Parent zones maintain pointers to child zones ( zone cuts ) Zone data is stored as Resource Records (RR) 26

27 Distributed, Hierarchical Database Root DNS Servers com DNS servers org DNS servers edu DNS servers yahoo.com DNS servers amazon.com DNS servers pbs.org DNS servers poly.edu umass.edu DNS serversdns servers Client wants IP for 1 st approx: Client queries a root server to find com DNS server Client queries com DNS server to get amazon.com DNS server Client queries amazon.com DNS server to get IP address for 27

28 DNS: Root Name Servers Contacted by local name server that can not resolve name Root name server: Contacts authoritative name server if name mapping not known Gets mapping Returns mapping to local name server e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 17 other locations) a Verisign, Dulles, VA c Cogent, Herndon, VA (also Los Angeles) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 11 locations) k RIPE London (also Amsterdam, Frankfurt) i Autonomica, Stockholm (plus 3 other locations) m WIDE Tokyo 13 root name servers worldwide b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA 28

29 DNS Components Authoritative Server Server maintaining authoritative content of a complete DNS zone Top-Level-Domain (TLD) servers & auth servers of organization s domains Pointed to in parent zone as authoritative Possible load balancing: master/slaves Recursive (Caching) Server Resolver Local proxy for DNS requests Caches content for specified period of time (soft-state with TTL) If data not available in the cache, request is processed recursively Software on client s machines (part of the OS) Windows-* and *nix: Stub resolvers Delegate request to local server Recursive requests only, no support for iterative requests 29

30 DNS Message Format Identification Flags and Codes Question Count Answer Record Count Name Server (Auth Record) Count Additional Record Count Questions Answers Authority Additional Information Q/R OPCode AA TC RD RA Zero RespCode Q/R Query/Response Flag Operation Code AA Auth. Answer Flag TC Truncation Flag RD Recursion Desired Flag RA Recursion Available Flag Zero (three resv. bits) Response Code 30

31 DNS Header Fields Identifier: a 16-bit identification field generated by the device that creates the DNS query. It is copied by the server into the response, so it can be used by that device to match that query to the corresponding reply Query/Response Flag: differentiates between queries and responses (0 ~ Query, 1 ~ Response) Operation Code: specifies the type of message (Query, Status, Notify, Update) Authoritative Answer Flag (AA): set to1 if the answer is authoritative Truncation Flag: When set to 1, indicates that the message was truncated due to its length (might happen with UDP, requestor can then decide to ask again with TCP as transport service) Recursion Desired: set to 1 if requester desired recursive processing Recursion Available: set to 1 if server supports recursive queries 31

32 TLD, Authoritative and Local DNS Servers Top-level domain (TLD) servers: responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp Network solutions maintains servers for com TLD Educause for edu TLD Authoritative DNS servers: organization s DNS servers, providing authoritative hostname to IP mappings for organization s servers (e.g., Web and mail). Can be maintained by organization or service provider Local DNS servers: Does not strictly belong to hierarchy Each ISP (residential ISP, company, university) has one Also called default name server When a host makes a DNS query, query is sent to its local DNS server Acts as a proxy, forwards query into hierarchy 32

33 DNS Records RR Format: (name, value, type, ttl) DNS: Distributed DB storing resource records (RR) Type=A name is hostname value is IP address Type=MX value is name of mailserver associated with name Type=NS name is domain (e.g. foo.com) value is IP address of authoritative name server for this domain Type=CNAME name is alias name for some canonical (the real) name is really servereast.backup2.ibm.com value is canonical name 33

34 DNS: Caching and Updating Records Once (any) name server learns mapping, it caches mapping Cache entries timeout (disappear) after some time TLD servers typically cached in local name servers Thus root name servers not often visited Update/notify mechanisms under design by IETF RFC

35 DNS Resource Records Atomic entries in DNS are called Resource Records (RR) Format: <name> [<ttl>] [<class>] <type> <rdata> name (domain name of resource) ttl (Time-to-live) class (used protocol): IN (Internet), CH (Chaosnet) type (record type): A (Host-Address), NS (Name Server), MX (Mail Exchange), CNAME (Canonical Name), AAAA (IPv6-Host-Address), DNAME (CNAME, IPv6) rdata (resource data): Content! (What did we want to look up?) 35

36 DNS Recursive and Iterative Queries DNS HEADER (send) - Identifier: 0x Flags: 0x00 (Q ) - Opcode: 0 (Standard query) - Return code: 0 (No error) - Number questions: 1 - Number answer RR: 0 - Number authority RR: 0 - Number additional RR: 0 QUESTIONS (send) - Queryname: (4)eris(7)prakinf(10)tu-ilmenau(2)de - Type: 1 (A) - Class: 1 (Internet) 2 3 iterative root DNS server Auth DNS server (TLD: c.de.net) local (caching) DNS server (via dhcp) recursive iterative Auth DNS server (TUI: floyd.tu-ilmenau.de) iterative p549d6941.dip.t-dialin.net eris.prakinf.tu-ilmenau.de 36

37 Example root DNS server Host at cis.poly.edu wants IP address for gaia.cs.umass.edu TLD DNS server 5 local DNS server dns.poly.edu requesting host cis.poly.edu authoritative DNS server dns.cs.umass.edu gaia.cs.umass.edu 37

38 Recursive Queries root DNS server Recursive query: Puts burden of name resolution on contacted name server Heavy load? 2 3 Iterated query: Contacted server replies with name of server to contact I don t know this name, but ask this server local DNS server dns.poly.edu TLD DNS server 1 8 requesting host cis.poly.edu authoritative DNS server dns.cs.umass.edu gaia.cs.umass.edu 38

39 Inserting Records Into DNS Example: just created startup Network Utopia Register name networkuptopia.com at a registrar (e.g., Network Solutions) Need to provide registrar with names and IP addresses of your authoritative name server (primary and secondary) Registrar inserts two RRs into the com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, , A) Put in authoritative server Type A record for and Type MX record for networkutopia.com 39

40 Security of the Domain Name System Vital service for the Internet Do you know the IP-Address of your mail server? You know you shouldn t follow the link but what about But: DNS does not support Threats: Data integrity Data origin authentication Denial of Service Data Authenticity/Integrity 40

41 DNS Data Flow Auth Server Caching Server Zone File Dynamic updates Slaves Resolver [ 41

42 DNS Security Issues Outline Robustness towards DDoS General issues Redundancy Robustness towards data corruption Cache Poisoning and simple countermeasures More complex countermeasures: Split-Split DNS Cryptographic countermeasures Data Integrity with TSIG records DNSSEC 42

43 Threats to DNS: Denial of Service DNS as vital service a worthy target Without DNS most Internet services will not work (usage of names rather than IP-Addresses for numerous reasons!) DNS Amplification Attack ( ) Spoofed queries (60 Bytes) may generate potentially large responses (4KBytes) Exploit open recursive servers to generate load on other DNS servers Exploit open servers as reflectors when flooding a victim with traffic (via source IP Address spoofing in request) DDoS Attacks on root servers: via notorious typos in TLDs 43

44 Robustness towards DDoS General issues Secure DNS server OS selection and updates Firewalls Server software selection and updates Redundancy and over provisioning Root. : 13 name server names ({a..m}.root-servers.net) com, net 13 name servers each de 8 name servers Anycast Announcement of an IP prefix from multiple locations Requests from different parts of the internet are routed to different machines with the same IP address Done with 6 of the 13 root-servers 44

45 DNS Threats to Data Integrity Corrupting Data Impersonating Master Cache Pollution Zone File Auth Server Caching Server Cache Impersonation Dynamic updates Unauthorised Updates Slaves Altered Zone Data (manually) Resolver 45

46 Threats to DNS: Data Corruption / Cache Poisoning All resolved RRs are cached at local DNS servers port_x: static in old DNS servers Q-ID_x: chosen sequentially in old DNS servers DNS slave servers replicate zone data from master Normal DNS lookup: 2 S: <port_x> D: 53/udp Q-ID_x Auth DNS server 1 S: <port_v> D: 53/udp Q-ID_v 3 S:53 D: <port_x> Q-ID_x Victim 4 S: 53 D: <port_v> Q-ID_v local DNS server (X) 46

47 DNS Threats Cache Poisoning: Simple Poisoning (1) Attack: plant fake data in slaves / caching servers (and nobody will realize the redirection from to malicio.us/phishing/yourbank.html ) DNS via udp/ip, no handshakes for connection establishment Transactions in DNS only through tuple of <auth server(ip-address), auth server(port), transaction id> With knowledge about transactions distribute malicious data IP Address of authoritative name servers are well known In many implementations same port for all transactions Q-ID unknown, but: BIND used to choose them sequentially 47

48 DNS Threats Cache Poisoning: Simple Poisoning (2) 1. Attacker sends request for target domain 2. DNS server performs lookup 3. Attacker sends fake information to known port_x, with last Q-ID +1 and source address of correct Auth DNS server 4. Second reply (by correct Auth DNS server) is ignored D: 53 S: <port_x> Q-ID_x + 1 Auth DNS server 1. Attacker requests DNS-Info on own Domain 2. Victim s server requests Info recursively 3. Port and last Q-ID known to Attacker D: 53 S: <port_x> Q-ID_x Victim local DNS server Auth DNS server of Attacker s Domain [<port_x>, Q-ID_x] 1. Victim requests IP for host in target domain 2. Local DNS server answers with poisoned info D: <port_x> S: 53 Q-ID_x + 1 Attacker 48

49 Mitigation of Cache Poisoning Random ports for each transaction (BIND8) Since Version 8 BIND uses PRNG for port number and query id selection However PRNG == Pseudo Random Number Generator, with knowledge about previous port numbers future port numbers can be guessed if PRNG not cryptographically secure (see network security course chapter 6) More random ports for each transaction (BIND9) New and better PRNG since BIND9, random numbers are harder to guess Cache Poisoning only after aging of entry in local DNS server Only if attacker attacks at the right moment, he can poison the cache Typical TTL: (2d) for most name servers Seconds to hours for A-Entries of organizations (tu-ilmenau.de 24h, deutschebank.de:60mins, commerzbank.de 30mins, postbank.de 30s, microsoft.com:60mins (where do you get your sec-updates today?)) Nevertheless: cache poisoning is still not solved completely! 49

50 Cache Poisoning with Brute Force Attacker sends multitude of requests for targeted domain to local DNS server of victim and Attacker sends multitude of fake replies with IP and port from auth server of targeted domain, guessing transaction id for one of the recursive requests from local caching server to auth server (2 16 x 2 16 = 2 32 ~ 4 Billion possible combinations) Victim requests data about targeted domain Local caching server responds with fake data 1 Victim 3 4 Victim s local DNS server 2 Attacker 50

51 Robustness towards Data Corruption: Split-Split DNS (1) Goal: Avoid cache poisoning from external machines Idea: Split the name service functions Name resolution (look up of DNS info) Domain information (Auth service of local DNS info) Internal server Implements name resolution Performs recursive look-ups at remote DNS servers Located behind firewall and only accepts requests from local LAN External server Authoritative server of domain Accepts remote requests but never accepts remote updates Zone transfer from external to internal server allowed 51

52 Split-Split DNS (2) Remote Auth Server Internal Client Internal Server Internal Requests Recursive Lookups Remote updates External Server Auth Server for local Domain External Requests NO remote updates External Client 52

53 Robustness towards Data Corruption: Data Integrity Usage of signatures to secure data at zone transfer master slave Pre shared symmetric key at each entity MD5 Hash used as signature TSIG Resource Record: (Name, Type ( TSIG ), Class ( ANY ), TTL( 0 ), Length, Data(<signature>)) Possibility to authenticate, but very complex to administrate in large domains (manual pre-sharing of keys) amount of keys required: n x (n-1) 2 Main application area: Secure communication between stub resolvers and security aware caching servers Zone transfers (master slave) [Vixie et. al: RFC 2845: Secret Key Transaction Authentication for DNS ] 53

54 DNSSEC Requirements DNSSEC aims at: End-to-end zone data origin authentication and integrity Detection of data corruption and spoofing DNSSEC does not provide: DoS-Protection (in fact, it facilitates DoS Attacks on DNS servers) Data delivery guarantees (availability) Guarantee for correctness of data (only that it has been signed by some authoritative entity) [Eastlake: RFC 2535: Domain Name System Security Extensions (obsolete)] [Arends et. al: RFC 4033: DNS Security Introduction and Requirements ] [RFCs:4033,4034,4035,4310,4641] 54

55 DNSSEC Usage of public key cryptography to allow for data origin authentication on a world wide scale RRSets (groups of RRs) are signed with the private key of authoritative entities Public keys (DNSKEYs) published using DNS Child zone keys are authenticated by parents (according to the zone hierarchy) and hence anchored trust chains established Only root zone key signing key (KSK) needed (manual distribution) to create complete trust hierarchy (in theory) Until then: islands of trust with manually shared anchor keys No key revocation DNSSEC keys should have short expiration date (quick rollover) 55

56 DNSSEC Targeted Threats Cache Pollution Zone File Auth Server Caching Server Cache Impersonation Dynamic updates Slaves Resolver Altered Zone Data 56

57 DNSSEC Means of Securing RRSets Goal: authenticity and integrity of Resource Record Sets Means: Public Key Cryptography (with Trust Chains) Security integrated in DNS (new RRs) New Resource Record Types: RRSig: RR for signatures to transmitted RRs DNSKEY: RR for transmission of public keys DS: RR for trust chaining (Trust Anchor signs Key of Child Zone) NSEC: RR for next secure zone in canonical order (authenticated denial for requested zone) 57

58 DNSSEC New Resource Records: RRSIG Resource Record for transmission of signatures RRSIG: (Name, Type, Algorithm, Labels, TTL, Sig Expiration, Sig Inception, Key Tag, Signer s Name, Signature) Name name of the signed RR Type RRSIG (46) Algorithm MD5(1), Diffie-Hellman(2), DSA (3) Labels number of labels in original RR (wildcard indication) TTL TTL at time of signature inception Signature Expiration End of validity period of signature Signature Inception Beginning of validity period of signature Key Tag ID of used key if signer owns multiple keys Signer s Name Name of the signer Signature Actual Signature 58

59 DNSSEC New Resource Records: DNSKEY Resource Record containing public keys for distribution DNSKEY: (Label, Class, Type, Flags, Protocol, Algorithm, Key) Label Name of key owner Class Always IN (3) Type DNSKEY Flags key types: Key Signing Key (257) or Zone Signing Key (256) Protocol Always DNSSEC (3) Algorithm RSA/MD5(1), Diffie-Hellman(2), DSA/SHA-1(3), elliptic curves(4), RSA/SHA-1(5) Key Actual key 59

60 DNSSEC New Resource Records: DS DS contains hash-value of DNSKEY of the name server of a sub zone Together with NS Resource Record, DS is used for trust chaining DS (Delegation Signer) (Name, Type, Key Tag, Algorithm, Digest Type, Digest) Name Name of the chained sub zone Type DS Key Tag Identification of the hashed key Algorithm RSA/MD5(1), Diffie-Hellman(2), DSA(3) (of referred DNSKEY) Digest Type SHA-1(1), SHA-256(2) Digest Actual value of hashed DNSKEY 60

61 DNSSEC New Resource Records: NSEC Next Secure (NSEC) gives information about the next zone / sub domain in canonical order (last entry points to first entry for the construction of a closed ring) Gives the ability to prove the non-existence of a DNS entry: Authenticated Denial NSEC (Name, Type, Next Domain) Name Name of the signed RR Type NSEC (47) Next Domain Name of the next domain in alphabetical order 61

62 Trust Anchor DNS Authority Delegation and Trust Chaining Parent Zone Signature with KSK DS pointing to child zone Signature with ZSK Child Zone Data can be trusted if signed by a ZSK ZSK can be trusted if signed by a KSK KSK can be trusted if pointed to by trusted DS record DS record can be trusted if Signed by parents ZSK Signed by locally configured trusted key TXT resource Signature with KSK Signature with ZSK 62

63 Trusted Key (locally configured) DNS Authority Delegation and Trust Chaining (Example) Parent Zone child NS ns.child DS ( ) <KSK-id> RRSIG DS ( ) ns DNSKEY DNSKEY RRSIG RRSIG Child Zone ( ) <KSK-id> ( ) <ZSK-id> dnskey ( )<KSK-id> parent. dnskey ( )<ZSK-id> child.parent. ns A RRSIG A ( ) <ZSK-id> child.parent. www A RRSIG A ( ) <ZSK-id> child.parent. 63

64 DNSSEC Trusted Zones Potential anchors TLD:.bg,.pr,.se Diversity of others 868 DNSSEC enabled zones 1759 anchored zones..net.bg.se.nl ripe.net.pr nlnetlabs.nl ftp.nlnetlabs.nl

65 DNSSEC Issues Pro s: Con s: DNSSEC allows to effectively counter unauthorized/spoofed DNS records Added complexity (signing, checking, key distribution) eases DoS attacks on DNS servers Zones completely need to be signed (performance challenge for large companies or registries) Authenticated denial with NSEC gives the possibility to walk the chain of NSEC and to gain knowledge on the full zone content (all zones/ sub domains) in O(N) Distribution of anchor keys still a manual task (allows for human error, social engineering) 65

66 Client-Server vs. Peer to Peer Client Request Response Server 66

67 Erweitertes Client-/Server-Modell Erweiterung des reinen Client-Server-Modells auf mehr als zwei Teilnehmer: Delegation von Teilaufgaben Nachrichtenketten Definition des Clients bleibt bestehen: Ein Client ist die auf einen Dienst bezogene originäre/ursprüngliche Quelle der Anfrage und letzte Senke der Antwort. Achtung!: DNS-Aufrufe oder ähnliche systemfremde Hilfsmittel gehören nicht in die Betrachtung des Modells! 67

68 Peer-to-Peer Idee Zuletzt häufig genutzter Name ( Buzzword ) Name flacher / anarchistischer Systeme Eigentlich eine Systemarchitektur (CDK: Peer-Process ) Zentrale Probleme: Finden von Ressourcen (Lokalisierung): Andere Knoten Dienste anderer Knoten Sinnvolle Weiterleitung von Anfragen/Daten (Routing) Unzuverlässigkeit der einzelnen Knoten Komplexität 68

69 Peer-to-Peer Definition Kommunikationsmodell asynchron (request-response) Rollenmodell: nur eine Rolle? symmetrisches Verhalten, alle Teilnehmer können prinzipiell das gleiche Allerdings: für jede Kommunikationsbeziehung eine Anfragender und ein Antwortender Organisationsmodell: vollkommen unstruktiert außer Bootstrapping-Punkt kein Kontextwissen und keine bekannte Struktur Per se keine Bezeichner, lediglich Namen Bezeichner können verteilt-algorithmisch eingeführt werden (Hashwerte...) Strukturen können verteilt-algorithmisch eingeführt werden (dynamische Supernodes...). Bessere Bezeichnungen: Collaborative Systems, dezentrale verteilte Systeme, kooperative Systeme 69