IPsec (Internet Protocol Security)

IPsec là một framework giúp bảo vệ lưu lượng IP trên tầng Network. Vì tự bản thân giao thức IP
không có bất kỳ tính năng bảo mật nào. IPsec có thể bảo vệ lưu lượng với các tính năng sau:

- Confidentiality: bằng việc mã hóa (encrypting) dữ liệu, không ai ngoại trừ người gửi và người
nhận có thể đọc được dữ liệu này.

- Integrity: nếu muốn chắc rằng không một ai thay đổi dữ liệu trong gói tin thì có thể tính toán
một giá trị băm (HASH), người gửi và người nhận sẽ có thể kiểm tra xem có sự thay đổi nào đã
được thực hiện đối với gói tin hay chưa.

- Authentication: người gửi và người nhận có thể xác thực lẫn nhau để đảm bảo rằng thực sự
đang giao tiếp với thiết bị theo chính sách đã đặt ra.

- Anti-replay: Ngay cả khi một gói tin được mã hóa và xác thực thì kẻ tấn công có thể bắt được
các gói này và thực hiện việc gửi lại lần nữa. Bằng cách sử dụng sequence number, IPsec sẽ
không truyền lại bất cứ gói tin nào trùng.

Là một Framework, IPsec sử dụng đa dạng các giao thức để triển khai các tính năng được mô tả
ở trên. Hình bên dưới là tổng quan:

Sơ lược theo hình trên thì để thực hiện mã hóa thì có thể chọn cái nào mình muốn như DES,
3DES hoặc AES, còn xác thực có thể chọn giữa MD5 và SHA.

1
 IPsec có thể sử dụng trên nhiều loại thiết bị khác nhau: Router, Firewalls, Server,… Một vài ví
dụ:

- Giữa hai Router để tạo nên kết nối VPN Site-to-Site, giống như chiếc cầu nối (Bridges) giữa 02
mạng LAN với nhau.

- Giữa thiết bị tường lửa (Firewall) và máy chủ Window cho việc truy cập VPN từ xa.

- Giữa 2 Linux Server để bảo vệ giao thức không được an toàn.

IPsec khá phức tạp và có nhiều cách khác nhau để thực hiện triển khai nó. Để tìm hiểu IPsec thì
nên bắt đầu với cái nhìn tổng quan sau đó sẽ xem xét chi tiết kỹ hơn từng thành phần.

Toàn bộ quy trình của IPsec gồm các bước sau:

1. Initiation: Một công cụ phải được sử dụng để kích hoạt việc tạo ra tunnel để bảo vệ dữ liệu. Ví
dụ khi cấu hình IPsec trên Router, có thể sử dụng Access-List để nói với Router rằng dữ liệu nào
cần được bảo vệ. Khi Router nhận được thứ gì đó mà phù hợp với Access-List, nó sẽ bắt đầu quá
trình khởi tạo IKE.
2. IKE Phase 1: đàm phán SA là để bảo vệ IKE.
3. IKE Phase 2: để bảo vệ IPSec (lưu lượng truyền thực của người dùng).
4. Data Transfer: Dữ liệu sẽ được bảo vệ bằng cách gửi thông qua tunnel IKE Phase 2
5. Termination: Khi không có bất kỳ dữ liệu nào được bảo vệ thì tunnel IPsec sẽ được kết thúc sau
một khoảng thời gian.

Bên dưới là thông tin chi tiết:

Trước khi có thể bảo vệ bất kỳ gói tin IP nào thì cần 2 IPsec peers để xây dựng một tunnel IPsec
(IPsec Tunnel).

Để thành lập 1 IPsec Tunnel, phải sử dụng giao thức gói là IKE (Internet Key Exchange).

Internet Key Exchange (IKE) là một giao thức được sử dụng để thiết lập các thuộc tính bảo mật
của IPSec Security Associations (SAs) như encryption key, thuật toán mã hóa và mode hoạt
động của IPSec peer. Internet Key Exchange cho phép các IPSec peer trao đổi động các khóa và
thương lượng IPSec Security Associations (SAs). Sử dụng Internet Key Exchange (IKE), IPSec
Security Associations (SAs) có thể được thiết lập động và loại bỏ sau một khoảng thời gian đã
thỏa thuận.

Internet Key Exchange (IKE) là một giao thức IETF và nó có hai phiên bản, một phiên bản cũ
IKEv1 (RFC 2409, RFC 4109) và một phiên bản tương đối mới, IKEv2 (RFC 5996, RFC 7296 và
RFC 7427).

Internet Key Exchange là một giao thức kết hợp được tạo ra từ giao thức Oakley, SKEME (A
Versatile Secure Key Exchange Mechanism for Internet) và ISAKMP (Internet Security
Association and Key Management Protocol). Giao thức ISAKMP là một khuôn khổ để trao đổi
khóa mã hóa và tải trọng liên kết bảo mật.

2
IKE dùng UDP, Port Number 500.

Hoạt động IKEv1 có thể được chia thành hai phase. 1) Phase 1 (IKE SA Negotiation) và
Phase 2 (IPSec SA Negotiation). IKEv1 Phase 1 đàm phán SA là để bảo vệ IKE. Nghĩa là,
Phase 1 được sử dụng để thương lượng các tham số và key cần thiết để thành lập Security
Association (SA) giữa 2 IPSec peer. Security Associations (SAs) được đàm phán trong Phase 1
sau đó được sử dụng để bảo vệ thông tin liên lạc IKE trong tương lai.

IKEv1 Phase 2 SA thương lượng là để bảo vệ IPSec (lưu lượng truyền thực của người dùng).

IKEv1 Phase 1 negotiation có thể xảy ra ở hai mode, Main Mode hoặc Aggressive Mode. IKEv1
Phase 1 Main mode có 3 cặp thông điệp (tổng số 6 thông điệp) giữa các IPSec peer. IKE Phase 1
Aggressive Mode chỉ có 3 lần trao đổi thông điệp.

IKEv1 Phase 2 (Quick Mode) chỉ có 3 thông điệp. Mục đích của IKEv1 Phase 2 là hình thành
IPSec SA.

Tập hợp các tham số mà hai thiết bị sử dụng được gọi là SA (Security Association). Đây là ví
dụ về hai thiết bị Router thiết lập thành công tunnel IKE Phase 1:

Tunnel IKE Phase 1 chỉ được sử dụng cho luồng dữ liệu quản trị (Management traffic). Có thể sử
dụng tunnel này như là phương thức bảo mật ( Secure Method) để thành lập nên tunnel thứ hai,
còn được gọi là Tunnel IKE Phase 2 hoặc IPsec Tunnel:

Sau khi IKE Phase 2 được hoàn thành, sẽ có một tunnel IKE Phase 2 được dùng để bảo vệ dữ
liệu của người dùng. Nghĩa là dữ liệu của người dùng sẽ được gửi thông qua tunnel IKE Phase 2
này:

3
Mặc dù IKE xây dựng tunnel nhưng nó không chứng thực và mã hóa dữ liệu của người dùng. Có
thể sử dụng hai giao thức khác cho việc này :
- AH (Authentication Header).
- ESP (Encapsulating Security Payload).
AH và ESP đều cung cấp xác thực và tính toàn vẹn nhưng chỉ có ESP hỗ trợ thuật toán mã hóa.
Do đó, ESP là sự lựa chọn phổ biến nhất hiện nay. Đồng thời cả 2 giao thức này đều hỗ trợ 2 chế
độ khác nhau :
- Transport mode.
- Tunnel mode.

Sự khác biệt giữa hai chế độ này là: chế độ Transport mode sẽ sử dụng Original IP header
trong khi ở chế độ Tunnel mode sẽ sử dụng New IP header. Dưới đây là ví dụ để giúp hình
dung về vấn đề này

Phần giải thích hai chế độ này được viết chi tiết hơn ở phần sau.

Bây giờ sẽ xem xét kỹ hơn chi tiết của từng thành phần:

1. IKE ( Internet Key Exchange)

IKE (Internet Key Exchange) là một trong những giao thức chính của IPsec để thõa thuận các
thông số bảo mật (liên kết bảo mật - security association) giữa 2 đầu. Theo trên thì IKE có 2
phiên bản:

- IKE v1.

4
 - IKE v2.

IKEv1 đã được giới thiệu khoảng năm 1998 và được IKEv2 thay thế vào năm 2005. Có một vài
sự khác biệt giữa 02 phiên bản này:

- IKEv2 yêu cầu ít băng thông hơn là IKEv1.

- IKEv2 hỗ trợ chứng thực EAP (bên cạnh Pre-shared keys và Digital certificates).

- IKEv2 được hỗ trợ tích hợp (build-in support) cho NAT đi qua (bắt buộc khi IPsec peer đứng
sau NAT Router).

- IKEv2 được tích hợp cơ chế lưu trữ (keepalive mechanism) cho tunnel.

Phần giải thích tiếp theo đều áp dụng cho IKEv1.

1.1 IKE PHASE 1

Có thể chia nhỏ giai đoạn Phase 1 này thành 3 bước cơ bản:

- Bước 1: Negotiation
Peer mà có lưu lượng truy cập cần được bảo vệ sẽ bắt đầu khởi tạo (Initiate) và thõa thuận
(negotiation) IKE Phase 1. Hai đầu sẽ đàm phán các hạng mục sau:
+ Hashing: Lựa chọn thuật toán băm để xác minh tính toàn vẹn (MD5, SHA…).
+ Authentication: Mỗi Peer sẽ phải chứng minh mình là ai. Hai tùy chọn thường được sử dụng
thường là Pre-Shared Keys hoặc Digital Certificates.

+ DH (Diffie Hellman) Group: DH là một phương pháp trao đổi khóa được phát minh sớm
nhất trong mật mã học. Nhóm này xác định (determines) độ mạnh của khóa được dùng trong
quá trình trao đổi khóa. Số nhóm này càng cao thì càng an toàn nhưng bù lại sẽ mất thời gian để
tính toán hơn. DH Group 1: 768-bit, DH Group 2: 1024-bit, DH Group 5: 1536-bit, DH Group 14:
2048-bit, DH Group 15: 3072-bit, DH Group 19: 256-bit elliptic curve, DH Group 20: 384-bit
elliptic curve.

+ Lifetime: Thời gian tunnel IKE Phase 1 tồn tại, thời gian càng ngắn thì càng bảo mật vì nó
phải xây dựng lại, đồng nghĩa với việc sẽ phải sử dụng khóa mới. Đối với mỗi nhà cung cấp sẽ sử
dụng lifetime khác nhau nhưng giá trị mặc định chung là 86400 giây (1 ngày).
+ Encryption: Thuật toán được sử dụng để mã hóa (DES, 3DES hoặc AES)
- Bước 2: DH Key Exchange
Một khi thõa thuận các thông số bảo mật thành công, hai peer sẽ biết nên sử dụng chính sách
bảo mật bao gồm những gì. Chúng sẽ sử dụng DH - group mà đã thương lượng trước đó để trao
đổi khóa. Kết quá sau cùng là cả 2 peer đều có cùng một khóa dùng chung (shared key).
- Bước 3: Authentication
Bước cuối cùng là cả 2 peer sẽ chứng thực lẫn nhau bằng Phương pháp chứng thực mà đã được
đồng ý trong lần thương lượng trước đó. Khi chứng thực thành công thì IKE Phase 1 đã hoàn
thành.

5
Để hoàn thành 3 bước trên có thể sử dụng 2 chế độ khác nhau:
- Main mode.
- Aggressive mode.

Main mode sử dụng 06 thông điệp trong khi đó Aggressive mode chỉ dùng 03 thông điệp. Main
mode là an toàn hơn vì các thông tin được mã hóa, ngược lại Aggressive mode làm việc này dưới
dạng Clear-Text. Cùng đi vào chi tiết sự khác nhau giữa 2 mode:

1.1.1 Main Mode:

IKEv1 Main mode sử dụng 06 message. Xem chúng thông qua chương trình Wireshark và giải
thích các trường (fields).

IKEv1 Phase 1 Main Mode - Message 1:

IKEv1 Main mode - Message 1: bao gồm các proposal (đề xuất) của Security Association.
Initiator (thiết bị khởi tạo IPSec) đề xuất các chính sách bằng cách gửi một hoặc nhiều đề xuất
của Security Association. IKEv1 Main Mode Message 1 chứa IKE header, SA payload, Proposal
payload và Transform payload. IKE sử dụng các loại Payload khác nhau để chia sẻ thông tin về
các Khóa và Security Association được dùng chung cho cả 2 IPsec peer. Payload có header và
thông tin khác dùng cho DOI. IKE có thể là DOI là viết tắt của Domain of Interpretation, trong
trường hợp này là IPSec.

SA payload được sử dụng để chỉ định rằng trao đổi ISAKMP cụ thể này là để thương lượng IPSec.
IKE / ISAKMP là một giao thức chung có thể được sử dụng để thương lượng các giao thức khác
nhau. Do đó, SA payload có chứa Domain of Interpretation (DOI), được sử dụng để đề cập đến
thương lượng IKE / ISAKMP dành cho IPSec.

Proposal payload bao gồm proposal number, Protocol ID, kích thước SPI, số lần transform và
SPI.

Transform payload bao gồm transform number, transform ID và các thuộc tính IKE SA như
Authentication (Pre-shared keys hoặc Digital Certificates), Thuật toán băm (MD5 hoặc SHA1),
Mã hóa (DES, 3DES hoặc AES), Tunnel lifetime (giây), Diffie-Hellman Group.

Initiator và Responder phải tính toán một giá trị, được gọi là cookie. Giá trị cookie được sử dụng
để bảo vệ IPSec peer chống lại các cuộc tấn công DoS và Re-Play. RFC đề xuất phương pháp tạo
cookie bằng cách thực hiện băm nhanh (Ví dụ MD5) trên IP Source và Destination Address, UDP
Source và Destination Port và một giá trị ngẫu nhiên bí mật được tạo local. Trường "Initiator
SPI", được đánh dấu trong phần capture bên dưới là giá trị Cookie được tạo bởi Initiator. Giá trị
Cookie phản hồi được giữ ở dạng trống, vì đây là thông điệp đầu tiên.

Tập hợp các thông số khởi tạo gọi là SPI (Security Parameter Index). SPI (Security
Parameter Index) là một giá trị duy nhất để xác định SA.
Domain of interpretation là IPsec và đây là lời đề nghị số 01 (Proposal number : 1). Trong mục
Transform Payload có thể tìm thấy các thuộc tính mà ta muốn sử dụng cho liên kết bảo mật này.

6
IKEv1 Phase 1 Main Mode - Message 2:

IKEv1 Main Mode - Message 2 là phản hồi từ cho Message 1. Mục đích của Message 2 là thông
báo cho Initiator các thuộc tính SA đã được thỏa thuận. Hầu hết các trường giống như trong gói
được gửi bởi Initiator. Chỉ có một proposal payload và transform payload có trong message 2, đó
là proposal và transform payload đã được đồng ý. Cũng lưu ý rằng cả hai giá trị cookie đều được
điền.

7
IKEv1 Phase 1 Main Mode - Message 3:

Hướng của Message 3 là từ Initiator đến Responder. Message có chứa Diffie-Hellman Key
Exchange Payload và Nonce payload từ Initiator.

8
IKEv1 Phase 1 Main Mode - Message 4:

Hướng của Message 4 là từ Responder đến Initiator. Message có chứa Diffie-Hellman Key
Exchange Payload và Nonce payload từ Responder. Nonce là một số ngẫu nhiên rất lớn được sử
dụng trong IKE. Số ngẫu nhiên IKE Nounce cũng được sử dụng để tính toán trong tạo khóa.

Xin lưu ý rằng 4 message đầu trong IKEv1 Phase 1 Main mode đầu tiên không được mã hóa.

9
IKEv1 Phase 1 Main Mode - Message 5:

Cả 2 IPSec peer đều tính toán Diffie-Hellman shared secret. 3 khóa được tạo bởi cả hai peer để
xác thực và mã hóa. Message 5 chứa Identification payload và Hash Payload từ Initiator.
Identification payload và Hash Payload được sử dụng để nhận dạng và xác thực. Tải trọng nhận
dạng và tải trọng tải trọng băm được gửi mã hóa trong IKEv1 Phase 1 Main Mode.

IKEv1 Phase 1 Main Mode - Message 6: 6th message contains Identification payload and
Hash Payload. Identification payload and Hash Payload are used for identitification and
authentication from Responder. Identification payload and Hash Payload payloads are sent
encrypted in IKEv1 Phase 1 Main Mode.

Message 6 chứa Identification payload và Hash Payload. Identification payload và Hash Payload
được sử dụng để nhận dạng và xác thực từ Responder. Tải trọng nhận dạng và tải trọng tải trọng
băm được gửi mã hóa trong IKEv1 Phase 1 Main Mode.

1.1.2 Aggressive Mode:

IKEv1 Phase 1 chỉ sử dụng ba thông báo để thiết lập IKE SA. Hai thông điệp đầu tiên trong
Aggressive mode bao gồm hầu hết mọi thứ cần thiết để tạo IKE SA. IKEv1 Phase1 Aggression
Mode nhanh hơn Main Mode, nhưng danh tính của các endpoint được trao đổi trong dạng Clear-
Text. Khi so sánh Main Mode và Aggressive Mode, Main mode được coi là an toàn hơn Aggressive
Mode, vì Identification payload được mã hóa trong Main Mode.

10
IKEv1 Phase 1 Aggressive Mode - Message 1:

Trong IKEv1 Phase1 Aggressive Mode, tất cả các thông tin cần thiết cần thiết để tạo ra Diffie-
Hellman shared secret được trao đổi trong hai thông điệp đầu tiên giữa các peer. Thông điệp đầu
tiên được gửi từ Initiator bao gồm SA payload, Proposal payload và Transform payload, giống
như Main Mode. Sự khác biệt chính trong Aggressive Mode là thông điệp đầu tiên bao gồm Diffie-
Hellman Key Exchange payload và Nonce payload. Identification payload cũng được thêm vào
trong thông điệp đầu tiên. Lưu ý rằng Identification payload được gửi dưới dạng Clear-Text,
không được mã hóa.

IKEv1 Phase 1 Aggressive Mode - Message 2:

Bây giờ Responder có thể tạo ra Diffie-Hellman shared secret. Responder tạo ra bí mật được chia
sẻ Diffie-Hellman. Responder cũng tạo Hash cho mục đích Xác thực. Tương tự như Message 2
trong IKEv1 Phase1 Main Mode, Message 2 trong IKEv1 Phase1 Aggressive Mode của IKEv1 cũng
chứa proposal và transform đã được đồng ý từ Responder. Nó cũng chứa Key Exchange Payload,
Nounce Payload, Identity Payload và Authentication Hash từ Responder.

11
IKEv1 Phase 1 Aggressive Mode - Message 3:

Giờ đây, Initiator có thể tạo ra Diffie-Hellman shared secret. Initiator cũng tạo Hash cũng cho
mục đích Xác thực. Hash payload được gửi dưới dạng mã hóa.

1.2 IKE PHASE 2

IKE Phase 2 Tunnel (IPsec Tunnel) sẽ được thực hiện dùng để bảo vệ toàn bộ dữ liệu của người
dùng. Chỉ có một cơ chế để xây dựng nên IKE Phase 2 Tunnel thường được gọi là Quick Mode.

12
Cũng tương tự như IKE Phase 1, 2 peer bị sẽ thõa thuận về một vài hạng mục sau:

- IPsec Protocol: Sử dụng AH hay ESP.

- Encapsulation Mode: Transport Mode hay Tunnel Mode.

- Encryption: Thuật toán sử dụng mã hóa sử dụng (DES, 3DES hoặc AES).

- Authentication: Thuật toán sử dụng chứng thực (MD5 hoặc SHA).

- Lifetime: IKE Phase 2 có hiệu lực trong khoảng thời gian. Khi chuẩn bị hết lifetime thì sẽ làm
mới lại khóa.

- DH Exchange (Options): Dùng cho PFS ( Perfect Forward Secrecy).

*** PFS là một tùy chọn và nó buộc các thiết bị chạy lại thuật toán trao đổi DH lần nữa để tạo
ra Shared Key mới trong mỗi IKE Phase 2 Quick Mode. Nói cách khác là nếu Perfect Forward
Secrecy (PFS) được bật, new shared key sẽ được tạo để sử dụng. Diffie-Hellman Key generation
được thực hiện lại bằng cách sử dụng các Nonces mới được trao đổi giữa các peer.

Phần thõa thuận này xảy ra giống như của IKE Phase 1 tunnel vì thế không thể thấy được gì.
Dưới đây là một vài thông tin bắt được ở Wireshark:

Message 1

Message 2

13
Message 3

Một khi hoàn thành IKE Phase 2 sẽ sẵn sàng bảo vệ dữ liệu của người dùng.

Sau khi thương lượng IKEv2 Phase 2 (Quick Mode) hoàn tất. Mỗi peer sẽ tạo ít nhất hai SA. Một
ở hướng vào và hướng ra.

IKEv2 không có Main hoặc Aggressive mode cho Phase 1 và cũng không có Quick Mode cho
Phase 2. Nhưng nó vẫn tồn tại 2 Phase, Phase 1 gọi là IKE_SA_INIT và Phase 2 gọi là
IKE_AUTH. Đồng thời nó cũng chỉ có 4 message cần thiết cho toàn bộ quá trình trao đổi.

2. IPsec Protocols

AH và ESP là 2 phương thức bảo mật được dùng trong IPSEC trong bảo vệ dữ liệu người dùng.
AH chỉ dùng các cách thức chứng thực, còn ESP dùng cả chứng thực và mã hóa cho data được
truyền đi trong phiên kết nối VPN.

Cả hai giao thức đều có thể sử dụng ở Transport Mode hoặc Tunnel Mode. Transport mode cung
cấp kết nối an toàn giữa hai điểm cuối bằng cách đóng gói phần payload của gói tin IP là chính,
trong khi Tunnel mode đóng gói toàn bộ gói IP để cung cấp một " secure hop" ảo giữa hai
gateway.

14
2.1 Authentication Header Protocol

AH cung cấp chứng thực và tính toàn vẹn (intengrity) nhưng nó lại không cung cấp bất kỳ
phương thức mã hóa nào. Mục đích cao nhất của AH là đảm bảo rằng dữ liệu được truyền và
nhận đúng nơi, phát hiện sự thay đổi dữ liệu trong khi truyền tải và để bảo vệ chống tấn công
lặp lại. Xác thực được thực hiện bằng các thuật toán băm trên gần như tất cả các trường của gói
IP (ngoại trừ những trường phải được thay đổi khi truyền, ví dụ như TTL hay header checksum)
và lưu trữ mã xác thực này trong AH header và được gửi đến đầu kia.

AH sử dụng 5 trường theo cấu trúc như sau:

- Next Header: Xác định loại giao thức của payload trong gói tin gốc ban đầu khi đóng gói, đây
là cách mà các IPsec header được liên kết với nhau. Ở ví dụ này là ICMP.

- Length: đây là chiều dài của trường AH Header. nếu là IPv6 thì trừ đi các Extension Header
(theo RFC 1883).

- Reserved: Trường này được dành riêng để sử dụng trong tương lai và phải bằng 0.

- SPI ( Security Parameter Index): đây là 32-bit định danh để người nhận biết gói tin này
đang thuộc về luồng nào. Bên cạnh đó, mỗi kết nối VPN được bảo vệ bằng AH bao gồm một
15
thuật toán băm (MD5, SHA-1...), dữ liệu bí mật và một loạt các tham số khác. Và SPI có thể
được coi như một chỉ mục các thông số bảo mật được cài đặt, cấu hình cho kết nối VPN.

- Sequence: Đây là số thứ tự tuần tự tăng dần được dùng để đánh cho dữ liệu khi dữ liệu được
truyền trong phiên kết nối VPN. Nếu dữ liệu truyền trong phiên kết nối VPN có số SN bị trùng thì
sẽ không được truyền trong phiên kết nối VPN. Mục tiêu là để chống tấn công theo hình thức lặp
lại. Giá trị SN này được nằm trong các dữ liệu được xác thực, do đó các sửa đổi sẽ được phát
hiện.

- Authentication Data: Đây là giá trị dùng để kiểm tra tính toàn vẹn được tính trên toàn bộ gói
tin (bao gồm hầu hết các header). Người nhận sẽ tính toán lại, nếu cùng một hàm băm thì dữ
liệu được chấp nhận.

Chú ý ICV (Integrity Check Value): đây là hàm băm được tính toán cho toàn bộ gói tin. Bên
nhận cũng sẽ tính toán hàm băm, khi nó không giống nhau thì dữ liệu truyền giữa 2 peer không
được đảm bảo tính toàn vẹn.

AH xác thực dựa trên các thuật toán băm mật mã tiêu chuẩn như MD5 hoặc SHA-1. Để tăng tính
bảo mật thì AH sử dụng Hashed Message Authentication Code (HMAC) kết hợp một giá trị bí mật
trong khi tạo ICV. Mặc dù kẻ tấn công có thể dễ dàng tính toán lại một hàm băm, nhưng nếu
không có giá trị bí mật thì hắn sẽ không thể tạo lại ICV thích hợp.

HMAC được mô tả bởi RFC 2104 và hình minh họa được cho như bên dưới:

16
2.1.1 Transport Mode

Transport mode là đơn giản vì nó chỉ thêm vào AH Header vào sau IP Header.

AH trong Transport Mode được sử dụng để bảo vệ cho trao đổi dữ liệu giữa 2 thiết bị đầu cuối
thông qua việc xác thực, cấn chú ý là nhưng nó không phải là một giao thức tạo ra tunnel. Nói
cách khác thì AH trong Transport Mode chỉ đơn giản là một kết nối IP được bảo mật.

Đây là một ví dụ về gói IP mang theo AH Transport Mode:

Trong AH Transport Mode, gói tin IP gốc chỉ được sửa đổi một chút, bao gồm tiêu đề AH mới giữa
tiêu đề IP và layload giao thức (TCP, UDP,…) và có sự xáo trộn mã giao thức liên kết các tiêu đề
17
khác nhau với nhau. Việc xáo trộn giao thức này được yêu cầu để cho phép trả lại gói IP gốc ở
đầu kia: sau khi AH header đã hoàn thành xác thực khi đến bên nhận nhận, AH header sẽ bị loại
bỏ và trả lại loại giao thức ban đầu (TCP, UDP…) trong gói tin IP gốc. Khi gói đến đích và vượt
qua kiểm tra xác thực, tiêu đề AH sẽ bị loại bỏ và trường Proto = AH trong tiêu đề IP được thay
thế bằng next header đã lưu. Kết quả là datagram IP trở lại trạng thái ban đầu.

Hình ảnh Wireshark:

18
Ở trên có thể thấy AH Header ở giữa IP Header và ICMP Header. Đây là gói bắt được khi thực
hiện lệnh Ping giữa 2 Router.

2.1.2 Tunnel Mode

AH trong Tunnel Mode thì toàn bộ gói IP được đóng gói bên trong một gói khác và được truyền
trên phiên kết nối VPN để đến nơi nhận. Gói tin được xác thực người gửi, kiểm tra tính toàn vẹn
để ngăn chặn việc sửa đổi trong quá trình truyền. AH trong Tunnel Mode sẽ tạo thêm 1 new ip
header vào gói tin gốc và cho phép địa chỉ nguồn và đích của gói tin khi truyền trong VPN khác
với địa chỉ nguồn và đích của gói tin gốc và điều này cho phép hình thành tunnel.

Việc này có thể hữu ích khi sử dụng IP Private và cần chuyển lưu lượng truy cập của mình thông
qua môi trường Internet. Tunnel Mode dùng được với AH nhưng cũng không cung cấp về mã
hóa:

Cụ thể như hình sau:

19
Khi một gói ở chế độ tunnel đến đích, gói tin sẽ trải qua quá trình kiểm tra xác thực giống và
những gói vượt qua kiểm tra sẽ bị loại bỏ toàn bộ new IP header và AH header để tạo gói tin IP
gốc, sau đó được đưa vào quy trình truyền thông thường theo mô hình OSI.

Toàn bộ gói tin IP này sẽ được chứng thực, có thể thấy ở Wireshark:

20
Ở trên thấy New IP Header, sau đó là AH Header và cuối cùng là gói tin IP gốc mang theo vài lưu
lượng ICMP.

*** Một vấn đề với AH là nó không hoạt động với NAT/PAT. Các trường trong IP Header như TTL
và Checksum sẽ được loại trừ bởi AH do nó biết những trường đó sẽ có sự thay đổi. Tuy nhiên
địa chỉ IP và số Port được thêm vào, nếu thay đổi những điều trên thì NAT, ICV của AH sẽ không
thể dùng.

2.2 ESP (Encapsulating Security Payload Protocols)

ESP được chọn phổ biến hơn vì nó cho phép mã hóa lưu lượng IP đồng thời ta có thể sử dụng
được trong Transport hoặc Tunnel Mode.

Cấu trúc của ESP như sau:

21
Việc thêm mã hóa làm cho ESP phức tạp hơn. Các RFC IPsec không nhấn mạnh vào bất kỳ thuật
toán mã hóa cụ thể nào, ESP có thể sử dụng DES, 3-DES, AES và Blowfish để bảo vệ payload.
Thuật toán được sử dụng cho một phiên kết nối VPN cụ thể được thể hiện thông qua khái niệm
Security Association (SA). Cần chú ý là SA không chỉ bao gồm thuật toán mà còn bao gồm khóa
được sử dụng. Không giống như AH, cung cấp một AH header trước payload, ESP thì thực hiện
bao quanh payload mà ESP đang bảo vệ bằng ESP header và ESP trailer. ESP Header thì gồm
Security Parameters Index, Sequence Number (có chức năng giống AH) và Encrypted payload
(như đã nói ở trên). Còn ESP trailer thì gồm padding, pad len, next header và optional
Authentication Data ổ cuối cùng. Có thể biết thêm là có thể sử dụng ESP mà không cần bất kỳ
mã hóa thực tế nào (sử dụng thuật toán NULL). Điều này không cung cấp tính bảo mật. Thật vô
nghĩa khi sử dụng ESP mà không có mã hóa hoặc xác thực (trừ khi đơn giản là thực hiện kiểm
tra giao thức). Padding được cung cấp để cho phép các thuật toán mã hóa blocksize. Độ dài của
padding được cung cấp trong trường pad len. Trường next header cung cấp loại protocol (IP,
TCP, UDP…) của tải trọng theo gói tin thông thường. Ngoài mã hóa, ESP còn dùng xác thực
(HMAC trong AH). Tuy nhiên khác AH là xác thực này chỉ dành cho ESP header và payload được
mã hóa, chứ không bao gồm cả gói IP. Nhưng điều này không làm suy yếu tính bảo mật của xác
thực mà còn mang lại một số lợi ích quan trọng. Khi kẻ tấn công kiểm tra gói IP chứa dữ liệu
ESP, về cơ bản không thể kiểm tra các thông tin có rong gói tin khi tuyền trong phiên kết nối
VPN (không xem được các thông tin trong gói IP gốc, kể cả địa chỉ IP nguồn và địa chỉ IP đích).

2.2.1 Transport Mode

Khi sử dụng Transpor Mode, ESP Header được thêm vào như sau:

22
Ở trên có thể thấy ESP được thêm vào, ở lớp Transport (ví dụ là TCP) và Payload sẽ được mã
hóa. ESP cũng cung cấp chứng thực nhưng không giống như AH, ESP không giành cho toàn bộ
gói IP.

Hình ảnh Wireshark:

23
Có thể thấy gói IP gốc và sử dụng thêm ESP. Phần IP Header ở dạng Clear-Text nhưng các nội
dung còn lại đều được mã hóa.

2.2.2 Tunnel Mode

Trong Tunnel Mode thì new IP HEADER được thêm vào IP gốc, điều này rất hữu ích cho VPN Site-
to-Site:

Nó cũng giống như ở Transport mode nhưng đã được thêm vào NEW IP HEADER. Gói IP gốc lúc
này cũng đã được mã hóa.

24
Hình ảnh Wireshark:

2.3 AH và ESP
25
Có thể sử dụng AH và ESP cũng lúc. Hãy cũng xem xét:

2.3.1 Transport Mode

Hãy xem gói tin IP:

Với Transport mode sẽ sử dụng gói tin IP gốc, sau đó sẽ là AH và ESP Header. Lớp Transport,
Payload và ESP Trailer sẽ được mã hóa. Bởi vì cũng sử dụng AH nên toàn bộ gói IP sẽ được xác
thực. Hình ảnh Wireshark:

2.3.2 Tunnel Mode

Đầu tiên sẽ có New IP HEADER sau đó sẽ là AH và ESP Header. Gói IP gốc sẽ được mã hóa hoàn
toàn và mọi thứ cũng sẽ được chứng thực nhờ AH. Hình ảnh Wireshark:
26
Building a real VPN

Toàn bộ mục đích của VPN là truyền dữ liệu giữa hai mạng đáng tin cậy qua một mạng trung
gian không đáng tin cậy, cũng như bằng cách xâu một cáp Ethernet rất dài giữa hai mạng. Điều
này thường được sử dụng để kết nối các văn phòng chi nhánh với trụ sở công ty, cho phép tất cả
người dùng chia sẻ các tài nguyên nhạy cảm mà không sợ bị đánh chặn.

27
VPN an toàn vì yêu cầu cả xác thực và mã hóa: ESP là cách duy nhất để cung cấp mã hóa,
nhưng cả ESP và AH đều có thể cung cấp xác thực. Vậy nên sử dụng cái nào? Xét một trường
hợp thiên về kỹ thuật, Về mặt kỹ thuật, gói ESP bên trong AH là có thể thực hiện được, nhưng
trên thực tế không được sử dụng phổ biến vì những hạn chế của AH đối với NAT. Bằng cách sử
dụng AH + ESP, thì tunnel đường hầm này không bao giờ có thể đi qua thiết bị NAT thành công.

Thay vào đó, ESP + Auth được sử dụng trong Tunnel mode để đóng gói đầy đủ lưu lượng khi đi
qua một mạng không đáng tin cậy, được bảo vệ bằng cả mã hóa và xác thực. Ngay cả loại giao
thức được đóng gói - TCP, UDP hoặc ICMP - cũng bị ẩn khỏi người bên ngoài.

Security Associations – SA và the Security Parameters Index – SPI

28
Nếu hai đầu cuối thiết lập được một kết nối an toàn thì các thông số bảo mật cần được chia sẻ là
cần thiết để tạo ra chức năng xác thực, khóa thuật toán mã hóa. Vấn đề là làm thế nào mà các
thông số bảo mật được trao đổi giữa 2 bên của phiên kết nối VPN.

Nói cách khác, Khi một sơ đồ dữ liệu IPsec - AH hoặc ESP (các thông số bảo mật) - đến một VPN
gateway, làm thế nào để gateway đó biết được bộ thông số nào (khóa, thuật toán và chính sách)
sẽ sử dụng.

Khái niệm về Security Association (SA) là một tập hợp các tham số cụ thể về kết nối và mỗi
gateway có thể có một hoặc nhiều Security Association. Khi một sơ đồ dữ liệu đến, ba thành
phần SA chính xác bên trong Security Associations Database (SADB):

- IP address của VPN gateway phía bên kia.

- IPsec Protocol (ESP or AH).

- Security Parameters Index

Bộ ba này có thể được hiểu giống như: IP, Protocol và số port, để tạo ra 1 socket trong việc
truyền dữ liệu.

Một lượng lớn thông tin được lưu giữ trong SADB:

- AH: authentication algorithm

- AH: authentication secret

- ESP: encryption algorithm

- ESP: encryption secret key

- ESP: authentication enabled yes/no

- Many key-exchange parameter

- Routing

- IP filtering policy

AH và NAT

Mặc dù AH cung cấp khả năng bảo vệ rất mạnh đối với nội dung của gói tin thông quan chứng
thực nhưng biện pháp bảo vệ này phải gặp phải vấn đề lớn: AH không tương thích với NAT
(Network Address Translation).

29
NAT được dùng để chuyển đổi (ánh xạ) từ địa chỉ IP private sang IP public và ngược lại, do đó
giảm nhu cầu về không gian IP public và có thể định tuyến. Trong quá trình này, thông tin về địa
chỉ trong IP header thực sự được thiết bị NAT sửa đổi thông tin về địa chỉ nguồn.

Khi địa chỉ IP nguồn bị thay đổi, header checksum phải được tính toán lại. Bên cạnh đó thiết bị
cấu hình NAT buộc phải giảm TTL đi 1.

Bởi vì header checksum và TTL là trường thông tin luôn thay đổi.

AH biết loại trừ 2 trường này, nhưng điều này không thể loại trừ địa chỉ IP. Do đó khi AH kiểm
tra Integrity Check Value (kiểm tra tính toàn vẹn của các giá trị) sẽ khiến sẽ bị lỗi khi được nơi
nhận thực hiện xác thực. Router NAT không thể tính toán lại ICV.

Điều này cũng xảy ra khi cấu hình PAT.

30