6 app-tcp

Week 6Internet applications

UDP and TCP

Agenda

•Internet applications

•DNS

•Email

•Web

•UDP

•TCP

DNS messages

Identification Flags

32 bits

Number of additionalNumber of authority

Number of answers12 bytes

Questions(variable number of resource records)

Number of questions

Answers(variable number of resource records)

Authority(variable number of resource records)

Additional information(variable number of resource records)

Each DNS request contains a number that will be returned in theresponse by the server to allow the client to match the request.

lQuestion/ResponselRecursive question or notlAuthoritative answer or notlPossible error

Examples

•Wireshark packet traces

•openDNS resovers

•8.8.8.8

•2001:4860:4860::8888

digdig www.ietf.org @2001:4860:4860::8888

; <<>> DiG 9.8.3-P1 <<>> www.ietf.org @2001:4860:4860::8888;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36945;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:;www.ietf.org. IN A

;; ANSWER SECTION:www.ietf.org. 1441IN CNAME www.ietf.org.cdn.cloudflare.net.www.ietf.org.cdn.cloudflare.net. 43 IN A 104.20.1.85www.ietf.org.cdn.cloudflare.net. 43 IN A 104.20.0.85

;; Query time: 39 msec;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888);; WHEN: Tue Oct 21 09:16:50 2014;; MSG SIZE rcvd: 107

dig

•Packets exchanged

sudo tcpdump -n -i en4 -vv udp port 53tcpdump: listening on en4, link-type EN10MB (Ethernet), capture size 262144 bytes09:16:50.749400 IP6 (flowlabel 0x8ea5d, hlim 64, next-header UDP (17) payload length: 38) 2001:6a8:3080:2:2908:3cb4:bbb4:ae0e.56551 > 2001:4860:4860::8888.53: [bad udp cksum 0x602c -> 0x0ffa!] 36945+ A? www.ietf.org. (30)09:16:50.769351 IP6 (hlim 55, next-header UDP (17) payload length: 115) 2001:4860:4860::8888.53 > 2001:6a8:3080:2:2908:3cb4:bbb4:ae0e.56551: [udp sum ok] 36945 q: A? www.ietf.org. 3/0/0 www.ietf.org. CNAME www.ietf.org.cdn.cloudflare.net., www.ietf.org.cdn.cloudflare.net. A 104.20.1.85, www.ietf.org.cdn.cloudflare.net. A 104.20.0.85 (107)

wireshark

wireshark

DNS spoofing attack

•What is this attack ?

•How to counter it ?

Agenda


•DNS

•Email

•Web

•UDP

•TCP

MIME•Multipurpose Internet Mail Extensions

•Constraints

•must remain compatible with old email servers

•short US-ASCII Lines

•must support non-English text

•must support various formats

•must allow to transmit audio, video, ..

MIME (2)• New header fields

• MIME-Version:

• version of MIME used to encode message

• Content-Description:

• comment describing the content of the message

• Content-Type:

• type of information inside message

• Content-Transfer-Encoding:

• how the message has been encoded

• Content-Id:

• unique identifier for the content

MIME: Content-Type• Content-Type : type/encoding

• type of content• text, image, video, application• multipart

• encoding of content• text/plain , text/html, image/gif,

image/jpeg , audio/basic, video/mpeg, video/quicktime, application/octet-stream, application/postscript

• multipart/alternative, multipart/mixed• attachment

Character setsl How to support rich character sets ?

•Content-Type: text/plain; charset=us-ascii

•Content-Type: text/plain; charset=iso-8859-1

•Character set suitable for Western European languages, defined by ISO, 8 bits per character

•Content-Type: text/plain; charset=unicode

•Universal character set

Content encoding•How to encode non-text data ?

•Base64

•Base64

•uses ASCII characters A...Z,a...z,0...9, "+" et "/"

•A=0, B=1, C=2, ... +=62 et /=63

•Each character is used to encode 6 bits

•24 bits from initial message -> 4 ASCII characters

•Special character “= ” used for padding

Multipart/mixed

Date: Mon, 20 Sep 1999 16:33:16 +0200From: Nathaniel Borenstein <[email protected]>To: Ned Freed <[email protected]>Subject: TestMIME-Version: 1.0Content-Type: multipart/mixed; boundary="simple boundary"

preamble, to be ignored

--simple boundaryContent-Type: text/plain; charset=us-ascii

partie 1

--simple boundaryContent-Type: text/plain; charset=us-ascii

partie 2--simple boundary

mailto:[email protected]



Agenda


•DNS

•Email

•Web

•UDP

•TCP

HTTP

ClientServer

MethodHeaderCRLF

MIME Document

Request

Method GET

lPOSTl...

Header contains additional informationabout request sent by client

Status lineHeaderCRLF

MIME Document

Response

Header contains information about serverand optional parameters specific to response

Success or failure

HTTP is a stateless protocol, server does not maintain any state fromone request to another

HTTP/1.0

• HTTP 1.0 - non-persistent connection

Client Server

CONNECT.request CONNECT.indication

CONNECT.confirmCONNECT.response

DATA.request(Request)

DATA.req(Response)

DATA.ind(Request)

DATA.ind(Response)

DISCONNECT.indDISCONNECT.req

DISCONNECT.reqDISCONNECT.ind

HTTP : Methods• Methods

• GET

• method used to request a "document" stored on server

• GET <document> HTTP/1.0• POST

• method used to send a "document" to a server

•document is part of the request and encoded as a MIME document

Request headers• Host: <name>

• Name of the server where the document is stored

• Authorization

• allows to perform access control• If-Modified-Since: <date>

• server will only send if more recent than date• Referer: <url>

• URL visited by the client before this request• User-Agent: <agent>

• client’s browser

HTTP : Status line

• Format : Version_HTTP Code Comment • Success/Failure

• 2xx : Success• Example : HTTP/1.0 200 OK

• 3xx : Redirection • 4xx : Client-side error• 5xx : Server-side error

HTTP Response

• Date• date of the document attached to

response• Server

• Name and version of http server used• Content-*

• MIME header of the attached document

HTTP 1.1HTTP 1.0

a single TCP connection is used to transmit a single document (html file, image,...)

HTTP 1.1

uses a single persistent TCP connection

This TCP connection can be used for several requests and the corresponding responses

the cost of establishing and releasing the TCP connection is amortised over multiple requests

Although HTTP 1.1 uses a single TCP connection for multiple requests, HTTP 1.1 remains stateless

HTTP 1.1Client

Server

CONNECT.request CONNECT.indication

CONNECT.confirm CONNECT.response

DISCONNECT.indDISCONNECT.req

DISCONNECT.reqDISCONNECT.ind

HTTP/1.1 200 OKKeep-Alive: timeout=15, max=99

Connection: Keep-Alive...

GET / HTTP1.1Connection: Keep-Alive

... HTTP/1.1 200 OKKeep-Alive: timeout=15, max=100

Connection: Keep-Alive...GET /images/logo.gif HTTP1.1

Connection: Keep-Alive...

HTTP Authentication

Client

Server

HTTP/1.0 401 Authorization reqWWW authenticate: machin

...

GET / HTTP1.1...

Browser asks user/password to user

HTTP/1.1 200 OK...

GET / HTTP1.1Authorization: User-password

...

GET /images/t.gif HTTP1.1Authorization: User-password

...Browser sends user/password in each request

http://WWW/

HTTP Cookies

Client

Server

HTTP/1.0 200 OKSet-Cookie: machin

...

GET / HTTP1.1...

Browser saves cookie

HTTP/1.1 200 OK...

GET /doc HTTP1.1Cookie: machin

...

GET /images/t.gif HTTP1.1Cookie: machin

...Browser sends cookie in all

requests sent to server

Response is functionof URL and cookie

Normal response

Examples

•Wireshark packet traces

•Google chrome network diagnostics

Example

curl -v www.ietf.org* Rebuilt URL to: www.ietf.org/* Hostname was NOT found in DNS cache* Trying 2400:cb00:2048:1::6814:155...* Connected to www.ietf.org (2400:cb00:2048:1::6814:155) port 80 (#0)> GET / HTTP/1.1> User-Agent: curl/7.38.0> Host: www.ietf.org> Accept: */*>

Example< HTTP/1.1 200 OK< Date: Tue, 21 Oct 2014 07:31:08 GMT< Content-Type: text/html< Transfer-Encoding: chunked< Connection: keep-alive< Set-Cookie: __cfduid=d90d850d78da8f53eb24ac0bed60aa2231413876667742; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.ietf.org; HttpOnly< Last-Modified: Fri, 10 Oct 2014 22:38:16 GMT< ETag: W/"8842406-4ac2-50519347abeda"< Vary: Accept-Encoding* Server cloudflare-nginx is not blacklisted< Server: cloudflare-nginx< CF-RAY: 17cbc0f5613b0c23-AMS< <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml">

Chrome

Agenda


•DNS

•Email

•Web

•UDP

•TCP

Transport layer

•Objectives

•Improve service provided to applications

•Multiplexing

Physical Physical

Datalink Datalink

NetworkNetwork

Physical

Datalink

Network

SegmentsTransport Transport

Network service

•Characteristics

•Connectionless

•Unreliable

•Maximum packet size

Physical Physical

Datalink Datalink

Packets NetworkNetwork

Physical

Datalink

Network Packets

UDP protocol

Source Port Destination port

UDP length UDP Checksum8 bytes

Payload

32 bits

ConstraintEach UDP segment mustfit inside a single IP packet

Used to identify the application that will receive this segment on destination

host

Checksum computed over the entire UDP segment and part of the IP

header to detect transmission errors.0 means that the sender did not

compute a checksum.

Used to identify the application that sent this segment on sending host

UDP ports

ServerClientSource port : 1234Destination port: 5678

Request

Response

Source port : 5678Destination port: 1234

UDP : limitations

• Maximum length of UDP SDUs depends on maximum size of IP packets

• Unreliable connectionless service• SDUs can get lost but transmission

errors will be detected

• UDP does not preserve ordering

• UDP does not detect nor prevent duplication

Usage of UDP•Request-response applications

•DNS, RPC, NFS, ..

•Applications with short delay

•Games

•Multimedia transfer

•Voice over IP

•Video over IP

Agenda


•DNS

•Email

•Web

•UDP

•TCP

TCP

•Service provided

•Connection-oriented

•Reliable

•No losses, no errors, no duplications

•Bytestream

TCP port numbers

Server : SClient : CSource Port : 1234Destination Port: 5678

Request

Response

Source Port : 5678Destination Port: 1234

Established TCP connections on clientLocal IP Remote IP Local Port Remote Port

C S 1234 5678

Established TCP connections on serverLocal IP Remote IP Local Port Remote Port

S C 5678 1234

TCP segment

Source port Destination port

Payload

32 bits

Checksum Urgent pointer

THL Reserved Flags

20 bytes

Sequence number

Optional header extension

Window

Flags :used to indicate the function of a segmentSYN : used during establishmentFIN : used during connection releaseRST : used in case of problemsACK : if true, means that the Acknowledgementnumber inside the segment is valid

Computed over the entire segment and part of the IP

header

Acknowledgement number

Segment header length

Multiple connections

Client: A

Client : B

Server : S

TCP connections on serverIP local IP remote Port local Port remoteS A 80 1234S A 80 1235 S B 80 1235

TCP connections on host AIP local IP remote Port local Port remote

A S 1234 80A S 1235 80

TCP connections on host BIP local IP remote Port local Port remote

B S 1235 80

Three-way handshake

ACK(seq=x+1, ack=y+1)

CONNECT.req

CONNECT.ind

SYN+ACK(ack=x+1,seq=y)CONNECT.resp

CONNECT.conf

Initial sequence number (x)

Initial sequence number (y)

SYN(seq=x)

Connection established

Connection established

The sequence numbers of all segments A->B will start at x+1

The sequence numbers of allsegments B->A will start at y+1

Connection refused

RST+ACK(ack=x+1,seq=0)DISCONNECT.req

DISCONNECT.ind

CONNECT.req

CONNECT.indSYN(seq=x)

Connection refused

A TCP entity should never send a RST segmentupon reception of another RST segment

Reliable data transfer

DATA.req ("abcd")

DATA.ind("abcd")

(seq=123,"abcd")

DATA.req ("jkl")

(seq=132,"jkl")

(seq=127,"efg")

DATA.req ("efg")(ack=127)

(ack=135)

DATA.ind("efghijkl")

DATA.req ("hi")

(seq=130,"hi")

Reliable data transfer

(seq=127,"ef")

(seq=123,"abcd")

(seq=123,"abcd")

(seq=127,"ef")

(ack=123)

Retransmission timer

(ack=129)

(ack=129)unnecessary retransmission

"abcdef"

Retransmission of all unacked segments

“ef” placed in buffer

Fast retransmit

(seq=123,"abcd")

(seq=120,"xyz")

(ack=123)

(seq=129,"gh")

(seq=131,"ij")

(ack=123)First duplicate ack

(ack=123)Second duplicate ack

(ack=123)Third duplicate ack

(seq=127,"ef")

Out of sequence

Out of sequence

Out of sequence

Fast retransmit

(seq=123,"abcd")

(ack=123)

(ack=123)

(ack=123)

(ack=123)

(ack=133)(seq=123,"abcd")

"abcdefghij"

(seq=127,"ef")

Out of sequence, in buffer(seq=129,"gh")

Out of sequence, in buffer(seq=131,"ij")

Out of sequence, in buffer

Flow control

(seq=122,"abcd")

(ack=126,rwin=0)

Last_ack=122, swin=100, rwin=4To transmit : abcdefghijklm

Last_ack=122, swin=96, rwin=0

Last_ack=126, swin=100, rwin=0 (ack=126,rwin=2)

(seq=126,"ef")

(ack=128,rwin=20)

Last_ack=126, swin=100, rwin=2Last_ack=126, swin=98, rwin=0

Last_ack=128, swin=100, rwin=20

Last_ack=128, swin=93, rwin=13(seq=128,"ghijklm")

(ack=135,rwin=20)Last_ack=135, swin=100, rwin=20

Connection release

FIN(seq=x)

DISCONNECT.req (A-B)

DISCONNECT.ind(A-B)

ACK(ack=x+1)DISCONNECT.conf(A-B)

ACK(ack=y+1)DISCONNECT.conf(A-B)

DISCONNECT.req(B-A)

DISCONNECT.ind(B-A)

FIN(seq=y)

Time WAIT Maintain state for this connection during twice MSLto be able to retransmit ACK if a segment is received from the other entity

outgoing connection closed

incoming connection closed

incoming connection closed

outgoing connection closed

State can be removed

Last sent data : x-1

Last sent data : y-1

Abrupt release

RST(seq=x)

DISCONNECT.req (abrupt)

DISCONNECT.ind(abrupt)

Connection closed

Connection closed



Last sent data : x

Engineering

6 app-tcp