Download Slide 1

Back to Cookies!
1
“Cookies”
Invented by Netscape, included in Netscape version 0.9β
(September, 1994)
Patent applied for in 1995, granted 1998.
Quote from original Netscape publication:
“The state object is called a cookie, for no compelling reason.”
Formalized in RFC 2109, February, 1997, which has minor
differences from the original Netscape proposal.
2
RFC 2109 HTTP State Management Mechanism
1. Abstract
2. Terminology
3
RFC 2109 HTTP State Management Mechanism - continued
2. TERMINOLOGY
► client – an application program that establishes connections
for the purpose of sending requests
(could be a proxy)
► user agent – the client that initiates a request, usually a browser.
► server
► proxy
► origin server – the server on which a given resource resides.
► fully-qualified domain name (FQDN)
4
2. TERMINOLOGY - continued
► request-host
► request-URI (Universal Resource Identifier)
URL:
www.mylab.org/cgi-bin/sampleform
request-host
request-URI
5
2. TERMINOLOGY - continued
► domain-match
Host A’s name domain-matches host B’s if
► their names or IP addresses match exactly
► A is a FDQN string and has the form NB,
where N is a non-empty string, B has the form .B́
and B́ is a FQDN
Examples:
► www.amazon.com
N
domain matches
.amazon.com
B
► www.amazon.com
does not domain-match
amazon.com
6
RFC 2109 HTTP State Management Mechanism
1. Abstract
2. Terminology
3. State and Sessions
7
3. STATE AND SESSIONS
Definition of session
1. Each session has a beginning and an end.
2. Each session is relatively short-lived.
3. Session is started by the origin server
4. Either the user-agent or the origin server may terminate a session
5. The session is implicit in the exchange of state information
(there is no special message to start or stop a session).
Informally: a session might include access to a catalog, selection
of purchase items into a shopping cart, checkout, and
acknowledgement of purchase.
An HTTP session may contain several TCP sessions
8
RFC 2109 HTTP State Management Mechanism
1. Abstract
2. Terminology
3. State and Sessions
4. Outline
4.1 Syntax
4.2 Origin Server Role
4.3 User Agent Role
9
4. OUTLINE
Origin server sends state information (cookie) to the user agent
User agent returns state information to origin server.
The goal is to have minimal impact on HTTP (i.e. an add-on to HTTP)
Impact will be confined to Common Gateway Interface (CGI) programs.
4.1 Syntax: General
Let’s learn it as we go along!
10
4.2 Origin Server Role
4.2.1 General
The origin server (surprising!) initiates a session, if it so desires.
To initiate a session, the origin server returns an extra response header to
the client,
Set-Cookie
Servers may return a Set-Cookie header with any response
(not necessarily every response).
The origin server may include multiple Set-Cookie headers in a
response.
A user agent returns a Cookie request header to the origin server
(if the user agent chooses to continue the session).
User agents should send Cookie request headers (subject to other rules
detailed below) with every request.
11
4. OUTLINE – continued
4.2.2 Set-Cookie Syntax
At least one cookie
Zero or more
attribute-value pairs
Netscape version
had “expires”
If “Version” missing,
defaults to Netscape
12
Example: Wireshark trace of response to user keying in
www.amazon.com
(from Lab session 8)
Hypertext Transfer Protocol
HTTP/1.1 302\r\n Response Code: 302
Date: Fri, 08 Oct 2004 18:24:09 GMT\r\n
Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix)
amarewrite/0.1 mod_fastcgi/2.2.12\r\n
Set-Cookie: session-id-time=1097827200;
path=/;
domain= .amazon.com;
expires=Friday, 15-Oct-2004 08:00:00 GMT\r\n
Netscape version
Set-Cookie: session-id=103-3915387-7090229;
“version” missing
path=/;
domain= .amazon.com;
expires=Friday, 15-Oct-2004 08:00:00 GMT\r\n
Location:
http://www.amazon.com/exec/obidos/subst/home/home.html/1033915387-7090229\r\n
Connection: close\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/html\r\n
13
\r\n
4. OUTLINE - continued
4.3 User Agent Role
4.3.1 Interpreting the Set-Cookie
The user agent keeps separate track of state information that arrives via
Set-Cookie response headers from each origin server.
The user agent applies these defaults for optional attributes that are
missing:
► Version – defaults to “old cookie” behavior as originally
specified by Netscape.
► Domain – defaults to the request-host.
► Max-Age – the default behavior is to discard the cookie
when the user-agent exits.
► Path – defaults to the path of the request URL that generated
the Set-Cookie response.
14
4. OUTLINE – continued
4.3 User Agent Role – continued
4.3.4 Sending Cookies to the Origin server
When the user agent sends a request to an origin server, the user agent
includes a Cookie request header if it has applicable cookies, based on:
► the request-host (defined earlier) – Domain Selection
AND
► the request URI (defined earlier) – Path Selection
AND
► the cookie’s age – Max-Age selection
www.mylab.org/cgi-bin/sampleform
request-host
request-URI
15
4. OUTLINE – continued
4.3.4 Sending Cookies to the Origin Server - continued
Domain selection:
The origin server’s FQDN must domain-match the domain
attribute of the cookie
16
4. OUTLINE – continued
4.3.4 Sending Cookies to the Origin Server - continued
Path Selection:
The path attribute of the cookie must match a prefix of the request-URI17
4. OUTLINE – continued
4.3.4 Sending Cookies to the Origin Server - continued
Max-Age Selection:
Cookies that have expired should have been discarded and not sent.
18
RFC 2109 HTTP State Management Mechanism
1. Abstract
2. Terminology
3. State and Sessions
4. Outline
4.1 Syntax
4.2 Origin Server Role
4.3 User Agent Role
5.Examples
19
Example: Wireshark trace of response to user keying in
www.amazon.com
(from Lab session 8)
Hypertext Transfer Protocol
HTTP/1.1 302\r\n Response Code: 302
Date: Fri, 08 Oct 2004 18:24:09 GMT\r\n
Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix)
amarewrite/0.1 mod_fastcgi/2.2.12\r\n
Set-Cookie: session-id-time=1097827200;
www.amazon.com
path=/;
domain-matches this
domain= .amazon.com;
expires=Friday, 15-Oct-2004 08:00:00 GMT\r\n
Netscape version
Set-Cookie: session-id=103-3915387-7090229;
“version” missing
path=/;
domain= .amazon.com;
expires=Friday, 15-Oct-2004 08:00:00 GMT\r\n
Location:
http://www.amazon.com/exec/obidos/subst/home/home.html/1033915387-7090229\r\n
Connection: close\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/html\r\n
20
\r\n
trace of next HTTP message client to server www.amazon.com
(www.amazon.com domain-matches .amazon.com)
21
Server sends
“customer” form
User completes form
and clicks “submit”
Form data
Server starts HTTP
session with Set-Cookie
Server sends
“merchandise”
form
Consequence of clicking
“submit” button
Client returns
“customer”
cookie 22
Server sends
“shipping” form
User selects “FedEX”
and clicks “submit”
Client sends
both cookies
Server sends
23
checkout form
User could still
abort purchase
but chooses to
proceed
User clicks on
“submit” button
Client sends all
three cookies
Form data
K
Server sends order
acknowledgement
24
Background to Chapter 9 - Classless and Subnet Address Extensions (CIDR)
and Chapter 31 – A Next-Generation IP
There are 232 possible IPv4 addresses.
When the predecessor of the Internet started in the 1970s it did not seem
possible that this address space would ever be exhausted.
No effort was made to allocate IP addresses carefully.
In particular:
● The classful addressing system is wasteful
(224 addresses to MIT)
● Every physical network had to have a unique network prefix
● Network prefixes were not allocated geographically
(example – 138.26.0.0 is UAB
138.25.0.0 is in Australia)
25
Comer: “In the early 1980s, as Ethernet gained popularity, it became
apparent that the classful addressing scheme would have insufficient
network addresses, especially class B prefixes.”
1985: Subnetting allowed organizations to share a single network prefix
over multiple physical networks, which helped conserve the IPv4 address
space (Comer, Chapter 9A).
1993: Shortage of IPv4 network addresses threatens, especially class B.
Some geographical allocation of class-C addresses
Supernetting/CIDR comes to the rescue, superseding “classfull”
addressing (Comer, Chapter 9B).
Present situation:
● The IPv4 address space is “really” near exhaustion
● Forwarding tables in the Internet backbone are very large
(200,000 entries).
2010? Large-scale adoption of IPv6 (Comer Chapter 31).
26
Recall:
Figure 4.1
Figure 9.3
Subnetting class B
network
27
9.16 Classless Addressing and Supernetting
Under the original “classful” addressing system IPv4 address space
was becoming exhausted.
The rigid class scheme made allocation of IP addresses inefficient.
Subnet addressing (1987) helped, but problem remained.
“Temporary” solution (1993) was to abandon classes completely and
let the network prefix be any length.
We already had the ability to do this, in the address mask!
This is called classless IP addressing, or supernetting.
28
9.16 Classless Addressing and Supernetting - continued
Example:
Organization wants a class-B network address – none available.
256 class-C addresses would have the same total number of addresses.
Problem:
Outsiders would need 256 entries in their routing tables, instead of one
(contrast subnetting, which is invisible to outsiders).
Solution:
Classless Inter-Domain Routing aggregates 256 contiguous class-C
networks together by carrying along a netmask of 255.255.0.0
(“treat these 256 contiguous class-C networks like a class-B network”)
The network address is never mentioned without also stating the netmask.
Problem with implementation of this: software
on all external routers had to be modified.
29
9.17 CIDR Address Blocks and Bit Masks
The netmask 255.255.0.0 is just one example.
The division between the network part and the host part of the IP address
can be placed (almost) anywhere by an appropriate address mask.
CIDR notation:
State number of bits in network part.
e.g. address mask 255.255.255.0 is CIDR /24
30
9.17 CIDR Address Blocks and Bit Masks – continued
The revised forwarding algorithm remains unchanged, but is now used
both internally and externally.
31
Figure 9.7
9.17 CIDR Address Blocks and Bit Masks – continued
CIDR allows allocation of different sizes of address blocks.
It was introduced in the context of privatization of the Internet, which also
introduced Internet Service Providers (ISPs).
Using CIDR, large ISPs are allocated large address blocks, which they can
then divide (using CIDR) into smaller blocks to allocate to their customers.
32
9.17 CIDR Address Blocks and Bit Masks – continued
Example:
Organization is assigned a block of 2048 addresses, based on 128.211.168.0
(notice ambiguous class – under classful system 128.211 is class-B
64K addresses)
Block size is 211 addresses, which would have been 8 class C networks.
Netmask for this block is
11111111 11111111 11111000 00000000
255
.
255
.
248
.
0
CIDR /21
Refer to this allocation as 128.211.168.0 /21
33
9.17 CIDR Address Blocks and Bit Masks - continued
Figure 9.9
34
9.18 Address Blocks and CIDR Notation
Possible address masks:
Class C
Class A
Class B
Figure 9.10
/31 and /32 useless!
35
9.19 A Classless Addressing Example
A large ISP has been allocated the entire class-B address 128.211.0.0
i.e. 128.211.0.0
/16
Large ISP has allocated the address block shown previously to a smaller ISP,
i.e. 128.211.168.0
/21
128.211.10101000.00000000
So smaller ISP has available
128.211.168.0
128.211.169.0
128.211.170.0
128.211.171.0
128.211.172.0
128.211.173.0
128.211.174.0
128.211.175.0
36
9.19 A Classless Addressing Example - continued
128.211.168.0 /21
Expands to:
3rd octet
128.211.168.0
10101 000
128.211.169.0
10101 001
128.211.170.0
10101 010
128.211.171.0
10101 011
128.211.172.0
10101 100
128.211.173.0
10101 101
128.211.174.0
10101 110
128.211.175.0
10101 111
4th octet
00000000
128.211.
168.0/22
128.211.
172.0/23
/24
/24
37
256 addresses
128.211.175.0/24
Smaller ISP has been allocated 128.211.168.0/21 Can
allocate partitions to customers:
256 addresses
128.211.174.0/24
1024 addresses
128.211.168.0/22
512 addresses
128.211.172.0/23
The smaller ISP could further partition 128.211.175.0/24
38
9.19 A Classless Addressing Example - continued
An ISP owning 128.211.0.0/16 might assign an individual needing only
two IP addresses
128.211.176.212
/30
Figure 9.11
The two IP usable addresses are:
128.211.176.213
and
128.211.176.214
39
9.19 A Classless Addressing Example - continued
Classless addressing, which is now used throughout the Internet,
treats IP addresses as arbitrary integers, and allows a network
administrator to partition addresses into contiguous blocks, where
the number of addresses in a block is a power of 2.
40
9.21 Longest-Match and Mixtures of Route Types
Consider the smaller ISP’s routers – entry router is R0
From R0 assume that all networks except 128.211.175.0 /24 are reached
through router R1 and 128.211.175.0 /24 is reached through R2
3rd octet
128.211.168.0
128.211.169.0
128.211.170.0
128.211.171.0
128.211.172.0
128.211.173.0
128.211.174.0
10101
10101
10101
10101
10101
10101
10101
000
001
010
011
100
101
110
128.211.175.0
10101
111
4th octet
00000000
41
256 addresses
128.211.175.0/24
9.19 A Classless Addressing Example – continued
Smaller ISP has been allocated 128.211.168.0/21
R2
256 addresses
128.211.174.0/24
1024 addresses
128.211.168.0/22
512 addresses
128.211.172.0/23
42
9.21 Longest-Match and Mixtures
of Route Types – continued
3rd octet
R0 table entry
128.211.168.0
128.211.169.0
128.211.170.0
128.211.171.0
128.211.172.0
128.211.173.0
128.211.174.0
10101
10101
10101
10101
10101
10101
10101
000
001
010
011
100
101
110
128.211.168.0/21 to R1
128.211.175.0
10101
111
128.211.175.0/24 to R2
Nothing gets forwarded to R2
43
9.21 Longest-Match and Mixtures of Route Types – continued
Figure 9.14
All traffic will be sent to 10.0.0.2
44
9.21 Longest-Match and Mixtures of Route Types – continued
Conclusion:
We need another modification to the forwarding algorithm:
Forward on basis of longest match in routing table
Can help by putting the most specific routes first.
45
9.22 CIDR Blocks Reserved for Private Networks
Figure 9.15
46
Please fill out the IDEA evaluation of this course!
The Dean is after me!
47