Transcript Document 769743

CS 6910 – Pervasive Computing
Spring 2007
Section 9 (Ch.9):
Mobile Communication Systems
Prof. Leszek Lilien
Department of Computer Science
Western Michigan University
Slides based on publisher’s slides for 1st and 2nd edition of:
Introduction to Wireless and Mobile Systems by Agrawal & Zeng
© 2003, 2006, Dharma P. Agrawal and Qing-An Zeng. All rights reserved.
Some original slides were modified by L. Lilien, who strived to make such modifications clearly
visible. Some slides were added by L. Lilien, and are © 2006-2007 by Leszek T. Lilien.
Requests to use L. Lilien’s slides for non-profit purposes will be gladly granted upon a written
request.
0
Chapter 9
Mobile Communication Systems
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
1
Outline




9.1. Introduction
9.2. Cellular System Infrastructure
9.3. Registration
9.4. Handoff Parameters and Underlying Support



9.5. Roaming Support




Home Agents, Foreign Agents, and Mobile IP
Rerouting in Backbone Routers
9.6. Multicasting
9.7. Security and Privacy




Parameters Influencing Handoff
Handoff Underlying Support
Encryption Techniques
Authentication
Wireless System Security
9.8. Firewalls and System Security
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
2
9.1. Introduction


Ideal cellular infrastructure:
 MS able to communicate with any other MS in the world
 Across cells
 Across MSC areas (MSC = mobile switching center)
 Across systems owned by different service provider
To approach the ideal, need
 Handoffs
 Roaming
across these “borders”
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
3
9.2. Cellular System Infrastructure


Cellular system infrastructure is fairly complex
The infrastructure as discussed earlier (Sec.1):
wired link
PSTN
Home phone
…
MSC
BSC
…
…
BS MS
BS MS
MSC
BSC
BSC
…
…
BS MS
BS MS
BS MS
…
BSC
…
BS MS
BS MS
BS MS
[LTL:]




BSC = BS controller
MSC = Mobile Switching Center
PSTN = Public Switched Telephone Network
PSTN connected to the ATM backbone
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
4
9.2. Cellular System Infrastructure – cont. 1
The infrastructure in more detail
1) Discussed in Sec. 1:


BTS = base transceiver system (tower + antenna)
transmitter + receiver)
(tranceiver =
BSC = BS controller (all electronics controlling BTSs, even k*100
BTSs)
 BS = base station = BTS + BSC
NOTE: We sometimes omit mentioning BTS, as if BTS + BSC were
co-located & were an integrated BS
Sometimes (as in the previous Figure) BTS is denoted as “BS”
 HLR = home location
register
 VLR = visitor home
location register

2) Not discussed yet:


AUC = authentication
center
EIR = equipment
identity register
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
5
9.2. Cellular System Infrastructure – cont. 2


Role of AUC (authentication center)
 Provides authentication – to verify user’s identity
 Provides encryption parameters – to provide confidentiality of calls
=> “prevents” cellular system operators & customers from fraud
(not 100% prevention!)
Role of EIR (equipment identity register)
 It is database with info about identities of mobile equipment

So, e.g., operator
accepts calls only
from equipment
of operator’s own
customers
=> “prevents” fraud

Implementations:


Separate AUC & EIR
Integrated AUC/EIR
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
6
9.2. Cellular System Infrastructure – cont. 3

HLR and VLR used in a way analogous to mail forwarding by
the U.S. Postal Service - fig. above
(pp. 190/- 192)
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
7
9.2. Cellular System Infrastructure – cont. 4


in cellular need not only forward link
(home MSC -> visiting MSC)
Need also a backward link (visiting MSC -> home MSC ) –
see fig. below for the bi-directional link
Backward link needed for, e.g.:
 Billing - done only by home MSC
(mobile switching center)
 Look at the list of access specifications – kept by home
MSC
Unlike in the USPS example,




Is MS active or not (e.g., delayed payment)
Local calls only or long distance calls allowed or both
Listing of calls made
Listing of charges
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
8
9.3. Registration

MS must register before being able to use cellular services



MS registration done each time the MS is switched on
Registration needed for:
 Billing
 Authentication
 Specifying access privileges
System also needs to know MS’s location —
established via beacon signals as follows
 BS periodically xmits beacon signal
 Beacon signal includes among others:







Cellular network id
Timestamp
Gateway address
ID of the paging area (PA)
Other BS parameters
- to be discussed later
If MS hears new BS, it adds it to its table – „active beacon kernel
table”
When MS wants to make a call, MS gets closest BS from the table
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
9

Steps followed for registered MS outside of its own subscription (home)
area
 Listen for new beacon
If MS hears new BS, it adds it to its „active beacon kernel table”
If MS wants to make a call via new BS, it initiates handoff
 MS (that wants to make a call via new BS), finds the closest BS from the
table
 Visiting BS/MSC determines:
 Who MS is
 Registered home MSC (for billing) for MS
 What kind of access permissions MS
(e.g., local calls only)
 Home MSC gets info from HLR and sends authentication response to
the BS currently serving the user (via Visiting MSC)


It is stored in VLR of the visiting MSC
BS at the visited location appproves or rejects user’s access
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
10

Steps followed for unregistered (e.g., was switched off – stepping off a plane)
MS outside of its own subscription (home) area
 User switches on MS
 MS listens for beacon signals from BSs
 MS registers with the closest BS
 MS then is authenticated via this BS

Visiting MSC for this BS contacts Home MSC


Details, similar as before, skipped
If BS at the visited location appproves MS
MS communicvates via this BS
(=authentication succeeds),
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
11


Beacon signals made wireless systems more intelligent
Table shows „information carried” by beacon signals in different
systems
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
12
9.4. Handoff Parameters
and Underlying Support


Handoff = change of radio resources from one cell to
another, adjacent cell
For handoff to succeed, the „new” cell needs a free channel
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
13
9.4.1. Parameters Influencing Handoff

If radio resources are fixed (= total # of available channels is fixed),
can increase # of channels by decreasing cell size (= coverage
area)


Due to more potential for reuse of channels if there are more cells
But there is a tradeoff:
Smaller cells lead to more frequent handoffs

Handoff can be initiated either by BS or MS

Handoff could be due to:



1) The radio link reasons
2) Network management reasons
3) Service-related reasons
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
14
9.4.1. Parameters Influencing Handoff – cont. 1

Handoff due to radio link reasons (1 above) is caused
primarily by MS mobility
It depends mostly on:









# of MSs that are in the cell
# of MSs that left the cell
# of calls generated in the cell
# of calls transferred to this cell from neighboring cells by handoff
# and duration of calls terminated in the cell
# of calls handed off to neighboring cells
...
Handoff due to network management reasons (#2 above)
might be necessary if the system needs to balance a drastic
imbalance of traffic in adjacent cells
Handoff due to service-related reasons is needed if QoS
(quality of service) drops too much
Time when it’s needed depends mostly on:





Signal strength
Signal phase
Signal strength and phase combined
Bit error rates
Distance
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
15
9.4.1. Parameters Influencing Handoff – cont. 2


Two ways of determining need for handoff
 Signal strength
 Carrier-to-interference ratio (CIR)
Example of handoff based on signal strength (= on received power) –
from Section 5


As MS moves, handoff must be done in the handoff area (between X3 & X4 )
Must find optimal handoff point within the handoff area
Signal strength
due to BSi
Signal strength
due to BSj
Pj(x)
Pi(x)
E
Pmin
BSi
X1
X3
MS
X5
Xk
X4
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
BSj
X2
(Modified by LTL)
16
9.4.1. Parameters Influencing Handoff – cont. 3

(2nd case) Handoff based on CIR –
when CIR gets too low, handoff must be made
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
17
9.4.2. Handoff Support


Two types of handoff:
 Hard handoff
 Soft handoff
Two orthogonal types of handoff:
 Handoff within a single MSC area
 Handoff crossing the boundary between two MSC areas
-- details below --
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
18

Hard handoff –
 Break before make
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
19

Soft handoff –
 Make before break
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
20

Handoff can require crossing a boundary between MSC areas


When a cell from which the handoff is made is in a different MSC area
than the cell to which handoff is made
Requires use of beacon signals and the HLR-VLR link
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
21
9.5. Roaming Support

Scenario 1: MS moves from Point a to Point b


Supported by MSC1 alone
Scenario 2: MS moves from Point b to Point c


Supported by MSC1 & MSC2
Requires setting up the bidirectional HLR-VLR link between them – as
shown in fig on next slide
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
22
9.5. Roaming Support – cont. 1

Information transmission path for Scenario 2

Incl. setting up the bidirectional HLR-VLR link between MSC1 and
MSC2
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
23
9.5. Roaming Support – cont. 2

Paging area (PA)
An area covered
by ≥ 1 MSC
needed to find
the current location of MS


In general, PA
needs not include the home
location of the MS
being searched for
Examples of PAs
 Let: MS(x) = MS in location (x)
 MSC1 alone constitutes PA for MS(a) & MS(b)
 MSC1+MSC2 constitute PA for MS(b) & MS(c)
 MSC3+MSC4 constitute PA for MS(d) & MS(e)
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
24
9.5. Roaming Support – cont. 3

Scenario 3: MS moves from Point d to Point e
 Supported by MSC3 and MSC4, but ...
 … in this case, using simply the bidirectional HLR-VLR link
for forwarding from MSC3 to MSC4 might be inefficient

Might even be terribly inefficient
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
25
9.5. Roaming Support – cont. 4

Inefficient simple forwarding - USPS analogy
John used to leave in Kalamazoo
He now lives in San Diego
A company from Santa Barbara sends letter to John’s old
address in Kalamazoo
Kalamazoo post office forwards it to San Diego

Q: Is it an efficient mechanism?




Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
26
9.5. Roaming Support – cont. 5

A: No, very inefficient!

The letter covers distance many times longer than the actual
(current) sender-adressee distance




Goes from Santa Barbara to Kalamazoo + from Kalamazoo to San Diego
Instead of going a short distance from Santa Barbara to San Diego
General problem: Forwarding from old address is very
inefficient!
LA
Problem details – example:


Suppose that the letter sent from Santa
Barbara (SB) is routed to LA, to Chicago
(C), to K-zoo (K)
Suppose that the letter forwarded from
the old K-zoo address is routed to Chicago,
to LA, to San Diego (SD)

See the routing tree

Q: How to solve this problem?
SD
SB
C
K
(How to shorten the distance that the letter must travel?)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
27
9.5. Roaming Support – cont. 6

Problem details – example:


Suppose that the letter sent from Santa Barbara (SB)
is routed to LA, to Chicago (C), to K-zoo (K)
Suppose that the letter forwarded from the old K-zoo
address goes to Chicago, to LA, to San Diego (SD)

See the routing tree

Solution: Use mail re-routing




SB
C
Instead of forwarding
Suppose that the letter sent from Santa
Barbara is routed to LA, then to Chicago
Chicago has intelligent database & knows
that John now lives in San Diego
Chicago re-routes letter to San Diego’s address
via LA


SD
Solution details – example:


LA
K
LA
SD
SB
Letter never sent to K-zoo
Observe distance (& time) saved
See re-routing extracted from the routing
tree
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
C
28
9.5. Roaming Support – cont. 7

Improved solution details – example:



Suppose that the letter sent from Santa
Barbara is routed to LA
LA has intelligent database & knows
that John now lives in San Diego
LA re-routes letter to San Diego’s address



Letter never sent even to Chicago
Observe how much distance (& time) saved
See the improved re-routing extracted from
the routing tree
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
LA
SD
SB
29
9.5. Roaming Support – cont. 8


We have seen a very simplified
routing tree so far
A more accurate one:
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
30
9.5. Roaming Support – cont. 9

Improve efficiency in passing
message to new address
– based on USPS analogy


Replace (simple) forwarding
with re-routing
Find a router R from which
can re-route as close to
sender as possible on the
packet flow route
 E.g., for a message sent from Santa Barbara, LA is “closer
to sender” than Chicago



Bec. it is more efficient to re-route from LA than from Chicago
From R can efficiently to re-route msg to new MS’s location
 Rather than delivering msg to old MS’s address & then
forwarding msg to new MS’s address
Efficiency of forwarding depends on the topology of the
network – i.e., on routes between old and new MS locations
(Original
figure from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
31
9.5. Roaming Support – cont. 10

Back to Scenario 3: MS moves from Point d to Point e
 Supported by MSC3 and MSC4, but ...
 … in this case, using simply forwarding from MSC3 to
MSC4 might be inefficient


Might even be
terribly inefficient
How inefficient?
It depends on the
topology of network
(Original
figure from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
32
9.5. Roaming Support – cont. 11


For the following questions, assume the network topology as
shown in the figure
Q: Why forwarding from
MSC1 to MSC2 is
very efficient?

Hint: Look at
links between
MSC1 & MSC2
(Original
figure from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
33
9.5. Roaming Support – cont. 12

Q: Why forwarding from
MSC1 to MSC2 is
very efficient?


Hint: Look at
links between
MSC1 & MSC2
A: Bec. there is a
direct connection
betw. MSC1 & MSC2
(red arrow)
Even if message for, e.g.,
MS(c) is delivered to MS(b),
very little effort is needed to
forward it from MS(b) to MS(c)
Also, R1-R2-R3-MSC1-MSC2 might even be more efficient than R1-R2-R3-R4MSC2
Of course, it might be better to re-route msgs for MS(c) starting at R3 rather
than forward it
Or, it might be better to re-route msgs for MS(c) starting at R2 if R2-R5-R6R4-MSC2 is more efficient
(Original
figure from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
34
9.5. Roaming Support – cont. 13

Q: Why forwarding from MSC2 to MSC3 is reasonably
efficient?

Hint: Look at the links between MSC2 & MSC3
(Original
figure from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
35
9.5. Roaming Support – cont. 14

Why forwarding from MSC2 to MSC3 is reasonably efficient?


Hint: Look at the links between
MSC2 & MSC3
A: Bec. there is a
“close” route betw.
MSC2 & MSC3
(red arrows, via R4 & R6)
Even if message for, e.g.,
MS(d) is delivered to MS(c),
only limited effort is needed
to forward it from MS(c) to
MS(d)
Also, R1-R2-R3-R4-MSC2-R4-R6-MSC3 might be not much more expensive than R1-R2-R5-R6-MSC3
(depending on network parameters, it might even be cheaper)
Of course, it might be better to re-route msgs for MS(d) starting at R2 (via
R5-R6-MSC3) rather than forward it
Or, it might be better to even re-route msgs for MS(d) starting at R4
(via R6-MSC3)
(Original
figure from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
36
9.5. Roaming Support – cont. 15

Q: Why forwarding from MSC3 to MSC4 is very inefficient?

Hint: Look at the links between MSC3 & MSC4
(Original
figure from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
37
9.5. Roaming Support – cont. 16

Why forwarding from MSC3 to MSC4 is very inefficient?


Hint: Look at the links between MSC3 & MSC4
A: Bec. there is only “distant”
route between MSC3
& MSC4
(red arrows, have to go all
the way back to R1: via R6,
R5, R2, R1, R7, R8, R9)
If message for, e.g., MS(e) is
sent to MS(d), very significant
effort needed to forward it
from MS(d) to MS(e)
Bec. R1-R2-R5-R6-MSC3-R6-R5-R2-R1-R7-R8-R9-MSC4 must be much more
expensive than R1-R7-R8-R9-MSC4
(observe that this forwarding goes all the way back to R1!)
Of course, it would be significantly better to re-route msgs for MS(e) starting
at R1 (via R7-R8-R9-MSC4) rather than forward it
(Original
figure from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
38
9.5.1. Home Agents, Foreign Agents,
and Mobile IP

Forwarding based on HLR-VLRis not sufficiently flexible
HLR/VLR = Home/Visitor Location Register

How more flexible forwarding can be implemented?
 Use home agents & foreign agents associated with
routers
 Use Mobile IP (= Mobile Internet Protocol)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
39
9.5.1. Home Agents, Foreign Agents, and Mobile IP – cont. 1

Home agent (HA)



One HA per MSC
Serves all MSs for
which this MSC is
home MSC
Example: Routers
selected for maintaining HAs for all
MSCs (MSC1 – MSC4)

Shown in Table

E.g., HA for MSC3 is on R6
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
40
9.5.1. Home Agents, Foreign Agents, and Mobile IP – cont. 2



Not only the closest router can serve as the HA router
 As in the above example
Foreign agent (FA)
 One per MSC
 Assists visiting MSs
 Forwards packets to the MS
HA-FA functionality is flexible
 More flexible than HLR-VLR functionality
 Supports mobility better

Even in an unknown territory
 Requires an agreement on “roaming” charges

An agreement between service providers of home network &
foreign network
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
41

Scenario when MS moves into new network




First, it needs to detect FA (via its beacon) OR send agent solicitation
msg
CoA = care-of address - either address of FA OR C-CoA (a new address
allocated to MS)
C-CoA = colocated CoA
CoA and C-CoA
are used similarly:
as forwarding
addresses for
the MS
Here is your CoA or C-CoA

Note:
Registration of MS
with HA has time
limit (expires)
CoA or C-CoA
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
42

Scenario: a msg from any source sent to MS

Captured and encapsulated by MS’s HA
-HA checks CoA
(or C-CoA) binding
for MS: exists? not
expired?
- HA encapsulates
msg for MS with
CoA (or C-CoA)
by HA
router and FA if CoA used
by FA
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
(Modified by LTL)
43

Other instances when MS register with its HA
1) When the CoA binding (or for C-CoA binding) expires, MS
must renew its registration with its HA

Expires due to time limit for CoA binding (or for C-CoA binding)
(Set in the last step in diagram of “Scenario when MS moves into new network”)
2) When MS returns to the home network

Notified HA stops forwarding to FA
3) When MS moves to another network

Notified HA knows the correct FA to forward to
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
44
9.5.2. Rerouting in Backbone Routers



Forwarding can be very inefficient (as shown above)
Let: a(MSCx) = area covered by MSCx
It is better to re-route than forward if
MS moves from a(MSCx) to a(MSCy)


Even if both have same HA router (HAR)
Example:
 Better to re-route
if MS moves from
a(MSC5) w/ HAR
R13 to a(MSC6)
w/ the same HAR
R13
MSC5 MSC6
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
45
9.5.2. Rerouting in Backbone Routers – cont. 1


It is much better to re-route than forward if
MS moves from a(MSCx) to a(MSCy) AND
HAR for MSCx has a much different attachment point to the
backbone network than HAR for MSCy
Examples:
 Much better to
re-route if MS
moves from a(MSC2)
w/ HAR R4 to
a(MSC4) w/ HAR R9


Attachment points for
HAR R4 are R3 and R6
Attachment point for
HAR R9 is R8
MSC5 MSC6
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
46
9.5.2. Rerouting in Backbone Routers – cont. 2


Best to re-route as soon as possible
- as soon as the paths to old MSC and new MSC split
Example: MS moving from a(MSC1) to a(MSC3):





The original route for MSC1 (old MSC) was R1-R2-R3-MSC1
Better to re-route at R2 than at R3
Re-routing (to new MSC3) at R2:
via R5-R6
Re-routing (to new MSC3) at R3:
via R4-R6
Re-routing at R3 is
worse – the total
path is longer (R1-R2R3-R4-R6-MSC3)
than the total path
for re-routing at R2
(R1-R2-R5-R6-MSC3)
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
47
9.5.2. Rerouting in Backbone Routers – cont. 3



Re-routing is a much better for roaming support than
forwarding
Q: How re-routing can be implemented?
A: HA-FA for a roaming MS update routing tables on routers


Record in the routing table for a given destination indicates (at least)
the next intermediate node to go to in order to eventually reach the
destination node
 E.g., the record for MS in a(MSC1) (a destination node) existing in the
routing table on R2 indicates “R3”
Example:
 MS moves from a(MSC1)
to a(MSC3)
 Entry for MS in
routing table on
R2 changed from
R3 to R5
(On R2 since R2 is
the earliest point
where paths to
old/new split)
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
48
9.5.2. Rerouting in Backbone Routers – cont. 4

Simplest solution: HA-FA for a roaming MS update routing
tables on all routers
 In other words, a global routing table, identical on all
routers
 Inefficient



Large routing tables (and replicated n times)
Expensive updates
Better solution: HA-FA for a roaming MS update routing
tables on gateway routers only


In other words, non-global, distributed routing tables


Gateway router – a selected “prominent” router, at a critical junction
In general different on different gateway routers
Efficient
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
49

Gateway routers and their distributed routing tables
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
50
9.6. Multicasting




Let: S – source, D – destination
Unicast: 1 S sends msgs to 1 D
 Using individual address
Multicast: 1 S sends msgs to n Ds
 Using a group address
Multicast extremely useful for applications involving group
communications
 Including audio/video delivery, teleconferencing,
distance learning, multiparty games, etc.
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
51
9.6. Multicasting – cont.

Multicast implementation:
 Not just n unicasts - much more efficient
 Group address key to efficiency:
It greatly reduces # of messages needed to deliver a
msg to all group members
=> saves bandwidth
Two basic multicasting methods
1) Using source-based tree
 For each source S in the group, create a shortest-path
tree


Rooted at S / Encompassing all group members
2) Using core-based tree
 One router selected as core router (CR)
 Any group member sending a packet sends it to CR
 CR forwards (in the general meaning of the word) the
packet to all group members using a shortest-path tree

Routed at CR / Encompassing all group members
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
52
9.6. Multicasting – cont. 2

Group membership is dynamic: members join/leave





Join to get multicast packets
Leave once need no more
No group membership/subscription needed to send
multicast packets to all members
Multicast trees (for both methods) must be efficiently
grafted/pruned in response to joining/leaving
MBONE - multicast backbone (infrastructure) on Internet
 Special multicast-capable routers (MROUTERs)
 MROUTERs connected via tunnels (dedicated paths)


Tunnels use regular links
Tunnels go over regular routers
(between MROUTERS)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
53
9.6. Multicasting – cont. 3

Multicast scenario on Internet — i.e., using MBONE
 Multicast packet (MP) sent to MROUTER
 MROUTER encapsulates MP making encapsulated MP
(EMP)
 MROUTER unicasts EMP via tunnels to other
MROUTERs



EMP is sent (unicast) as a regular IP packet
Receiving MROUTER decapsulates EMP recovering MP
Multicast in wireless networks
 Much more complex


Due to mobility of group members
Problems in wireless networks



(discussed below)
include:
Non-optimal path length
Packet duplication
Maintaining packet delivery during multicast tree
generation/update
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
54
9.6. Multicasting – cont. 4

Two multicast methods over Mobile IP:
Defined by standard body IETF (Internet Engineering Task Force)
1) Bidirectional tunneling (BT)
2) Remote subscription
MP

EMP
MP
1) Bidirectional tunneling (BT) – cf. fig
 When MS moves into foreign network, its HA creates
bidirectional tunnel to its current FA




HA acts as MROUTER
HA encapsulates MP (multicast packet)
HA sends EMP (encapsulated MP) to FA
FA decapsulates EMP & forwards MP to MS
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
55
9.6. Multicasting – cont. 5

2) Remote subscription
 When MS moves into foreign network, its new FA sends
a ‘tree join’ request



MPs



Request sent for each multicast tree to which MS belongs
Unless FA already a member of a given multicast tree
(multicast packets)
for MS are then sent directly to FA
Not via HA as before
FA forwards packets to MS
Note:
“FA sends a ‘tree join’ request” =
= “FA subscribes to a multicast group using this tree”
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
56
9.6. Multicasting – cont. 6

Problems with bidirectional tunneling (BT)
1) Packet replication
Example



MPi
EMPi
MPi
HA receives multicast packet MPi for group G
MPi
(to be delivered to MS1 -
HA does what it always does:
 HA encapsulates MPi as EMPi / HA sends EMPi to FA for MS1
 HA sends EMPi to FA for MS2 / HA sends EMPi to FA for MS3
FA receives EMPi for a given MS, decapsulates EMPi & forwards it to
indicated MS


EMPi
EMPi
Assume that:
a) MS1 - MS3 have the same home agent HA
b) MS1 - MS3 subscribe to the same multicast group G
c) MS1 - MS3 have the same FA (bec. all moved to same foreign network)
MS3)

MPi
Cf. Slide 43 (Fig. 9.12) to see that each EMP is destined for a single MS
Problem illustration: HA sent EMPi separately for each of its
MSs that subscribes to G
 As a result packet EMPi is replicated by the same HA
(duplication = replication 2 times, the smallest degree of replication)
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
57
9.6. Multicasting – cont. 7

Problems with bidirectional
tunneling (BT) – cont.
2) Tunnel convergence
Example

Assume that:
a) MS1 – MS4 have home agents
as shown in fig.
(MS3&MS4 share HA3; others – different)
b) MS1 – MS4 subscribe to the same multicast group G
c) MS1 – MS4 have the same FA (bec. they moved to the same foreign network)


Different HA1 - HA3 receive the same multicast packet MPi for group
G (to be delivered to MS1 - MS3)
Different HA1 - HA3 send different encapsulated multicast packets
EMPi1 – EMPi3 to FA (to be delivered to MS1 – MS4)



Note: HA noticed that CoA(MS3) = CoA(MS4), so HA3 sent only 1 copy
of EMPi. Hence, no replication of EMPi3 for MS3 and MS4.
FA receives EMPi1 – EMPi3, decapsulates them & forwards them to
the indicated MS or MSs (MSs in case of EMPi3)
Problem illustration: Each HA paired with FA (via a “convergent
tunnel”) sent EMPi separately for its MSs that subscribe to G
 As a result packet EMPi is replicated by different HAs
(in packet replication, it was replicated by the same HA)
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
58
9.6. Multicasting – cont. 8

Advantages of remote subscription
 No packet duplication



Since FA subscribes to the multicast group (and tree)
=> gets packets directly, not via HA
Prevents non-optimal path discovery (discussion omitted)
Problems with remote subscription
1) Data disruption before FA joins multicast group/tree
2) Frequent tree updates
 Needed each time MSx moves to new network


FA for the new network has to join each multicast group G such
that:
 MSx belongs to G
AND
 FA does not belong to G
FA for the old network has to leave each multicast group G such
that:
 MSx belongs to G
AND
 no other MS served by this FA belongs to G
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
59
9.6. Multicasting – cont. 9


Solution for the tunnel convergence problem:
Mobile multicast (MoM) protocol
 Ensure that only one HA for a given multicast group G
sends EMP to a given FA
MoM implementation:
 Given a set of HAs “connected” to a given multicast
group/tree, FA selects one of them

This one is named: designated multicast service provider (DMSP)
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
60
9.6. Multicasting – cont. 10

Problems with MoM protocol
1) Data disruption when last MS for HA selected as DMSP
leaves the FA’s network (and FA still includes members of the multicast
tree that was served by DMSP)
=> data disruption till new DSMP selected

To prevent it can have >1 DSMP (but then possible packet
replication)
2) Packet replication
 If FA is a tree node

Being a tree node, it can receive replicated MPs from > 1 tree
node
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
61
9.7. Security and Privacy

Security challenges in wireless systems
1) Assured delivery of messages
 Example attack: Jamming by a powerful transmitter
 A solution: use frequency hopping
2) Authenticity of messages
 A solution: use digital signatures
3) Secrecy of messages
 A solution: use encryption of messages

Solutions for Challenges 2 and 3 based on:
Cryptography
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
62
9.7.0. Introduction to Cryptography

We’ll cover briefly:
 Keyed Cryptographic System
 Classification of Cryptosystems w.r.t. Keys
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
63
Keyed Cryptographic System
Encryption
Key
P

E
C
KD
D
P
C = E(KE, P)


Decryption
Key
KE
E = set of encryption algorithms / KE selects Ei  E
P = D(KD, C)

D = set of decryption algorithms / KD selects Dj  D

Crypto algorithms and keys like door locks and keys

We need:
P = D(KD, E(KE, P))
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
64
Classification of Cryptosystems w.r.t. Keys
1) Keyless cryptosystems
 E.g., Caesar’s cipher:
 x – any letter
 x -> x+3, that is:
A D, B E, C  F, …, W  Z, X  A, …
 E.g., encryption using Caesar’s cipher:
 “HELLO WORLD”  “khoor zruog”
2) Keyed cryptosystems
2a) Symmetric cryptosystems
2b) Asymmetric cryptosystems
[cf. B. Endicott-Popovsky, U. Washington]
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
65
Classification of Cryptosystems
w.r.t. Keys - cont.
KE
P

E
KD
C
D
P
More on: (2) Keyed cryptosystems
2a) Symmetric cryptosystems: KE = KD
 Classic
 Encipher and decipher using the same secret key

Same key OR one key is easily derived from other
2b) Asymmetric cryptosystems: KE ≠ KD
 A.k.a. a public key encryption (PKE)
 Encipher / decipher using different keys:
Secret private key + widely-known public key:
< kPRIV, kPUB>

Computationally infeasible to derive the private key from the
public key

It is OK if the public key easily derived from the private key
[cf. B. Endicott-Popovsky, U. Washington]
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
66
9.7.1. Encryption Techniques

Example: simple encryption using permutation

Can use very simple hardware (pins + wires)
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. Lilien
Lilen P. Agrawal and Qing-An Zeng. All
67
9.7.1.
Encryption
Techniques
– cont. 1

Example: block encryption using DES (Data Encryption
Standard)



Uses a secret encryption key to modify output for given input
Example input – fig. a
/ Example output – fig. b
Encryption for this example (compare fig. a & b):




57th bit of input block becomes 1st bit xmitted
49th bit of input block becomes 2nd bit xmitted
…
Encryption for this example (compare fig. b & c):



8th bit of received block becomes 1st bit decrypted (recovered)
24th bit of received block becomes 2nd bit decrypted
…
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
68
9.7.1. Encryption Techniques – cont. 2

Generic block encryption scheme
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
69
9.7.1. Encryption Techniques – cont. 3

Example: complex encryption scheme
 Consisting of XOR-ing & permutation
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
70
9.7.1. Encryption Techniques – cont. 4

Example: Some details of encryption procedure

A bit more detail about DES: next 2 slides (optional – may SKIP)
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
71
9.7.1. Encryption Techniques – cont. 5
++SKIP++ Generation of “Round Keys” in DES


DES includes 16 rounds
Each round has its own round key derived from user’s key
 key – user-supplied
key
64-bit key (input)
C0
D0
LSH
LSH
PC-2
C1
LSH
PC-1, PC-2 –
permutation tables
 In addition, PC-2
extracts 48 of 56 bits
 Ci / Di – provides
confusion / diffusion
 LSH –left shift
(rotation) tables

PC-1
K1
D1
LSH
 K1 – K16 – round
keys (outputs)
PC-2
K16
 Length(Ki) = 48
[Fig: cf. Barbara Endicott-Popovsky, U. Washington]
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
72
9.7.1. Encryption Techniques – cont. 6
Input
++SKIP++ Basic DES Structure
Input Permutation




Input:
64 bits (a block – cf. Slide 68)
L0
Li/Ri– left/right half of the input block for
iteration i (32 bits) – subject to substitution S and
permutation P
K - user-supplied 64-bit key
Ki - round key (cf. next slide):
 56 bits used +8 unused
S

Output:

L1
R1
L16
R16
64 bits (a block – cf. Slide 68)
Note:
 Ri becomes L(i+1)
 All basic op’s are simple logical ops
K
P
(unused for E but often used for error checking)

R0
K1
K16
Final Permutation
Output
Left shift / XOR
[Fig. – cf. J. Leiwo]
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
73
9.7.1. Encryption Techniques – cont. 7
Public Key Encryption (PKE)


Recall: Two main types of cryptosystems:
 Secret key encryption (= symmetric cryptosystem)
 Public key encryption (= PKE = asymmetric cryptosystem)
We’ll discuss:
1) Motivation for PKE
2) PKE definition and characteristics
More details than covered immediately below can be found at
the end of at this section (optional – can be skipped)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
74
9.7.1. Encryption Techniques – cont. 8
1) Motivation for PKE



Classic symmetric cryptosystem: with a secret key
Problems:
 A lot of keys
2
 o(n ) keys for n users
(n * (n-1) /2 keys)
— if each must be able to communicate with each
 Secure distribution of so many keys
 Secure storage for the keys
 User with n keys can’t just memorize them
Can have a system with significantly fewer keys?
Yes!
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
75
9.7.1. Encryption Techniques – cont. 9
2) PKE Definition and Characteristics

1976 — Diffie and Hellman — new kind of cryptosystem:
public key encryption (PKE) =
= asymmetric cryptosystem




Key pair: < kPRIV, kPUB>
Each user owns one private key
Each user shares the corresponding public key with n-1
remaining users
=> n users share each public key
Only 2n keys for n users
2n = n * (1 + n * 1/n)





Since public key is shared by n people: 1 „owner” + (n-1) others = n
1/n since each part „owns” 1/n of the public key
Even if each communicates with each
Reduction from o(n2) to o(n) keys!
n key pairs are:
<kPRIV-1, kPUB-1 >, <kPRIV-2, kPUB-2>, ..., <kPRIV-n, kPUB-n>
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
76
9.7.1. Encryption Techniques – cont. 10


Recall: PKE - Encipher & decipher using different keys:
Secret private key & widely-known public key: < kPRIV, kPUB>
Two E/D uses for a key pair <kPRIV, kPUB >

P = D(kPRIV, E(kPUB, P))
 User encrypts msg with kPUB
 Recipient decrypts msg with kPRIV

Only recipient can decrypt it
 Bec. only recipient knows kPRIV
(kPUB” ”locks”)
(kPRIV ”unlocks”)
OR

P = D(kPUB, E(kPRIV, P))
(e.g., in RSA)
 User encrypts msg with kPRIV
(kPRIV ”locks”)
 Recipient decrypts msg with key kPUB
(kPUB ”unlocks”)

So anybody can decrypt (bec. anybody know kPUB)
 Used for digital signature – for authentication (below)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
77
9.7.1. Encryption Techniques – cont. 11

Having PKE, do we still need symmetric encryption (SE)?

Yes, SEs are 10,000+ times (!) faster than PKEs


PKEs use slow exponentiation – involves multiplication & division
SEs use only much faster bit operations (add, XOR< substitute, shift)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
78
9.7.1. Encryption Techniques – cont. 12

KE
RSA encryption method
– a PKE crypto system
 Order of D/E does not matter in RSA:
P = E (D(P)) = D(E(P))



P
E
KD
C
D
P
More precisely: P = E(kE, D(kD, P)) = D(kD, E(kE, P))
Encryption:
C = Pe mod n
KE = (n, e)
 Given C, it is very difficult to find P without knowing
KD
Decryption:
P = Cd mod n
KD = (n, d)
Text above: © 2007 by Leszek T. Lilien

A bit more detail on the RSA method
 To determine n, first select large prime numbers p & q
(e.g. each nearly 100-digit long)
=> n = p*q is large
(e.g. each nearly 200-digit long)
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
79
9.7.2. Authentication



Authentication – ensure that the user is genuine
 E.g., prevent impostors
Simplest authentication solution: login-password
 Not heavy-duty protection
Another authentication solution:
user provides ID + digital signature

Based on asymmetric key cryptography

System creates key pair: public key + private key


Public key - made public by the system
Private key - kept secret by system (v. difficult to derive from public key)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
80
9.7.2. Authentication – cont. 1
Using PKE for Digital Signatures

Transmitting signed msgs from S to R (using PKE)
 Original message:
(P = plaintext, C = ciphertext)
P



Privacy transformation by S: C = E(P, KPUB-R)
 Only R can decrypt it (with KPRIV-R)
Authenticity transformation = signing by S:
Sg = Sg(S, C) = D(C, KPRIV-S)
 Only S can produce Sg(S, C)
(with KPRIV-S)
Sent message:
C
Sg
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
81
9.7.2. Authentication – cont. 2

Transmitting signed msgs with PKE - cont.
 Msg received by R:
C
Sg

Step 1: R verifies Sg with S’s public key KPUB-S:
If E( Sg, KPUB-S) = C, then signature is valid


[ C = E(P, KPUB-R) ]
[Sg = Sg(S, C) = D(C, KPRIV-S)]
[i.e., Sg = D( E(P, KPUB-R) , KPRIV-S)
bec. E( Sg, KPUB-S) = E( D(C, KPRIV-S), KPUB-S) = C
Step 2: R decodes C (obtained in Step 1) with R’s private key
KPRIV-R:
P = D(C, KPRIV-R)

bec. D(C, KPRIV-R) = D( E(P, KPUB-R), KPRIV-R) = P
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
82
9.7.2. Authentication – cont. 3

Properties:
C
Sg

Authenticity:
If Sg is verified successfully, S is authenticated


[ C = E(P, KPUB-R) ]
[Sg = Sg(S, C) = D(C, KPRIV-S)]
Only S can produce valid S’s signature
 Bec. only S could have known KPRIV-S that is successfully
decrypted with KPUB-S
Unforgeability:
If C is forged, Sg verification will fail
( i.e., fails iff E( Sg, KPUB-S) ≠ C )

Non-repudiation (undeniability):
If Sg is verified successfully, S must be the sender

Bec. only S could have produced it, and have sent C”+”Sg
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
83
Authentication – cont. 4
Using Hash Fcns for Digital Signatures


Problem with above scheme:
very long signature – length(Sg) = length(P)
Solution: Using hash fcn H for digital signatures

Signature over H(P), not over P (when plaintext P signed)
length(Sg) = length( H(P) ) << length (P)

Signature can also be over H(C), not over C (when
ciphertext C signed)
length(Sg) = length( H(C) ) << length (C)
Before:
Now:
m
m
Sg(S, m)
Sg(S, H(m))
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
m = P or m = C
84
Authentication – cont. 5

Scenario – using signature over H(m), m = P or M = C

Fig. uses different notation:
 s = Sg
 DA(x) = D(x, KPRIV-A)
 EA(x) = E(x, KPUB-A)
[Fig — cf. J. Leiwo]
Note:
Any alteration of m is detected by B’s „Verify” step even
if m is not encoded with KPUB-B —due to use of H(m)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
85
9.7.2. Authentication – cont. 6

Do-it-yourself exercise:
See the scheme shown in the fig. (textbook, p. 210)
 See that it must keep the “public” key secret


It must be a secret shared only by System & User i (otherwise
anybody knowing it can sign as User i would)
Our scheme above does not require secrecy of the public
key (public should be public)
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
86
9.7.2. Authentication – cont. 7

Study-it-yourself:



See that the scheme presented in the fig. above (from the
textbook) is not a good use of public/private keys.
The major problem: the “public” key is not really public - it
must be a secret shared only by BS & MS
 Otherwise anybody knowing the key can send c and be
authenticated
In the authentication scheme presented earlier the public
key is indeed known publicly but authentication works
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
87
9.7.2. Authentication – cont. 8


Do-it-yourself exercise: Modify the following textbook
scheme so that the public key can indeed be public
The textbook scheme: Use of RSA for authentication in wireless


Problem - fig. (a): always the same bit pattern sent (ID is fixed)
 Can be intercepted & used by an impostor
Solution: add challenge-response interaction – fig. (b)
 R is different each time

Only somebody knowing value of e can provide correct response
input for the response) - only this MS knows this e value
(using R as
NOTE:
Here again must
keep “public” key
a secret of BS &
this MS
(otherwise
anybody knowing
it can answer the
challenge)
(Original
figures from the
(Modified
textbookbyused)
LTL)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
88
9.7.3. Wireless System Security


Wireless system security includes:
 Confidentiality
 Integrity
 Availability
-------- above: CIA – classic security elements ------- Nonrepudiation (undeniability)
 Authentication
Three categories of security mechanisms:
 Prevention mechanism
 Detection mechanisms
 Recovery mechanisms
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
89
9.7.3. Wireless System Security – cont. 1

Must strike a balance between cost of security &
expected/potential cost of security violation
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
90
9.7.3. Wireless System Security – cont. 2


Threats to security can be:
 Accidental - accidents, mistakes, etc.
 Intentional = attacks
Dimension 1 of attack categories
 See fig.
(Original
figures from the textbook used)
Copyright
2003, Dharma
rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All
91
9.7.3. Wireless System Security – cont. 3

Dimension 2 of attack categories
1) Active attacks
 Masquerading
 Replay
 Modification of data
 DoS (denial of service)
2) Passive attacks
 E.g. eavesdropping on wireless communications
 E.g. monitoring msg traffic, CPU usage, disk usage
 Very hard to detect


Bec. they do not disturb the system
Eavesdropping can be prevented, e.g., with
encryption
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
92
9.8. Firewalls and System Security




Security more challenging in wireless systems
 Bec. open-air transmission more vulnerable
Firewall can help
Two basic types of firewalls w.r.t. scope:
 Network firewall – protects its subnetwork
 Host-based firewall – protects its host
Firewall = device (h/w), or software, or combination of both
designed to keep „bad things” out, keep sensitive info in
that is:
1) to prevent unauthorized external users from accessing
network (a network firewall) and/or single host (a host-based
firewall)
2) to prevent inside network/host users (a network/host firewall,
respectively) from accessing certain external resources
(E.g., prevent them from accessing dangerous web sites)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
93
9.8. Firewalls and System Security – cont. 1

Firewall functions:
 Traffic filtering

It can be based on:






IP source/destination address
Source/destination TCP/UDP port nr
Arrival/destination interface
IP protocol
Web authentication
Other security mechanism
 Firewalls follows a security policy
 Security policy specifies what are „bad things” or what is
“sensitive info”

E.g., requires that traceroute & ping -o can't see internal hosts
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
94
9.8. Firewalls and System Security – cont. 2

Examples of security policy requirements w.r.t. firewalls:
 Block any access from the outside, allow all accesses to
the outside
 Allow”from” accesses only for certain activities OR only
to/from certain subnets/hosts/apps/users


E.g., prevent outside access to subnet hosts except for mail
server accesses
Choice of default firewall behavior
1) Default permit

„That which is not expressly forbidden is allowed”
2) Default deny


„That which is not expressly allowed is forbidden”
Users prefer default permit,
security experts prefer default deny
=> sysadmin must make the choice
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
95
9.8. Firewalls and System Security – cont. 3

Basic kinds of firewalls:

Hardware firewalls

More common

Implemented on router level

More expensive / more difficult to configure

Software firewalls

Used in single workstations

Less expensive / Easier to configure
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
96
9.8. Firewalls and System Security – cont. 4

Firewalls in WLAN (wireless LAN) environments:

Typically, located at a wireless access point (AP)


AP - single point of connectivity to the Internet for all users
within the AP’s domain
AP/firewall perform authentication using authentication
server

Authentication server = AAA server = authentication,
authorization and accounting server


AP/firewall and AAA server within the same administrative domain
Protocols used by AAA Server

RADIUS – the most popular protocol


RADIUS = remote authentication dial-in user service
DIAMETER – a newer & improved protocol
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
97
9.8. Firewalls and System Security – cont. 5

Firewalls in cellular 3G systems:

Connection route:
MS – BSS (base station subsystem) – MSC (mobile switching center)
– gateway MSC – WAP (wireless application protocol) gateway Internet

Typically, firewall between WAP gateway & Internet

But sysadmin can put it somewhere else
More details on firewalls can be found at the end of at this
section (optional – can be skipped)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
98
The End of Section 9 (Ch. 9)
OPTIONAL details (that you may SKIP)
for Section 9.7 (security & privacy) &
Section 9.8 (firewalls & security) follow
99
9.7. Security and Privacy
9.7.1. Encryption Techniques
All the following slides can be
SKIPped
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
100
Overview of DES (1)
 DES - a block cipher
 A product cipher
 16 rounds (iterations) on the input bits (of P)
 substitutions (for confusion) and permutations (for diffusion)
 Each round with a round key
 Generated from the user-supplied key
 Easy to implement in S/W or H/W
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
101
Generation of “Round Keys” in DES


DES includes 16 rounds
Each round has its own round key derived from user’s key
 key – user-supplied
key

PC-1

C0
D0

LSH
LSH
PC-2
C1
K1

D1

LSH
LSH
PC-2
K16
64-bit key (input)
PC-1, PC-2 –
permutation tables
In addition, PC-2
extracts 48 of 56 bits
Ci / Di – provides
confusion / diffusion
LSH –left shift
(rotation) tables
K1 – K16 – round
keys (outputs)
 Length(Ki) = 48
[Fig: cf. Barbara Endicott-Popovsky, U. Washington]
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
102
Basic DES Structure




Input:
64 bits (a block)
Li/Ri– left/right half of the input block
for iteration i (32 bits) – subject to
substitution S and permutation P
K - user-supplied 64-bit key
Ki - round key (cf. next slide):


Input Permutation
L0
R0
S
K
P
56 bits used +8 unused
(unused for E but often used for error checking)

Input
Output:
64 bits (a block)
Note:
 Ri becomes L(i+1)
 All basic op’s are simple logical ops

L1
R1
L16
R16
K1
K16
Final Permutation
Left shift / XOR
Output
[Fig. – cf. J. Leiwo]
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
103
Public Key Encryption (PKE)


Recall: Two main types of cryptosystems:
 Secret key encryption (= symmetric cryptosystem)
 Public key encryption (= PKE = asymmetric cryptosystem)
Outline for PKE
1) Motivation for PKE
2) Characteristics of PKE
3) RSA (Rivest-Shamir-Adelman) Encryption
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
104
1) Motivation for PKE

Classic symmetric cryptosystem: with a secret key

Problems:



A lot of keys
2
 o(n ) keys for n users
(n * (n-1) /2 keys)
— if each must be able to communicate with each
Secure distribution of so many keys
Secure storage for the keys


User with n keys can’t just memorize them
Can have a system with significantly fewer keys?
Yes!
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
105

1976 — Diffie and Hellman — new kind of cryptosystem:
public key encryption (PKE) =
= asymmetric cryptosystem




Key pair: < kPRIV, kPUB>
Each user owns one private key
Each user shares the corresponding public key with n-1
remaining users
=> n users share each public key
Only 2n keys for n users
2n = n * (1 + n * 1/n)





Since public key is shared by n people: 1 „owner” + (n-1) others = n
1/n since each part „owns” 1/n of the public key
Even if each communicates with each
Reduction from o(n2) to o(n) keys!
n key pairs are:
<kPRIV-1, kPUB-1 >, <kPRIV-2, kPUB-2>, ..., <kPRIV-n, kPUB-n>
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
106
2) Characteristics of PKE

PKE requirements
1. It must be computationally easy to encipher and
decipher a message given the appropriate key
2. It must be computationally infeasible to derive kPRIV
from kPUB
3. It must be computationally infeasible to determine
kPRIV from a chosen plaintext attack
Barbara
U. Washington]
Copyright
2003, Dharma
Qing-An
Zeng.Endicott-Popovsky,
All rights reserved
©
2007 by©Leszek
T. LilienP. Agrawal and [cf.
107

Key pair characteristics

One key is inverse of the other key of the pair
 i.e., it can undo encryption provided by the other:



D(kPRIV, E(kPUB, P)) = P
D(kPUB, E(kPRIV, P)) = P
One of the keys can be public
 Since each key does only half of E ”+” D

As shown above – need both E and D to get P back
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
108


Recall: PKE - Encipher & decipher using different keys:
Secret private key & widely-known public key: < kPRIV, kPUB>
Two E/D uses for a key pair <kPRIV, kPUB >
 P = D(kPRIV, E(kPUB, P))


User encrypts msg with kPUB
Recipient decrypts msg with kPRIV

Only recipient can decrypt it

Bec. only recipient knows kPRIV
OR
 P = D(kPUB, E(kPRIV, P))



(kPUB” ”locks”)
(kPRIV ”unlocks”)
(e.g., in RSA)
User encrypts msg with kPRIV
(kPRIV ”locks”)
Recipient decrypts msg with key kPUB (kPUB ”unlocks”)
 So anybody can decrypt (bec. anybody know kPUB)
 Used for digital signature – for authentication (later)
Having PKE, do we still need symmetric encryption (SE)?
 Yes, SEs are 10,000+ times (!) faster than PKEs


PKEs use slow exponentiation – involves multiplication & division
SEs use only much faster bit operations (add, XOR< substitute, shift)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
109
3) RSA Encryption



RSA = Rivest, Shamir, and Adelman (MIT), 1978
Based on underlying hard problem:
 Number theory – determining prime factors of a given
large number (ex. factoring of small #: 5  5, 6  2 *3)
 Arithmetic modulo n
How secure is RSA?
 So far remains secure (after all these years...)
 Will sb propose a quick algorithm to factor large
numbers?
 Who knows… Could happen tomorrow… or never
 Will quantum computing break it?
 Research will tell - TBD
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
110

RSA encryption method – a PKE crypto system
 Order of D/E does not matter in RSA:
P = E (D(P)) = D(E(P))



More precisely: P = E(kE, D(kD, P)) = D(kD, E(kE, P))
Encryption:
C = Pe mod n
KE = (n, e)
 Given C, it is very difficult to find P without knowing
KD
Decryption:
P = Cd mod n
KD = (n, d)
Text above: © 2007 by Leszek T. Lilien

More detail on the RSA method for deriving private-public
keys
 p & q are large prime numbers (e.g. each nearly 100-digit long)
=> n = p*q is large (e.g. each nearly 200-digit long)
Copyright © 2003, Dharma P. Agrawal and Qing-An Zeng. All rights reserved
111
9.7.3. Wireless System Security
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
112
Firewalls

Outline
a) Introduction
b) What is a firewall
c) Firewall design
d) Types of firewalls
i. Packet filters
(i-1) Simple packet filters
(i-2) Stateful packet filters
ii. Application proxies
(ii-1) Guards
(“top model” subcategory)
iii. Personal firewalls
e) Comparison of firewall types
f) Example firewall configurations
g) What firewalls can—and can’t—block
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
113
a. Introduction

Firewalls

Invented in the early 1990’s

But idea related to reference monitors from 1970’s

What is reference monitor?

OS includes kernel / core / nucleous – responsible for lowestlevel functions

Incl. synchronization, inter-process communication,
msg passing, interrupt handling

Security kernel – provides security mechanisms for entire OS

Incl. security interfaces among h/w, OS, other parts of
computing system

Typically, security kernel is a part of OS kernel

Reference monitor is portion of security kernel that controls
access to objects (controls „references” to objects)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
114
b. What is a firewall (1)
Firewall = device (h/w), or software, or combination of both
designed to prevent unauthorized users from accessing
network and/or single workstation

Wall between protected local (sub)net & outside global net



Inspect each individual inbound or outbound packet of
data sent to / from protected system
Check if it should be blocked or allowed to enter
Firewalls keep „bad things” out, keep sensitive info in

Security policy specifies what are „bad things”



E.g., requires that traceroute & ping -o can't see internal hosts
F. protect against security threats from external network
F. are effective in protecting local subnet incl. its
sensitive info
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
115
What is a firewall (2)

Examples of security policy requirements w.r.t. firewalls:
 Block any access from the outside, allow all accesses to
the outside
 Allow”from” accesses only for certain activities OR only
to/from certain subnets/hosts/apps/users


E.g., prevent outside access to subnet hosts except for mail
server accesses
Choice of default firewall behavior
1) Default permit

„That which is not expressly forbidden is allowed”
2) Default deny


„That which is not expressly allowed is forbidden”
Users prefer default permit, security experts prefer
default deny

Sysadmin must make the choice
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
116
c. Firewall design (1)

Firewall design principles:
 Small / simple enough for rigorous analysis
 KISS principle (= „Keep It Simple, Stupid”)
 Simple firewall functionality

Tamperproof
 Typically well isolated (=> highly immune to modifications)



On a separate computer
With direct connections only to the outside networks and to
the inside network
Designed to be always invoked
 Efficient enough not too be a bottleneck
 Placed strategically

All network accesses that we want to control pass through it
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
117
Firewall design (2)

General firewall techniques:
1) Service control

Type of service: inbound or outbound
2) Traffic filtering — based on IP address & TCP port nr

Provide proxy software to receive or interpret service
request before passing it on

Could also host server software (e.g. Web or mail service)

Not recommended

Complicates it (more code => more vulnerabilities)
3) User Control

Control access to service using ACLs
4) Behavior Control

E.g. filter e-mail for spam
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
118
Firewall design (3)

Basic firewall characteristics

All traffic (incoming / outgoing) must pass thru firewall

Only authorized traffic allowed to pass

Firewall itself must be immune to penetration


I.e. must use trusted system w/ secure OS (min. size/complexity)
Usually implemented on dedicated device



Dedicated = only firewall functions performed on this device
Firewall code must be very well protected
Basic kinds of firewalls:

Hardware firewalls

More common

Implemented on router level

More expensive / more difficult to configure

Software firewalls

Used in single workstations

Less expensive / Easier to configure
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
119
d. Types of firewalls (1)
Types of firewalls

i.
Packet filters / packet filtering firewalls
(i-1) Simple packet filters / (simple) packet filtering gateways
/ screening routers
(i-2) Stateful packet filters / stateful inspection firewalls
ii.
Application proxies
/ proxy firewalls / application-level
gateways
(ii-1) Guards (a special case of app proxies)
iii. Personal firewalls
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
120
Types of firewalls (2)

Firewall properties:

Packet filter properties:

Transparent

Does not change traffic, only passes it

Proxy properties:

Active

Intercepts traffic & acts as an intermediary
Different firewall types needed for different needs



„Different strokes for different floks” — e.g.:
Simple packet filters / screening routers – implement simplistic
security policies

Simple is best if sufficient to counter exisiting threats well
App proxies – much richer capabilities
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
121
Types of firewalls (3)
Firewall is a type of host

Even some routers are host-based
To have better tools available (editors, programming tools)


Programmable
Minimal functionality

Reduces vulnerabilities


Small = > less complex => fewer vulnerabilities
Reduces motivation for attacks

No password files to steal, etc.
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
122
(i) Packet filters (1)


Packet filters — a.k.a. packet filtering firewalls
(i-1) Simple packet filters („memoryless”)
(i-2) Stateful packet filters (with „memory”)
Basis for packet filtering
1) Packet IP addresses

Filtering based on both source/destination addresses
2) Port number determines TCP transport protocol type



Recall “portprotocol” mapping in TCP: 21FTP, 23Telnet,
25SMTP, 80HTTP, 110POP, 161 SNMP, etc.
Filtering based on port nr
Packet filtering firewalls do not „see” other packet fields


See only IP address ‘ transport protocol type
E.g., can not allow only some Telnet commands OR exclude only
some other Telnet commands
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
123
(i) Packet filters (2)

Examples of packet filtering – see text
1a) Packet address filtering (cf. Fig. 7-35, p. 459)
Can block traffic from specific subnets and/or allow traffic from
specific subnets
1b) Packet address filtering (cf. Fig. 7-36, p. 460)
Can block traffic from specific IP addresses and/or allow traffic
from specific IP addresses
2) Filtering based on transport protocol (cf. Fig. 7-35, p. 459)
Can block traffic using Telnet protocol (port 23) but allow HTTP
traffic (port 80)

To avoid overburdening router, firewall can run on device
behind router (on subnet side)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
124
(i-1) Simple packet filters (1)
Simple packet filters / (simple) packet filtering gateways /
screening routers — simplest firewall type


Simple packet filters (PFs) are memoryless
=> can not perform attack detections that require
remembering state (history/context) of ≥ N last pkts
 E.g., can not see that prev. & curr. pkt indicate attack
 “Attack signature” (i.e., attack pattern) would be clearly
visible if both pkts were put together


Example: Certain attack script known to use Telnet (port 23)
and then SNMP (port 161)
The same source address in previous pkt, using port 23, and in
current packet, using port 161, constitutes attack signature
Why need to remember ≥ N last pkts?

TCP pkts arrive in order different than sending order
=> remembering ≤ N last pkts is not enough
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
125
(i-1) Simple packet filters (2)

Cheating simple (memoryless) PF:
 Attacker divides pkt (including attack signature) into
many v. short pkts
 Attack signature (pattern) would be visible in
original long pkt

Even memoryless simple PF would detect it
 Pattern of attack is completely invisible in any
single short pkt


=> memoryless simple PF is unable to detect attack
Additionally, TCP pkts arrive in order different than
their sending order
=> remembering just last packet would not be
enough – must remember N last packets
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
126
(i-1) Simple packet filters (3)

One very important task for simple packet filtering
gateways: Validating inside IP addresses

Inside hosts trust more other inside host

Simple filtering assures that no external source can
masquerade as internal source

Blocks any packet coming from outside network that claims to
be sent by internal host

Cf. Fig. 7-37, p. 460
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
127
(i-1) Simple packet filters (4)

Simplicity of inspection is both disadvantage & advantage

Disadvantage because of high granularity

E.g., can block all Telnet coomands, but can not block
only selected telnet commands

Advantage beacuse reduces complexity

Filtering rules to block, e.g., only selected Telnet traffic would
have to be much more detailed
=> more complex
=> more vulnerable
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
128
(i-2) Stateful packet filters
Stateful packet filters — a.k.a. stateful inspection firewalls


Keep state/history/context of  N previously seen pkts
=> stateful packet filters have memory


This allows detection of some attacks that simple PFs
can not detect
Still limited to detection based on IP address & TCP
transport protocol type (port nr)
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
129
(ii) Application proxies (1)

Application proxies / proxy firewalls / application-level
gateways / application proxy gateways
Note: The term bastion host (used in text) should not be used as a
synonym. Bastion host is a host that serves as a platform for app
proxy or circuit-level proxy [Stallings, Crypto&Net.Sec, p.625].


Application proxies include — as a special case
(ii-1) Guards
App proxy firewalls fix basic problem with packet filtering
firewalls because they:

See all pkt data (not just IP adresses and port #s)

(In addition, they are stateful => can analyze multiple pkts)
=> can detect/derail more sophisticated attacks

Can filter out harmful commands in pkt stream
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
130
(ii) Application proxies (2)

For example, app proxies can prevent:

Use of back door open to pkts inbound to SMTP port
(Port 25)

Flawed application run by user U (e.g., an e-mail agent) has
all U’s privileges => can cause damage
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
131
(ii) Application proxies (3)
Act as mediators/censors (!) of app-level traffic – like
benevolent „woman-in-the middle”  (not an official term!)




They “censor” insecure actions
Maybe a rare case of a truly benevolent censor
Ex. scenario of using app proxy gateway G: [cf. ibid, p.624]

Extern. user U tries to Telnet to host H protected by G

G intercepts U’s packets

G acts as H would: asks U for id+pwd

U replies w/ id+pwd

G logs in into H on behalf of U

G relays H’s msgs to U

Etc., etc.
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
132
(ii) Application proxies (4)



Examples of app proxy activities
 Preventing outsiders from modifying company’s online
price list
 More - see bulleted list on p. 462
App proxy must implement code for given app (e.g., for
Telnet) to be able to perform service to this app
Netadmin can configure app proxy to support only selected
features of an app

Unsupported features are considered too risky
=> not available
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
133
(ii) Application proxies (5)

App proxies provide higher level of security than packet
filters (PFs)

PFs try to deal with all potentially deployable applications
that could use TCP/IP (default permit philosophy)

App proxy considers only few allowable apps among
ones actually deployed in a given system (default deny
philosophy)
App proxy can easily log/audit traffic at app level (vs.

transport level for PFs)

Prime disadvantage of app proxies: Processing overhead for
each app-level connection

1 connection split into 2 logical connections


With “woman-in-the-middle” 
Circuit-level gateways (another proxy subcategory) splits
1 TCP connection into 2 TCP connections
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
134
(ii) Application proxies (6)
(ii-1) Guards = most sophisticated category of app proxies (“top
model”)
Limited only by what is computable (& by human creativity)
No sharp boundary between app proxies and guards




At some point of upgrading app proxy, it becomes a guard
Examples of guard activities
 Limiting nr of msgs (or nr of msg characters) that a
student may e-mail per week
 Easiest if done by gurad monitoring mail transfer
protocol
 More - see bulleted list on p. 464
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
135
(iii) Personal firewalls

Regular firewalls protects subnetworks
Personal firewalls protect single hosts

For small business / home office / home

Can be used to complement conventional firewall

Next line of defense

Customized to user(s) of particular host

Firewall capabilities at a lower price
Personal firewall is application program


Products include: Norton Personal Firewall (Symantec), McAfee
Personal Firewall, Zone Alarm (Zone Labs)
Personal firewall also enforces certain security policy



E.g., if you’re using default personal firewall’s policy on your
computer, see its rules
Combine it with antivirus software for more effective
protection & with automatic (or very frequent manual)
OS and antivirus s/w updates
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
136
e. Comparison of firewall types

Comparison of firewall types
 See Table 7-8, p. 465
 Criteria:
 Complexity
 Part of packets visible to firewall
 Difficulty of auditing
 Basis for screening
 Difficulty of configuring
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
137
f. Example firewall configurations

Example firewall configurations
 Subnet with screening router (simple packet filtering)

Subnet with proxy gateway (app proxy)
Copyright
2003, Dharma
Zeng.
All rights Security”
reserved by Pfleeger&Pfleeger
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An
Fig. from
“Computer
138
f. Example firewall configurations – cont.

Subnet with simple PF & app proxy

Note:
The LAN between outer firewall (“screening router”
in the fig) and the inner firewall (“proxy firewall” in
the fig) constitutes DMZ (demilitarized zone)
Copyright
2003, Dharma
Zeng.
All rights Security”
reserved by Pfleeger&Pfleeger
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An
Fig. from
“Computer
139
g. What firewalls can—and can’t—block
Firewalls are not a panacea - only a perimeter protection
Points 2 remember about firewalls — see text, p.466-467








Can protect environment only if control its whole perimeter
Do not protect data outside the perimeter
Are most visible subnet component – attractive attack targets
Must be correctly configured, & config must be periodically updated
Firewall platforms should not have any s/w that could help attacker
who penetrates firewall in subsequent exploits
Firewalls exercise very limited control over content they let in
 Other means of verifying/enforcing accuracy/correctness must
be used inside perimeter
Copyright
2003, Dharma
©
2007 by©Leszek
T. LilienP. Agrawal and Qing-An Zeng. All rights reserved
140
The End of Section 9 (Ch. 9)
(incl. OPTIONAL details that you may SKIP)
141