Real-World Protocols I
CS 3IS3
Ryszard Janicki
Department of Computing and Software, McMaster University, Hamilton, Ontario, Canada
Acknowledgments: Material based on Information Security by Mark Stamp (Chapters 10.1-10.4)
Ryszard Janicki
Real-World Protocols I 1/38
Secure Shell (SSH)
Creates a “secure tunnel”
Insecure command sent thrugh SSH “tunnel” are then secure SSH is used with things like rlogin
rlogin send paswors in the clear.
SSH makes rlogin secure (similar for other features)
SSH is a relatively simple protocol SSH authentication can be based on:
Public keys, or Digital certificates, or Passwords
Here, we consider certificate mode
We will also consider a slightly simplified SSH
Ryszard Janicki
Real-World Protocols I 2/38
Simplified SSH
Simplified SSH
Alice, CP, RA CS, RB
ga mod p
gb mod p, certificateB, SB
Alice E(Alice, certificateA, SA, K) Bob
CP C=P“c=ry“pctoryptroporospeods”e,da”,ndanCd SCS= =“cr“ycprytoptsoeslelcetcetedd”” AABBaa bb abab
H =Hh=(Ahl(icAelic,Be,oBbob,C, CP,,CS,R ,,R, g,g mmodopd, gp,gmomd po,dg p,mgod pm)od p) S =S [ H=] [ H ]
B B Bob Bob
S =S [H=, A[Hli,cAel,icee,rcteifritciaficteate] ]
A A
ab ab
A AlicAelice
K =Kg=mgodmpod p
Part 3 Protocols
MiM attack fails here!
78
Ryszard Janicki
Real-World Protocols I 3/38
MiMAttack on SSH?
MiM Attack on SSH?
Alice, RA
RB
ga modp
Alice, RA
RB
gt modp
gb mod p, certB, SB E(Alice,certA,SA,K) Bob
gt mod p, certB, SB Alice E(Alice,certA,SA,K)
Trudy Where does this attack fail?
The attack fails since:
Alice computes Alice computes
H = h(Alice,Bob,CP,CS,R ,R ,ga mod p,gt mod p,gat mod p) a ABatat
Ha = h(Alice,Bob,CP,CS,RA,RB,g mod p,g mod p,g mod p) But Bob signs
But Bob signs
Hb = h(Alice,Bob,CP,CS,RA,RB,gt mod p,gb mod p,gbt mod p)
Hb = h(Alice,Bob,CP,CS,RA,RB,gt mod p,gb mod p,gbt mod p) Part 3 Protocols 79
Ha ̸= Hb
Ryszard Janicki
Real-World Protocols I 4/38
Secure Socket Layer (SSL)
Socket layer
“Socket layer”
lives between User
application
transport
network
link
physical
application
“Socket layer” lives
and transport
between application and OS layers
transport layers
SSL usuSalSlyLbuetswueaelnly HTTP abnedtTwCePen HTTP
NIC
Socket “layer”
and TCP
Part 3 Protocols 81
Ryszard Janicki
Real-World Protocols I 5/38
What is SSL?
SSL is the protocol used for majority of secure Internet transactions today
For example, if you want to buy a book at amazon.com. . .
You want to be sure you are dealing with Amazon (authentication)
Your credit card information must be protected in transit (confidentiality and/or integrity)
Simple SSL-like Protocol
As long as you have money, Amazon does not really care who
you are, so no need for mutual authentication!
Simple SSL-like Protocol
Alice
I’d like to talk to you securely Here’s my certificate
{K}Bob
protected HTTP Bob
Is Alice sure she is talking to Bob?
Is Alice sure she’s talking to Bob? Is Bob sure he is talking to Alice?
Is Bob sure he’s talking to Ryszard Janicki
Alice?
Real-World Protocols I 6/38
Simplified SSL Protocol
Simplified SSL Protocol
SSisisththeesso-calledprree-m-masatsetrersescerectret KK==h(Sh(,RS,R,R,)R )
A AB B “m“msgsgss””mmeeaannssaalllppreviousmesssaaggeses
CCLLNNTTanadndSSRRVRaare constaannttss
6 “keys” are derived from K = h(S,RA,RB) Part 3 Protocols 84
2 encryption keys: client and server
2 integrity keys: client and server
2 IVs (Initialization Vectors): client and server Different keys in each direction prevent certain types of
attacks.
Encryption of h(msgs,CLNT,K) adds no security, a minor flaw
Can we talk?, cipher list, RA certificate, cipher, RB {S}Bob, E(h(msgs,CLNT,K),K)
Alice
h(msgs,SRVR,K)
Data protected with key K Bob
Ryszard Janicki
Real-World Protocols I 7/38
SSL Authentication
Simplified SSL Protocol
Can we talk?, cipher list, RA certificate, cipher, RB {S}Bob, E(h(msgs,CLNT,K),K)
h(msgs,SRVR,K)
Data protected with key K Bob
Alice
S is the so-called pre-master secret
Alice authenticates Bob, not vice-versa
K = h(S,R ,R )
Mutual aAutheBntication is possible: Bob sends certificate
“mresqguse”smt einanmsesaslal gpere2vious messages
CLNTTahnedn ScliRenVtRmaurstehcaovensatvaanltidscertificate
But, if server wants to authenticate client, server could instead
Part 3 Protocols 84 require password
Ryszard Janicki
Real-World Protocols I 8/38
SSL MiM Attack?
SSL MiM Attack?
RA RA
certificate , R certificate , R TB BB
{S1}Trudy,E(X1,K1) h(Y1,K1)
{S2}Bob,E(X2,K2) h(Y2,K2)
Trudy
Q: What prevents this MiM “attack”?
E(data,K2) Bob Question: What prevents this MiM “attack”?
E(data,K1)
Alice
A: Bob’s certificate must be signed by a
Answer: Bob’s certificate must be signed by a certificate certificate authority (CA)
authority (CA)
What does browser do if signature not valid? IfsWignhatudroesnuostervadloidw,hbenrobwroswersesrecnodmspalaiwnsa?rning.
Part 3 Protocols 87
Alice may ignore the warning and allow to proceed, potential
danger?
Ryszard Janicki
Real-World Protocols I 9/38
SSL Sessions and Connections
SSL session is established as shown on previous slides
SSL was originally designed for use with HTTP 1.0
HTTP 1.0 often opens multiple simultaneous (parallel)
connections, i.e. multiple connections per session
SSL session is costly, involves public key operations
SSL Connection
SSL has an efficient protocol for opening new connections
given an existing session
session-ID, cipher list, RA
session-ID, cipher, RB, h(msgs,SRVR,K)
Alice
Assuming SSL session exists
h(msgs,CLNT,K)
Protected data Bob
Assuming SSL session exists
So, S is already known to Alice and Bob
So, S is already known to Alice and Bob Both sides must remember session-ID
Both sides must remember session-ID
Again, K = h(S,RA,RB) Again, K = h(S,RA,RB)
No public key operations! (relies on known S)
No public key operations! (relies on known S) Part 3 Protocols 89
Ryszard Janicki
Real-World Protocols I 10/38
SSL vs IPSec (Internet Protocol Security)
IPSec (Internet Protocol Security) – discussed next
Lives at the network layer (part of the Operating System) Encryption, integrity, authentication, etc.
Is overly complex, has some security “issues”
SSL (and IEEE standard known as TLS or Transport Layer Security)
Lives at socket layer (part of user space) Encryption, integrity, authentication, etc. Relatively simple and elegant specification
IPSec: OS must be aware, but not applications SSL: Applications must be aware, but not OS SSL built into Web early-on (Netscape)
IPSec often used in VPNs (secure tunnel) Reluctance to retrofit applications for SSL IPSec not widely deployed (complexity, etc.) The bottom line?
Internet less secure than it could be!
Ryszard Janicki
Real-World Protocols I 11/38
IPSec and SSL
IPSec and SSL
IPSec lives at
the network User layer
application
transport
network
link
physical
IPSec lives at the network layer
IPSec is transparent to
SSL
IPSec is OS transparent to
IPSec
applications
applications
Part 3 Protocols 93
NIC
Ryszard Janicki
Real-World Protocols I 12/38
IPSec and Complexity
IPSec is a very complex protocol
Over-engineered
Lots of (generally useless) features
This is an unfortunate property of most of modern designs: cars, operating systems, webpages, software packages,
TV sets, gadgets, appliances, etc., a lot of generally useless or very seldom used features (often called “intelligent”).
Flawed – Some significant security issues.
This is one of the consequence of being unnecessarily complex and over-engineered.
Interoperability is serious challenge
Defeats the purpose of having a standard!
Ryszard Janicki
Real-World Protocols I 13/38
IKE and ESP/AH
Two parts to IPSec. . .
IKE: Internet Key Exchange
Mutual authentication
Establish session key
Two “phases” – like SSL session/connection
ESP/AH
ESP: Encapsulating Security Payload – for confidentiality
and/or integrity
AH: Authentication Header – integrity only
Ryszard Janicki
Real-World Protocols I 14/38
IKE
IKE has 2 phases
Phase 1 – IKE security association (SA) Phase 2 – AH/ESP security association
Phase 1 is comparable to SSL session
Phase 2 is comparable to SSL connection
Not an obvious need for two phases in IKE In the context of IPSec, that is
If multiple Phase 2’s do not occur, then it is more costly to have two phases
Ryszard Janicki
Real-World Protocols I 15/38
IKE Phase 1
4 different “key options”
Public key encryption (original version)
Public key encryption (improved version) Public key signature
Symmetric key
For each of these, ,2 different “modes” Main mode and aggressive mode
There are 8 versions of IKE Phase 1!
Need more evidence it’s over-engineered?
We discuss (briefly) 6 oft he 8 Phase 1 variants
Public key signatures (main and aggressive modes) Symmetric key (main and aggressive modes) Public key encryption (main and aggressive)
Why public key encryption and public key signatures?
Always know your own private key
May not (initially) know other side’s public key
Ryszard Janicki
Real-World Protocols I 16/38
IKE Phase 1
Uses ephemeral Diffie-Hellman to establish session key Provides perfect forward secrecy (PFS)
Let a be Alice’s Diffie-Hellman exponent
Let b be Bob’s Diffie-Hellman exponent
Let g be generator and p prime Recall that p and g are public
Ryszard Janicki
Real-World Protocols I 17/38
IKE Phase 1: Digital Signature
IKE Phase 1: Digital Signature (Main Mode)
Alice
IC, CP IC,RC, CS IC,RC, ga mod p, RA
IC,RC, gb mod p, RB
IC,RC, E(“Alice”, proofA, K) Bob
IC,RC, E(“Bob”, proofB, K)
K = h(IC,RC,g mod p,RA,RB)
(Main Mode)
CP = crypto proposed, CS = crypto selected
CP = crypto proposed, CS = crypto selected
IC = initiator “cookie”, RC = responder “cookie”
IC = initiabtor “cookie”, RC = responder “cookie”
ab SKEKYID==h(hI(CR,R,CR,,ggabmooddp,)RA,RB)
AB
proof = [h(SKEYID,g mod p,g mod
a abb SAKEYID=h(RA,RB,g modp)
Paprt,I3C,RProCto,cColsP,“Alice”)]Alice a b 101
proofA = [h(SKEYID,g mod p,g mod p,IC,RC,CP,“Alice”)]Alice
Ryszard Janicki
Real-World Protocols I 18/38
IKE Phase 1: Public Key Signature (Aggressive Mode))
IKE Phase 1: Digital Signature
Main:
Alice
(Main Mode)
IC, CP IC,RC, CS IC,RC, ga mod p, RA
IC,RC, gb mod p, RB
IC,RC, E(“Alice”, proofA, K) Bob
IC,RC, E(“Bob”, proofB, K)
IKE Phase 1: Public Key
CP = crypto proposed, CS = crypto selected ——————————————————
ICS=iingitinataort“ucoroekie(”,ARCgg=reespsosnidvere“cMookoied”e) Aggressive:
K = h(IC,RC,gab mod p,RA,RB)
P
IC, “Alice”,abga mod p, R , CP SKEYID = h(RA, RB, g mod p) A
proof = [h(SKEYID,ga mod p,gb mod A IC,RC, “Bob”, RB,
aprt,I3C,RProCto,cColsP,“Aliceb”)] 101
Alice
Bob
Alice
g mod p, CS, proof
IC,RC, proofA
B
Main differences from main mode
Main differences from main mode Not trying to hide identities
o Not trying to hide identities
Cannot negotiate g or p o Cannot negotiate g or p
Part 3 Protocols Ryszard Janicki
Real-Wo1r0ld2 Protocols I 19/38
Main vs Aggressive Modes
Main mode MUST be implemented Aggressive mode SHOULD be implemented
So, if aggressive mode is not implemented, “you should feel guilty about it”
Might create interoperability issues
For public key signature authentication
Passive attacker knows identities of Alice and Bob in aggressive mode, but not in main mode
Active attacker can determine Alice’s and Bob’s identity in main mode
Ryszard Janicki
Real-World Protocols I 20/38
IKE Phase 1: Symmetric Key (Main Mode)
IKE Phase 1: Symmetric Key
(Main Mode)
Same as signature mode except Same as signature mode except
o KAB = symmetric key shared in advance KAB = symmetric key shared in advance
o K = h(IC,RC,gab mod p,R ,R ,K ) K=h(IC,RC,gabmoAdpB,RA,BR,K )
Alice
KAB
IC, CP IC,RC, CS
IC,RC, ga mod p, RA IC,RC, gb mod p, RB
IC,RC, E(“Alice”, proofA, K) Bob IC,RC, E(“Bob”, proofB, K) KAB
ab ab oSKEYSIKDEY=IhD(K=,hg(Km,godmp)odp)
Part 3 pP,rIoCtoc,RolsC,CP,“Alice”) 104
A B AB
ab
proofA = h(SKEYIDa,g mod pb,g mod p,IC,RC,CP,“Alice”)
o proof = h(SKEYID,g mod p,g mod A
Ryszard Janicki
Real-World Protocols I 21/38
IKE Phase 1: Symmetric Key
Problems with Symmetric Key (Main Mode)
Alice
KAB
IC, CP IC,RC, CS
IC,RC, ga mod p, RA IC,RC, gb mod p, RB
IC,RC, E(“Alice”, proofA, K) Bob IC,RC, E(“Bob”, proofB, K) KAB
Same as signature mode except Catch-22
o KAB = symmetric key shared in advance Alice sends her ID in message 5
o K = h(IC,RC,gab mod p,RA,RB,KAB) Alice’s ID encrypted with K
o SKEYID = h(K, gab mod p)
To find K Bob must know KAB
o proofA = h(SKEYID,ga mod p,gb mod
To get K Bob must know he’s talking to Alice! AB
Part 3 pP,rIoCtoc,RolsC,CP,“Alice”) 104 Result: Alice’s IP address used as ID!
Why go to all of the trouble of trying to hide identities in 6 message protocol?
Ryszard Janicki
Real-World Protocols I 22/38
(Main Mode)
IKE Phase 1: Symmetric Key (Aggressive Mode)
(Aggressive Mode)
IC, “Alice”, ga mod p, RA, CP
IC,RC, “Bob”, RB, gb mod p, CS, proofB
Alice IC,RC, proofA Bob SaSmame efofromrmatatasasdidgigtiatlasl isgingantautruereagagrgersessiviveemmodoede
Not trying to hide identities… Not trying to hide identities. . .
As a result, does not have problems of main mode As a result, does not have problems of main mode
But does not (pretend to) hide identities But does not (pretend to) hide identities
Part 3 Protocols 106
Ryszard Janicki
Real-World Protocols I 23/38
IKE Phase 1: Symmetric Key
IKE Phase 1: Public Key
IKE Phase 1: Public Key Encryption (Main Mode)
Encryption (Main Mode)
CP = crypto proposed, CS = crypto selected CP = crypto proposed, CS = crypto selected
Alice
IC, CP IC,RC, CS
IC,RC, ga mod p, {RA}Bob, {“Alice”}Bob
IC,RC, gb mod p, {RB}Alice, {“Bob”}Alice
IC,RC, E(proofA, K) Bob IC,RC, E(proofB, K)
IC = initiator “cookie”, RC = responder “cookie”
IC = initiator “cookie”, RC = responder “cookie”
K = h(IC,RC,gab mod p,RA,RB) K=h(IC,RC,gab modp,R ,R )
SKEYID = h(RA, RB, gab mod p)A B
SKEYID=h(R ,aR ,gab mbodp)
proof = h(SKEYID,g mod p,g mod A
AB
Part 3 Pprrootocfols= h(SKEYID,g mod p,g mod p,IC,RC,CP,”Al1ic07e”) p,IC,RC,ACP,“Alice”) a b
Ryszard Janicki
Real-World Protocols I 24/38
IKE Phase 1: Public Key
IKE Phase 1: Public Key Encryption (Aggressive Mode)
Encryption (Aggressive Mode)
Alice
IC, CP, ga mod p, {“Alice”}Bob, {RA}Bob
IC,RC, CS, gb mod p, {“Bob”}Alice, {RB}Alice, proofB
IC,RC, proofA
Bob
K, proofA, proofB computed as in main mode
K, proofA, proofB computed as in main mode
Note that identities are hidden Note that identities are hidden
o The only aggressive mode to hide identities
The only aggressive mode to hide identities
o So, why have a main mode?
So, why have a main mode?
Part 3 Protocols 108
Answer: In aggressive mode, the crypto parameters g and p
must be known before starting, while in main mode, they can be negotiated. In addition, main mode MUST be implemented, while aggressive mode SHOULD be implemented, so you may have no choice but to use main mode, in spite of its almost non-existent advantages over the more efficient aggressive mode.
Ryszard Janicki
Real-World Protocols I 25/38
Public Key Encryption Issue?
In public key encryption, aggressive mode. . . Suppose bad Trudy generates
Exponents a and b Nonces RA and RB
Trudy can compute “valid” keys and proofs: gab mod p, K, SKEYID, proofA and proofB
Public Key Encryption Issue?
All of this also works in main mode
TrudyTcraundycrceaantecrmeaetsesamgesstahgaets athpaptearpspetoarbsetobetween Alice be between Alice and Bob
Trudy (as Alice)
IC,RC, proof
A
Trudy (as Bob)
and Bob
IC, CP, ga mod p, {“Alice”}Bob, {RA}Bob
IC,RC, CS, gb mod p, {“Bob”}Alice, {RB}Alice, proofB
Appears valid to any observer, including AppeaArslicvealaidndtoBaonby! observer, including Alice and Bob!
Part 3 Protocols
Ryszard Janicki
Real-World Protocols I
110
26/38
Plausible Deniability
Trudy can create fake “conversation” that appears to be between Alice and Bob
Appears valid, even to Alice and Bob!
A security failure?
In IPSec public key option, it is a feature. . .
Plausible deniability: Alice and Bob can deny that any conversation took place!
In some cases it might create a problem
E.g., if Alice makes a purchase from Bob, she could later
repudiate it (unless she had signed)
Ryszard Janicki
Real-World Protocols I 27/38
IKE Phase 1: Public Key
Encryption (Main Mode)
IKE Phase 1 “Cookies”
CP = crypto proposed, CS = crypto selected
IC and RC- cookies (or “anti-clogging tokens”) supposed to
IC = initiator “cookie”, RC = responder “cookie” prevent DoS (Denial of Service) attacks
K = h(IC,RC,gab mod p,RA,RB)
No relation to Web cookies
SKEYID = h(RA, RB, gab mod p)
To reduce DoS threats, Bob wants to remain stateless as
proofA = h(SKEYID,ga mod p,gb mod
Part 3 Protocols 107 p,IC,RC,CP,“Alice”)
long as possible
But Bob must remember CP from message 1 (required for proof of identity in message 6)
Bob must keep state from 1st message on
So, these “cookies” offer little DoS protection
Alice
IC, CP IC,RC, CS
IC,RC, ga mod p, {RA}Bob, {“Alice”}Bob
IC,RC, gb mod p, {RB}Alice, {“Bob”}Alice
IC,RC, E(proofA, K) Bob IC,RC, E(proofB, K)
Ryszard Janicki
Real-World Protocols I 28/38
IKE Phase 1 Summary
Result of IKE phase 1 is
Mutual authentication
Shared symmetric key
IKE Security Association (SA)
But phase 1 is expensive
Especially in public key and/or main mode
Developers of IKE thought it would be used for lots of things – not just IPSec (common design error!)
Partly explains the over-engineering. . .
Ryszard Janicki
Real-World Protocols I 29/38
IKE Phase 1 vs IKE Phase 2
Phase 1 establishes IKE SA Phase 2 establishes IPSec SA Comparison to SSL. . .
SSL session is comparable to IKE Phase 1 SSL connections are like IKE Phase 2
IKE could be used for lots of things,but in practice, it is not! (again common design error!)
Ryszard Janicki
Real-World Protocols I 30/38
IKE Phase 2
IKE Phase 2
IC, RC, CP, E(hash1,SA,RA,K) IC, RC, CS, E(hash2,SA,RB,K)
Alice IC, RC, E(hash3,K) Bob Key K, IC, RC and SA known from Phase 1
Key K, IC, RC and SA known from Phase 1
Proposal CP includes ESP and/or AH
Proposal CP includes ESP (Encapsulating Security Payload)
Hashes 1,2,3 depend on SKEYID, SA, RA and RB
and/or AH (Authentication Header), see textbook for details
Keys derived from KEYMAT = h(SKEYID,RA,RB,junk) Hashes 1,2,3 depend on SKEYID, SA, R and R
Recall SKEYID depends on phase 1 key method A
Part 3 Protocols 115
B OptiKoneaylsPdFeSri(veepdhefmroemralKDEifYfMie-AHTell=mahn(SexKcEhYanIgDe,)RA,RB,junk)
Recall SKEYID depends on phase 1 key method Optional PFS (Ephemeral Diffie-Hellman exchange)
Ryszard Janicki
Real-World Protocols I 31/38
IPSec
After IKE Phase 1, we have an IKE SA After IKE Phase 2, we have an IPSec SA
Authentication completed and have a shared symmetric key (session key)
Ryszard Janicki
Real-World Protocols I 32/38
IP Review
IP (Internet Protocol) and TCP (Transmission Control
Protocol)IP Review
IP datagram is of the form
IP datagram is of the form
IP datagram is of the form:
IP header data
IP header
data
WhhereerIePIhPeahderaidseris Where IP header is
IP and TCP
Part 3 Protocols 117
ConsiderWeb traffic, for example
Part 3 Protoc
Consider Web traffic, for example
ols
117
o IP encapsulates TCP and…
IP encapsulates TCP and. . .
o …TCP encapsulates HTTP
. . . TCP encapsulates HTTP
data
IP header
IP header
TCP hdr
IP data includes TCP header, etc. IP data includes TCP header, etc.
HTTP hdr
app data
Part 3 Protocols Ryszard Janicki
Real-World Pro1t1o8cols I 33/38
IPSec Transport Mode
IPSec Transport Mode
Sec Transport Mode IPSec Transport Mode
IP header
data
IP header
IPSec header
data
ansporTtranmspordt meodeedsesiignedefdor fhosrt-tho-ohosst -to-host
ansport mode is efficient
Transport mode is efficient
Adds minimal amount of extra header
AddsmTinheimoraiglinamlhoeaudnetrroemfaeinxstraheader Passive attacker can see who is talking
e original header remains
Passive attacker can see who is talking
Protocols
Ryszard Janicki
Real-World Protocols I 119 34/38
P
r r
h
IPSec: Host-to-Host
IPSec: Host-to-Host
IPSec transport mode used here IPSec transport mode used here
There may be firewalls in between, we need Tunnel Mode There may be firewalls in between
o If so, is that a problem?
Part 3 Protocols 120
Ryszard Janicki
Real-World Protocols I 35/38
IPSec Tunnel Mode
IPSec Tunnel Mode
IPSec Tunnel Mode IPSec Tunnel Mode
new IP hdr
IPSec hdr
TuTnranesplomrtomdoedefdoersigfnierdewforafillr-etwoa-ll-ftior-efirwewalalllttraffifcfic Original IP packet encapsulated in IPSec
Original IP packet encapsulated in IPSec Original IP header not visible to attacker
Original IP header not visible to attacker New IP header from firewall to firewall
o New IP header from firewall to firewall
Attacker does not know which hosts are talking
o Attacker does not know which hosts are talking Part 3 Protocols 121
IP header
IP header
data
data
Ryszard Janicki
Real-World Protocols I 36/38
IPSec: Firewall-to-Firewall
IPSec: Firewall-to-Firewall
IPSec tunnel mode used here IPSec tunnel mode used here
Note: Local networks not protected Note: Local networks not protected
Is there any advantage here?
Part 3 Protocols 122
Ryszard Janicki
Real-World Protocols I 37/38
n
Comparison of IPSec Modes
s
Comparison of IPSec Modes
Transport Mode
Transport M
Transport Mode
Transport Mode o Host-to-ho
Transport Mode: Host-to Host
IP header data
o Host-to-host
Tunnel Mode
IP header
data
IP header IPSec header data
o Firewall-to- o Firewall-to-
Tunnel Mode
IP header
IPSec header
data
Tunnel Mode Tunnel Mode: Firewall-to-Firewall
firewall firewall
Tunnel Mode
IP header data
Transport M Transport Mode
not necessar not necessary…
IP header
data
…but it’s mo …but it’s more
new IP hdr
IPSec hdr
IP header
data
ew IP hdr IPSec hdr IP header data Part 3 Protocols
efficient efficient
Transport Mode not necessary. . .
Part 3 Protocols
. . . but it’s more efficient
123
Ryszard Janicki
Real-World Protocols I 38/38
r