Transport layer Transp anspor ort t se services ices and nd pr - - PowerPoint PPT Presentation

Transport layer

Transp anspor

• rt

t se services ices and nd pr protocols

• cols

 Provide communication between

application processes running on different hosts

 Protocols run in end system OS

 Sender transport breaks up application

messages, passes to network layer

 Receiver transport reassembles

application messages, passes to destination application

 Two main transport protocols

 TCP and UDP

Portland State University CS 430P/530 Internet, Web & Cloud Systems

applicatio n transport network data link physical applicatio n transport network data link physical

Transp anspor

• rt

t Layer er Func unctio tions ns

 Demux to upper layer  Connection setup  Delivery semantics  Flow control  Congestion control  Security

Portland State University CS 430P/530 Internet, Web & Cloud Systems

De Demu mux x to up uppe per r layer er (both th TCP P & UDP DP)

 Delivering data to correct application process  Which process gets this request?  Done via 16-bit source port and 16-bit destination port in both

UDP and TCP

Portland State University CS 430P/530 Internet, Web & Cloud Systems

SMTP

HTTP DNS NTP TCP UDP IP NET1 NET2 NETn …

TCP/UDP IP

Port Number

Datalink NET

Protocol Field Type Field

Interne ernet t service vices s la layered ered on top p of TCP/U CP/UDP DP

 What uses TCP?

 HTTP (Web pre-2016)  SMTP (E-mail transmission)  IMAP

, POP (E-mail access)

 What uses (mainly) UDP?

 DNS  NTP (network time protocol)  Highly interactive on-line games (First-Person Shooters)

 Many protocols can use both

 e.g. DNS

Portland State University CS 430P/530 Internet, Web & Cloud Systems

 Protocols and their ports listed in /etc/services on *nix or

C:\WIN*\system32\services

 IANA

 http://www.iana.org/assignments/port-numbers

Portland State University CS 430P/530 Internet, Web & Cloud Systems

echo 7/tcp echo 7/udp ssh 22/tcp # SSH Remote Login Protocol ssh 22/udp telnet 23/tcp smtp 25/tcp domain 53/tcp # Domain Name Server domain 53/udp http 80/tcp # WorldWideWeb HTTP http 80/udp # HyperText Transfer Protocol netbios-ssn 139/tcp # NETBIOS session service netbios-ssn 139/udp bgp 179/tcp # Border Gateway Protocol bgp 179/udp https 443/tcp # http protocol over TLS/SSL https 443/udp microsoft-ds 445/tcp # Microsoft Naked CIFS microsoft-ds 445/udp

source port # dest port # 32 bits

Application data (message) UDP segment format

length checksum Length, in bytes of UDP segment, including header

UDP DP: : Use ser Da Datagram tagram Protocol

• col

 Barebones transport protocol

Portland State University CS 430P/530 Internet, Web & Cloud Systems

UDP DP and nd tr transp nspor

• rt

t layer er func unctio tions ns

 Demux via port numbers  Connection setup (none)

 Connectionless  No handshaking between sender and receiver  Minimal state

 Delivery semantics

 Unreliable, unordered, mostly unicast

 No flow control support  No congestion control support  No security support  Often used for for streaming multimedia apps and other apps that

are loss tolerant, but rate sensitive

Portland State University CS 430P/530 Internet, Web & Cloud Systems

TCP: P: Transm ansmiss ission ion Contr ntrol

• l Protocol
• col

 Connection-oriented  Delivery semantics

 Reliable, in-order byte stream  Unicast (point-to-point)  Full duplex (bi-directional flow)

 Flow and congestion controlled:

 Pipelined operation where size of "pipe" (i.e. bandwidth) controlled  Control algorithm keeps sender from overwhelming receiver or

network

 Done over IP via checksum, sequence numbers, acknowledgments,

retransmissions, rate limits on sender

Portland State University CS 430P/530 Internet, Web & Cloud Systems

socket door TCP send buffer TCP receive buffer socket door

segment

application writes data application reads data

• 1. Wh

. What at if if th the Da e Data ta is is C Cor

• rrupt

rupted ed?

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Internet GET windex.html GET index.html Solution: Add a checksum Problem: Data Corruption 0,9 9 6,7,8 21 4,5 7 1,2,3 6

X

Seg egme ment nt integrit egrity y via a checks ecksum um

 Checksum included in

header by sender

 Generated by treating data in

the packet as numbers and adding them

 Receiver performs same

• peration as sender and

checks result

 Corruption detected when

no match

Portland State University CS 430P/530 Internet, Web & Cloud Systems

source port # dest port #

32 bits

application data (variable length) sequence number acknowledgement number

Receive window Urg data pnter checksum

F S R P A U

head len not used

Options (variable length)

Solution: Add Sequence Numbers Problem: Out of Order

• 2. Wh

. What at if if th the Dat e Data a is is O Out of ut of Or Orde der?

Portland State University CS 430P/530 Internet, Web & Cloud Systems

GET x.th inde ml GET x.thindeml GET index.html ml 4 inde 2 x.th 3 GET 1

Seq eque uence nce num umber ers

 Each segment labeled with a “unique”

number to establish ordering

 Allows receiver to identify which

packets have been received

 Initialized during connection setup via

3-way handshake

Portland State University CS 430P/530 Internet, Web & Cloud Systems

A B

SYN + Seq A SYN+ACK-A + Seq B ACK-B

source port # dest port #

32 bits

application data (variable length) sequence number acknowledgement number

Receive window Urg data pnter checksum

F S R P A U

head len not used

Options (variable length)

3.

• 3. Wh

What at if if th the Dat e Data a is is L Los

• st?

t?

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Internet GET index.html Problem: Lost Data Internet GET index.html Solution: Timeout and Retransmit (implemented in OS) GET index.html GET index.html

How? w? Ackno knowledgem wledgemen ents ts

 TCP receiver sends an

acknowledgement back to sender for the data it receives

 Sending OS keeps a copy of every

segment it sends

 Acknowledgments allows sender to

“move on” (i.e. discard copy once it is known to have been delivered)

 Also lets sender know that network

has the capacity to deliver its packets

Portland State University CS 430P/530 Internet, Web & Cloud Systems

source port # dest port #

32 bits

application data (variable length) sequence number acknowledgement number

Receive window Urg data pnter checksum

F S R P A U

head len not used

Options (variable length)

Retran etransmi smissi ssions

• ns

 Two ways

 Via timeout events

 TCP uses single retransmission timer  Sender sends segment and sets a timer  If no acknowledgment received and timer goes off, retransmit  Timer is based on measured round-trip times and round-trip time variations

 (e.g. Timeout after Average RTT + 2*standard deviation of RTT)

 Via missing acknowledgements

 If receiver reports it has received packets 1, 3, 4, and 5, sender automatically

resends 2 before timeout

Portland State University CS 430P/530 Internet, Web & Cloud Systems

• 4. What

t if rec eceiv eiver er has s no res esour urces ces (flow w cont ntrol)?

• l)?

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Internet PUT remix.mp4 Problem: Overflowing receiver buffers Solution: Receiver advertised window Internet PUT remix.mp4

16KB free

TCP P flow w contr ntrol

• l

 Receiver has a finite buffer

RcvBuffer

 Flow control to make sure sender

won't overflow it

 Rcvr advertises spare room in

buffer by including value of

RcvWindow in each

segment/ACK

 Also known as the “advertised”

window

 Sender limits unACKed data to RcvWindow to avoid overflow

Portland State University CS 430P/530 Internet, Web & Cloud Systems

source port # dest port #

32 bits

application data (variable length) sequence number acknowledgement number

Receive window Urg data pnter checksum

F S R P A U

head len not used

Options (variable length)

• 5. What

t if Netw etwor

• rk

k is Ov s Over erloaded? loaded?

 Short bursts: buffer  What if buffer overflows?

 Packets dropped and retransmitted  Sender adjusts rate until load = resources

 Called “Congestion control”

Portland State University CS 430P/530 Internet, Web & Cloud Systems

TCP P cong ngest estion ion contr trol

• l

 Goal

 Prevent spurious retransmissions of packets still in flight  Reduce the number of undelivered packets which consume network

resources and are dropped before reaching destination

 Mechanism

 Sender keeps an internal congestion window (cwnd) and “probes” for

usable bandwidth continuously

 Increase cwnd until loss (congestion)  Decrease cwnd upon loss

 Size of window denotes how much network is able to absorb

 “Size of the pipe”  Make cwnd as large as possible without loss

 Sender’s maximum window the minimum of receiver's advertised

window and congestion window

 min(RcvWindow,cwnd)

Portland State University CS 430P/530 Internet, Web & Cloud Systems

TCP wi windo ndowing wing algori gorith thm (1990s)

 Slow start (compared to sending at full rate immediately)

 When connection begins, quickly ramp up to respectable rate  Increase rate exponentially fast until first loss event

 cwnd = 1 for 1st RTT  cwnd = 2 for 2nd RTT  cwnd = 4 for 3rd RTT

 If loss occurs when cwnd = W

 Network can handle 0.5W ~ W segments  Cut cwnd in half, grow window more slowly  Grow cwnd by 1 every round-trip time  Results in additive increase

Portland State University CS 430P/530 Internet, Web & Cloud Systems

1 2 4

RTT RTT RTT

W W+1 2W Congestion avoidance Fast Retransmit/Recovery Slow-start

TCP P th throug ughput hput (1990 90s)

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Issue sue #1: : Short t tr tran ansf sfer ers

 Short transfers perform poorly

 Flows timeout on loss if cwnd < 3  Multiple round-trip times needed for even small HTML files!

 Parameters tuned for 1980s modems!

 cwnd = 1 gets you 20kbps (500 byte segments with 200ms RTT)  Cable modems at 1000x capacity

 Solution: Use larger initial cwnd

 IETF approved initial cwnd = 10  /usr/src/linux/include/net/tcp.h

/* TCP initial congestion window as per draft-hkchu-tcpm-initcwnd-01 */ #define TCP_INIT_CWND 10

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Iss ssue ue #2: Large rge W ( (long ng-fat at pi pipe pes) s)

 Requires bit error rate smaller than most links  Packets transferred in sawtooth from W to 2W (50,000 to 100,000)

 W + (W+1) + (W+2) …. + 2W = (3W/2) * (W+1) = 1.5W(W+1)  For W=100,000, need no losses for 15 billion packets (L < 10-10)

 Sawtooth results in persistently low link utilization

 Time to go from W to 2W? => over an hour!  Averages ¾ max. rate

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Packet loss Time (RTT) Congestion avoidance Packet loss Packet loss cwnd Slow start Packet loss

100,000 10Gbps 50,000 5Gbps 1.4 hours 1.4 hours 1.4 hours

TCP

 Solution #1: TCP Cubic for long-fat pipes

 The congestion window is a cubic function of time since the last

congestion event, with the inflection point set to the window prior to the event.

 Used ininially in QUIC and in Linux versions > 2.6.19

Portland State University CS 430P/530 Internet, Web & Cloud Systems

CUBIC window curves with competing flows (NS simulation in a network with 500Mbps and 100ms RTT), C = 0.4, β = 0.8.

Portland State University CS 430P/530 Internet, Web & Cloud Systems

 Solution #2: BBR

 Google's replacement to TCP Cubic (pluggable in QUIC)  Bottleneck Bandwidth and Round-trip propagation time

 Use recent measurements of network bandwidth and round-trip time to model

how quickly to send (e.g. machine learning)

 Experimental, but Google now owns many clients and servers

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Revis isiting iting Trans anspor port t Layer er Fun unctions ctions

 Demux to upper layer  Connection setup  Delivery semantics  Flow control  Congestion control  Security

Portland State University CS 430P/530 Internet, Web & Cloud Systems

SSL/TLS

TCP/ P/IP IP se securit urity

 No initial support for

 Secrecy (eavesdropping)  Server authentication (impersonation)  Message integrity (man-in-the middle tampering)

 Netscape Secure Sockets Layer (SSL) (1994)

 Bolted on between application and transport layer to add security

 Now: Transport Layer Security (TLS)

 HTTP over TLS => https://  www.openssl.org

 Adoption initially slow

 Server overhead  Lack of incentive  Difficulty in obtaining certificates

 Now ubiquitous

 Hardware support (x86 instructions for AES, dedicated ASICs)  Snowden surveillance revelations  Let’s Encrypt (2014) free TLS certificates

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Bu But t first st, , sy symm mmetric etric en encr crypt yption ion

 Three main algorithms:

 k = Keygen(n)  C = Encrypt(k, M)  M = Decrypt(k, C)

 Use the same key to encrypt and decrypt!

 If you can encrypt, then you can also decrypt

 Examples:

 Block ciphers: AES (Advanced Encryption Standard)  Stream ciphers: Salsa20/ChaCha

 Performance: Fast, easy to accelerate, good for large amounts of

data

 But, has a key distribution problem

Portland State University CS 410/510 Blockchain Development & Security

Asym ymme metric tric encr cryption yption (P (Publi blic c Key, , Pr Privat ate e Key) y)

 Also has three main algorithms

 Key generation  Encryption  Decryption  But also supports digital signatures and their verification

 Uses different keys to encrypt and decrypt (“asymmetric” crypto)

 Anyone can encrypt a message  Only the owner of the private key can decrypt

 Examples:

 RSA  ECDSA

 Performance: Slow, hard to accelerate, good for only small amounts of

data

 But, easy to distribute public keys

Portland State University CS 410/510 Blockchain Development & Security

Fi Figu gure re def efini initions tions

 Public key  Private key (kept secret)  Plaintext  Ciphertext

Asy symmetric mmetric en encryption yption

 Bob uses key generation algorithm to generate keys

 Bob's public key  Bob's private key

 Bob publishes  Alice encrypts her message with and sends it to Bob  Only Bob can decrypt Alice's message with

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Enc Dec

Di Digi gital tal si sign gnatures atures

 Public-key also supports digital signing and verification algorithms

 Used to generate signatures to authenticate data (non-repudiation)

 Bob with a message to withdraw $1 from Bank of Alice  Bob signs message using private key  Sends message with signature to Alice  Alice uses Bob's public key to verify only Bob could have sent it  Debits Bob's account $1 and sends him $1

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Verify Sign

Typi pical cally ly, , hash sh of me mess ssage ge si sign gned ed

Portland State University CS 410/510 Blockchain Development & Security

Asy symmetric mmetric + sy symm mmetric etric us used ed toget gether er

 Asymmetric encryption operations expensive  Symmetric encryption has key distribution problem  Combine

 Use asymmetric encryption to establish secret symmetric encryption

key

 Use symmetric encryption key for large-scale data transfer

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Practical actical Rea eal-World

• rld En

Encrypt yption ion (PGP) P)

 Combine secret key and public key crypto  Goal: Send a large message M to Bob who has public key

 Generate a random (symmetric) key

k = Keygen(n)

 Encrypt M with k

Cm = Enc(k, M)

 Encrypt k with

Ck = Enc( , k)

 Send Cm and Ck to Bob  Bob decrypts k from Ck

k = Dec( ,Ck)

 Then uses k to decrypt M

M = Dec(k, Cm)

Portland State University CS 410/510 Blockchain Development & Security

Bob Bob Bob Bob

Qu Ques estio tion

 How do you securely obtain someone's public key?  Must exchange yours for mutual authentication  Doesn't work for web transactions!

Portland State University CS 430P/530 Internet, Web & Cloud Systems

HTTPS TPS and nd cer ertif tifica icate e aut uthorities rities

 How does Alice (browser) obtain an authentic copy of Bob ?

 Through a trusted third-party called a Certificate Authority (CA)  Alice's browser and Bob's server contain public-key of CA (via software dist)  Bob asks CA to sign a certificate containing his public key  CA validates proof

Portland State University CS 430P/530 Internet, Web & Cloud Systems

CA

Bob +proof “I am Bob.com”

Alice

CA

check proof Issue Cert Bob.com key is Bob ( CA sig) Bob.com key is Bob ( CA sig) ( Bob

Bob )

Bob.com

CA

Verify cert

Did CA vouch for Bob?

For Let's Encrypt (you own DNS record and IP)

https://bob.com

CA

Cer ertif tificat icate e Aut uthorities rities

 How many are there in your browser (or OS)?  Do you feel safe trusting them?  Example: Chrome onWindows (in Settings)

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Master secret encrypted w/

SSL/TLS /TLS (se server er aut uth only) ly)

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Client random + cipher suites Sever random + cipher suites +

Server Hello Client Hello Client Key Exchange Finished Encrypted application data (e.g. https)

• 1. Verify cert with ,

extract ,encrypt master secret w/ key

• 2. Decrypt master

secret with generate keys and randoms Slow

Client Server

• 3. Generate keys from

master secret + randoms

Initial SSL Handshake

Iss ssue ue

 Computationally expensive, multiple round-trip time delays  TLS 1.3

 Fast-open  Establish cryptographic key between client and server upon first

connection

 Used as a connection cookie similar to ssh key for your Bitbucket repository)

 Allow server to immediately send to client upon initial SYN packet to

remove an RTT delay

 Basis for 0-RTT handshake in QUIC

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Res esult ult

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Iss ssue ue #1

 But, what if someone reserves 0regonctf.org?  Can they generate?  Yes. Conflation in UI of security and identity  We have trained a generation of Internet users to believe the green

lock provides both secrecy *and* authenticity

Portland State University CS 430P/530 Internet, Web & Cloud Systems

 Green padlock and "s" at the end of https now viewed as a tacit

guarantee that a site is trustworthy!

 Let's Encrypt being used heavily for phishing attacks

 Result

 They [phishing attackers] are more frequently incorporating website certificates – third-

party verification that a site is secure – when they send potential victims emails that imitate trustworthy companies or email contacts.

Portland State University CS 430P/530 Internet, Web & Cloud Systems

 According to FireEye's Q1 2019 Email Threat report, released on

Tuesday, there has been a 26 percent increase in the use of malicious URLs made to appear legitimate through HTTPS, quarter-on-quarter, while the popularity of the traditional malware-laden email attachment is steadily falling.

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Iss ssue ue #2

 Two browser windows or one?

Portland State University CS 430P/530 Internet, Web & Cloud Systems

Iss ssue ue #3

 What happens if a CA is compromised (including )?

 2011: Comodo and DigiNotar CAs hacked, issue certs for Gmail,

Yahoo! Mail, …

 2013: TurkTrust issued cert. for gmail.com  2014: Indian NIC (intermediate CA trusted by the root CA

IndiaCCA) issue certs for Google and Yahoo! domains

 2015: MCS (intermediate CA cert issued by CNNIC) issues certs for

Google domains

 Rogue nation-states owning certificate authorities  Rogue CA mints certificates for anyone wanting to impersonate

another site

Portland State University CS 430P/530 Internet, Web & Cloud Systems

CA

En Enab ables les ma man in th the mi e middle ddle att ttack ack

Attacker proxies data between user and bank. Sees all traffic and can modify data at will. GCHQ Flying Pig program

Portland State University CS 430P/530 Internet, Web & Cloud Systems

bank.com

attacker ClientHello ClientHello BankCert BadguyCert of bank.com ServerCert (BankCert) ServerCert (BadguyCert) GET https://bank.com SSL key exchange SSL key exchange

k1 k1 k2 k2

HTTP data enc with k1 HTTP data enc with k2 (cert for bank.com signed by a rogue CA)

Potential ential so solut utions ions

 See Web Security course  Dynamic HTTP public-key pinning

 Let a site declare CAs that can sign its cert  On subsequent HTTPS, browser rejects certs issued by other CAs  TOFU: Trust on First Use

 Certificate Transparency: [LL’12]

 CAs must advertise a log of all certs. they issued  Browser will only use a cert if it is published on log server

 Efficient implementation using Merkle hash trees

 Companies can scan logs to look for invalid issuance  Certs on a block-chain?

Portland State University CS 430P/530 Internet, Web & Cloud Systems