14 IPsec Explanation of All Packets
14 IPsec Explanation of All Packets
Problem statement:To study the IPsec (ESP and AH) protocol by capturing the packets using
Wireshark tool.
Firstthe IdentityProtection(MainMode)messagesnegotiatesecurityparameterstoprotectthenext 3
messages (Quick Mode) and whatever is negotiated in Phase 2 is used to protectproductiontraffic(ESP
or AH, normallyESP forsite-siteVPN).
Wecallfirst 6messagesas Phase1andlast3messagesasPhase2.
2. Phase1
PolicyNegotiation
Both peers add auniqueSPIjustto uniquelyidentifyeach side's SecurityAssociation (SA):
In frame #1, the Initiator (172.16.1.70) sends a set of Proposals containing a set of
securityparameters(Transforms)thatResponder(172.16.1.71)canpick ifitmatchesitslocalpolicies:
In frame#2theResponder(172.16.1.71)picks oneoftheTransforms:
DHKeyExchange
Then, next 2 Identity Protection packets both peers exchange Diffie-Hellman public keyvalues and
nonces (random numbers) which will then allow both peers to agree on a sharedsecretkey:
WithDHpublickeyvalueand thenonce,bothpeers will generate aseedkeycalledSKEYID.A further 3
session keys will be generated using this seed key for different purposes:SKEYID_d(dfor
derivative):not usedbyPhase 1.It isusedasseed keyforPhase2 keys,
i.e.seedkeyforproductiontraffickeys inPlainEnglish.
SKEYID_a(a for authentication): this key is used to protect message integrity in everysubsequent
packets as soon as both peers are authenticated (peers will authenticate each otherin next 2 packets).
Yes, I know, we verify the integrity by using a hash but throwing a keyintoahash adds
strongersecurityto hash andit's called HMAC.
SKEYID_e(e for encryption): you'll see that the next 2 packets are also encrypted. Asselected
encryption algorithm for this phase was AES-CBC (128-bits) then we use AES withthiskeyto
symmetricallyencrypt further data.
Nonceis just toprotect against replayattacks byaddingsomerandomness tokeygeneration
Authentication
Thepurposeofthisexchangeistoconfirmeachother'sidentity.Ifwesaid we'regoingtodothisusingpre-
sharedkeys thenverification consistsof checkingwhetherbothsides hasthe
same pre-shared key. If it is RSA certificate then peers exchange RSA certificates andassuming the CA
that signed each side is trusted then verification complete successfully.Inour case, this is donevia pre-
sharedkeys:
In packet #5 the Initiator sends a hash generated using pre-shared key set as key material sothat
onlythose who possess pre-master keycan do it:
Theresponderperformsthesamecalculationandconfirms thehashiscorrect.
ResponderalsosendsasimilarpacketbacktoInitiatorinframe#6butIskipped
forbrevity.Nowwe'rereadyforPhase2.
3. Phase2
The purpose of this phase is to establish the security parameters that will be used
forproductiontraffic(IPSecSA):
Note: Identification payload carries source and destination tunnel IP addresses and if thisdoesn't match
what is configured on both peers then IPSec negotiation will not proceed.Then,in frame
#8weseethatResponder picked oneof theProposals:
Frame#9 isjust anACK tothepicked proposalconfirmingthatInitiatoracceptedit: