Datakom høsten 20021 Datakommunikasjon høsten 2002 Forelesning nr 11, mandag 28. oktober Eksempel på ruter med 802.11b FireWalls IP v6 FTP.

Presentasjon om: "Datakom høsten 20021 Datakommunikasjon høsten 2002 Forelesning nr 11, mandag 28. oktober Eksempel på ruter med 802.11b FireWalls IP v6 FTP."— Utskrift av presentasjonen:

1 Datakom høsten 20021 Datakommunikasjon høsten 2002 Forelesning nr 11, mandag 28. oktober Eksempel på ruter med 802.11b FireWalls IP v6 FTP

2 Datakom høsten 20022 Øvingsoppgaver Oppgave 1 a)Forklar hvordan en FireWall (brannmur) fungerer b)Hvordan må brannmuren konfigureres for å hindre at en fra utsiden kan sette opp en TCP forbindelse til nettet på innsiden? Oppgave 2 a)Hva er forskjellen på ”Go-back-N ARQ” og ”selective-reject ARQ”? b)Hva er forskjellen på en forbindelsorient og en forbindelsesløs tjeneste (”connection-oriented” og connectionless”)? c)Er TCP forbindelsesorientert eller forbindelsesløs? d)Tegn oppkoblingssekvensen for TCP (dvs. hvilke meldinger benyttes). e)Maskin A og maskin B er forbundet via et lokalnett. Maskin A har en FTP-klient og en mail-klient, mens maskin B har en FTP server og en mail server. Både FTP og SMTP (Simple mail Transfer Protocol) benytter TCP som transportprotokoll. Hvordan klarer TCP å levere data til den riktige applikasjonen.

3 Datakom høsten 20023

4 4

5 5

6 6

7 7

8 8

9 9

10 10

11 Datakom høsten 200211

12 Datakom høsten 200212 Encryption zWired Equivalent Privacy or WEP allows you to encrypt the traffic between your Wireless PC and the Gateway. It is important to remember that with WEP disabled anyone with a Wireless PC can eavesdrop on your network. 3Com recommends that you get the network working with WEP disabled first and then enable it as the last step. This will simplify setting up your network. zWireless Encryption Type There are two levels of encryption available, 64 bit and 128 bit. 128 bit WEP is more secure than 64 bit. Use the "Wireless Encryption Type" box to select the desired level. zKey Generation Method A Key is a hexadecimal (0-9, A-F) number used to encrypt and decrypt the data. There can be up to 4 keys and each key can be as long as 26 digits. The Gateway also offers a number of methods for converting plain text into hex keys. The text is much easier to remember than hex keys but it relies on your wireless adapters also supporting this feature. Different manufacturers have developed different ways of converting plain text and so interoperability is not guaranteed. If you are experiencing difficulty, the Manual Hex Key method is supported by most vendors.

13 Datakom høsten 200213 The Gateway supports 4 methods to specify the WEP Keys : z1) Manual Hex Key zThis method allows you to manually enter hex keys. Virtually all manufacturers support this scheme. z2) 3Com Encryption String zThis method is only supported by 3Com Wireless products. The string can contain any alpha numeric characters and must be between 6 and 30 characters long. A single string will automatically generate 4 unique keys for 64 or 128 bit WEP. z3) ASCII zThis method is supported by some adapter cards running under Windows XP. The string must be exactly 5 characters for 64 bit WEP and 13 characters for 128 bit WEP. You must enter a separate string for each of the 4 Keys. You can leave a string blank so long as this Key is not selected as the Active Transmit Key. z4) Passphrase zThis is another common method and similar to the 3Com Encryption string. In 64 bit WEP, the Passphrase will generate 4 different keys. However, in 128 bit WEP, this method only generates 1 key which is replicated for all 4 keys. zActive Transmit Key The "Active Transmit Key" selects which of the 4 Keys the Gateway uses when it transmits. You can change the selected key every now and then to increase the security of your network.

14 Datakom høsten 200214 Clone MAC Address Some ISP's use the hardware (MAC) address of the device you connect to the Internet with to identify you. If you have previously used a different device with your current ISP, and they use your MAC address to identify you, then you can change the MAC address on the WAN side of your Gateway to be that of your old device.

15 Datakom høsten 200215

16 Datakom høsten 200216

17 Datakom høsten 200217

18 Datakom høsten 200218

19 Datakom høsten 200219

20 Datakom høsten 200220

21 Datakom høsten 200221

22 Datakom høsten 200222

23 Datakom høsten 200223 Firewalls Two firewall types: ypacket filter yapplication gateways To prevent denial of service attacks: ySYN flooding: attacker establishes many bogus TCP connections. Attacked host alloc’s TCP buffers for bogus connections, none left for “real” connections. To prevent illegal modification of internal data. ye.g., attacker replaces CIA’s homepage with something else To prevent intruders from obtaining secret info. isolates organization’s internal net from larger Internet, allowing some packets to pass, blocking others. firewall

24 Datakom høsten 200224 Packet Filtering zInternal network is connected to Internet through a router. zRouter manufacturer provides options for filtering packets, based on: ysource IP address ydestination IP address yTCP/UDP source and destination port numbers yICMP message type yTCP SYN and ACK bits z Example 1: block incoming and outgoing datagrams with IP protocol field = 17 and with either source or dest port = 23. yAll incoming and outgoing UDP flows and telnet connections are blocked. z Example 2: Block inbound TCP segments with ACK=0. yPrevents external clients from making TCP connections with internal clients, but allows internal clients to connect to outside.

25 Datakom høsten 200225 Application gateways zFilters packets on application data as well as on IP/TCP/UDP fields. zExample: allow select internal users to telnet outside. host-to-gateway telnet session gateway-to-remote host telnet session application gateway router and filter 1. Require all telnet users to telnet through gateway. 2. For authorized users, gateway sets up telnet connection to dest host. Gateway relays data between 2 connections 3. Router filter blocks all telnet connections not originating from gateway.

26 Datakom høsten 200226 Certification Authorities zCertification authority (CA) binds public key to particular entity. zEntity (person, router, etc.) can register its public key with CA. yEntity provides “proof of identity” to CA. yCA creates certificate binding entity to public key. yCertificate digitally signed by CA. z When Alice wants Bob’s public key: z gets Bob’s certificate (Bob or elsewhere). z Apply CA’s public key to Bob’s certificate, get Bob’s public key

27 Datakom høsten 200227 Secure sockets layer (SSL) zPGP provides security for a specific network app. zSSL works at transport layer. Provides security to any TCP-based app using SSL services. zSSL: used between WWW browsers, servers for I- commerce (shttp). zSSL security services: yserver authentication ydata encryption yclient authentication (optional) z Server authentication: ySSL-enabled browser includes public keys for trusted CAs. yBrowser requests server certificate, issued by trusted CA. yBrowser uses CA’s public key to extract server’s public key from certificate. z Visit your browser’s security menu to see its trusted CAs.

28 Datakom høsten 200228 SSL (continued) Encrypted SSL session: zBrowser generates symmetric session key, encrypts it with server’s public key, sends encrypted key to server. zUsing its private key, server decrypts session key. zBrowser, server agree that future msgs will be encrypted. zAll data sent into TCP socket (by client or server) i encrypted with session key. z SSL: basis of IETF Transport Layer Security (TLS). z SSL can be used for non- Web applications, e.g., IMAP. z Client authentication can be done with client certificates.

29 Datakom høsten 200229 Kommunikasjonslagene (referert til OSI) ApplicationPresentationSession Ethernet IP ARP ICMP TCPUDP NetworkTransportData LinkPhysicalApplicationTransportNetworkData Link PPP FTPHTTP DNS OSI Internet-TCP/IP SMTP RFC871

30 Datakom høsten 200230 zRuting yIP adresser yVeivalg zFragmentering zOverføring(‘best effort’) yUpålitelig yForbindelsesløs Pakker kan: xmistes xdupliseres xkomme i feil rekkefølge IP rydder ikke opp i dette IP - Internet Protocol RFC791

31 Datakom høsten 200231 IP Header VersionIHLType of ServiceTotal length Source Address Destination Address Options Version -Hvilken verson av IP som benyttes, her vil det stå 4, siden dette er en IPv4 header IHL -Internetwork Header Length - headerens lengde i 32-bits ord (er 5 for header uten opsjoner) Type of Service -Precedence (3 bit), Delay (low/normal), Throughput (normal/high), Reliability (normal/high), Cost (normal/maximize) Total Length -Totalt antall oktetter (IP-header + data) Identification 0 DFDF MFMF Fragment Offset Identification -Benyttes for å identifisere sammenhørende fragmenter (når opprinnelig IP-pakke var for stor for link-laget). DF -Don’t Fragment - settes hvis det ikke ønskes at pakker skal fragmenteres.0 - Null - Alltid satt til 0MF - More-flag;1 hvis flere fragmenter, 0 hvis siste fragment (eller hvis ikke fragmentert). Fragment Offset -Offset i antall 64-bits ord; plassering av dette fragmentet i opprinnelig pakke (= 0 for første fragment eller hvis ikke fragmentert) Time to LiveProtocolHeader Checksum Time To Live -Maxverdi for søkets levetid. Angis i sekunder, men blir i praksis antall ruterhopp; telles ned i hver ruter det passerer inntil det når 0, da sendes det ikke videre. Protocol -Angir det overliggende lags protokoll, f.eks. TCP. RFC791 Eksempel

32 Datakom høsten 200232 IP-adresser 0 NettLokal Klasse A (0-127): 01 NettLokal Klasse B (128-191): 011 NettLokal Klasse C (192-223): RFC791

33 Datakom høsten 200233 IP-adresser zHvordan angis en IP-adresse? yfire desimale nummer, et pr. byte i adressen, separert med punktum yKalles for “dotted decimal notation” yEksempel 193.69.136.36

34 Datakom høsten 200234 IP-adresser zSpesielle adresser yBroadcast - en til alle Lokaladresse har alle bit satt til 1 yLoopback (tilgang til tjenester på egen maskin) 127.0.0.1 yAlle bit 0; ukjent IP-adresse (eller default rute) zMåter å adressere yUnicast - en til en yBroadcast - en til alle yMulticast - en til mange

35 Datakom høsten 200235 Subnett zKlasseinndelingen er lite fleksibel, og gir mange ubrukte adresser zBedre utnyttelse av adresseområdet oppnås ved bruk av subnettmasker. zEn subnettmaske angir hvor stor del av adressen som er nettprefikset (nett+subnett) og dermed også hvor stor del lokaladressen er RFC950

36 Datakom høsten 200236 Subnett, eksempel RFC791 01 NettLokal Opprinnelig klasse B (1 nett med 65.536 lokaladresser) Nå: 64 subnett, hvert med 1022 lokaladresser 01 NettSubnettLokal Subnettmaske: 255.255.252.0 eller /22

37 Datakom høsten 200237 Subnett zVariabel Length Subnet Mask yMan kan ha subnett av forskjellig størrelse yMer effektiv utnyttelse av organisasjonens adresseområde. zMåter å angi subnettmasker: y193.69.136.36, subnettmaske 255.255.255.0 y193.69.136.36/24 y/24 betyr at 24 bit benytttes til å angi nettadressen yTotalt tilgjengelig 32 bit y32 – 24 = 8 bit til host adresser RFC950

38 Datakom høsten 200238 Subnett - variable subnettmasker, eksempel RFC950 011 NettLokal Opprinnelig klasse C nett, 1 nett med 254 lokaladresser 011 NettLokal 4 subnett, hvert med 30 lokaladresser Subnett xx0 011 NettLokal 4 subnett, hvert med 14 lokaladresser Subnett 0x1x Pluss: 011 NettLokal 8 subnett, hvert med 6 lokaladresser Subnett x1x1x NÅ:

39 Datakom høsten 200239 Adresseoversetting zBedre kjent som NAT (Network Address Translator) zIP-adresser innenfor et nettverk yikke er gyldige for bruk utenfra yskal skjules for utenverdenen zEn organisasjon har færre eksterne adresser enn størrelsen på det interne nettverket tilsier  Noen adresseområder er reservert til privat bruk y10.0.0.0 - 10.255.255.255 y172.16.0.0 - 172.31.255.255 y192.168.0.0 - 92.168.255.255  Disse adressene kan fritt benyttes bak en brannmur uten å komme i konflikt med andre sine IP-adresser på Internett. RFC2663

40 Datakom høsten 200240 IP addressing: CIDR zclassful addressing: yinefficient use of address space, address space exhaustion ye.g., class B net allocated enough addresses for 65K hosts, even if only 2K hosts in that network zCIDR: Classless InterDomain Routing ynetwork portion of address of arbitrary length yaddress format: a.b.c.d/x, where x is # bits in network portion of address 11001000 00010111 00010000 00000000 network part host part 200.23.16.0/23

41 Datakom høsten 200241 The Internet Network layer routing table Host, router network layer functions: Routing protocols •path selection •RIP, OSPF, BGP IP protocol •addressing conventions •datagram format •packet handling conventions ICMP protocol •error reporting •router “signaling” Transport layer: TCP, UDP Link layer physical layer Network layer

42 Datakom høsten 200242 IPv6 - Hvorfor? zFor få adresser i IPv4 ySnart ikke fler igjen zFor dårlig organisering av IPv4 adressene yMange entries i ruting-tabeller yMye data som må utveksles mellom ruterne zSvakheter i IPv4 skal bedres ySikkerhet yQuality of Service IPng working group

43 Datakom høsten 200243 VersionIHLType of ServiceTotal Length Source Address Destination Address Options Identification 0 DFDF MFMF Fragment Offset Time to LiveProtocolHeader Checksum IPv4 header  IPv6 header Total Length  Payload Length  økes til 128 bits TTL  Hop LimitProtocol  Next Header Ikke behov for IHL (Internet Header Length) siden IPv6-headeren har konstant lengde. Type of Service - noe av det denne har vært brukt til kan erstattes av Class- parametern i IPv6 Fragmentering hånderes i egen ‘Fragmentation Header’, ikke nødvendig med fragmenteringsinfo i IPv6-headeren. Funksjonen er også endret. Header Checksum - Kan fjernes fordi lag 2 utfører feilkontroll, samt at TCP har ende-til-ende feilkontroll Options hånderes i egne ‘Extention Headers’.

44 Datakom høsten 200244 IPv6 Header RFC2460 Source Address Destination Address Hop LimitNext HeaderPayload Length Flow LabelVersionTraffic class Version - samme navn og funksjon som i IPv4, men annen verdi, skal nå identifisere IPv6 (=6). Class - Ny for v6 (evt. erstatter ToS (Type of Service) i v4), kan benyttes for å skille typer av trafikk Flow Label - Ny for v6, avsender benytter denne til å angi QoS (Quality of Service), f.eks real-time data som tale og video. Payload Length (  v4 Total Length) - antall bytes data. Til forskjell fra v4 inkluderes ikke lengden på headeren, men evt. ‘extension headers’ er inkludert. Next header (=v4 Protocol) - Beskriver neste header (i samme pakke), enten dette er en ‘extension header’ eller header for overliggende protokoll. Hop Limit (=v4 Time To Live) - Parameter har endret navn for å bedre samsvare med virkeligheten.

45 Datakom høsten 200245 IPv6 Header zEnklere header enn v4 yKun dobbelt så stor, selv om addressefeltene er 4- doblet yElementer som ikke alltid benyttes, er fjernet fra header zIngen begrensning på lengde på opsjonsfelt yOpsjoner kommer nå med egne header, ikke lenger inkludert i generell IP-header yDet kan være flere opsjoner (extension headers) i en IP-pakke. RFC2460

46 Datakom høsten 200246 IPv6 Extension Headers zHop-by-Hop Options header zRouting header zFragment header zAuthentication header (IPSec- Internet Protocol Security) zEncapsulating Security Payload header (IPSec- Internet Protocol Security) zDestination Options header RFC2460

47 Datakom høsten 200247 IPv6 adresser z3 kategorier adresser yUnicast, single interface yMulticast, sett av interface yAnycast, nærmeste interface  Ingen broadcast addresses in IPv6 zAdressen angis i hex, med ‘:’ mellom hvert 16-bits ord. yEksempel: 1080:0:0:0:8:800:200C:417A yKan også skrives: 1080::8:800:200C:417A RFC2373

48 Datakom høsten 200248 Fra IPv4 til IPv6 Hvordan skal oppgradering til IPv6 foregå? zVanskelig (=umulig) og kostbart å få oppgradert hele Internett samtidig zMå være mulig å gjøre dette gradvis zIPv4 og IPv6 må kunne fungere side om side i samme nett i en lengre periode zTransisjon fra IPv4 til IPv6 har vært vurdert helt fra begynnelsen av, dvs. en del av designet i IPv6. RFC2893

49 Datakom høsten 200249 Fra IPv4 til IPv6 zFlere mulige løsninger: yDual stack, dvs. har support for både IPv4 og IPv6 yTunneling mode for å kjøre IPv6 over IPv4 zIPv4-kompatible IPv6-adresser zAdressekonvertering zDisse vil kombineres RFC2893

50 Datakom høsten 200250 IPv4 Dual stack IPv6 RFC2893 •All trafikk som både origineres og termineres innenfor IPv6 området går med IPv6 •All trafikk som har minst et endepunkt i IPv4-området går med IPv4, selv om det andre endepunktet skulle være i IPv6- området.

51 Datakom høsten 200251 Dual stack zEn node har både IPv4 og IPv6 implementert yHar da også normalt tilordnet både IPv4 og IPv6 adresse yBegge disse må ha et record i DNS zVelger v4 eller v6 på bakgrunn av yinformasjon fra navneserver (ang. destinasjon) yHva hvis det returneres både en v4 og en v6 adresse? xDa må det velges, enten av applikasjonen eller at ‘resolveren’ filtrerer / bestemmer prioriteringen. RFC2893

52 Datakom høsten 200252 IPv6 i IPv4 tunnel IPv4 IPv6 RFC2893

53 Datakom høsten 200253 Adresse og protokollkonvertering IPv4  IPv6 IPv4 IPv6 RFC2765RFC2765, RFC2766 RFC2766