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

Datakom høsten Ø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.

Datakom høsten 20023

4

5

6

7

8

9

10

Datakom høsten

Datakom høsten 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.

Datakom høsten 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.

Datakom høsten 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.

Datakom høsten

Datakom høsten

Datakom høsten

Datakom høsten

Datakom høsten

Datakom høsten

Datakom høsten

Datakom høsten

Datakom høsten 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

Datakom høsten 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.

Datakom høsten 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.

Datakom høsten 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

Datakom høsten 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.

Datakom høsten 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.

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

Datakom høsten 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

Datakom høsten 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

Datakom høsten IP-adresser 0 NettLokal Klasse A (0-127): 01 NettLokal Klasse B ( ): 011 NettLokal Klasse C ( ): RFC791

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

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

Datakom høsten 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

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

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

Datakom høsten Subnett - variable subnettmasker, eksempel RFC 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Å:

Datakom høsten 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 y y y  Disse adressene kan fritt benyttes bak en brannmur uten å komme i konflikt med andre sine IP-adresser på Internett. RFC2663

Datakom høsten 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 network part host part /23

Datakom høsten 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

Datakom høsten 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

Datakom høsten 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’.

Datakom høsten 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.

Datakom høsten 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

Datakom høsten 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

Datakom høsten 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

Datakom høsten 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

Datakom høsten 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

Datakom høsten 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.

Datakom høsten 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

Datakom høsten IPv6 i IPv4 tunnel IPv4 IPv6 RFC2893

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