Đ I H C KHOA H C T NHIÊN TP. H CHÍ MINHẠ Ọ Ọ Ự Ồ

KHOA ĐI N T - VI N THÔNGỆ Ử Ễ

B MÔN VI N THÔNG VÀ M NGỘ Ễ Ạ------oOo------

BÁO CÁO Đ TÀIỀ :

IPSEC over TCP/UDP

GVHD: Tr n Th Th o Nguyênầ ị ả

Nhóm trình bày : Nhóm ph n bi n :ả ệ Hoàng Đ c Phúứ 0920090 Nguy n Hoài Nhânễ 0920078

Nguy n Hùng C ng 0920010ễ ườ Đ ng Ngàn Nh t Ph ng ặ ấ ươ0920092

H Minh Tâmồ 0920219 Tr n Th Nh Th m ầ ị ư ắ 0920223

Nguy n Thanh Hùng 0920181ễ Võ Qu c Anh ố0920149

Phan Th Xuân Lanị 0920054

MỤC LỤC

I. GIỚI THIỆU :..................................................................................................3

II. KẾT NỐI IP SEC:...........................................................................................8

III. ISAKMP/IKE GIAI ĐOẠN 1: TẠO KẾT NỐI QUẢN LÝ:.......................9

A. Kết nối quản lý:..........................................................................................10

1.Main Mode:...............................................................................................10

2.Aggressive Mode:......................................................................................11

3.ISAKMP/IKE Transforms:........................................................................11

B. Giao thức trao đổi key: Diffie-Hellman (DH):........................................13

C. Chứng thực thiết bị:...................................................................................14

IV. ISAKMP/IKE GIAI ĐOẠN 2: TẠO KẾT NỐI DỮ LIỆU:.......................15

A. Những thành phần trong ISAKMP/IKE giai đoạn 2:............................15

B. Các giao thức bảo mật giai đoạn 2:..........................................................16

1.Giao thức Authentication Header (AH):...................................................17

2.Giao thức Encapsulating Security Payload ( ESP):.................................26

C. Phương thức kết nối trong Phase 2:.........................................................32

1.Transport mode :.......................................................................................32

2.Tunnel mode:............................................................................................34

D. Phase 2 Transforms:..................................................................................36

E. Kết nối dữ liệu:...........................................................................................36

V. IPSEC OVER TCP/UDP :............................................................................37

A. Vấn đề chuyển đổi địa chỉ trong IP Sec:..................................................37

B. Giải quyết vấn đề chuyển đổi địa chỉ trong IP Sec:................................41

VI. TÀI LIỆU THAM KHẢO:...........................................................................44

I. GIỚI THIỆU :

1. Nhu cầu sử dụng IP Sec hiện nay:

Giao thức TCP/IP đóng một vai trò rất quan trọng trong các hệ thống

hiện nay. Về nguyên tắc, có nhiều tùy chọn khác nhau về giao thức để triển khai

các hệ thống mạng như TCP/IP, TPX/SPX, NetBEUI, Apple talk,… Tuy nhiên

TCP/IP là sự lựa chọn gần như bắt buộc do giao thức này được sử dụng làm

giao thức nền tảng của mạng Internet.

Vào thời điểm thiết kế giao thức này, vấn đề bảo mật thông tin chưa thật

sự được quan tâm, do đó, các giao thức trong bộ TCP/IP hầu như không được

trang bị bất cứ giao thức nào. Cấu trúc gói dữ liệu (IP, TCP, UDP và cả các

giao thức ứng dụng) được mô tả công khai, bắt được gói IP trên mạng, ai cũng

có thể phân tích gói để đọc phần dữ liệu chứa bên trong, đó là chưa kể hiện nay,

các công cụ bắt và phân tích gói được xây dựng với tính năng mạnh và phát

hành rộng rãi.Việc bổ sung các cơ chế bảo mật vào mô hình TCP/IP, bắt đầu từ

giao thức IP là một nhu cầu cấp bách.IP Security (IPSec) là một giao thức được

chuẩn hoá bởi IETF từ năm 1998 nhằm mục đích nâng cấp các cơ chế mã hoá

và xác thực thông tin cho chuỗi thông tin truyền đi trên mạng bằng giao thức IP.

Hay nói cách khác, IPSec là sự tập hợp của các chuẩn mở được thiết lập để đảm

bảo sự cẩn mật dữ liệu, đảm bảo tính toàn vẹn dữ liệu và chứng thực dữ liệu

giữa các thiết bị mạng IPSec cung cấp một cơ cấu bảo mật ở tầng 3 (Network

layer) của mô hình OSI.

IPSec được thiết kế như phần mở rộng của giao thức IP, được thực hiện

thống nhất trong cả hai phiên bản IPv4 và IPv6. Đối với IPv4, việc áp dụng

IPSec là một tuỳ chọn, nhưng đối với IPv6, giao thức bảo mật này được triển

khai bắt buộc.

2. Khái niệm IP Sec :

IPSec (Internet Protocol Security) là một giao thức được IETF phát triển.

IPSec được định nghĩa là một giao thức trong tầng mạng cung cấp các dịch

vụ bảo mật, nhận thực, toàn vẹn dữ liệu và điều khiển truy cập. Nó là một tập

hợp các tiêu chuẩn mở làm việc cùng nhau giữa các phần thiết bị.

Một cách chung nhất, IPSec cho phép một đường ngầm bảo mật thiết lập

giữa 2 mạng riêng và nhận thực hai đầu của đường ngầm này. Các thiết bị

giữa hai đầu đường ngầm có thể là một cặp host, hoặc một cặp cổng bảo mật

(có thể là router, firewall, bộ tập trung VPN) hoặc một cặp thiết bị gồm một

host và một cổng bảo mật. Đường ngầm đóng vai trò là một kênh truyền bảo

mật giữa hai đầu và các gói dữ liệu yêu cầu an toàn được truyền trên đó.

IPSec cũng thực hiện đóng gói dữ liệu các thông tin để thiết lập, duy trì và

hủy bỏ kênh truyền khi không dùng đến nữa. Các gói tin truyền trong đường

ngầm có khuôn dạng giống như các gói tin bình thường khác và không làm

thay đổi các thiết bị, kiến trúc cũng như những ứng dụng hiện có trên mạng

trung gian, qua đó cho phép giảm đáng kể chi phí để triển khai và quản lý.

IPSec có các cơ chế cơ bản để đảm bảo an toàn dữ liệu đó là AH

(Authentication Header), ESP (Encapsulating Security Payload), IKE (Internet

Key Exchange) và ISAKMP (Internet Security Association and Key

Management Protocol) trong đó IPSec phải hỗ trợ ESP và có thể hỗ trợ AH:

AH cho phép xác thực nguồn gốc dữ liệu, kiểm tra tính toàn vẹn dữ

liệu và dịch vụ tùy chọn chống phát lại của các gói IP truyền giữa hai

hệ thống. AH không cung cấp tính bảo mật, điều này có nghĩa là nó

gửi đi thông tin dưới dạng bản rõ.

ESP là một giao thức cung cấp tính an toàn của các gói tin được

truyền bao gồm: Mật mã dữ liệu, xác thực nguồn gốc dữ liệu, kiểm

tra tính toàn vẹn phi kết nối của dữ liệu. ESP đảm bảo tính bí mật

của thông tin thông qua việc mật mã gói tin IP. Tất cả lưu lương ESP

đều được mật mã giữa hai hệ thống. Với đặc điểm này thì xu hướng

sẽ sử dụng ESP nhiều hơn AH để tăng tính an toàn cho dữ liệu.

Cả AH và ESP là các phương tiện cho điều khiển truy nhập, dựa

vào sự phân phối của các khóa mật mã và quản lý các luồng giao

thông có liên quan đến những giao thức an toàn này.

IKE (Internet Key Exchange): IKE là giao thức thực hiện quá trình

trao đổi khóa và thỏa thuận các thông số bảo mật giữa các thiết bị với

nhau như: mã hóa thế nào, dùng thuật toán nào, bao lâu trao đổi khóa

một lần. Sau khi trao đổi xong thì sẽ có một thương lượng giữa hai đầu

cuối, khi đó IPsec SA (Security Association) được tạo ra. Một SA, là

một liên kết bảo mật, có thể được xem là một nhóm những thành phần,

thông số bảo mật đã được thống nhất giữa 2 đầu cuối, nói cách khác,

khi tất cả các thông số đã được thương lượng và các khóa đã được tạo

ra, một thiết bị có 1 SA và nó có thể sử dụng SA này để giao tiếp với

một thiết bị khác.

ISAKMP (Internet Security Association and Key Management

Protocol): là một giao thức thực hiện việc thiết lập, thỏa thuận và quản

lý chính sách bảo mật SA. Giao thức này đi kèm với giao thức IKE

nên ta sẽ viết ISAKMP/IKE.

Những giao thức này có thể được áp dụng một mình hay kết hợp với

nhau để cung cấp tập các giao thức an toàn mong muốn trong IPv4 và IPv6,

nhưng cách chúng cung cấp các dịch vụ là khác nhau. Đối với cả hai giao

thức AH và ESP này, IPSec không định các thuật toán an toàn cụ thể được

sử dụng, mà thay vào đó là một khung chuẩn để sử dụng các thuật toán theo

tiêu chuẩn công nghiệp. IPSec sử dụng các thuật toán: Mã nhận thực bản tin

trên cơ sở băm (HMAC), thuật toán MD5 (Message Digest 5), thuật toán

SHA-1 để thực hiện chức năng toàn vẹn bản tin; Thuật toán DES, 3DES để

mật mã dữ liệu; Thuật toán khóa chia sẻ trước, RSA chữ ký số và RSA mật

mã giá trị ngẫu nhiên (Nonces) để nhận thực các bên. Ngoài ra các chuẩn

còn định nghĩa việc sử dụng các thuật toán khác như IDEA, Blowfish và RC4.

IPSec có thể sử dụng giao thức IKE (Internet Key Exchange) để xác thực hai

phía và làm giao thức thương lượng các chính sách bảo mật và nhận thực

thông qua việc xác định thuật toán được dùng để thiết lập kênh truyền, trao

đổi khóa cho mỗi phiên kết nối, dùng trong mỗi phiên truy cập. Mạng dùng

IPSec để bảo mật các dòng dữ liệu có thể tự động kiểm tra tính xác thực của

thiết bị bằng giấy chứng nhận số của hai người dùng trao đổi thông tin qua

lại. Việc thương lượng này cuối cùng dẫn đến thiết lập kết hợp an ninh (SAS)

giữa các cặp bảo mật, kết hợp an ninh này có tính chất hai chiều trực tiếp.

Thông tin kết hợp an ninh được lưu trong cơ sử dữ liệu liên kế an ninh, và mỗi

SA được ấn định một số tham số an ninh trong bảng mục lục sao cho khi kết

hợp một địa chỉ đích với giao thức an ninh (ESP hoặc AH) thì có duy nhất một.

3. Lịch sử phát triển của IP Sec:

Từ khi công nghệ ipsec ra đời, nó không chỉ còn được biết đến như một

chuẩn interrnet đơn lẽ nữa, mà hơn thế nữa còn được định nghĩa trong chuẩn

RFC, được kể đến trong bảng sau:

RFC Tiêu đề Chủ đề Thời

gian

1825 Security Architure for the Internet

Protocol

(kiến trúc bảo mật cho giao thức Internet)

IPSec 8/1995

1826 IP Authentication Header

(Nhận thực tiêu đề IP)

AH 8/1995

1827 IP Encapsulating Security Payload

(đóng gói an toàn tải IP)

ESP 8/1995

1828 IP Authentication Using Keyed MD5

(Nhận thực IP sử dụng khoá MD5)

MD5 8/1995

1829 The ESP DES-CBC Transform

(sự biến đổi ESP nhờ DES-CBC)

DES 8/1995

2104 HMAC: Keyed-Hashing for Message

Authentication

HMAC 1/1997

(HMAC: Khoá băm cho nhận thực bản

tin)

2202 Test Cases for HMAC-MD5 and HMAC-

SHA-1

(các trường hợp kiểm tra cho HMAC-

MD5 và HMAC-SHA-1)

HMAC-MD5

HMAC-SHA-1

9/1997

2401 Security Architure for Internet Protocol IPSec 10/1998

2402 IP Authentication Header AH 10/1998

2403 The Use of HMAC-MD5-96 within ESP

and AH (sử dụng HMAC-MD5-96 cùng

với ESP)

HMAC-MD5 10/1998

2404 The Use of HMAC-SHA-1-96 within ESP

and AH (sử dụng HMAC-SHA-1-96 cùng

với ESP và AH)

HMAC-SHA-1 10/1998

2405 The ESP DES-CBC Cipher Algorithm

With Explicit IV

(Thuật toán mã hoá ESP DES-CBC cùng

IV (vector khởi tạo))

DES 10/1998

2406 IP Encapsulating Security Payload ESP 10/1998

2407 The Internet IP Security Domain of

Interpretation for ISAKMP (bảo mật gói

tin IP trong phạm vi làm sáng tỏ

ISAKMP)

ISAKMP 10/1998

2408 Internet Security Association and Key

Management Protocol

ISAKMP 10/1998

(giao thức quản lý kết hợp an ninh

Internet và Khoá)

2409 The Internet Key Exchange

(phương thức trao đổi khoá internet)

IKE 10/1998

2410 The NULL Encryption Algorithm and Its

Use With IPSec

(vô hiệu thuật toán bảo mật và sử dụng nó

với IPSec)

NULL 10/1998

2451 The ESP CBC-Mode Cipher Algorithms

(thuật toán mật mã kiểu CBC cho ESP)

CBC 10/1998

II. KẾT NỐI IP SEC:

Ph n này sẽ trình bày v quá trình t o k t n i đ chia s d li uầ ề ạ ế ố ể ẻ ữ ệ

m t cách b o m t gi a hai thi t b IPsec. Hai thi t b đó ph i đi qua 5ộ ả ậ ữ ế ị ế ị ả

b c c b n sau đây:ướ ơ ả

1. K t n i IPsec sẽ đ c b t đ u n u có m t yêu c u nào đó, th ngế ố ượ ắ ầ ế ộ ầ ườ

là yêu c u c n có 1 k t n i b o m t t m t thi t b mu n k t n iầ ầ ế ố ả ậ ừ ộ ế ị ố ế ố

v i m t thi t b đích. T t nhiên ng i qu n tr ho c m t ng iớ ộ ế ị ấ ườ ả ị ặ ộ ườ

dùng b t kỳ đ u có th b t đ u quá trình này t thi t b c a h .ấ ề ể ắ ầ ừ ế ị ủ ọ2. N u ch a có m t k t n i VPN nào t n t i, IPsec sẽ s d ngế ư ộ ế ố ồ ạ ử ụ

ISAKMP/IKE Phase 1 đ t o m t ể ạ ộ k t n i qu n lýế ố ả b o m t. K t n iả ậ ế ố

qu n lý này là c n thi t vì nó đ m b o cho 2 thi t b có th liên l cả ầ ế ả ả ế ị ể ạ

v i nhau m t cách an toàn, h n n a, nó có th t đó xây d ng m tớ ộ ơ ữ ể ừ ự ộ

k t n i d li u b o m t.ế ố ữ ệ ả ậ3. Thông qua k t n i qu n lý b o m t này, hai thi t b sẽ th ngế ố ả ả ậ ế ị ươ

l ng, th ng nh t các thông s b o m t đ c s d ng đ t o nênượ ố ấ ố ả ậ ượ ử ụ ể ạ

m t ộ k t n i d li uế ố ữ ệ . Các k t n i d li u đ c dùng đ truy n cácế ố ữ ệ ượ ể ề

d li u nh files, Telnets, email, video, voice,… ữ ệ ư4. Khi k t n i d li u đã đ c t o, các thi t b IPsec có th s d ngế ố ữ ệ ượ ạ ế ị ể ử ụ

nó đ truy n d li u m t cách an toàn. N u hàm HMAC đ c sể ề ữ ệ ộ ế ượ ử

d ng thi t b ngu n đ t o ra ch ký s , thì thi t b đích sẽ ki mụ ở ế ị ồ ể ạ ữ ố ế ị ể

tra các ch ký này đ xác đ nh tính toàn v n c a d li u cũng nhữ ể ị ẹ ủ ữ ệ ư

ch ng th c thông tin đó là đúng hay sai. Ngoài ra, n u d li u đ cứ ự ế ữ ệ ượ

mã hóa t i ngu n thì t i đích nó sẽ đ c gi i mã.ạ ồ ạ ượ ả5. C k t n i qu n lý và k t n i d li u đ u có m t th i gian t n t iả ế ố ả ế ố ữ ệ ề ộ ờ ồ ạ

(lifetime) xác đ nh. Đi u này là đ đ m b o cho các khóa b o m tị ề ể ả ả ả ậ

sẽ đ c t o l i và khác v i lúc tr c, do đó tránh đ c tr ng h pượ ạ ạ ớ ướ ượ ườ ợ

ai đó sẽ tìm cách phá khóa b o m t c a b n. Khi h t th i h nả ậ ủ ạ ế ờ ạ

lifetime này, k t n i sẽ t đ ng đóng l i và đ c t o l i n u ta ti pế ố ự ộ ạ ượ ạ ạ ế ế

t c c n g i d li u.ụ ầ ử ữ ệ

Đ có cái nhìn c th h n v giao th c IPsec. Các ph n sau đây sẽ l nể ụ ể ơ ề ứ ầ ầ

l t trình bày v các giai đo n (Phase) ho t đ ng c a ISAKMP/IKE.ượ ề ạ ạ ộ ủ

III. ISAKMP/IKE GIAI ĐOẠN 1: TẠO KẾT NỐI QUẢN LÝ:

Trong ph n này chúng ta sẽ làm rõ h n các b c đ thi t l p m tầ ơ ướ ể ế ậ ộ

k t n i qu n lý IPsec.ế ố ảISAKMP và IKE ho t đ ng cùng nhau đ thi t l p m t k t n i b oạ ộ ể ế ậ ộ ế ố ả

m t, an toàn h n gi a hai thi t b . ISAKMP đ nh nghĩa các thông s c a góiậ ơ ữ ế ị ị ố ủ

tin, v i c ch là m t giao th c trao đ i khóa (Key), và th c hi n m t quáớ ơ ế ộ ứ ổ ự ệ ộ

trình đàm phán. Tuy nhiên giao th c ISAKMP không đ nh nghĩa cách t o,ứ ị ạ

chia s Key, ho c qu n lý k t n i b o m t nh th nào mà giao th c IKEẻ ặ ả ế ố ả ậ ư ế ứ

sẽ th c hi n vi c này.ự ệ ệĐ hi u rõ chi ti t ISAKMP/IKE thi t l p m t k t n i qu n lý nhể ể ế ế ậ ộ ế ố ả ư

th nào? Ph n sau đây sẽ bao g m các ý sau:ế ầ ồ+ K t n i qu n lý.ế ố ả

+ Giao th c trao đ i Key: Diffie-Hellman.ứ ổ+ Ch ng th c thi t b .ứ ự ế ị

A. K t n i qu n lýế ố ả :

K t n i đ c thi t l p trong giai đo n 1. K t n i này s d ng giaoế ố ượ ế ậ ạ ế ố ử ụ

ti p UDP port 500. Đây là m t k t n i 2 chi u, 2 peers có th chia s cácế ộ ế ố ề ể ẻ

thông đi p IPsec cho nhau.ệL u ý: Các k t n i ISAKMP/IKE s d ng giao th c UDP. Port ngu nư ế ố ử ụ ứ ồ

và đích là 500; tuy nhiên, m t vài nhà cung c p s d ng s port ng uộ ấ ử ụ ố ẫ

nhiên l n h n 1023 thay vì 500.ớ ơDù là m t k t n i site-to-site hay là k t n i t xa, có 3 đi u sau đâyộ ế ố ế ố ừ ề

sẽ x y ra trong quá trình ISAKMP/IKE giai đo n 1:ả ạ1. Các peers sẽ đàm phán v i nhau v vi c k t n i qu n lý sẽ đ c b o vớ ề ệ ế ố ả ượ ả ệ

nh th nào.ư ế2. Các peers sẽ dùng thu t toán Diffie-Hellman đ chia s thông tin v Keyậ ể ẻ ề

đ b o v vi c qu n lý k t n i.ể ả ệ ệ ả ế ố3. Các peers sẽ đ nh danh, xác nh n v i nhau tr c khi quá trìnhị ậ ớ ướ

ISAKMP/IKE giai đo n 2 di n ra.ạ ễISAKMP/IKE giai đo n 1 ch u trách nhi m cho vi c thi t l p k t n iạ ị ệ ệ ế ậ ế ố

qu n lý an toàn. Tuy nhiên ta l i có 2 ch đ đ th c hi n 3 b c trên:ả ạ ế ộ ể ự ệ ướ

+ Main (ch đ chính).ế ộ

+ Aggressive (ch đ linh ho t).ế ộ ạ

1. Main Mode:

Main mode th c hi n 3 trao đ i 2 chi u, t ng c ng là 6 packets. Baự ệ ổ ề ổ ộ

s trao đ i là 3 b c đ c li t kê trong ph n trên: đàm phán chính sáchự ổ ướ ượ ệ ầ

b o m t s d ng đ qu n lý k t n i, s d ng Diffie-Hellman đ mã hóaả ậ ử ụ ể ả ế ố ử ụ ể

keys dùng cho thu t toán mã hóa và hàm HMAC đã đ c đàm phán b cậ ượ ở ướ

1, và th c hi n xác th c thi t b s d ng m t trong ba cách sau: pre-ự ệ ự ế ị ử ụ ộshared keys, RSA encrypted nonces (khóa RSA s d ng m t l n) ho c RSAử ụ ộ ầ ặ

signatures (digital certificates – ch ng th c s ).ứ ự ố

Main mode có m t u đi m: b c xác th c thi t b di n ra thôngộ ư ể ướ ự ế ị ễ

su t trong c quá trình k t n i qu n lý, vì k t n i này đã đ c xây d ng ố ả ế ố ả ế ố ượ ự ở

hai b c đ u tiên tr c khi vi c ch ng th c thi t b di n ra. Nên b t kìướ ầ ướ ệ ứ ự ế ị ễ ấ

thông tin nh n d ng c a 2 peers g i cho nhau đ u đ c b o v kh i cácậ ạ ủ ở ề ượ ả ệ ỏ

cu c nghe tr m.ộ ộMain Mode là mode m c đ nh c a Cisco cho k t n i site-to-site vàặ ị ủ ế ố

k t n i t xa.ế ố ừ

2. Aggressive Mode:

Trong mode này, ch có 2 quá trình trao đ i. Trao đ i đ u tiên baoỉ ổ ổ ầ

g m danh sách các chính sách b o m t s d ng cho k t n i qu n lý, publicồ ả ậ ử ụ ế ố ả

key có đ c t c p “public/private key” đ c t o ra b i DH, các thông tinượ ừ ặ ượ ạ ở

nh n d ng, thông tin xác minh các thông tin nh n d ng (ví d nh ch ký).ậ ạ ậ ạ ụ ư ữ

T t c đ u đ c ép vào m t gói tin. Quá trình trao đ i th 2 là s tr l iấ ả ề ượ ộ ổ ứ ự ả ờ

(ACK) cho gói v a nh n đ c, ngoài ra nó còn chia s key đã mã hóa (dùngừ ậ ượ ẻ

thu t toán DH), và thông tin k t n i qu n lý đã đ c thi t l p thành côngậ ế ố ả ượ ế ậ

hay ch a.ưAggressive Mode có m t u đi m h n Main Mode: k t n i qu n lýộ ư ể ơ ế ố ả

đ c thi t l p nhanh h n, tuy nhiên nh c đi m c a nó là b t kì nh ngượ ế ậ ơ ượ ể ủ ấ ữ

thông tin nh n d ng đ c g i đ u là clear text. Do đó, n u m t ai đó ngheậ ạ ượ ở ề ế ộ

tr m thông tin trên đ ng truy n, h có th bi t đ c các thông tin nh nộ ườ ề ọ ể ế ượ ậ

d ng s d ng đ t o ch ký cho vi c xác th c thi t b . Vì v y, n u ta loạ ử ụ ể ạ ữ ệ ự ế ị ậ ế

l ng v vi c có th b xem tr m thông tin nh n d ng thi t b , ta nên sắ ề ệ ể ị ộ ậ ạ ế ị ử

d ng Main Mode.ụ

3. ISAKMP/IKE Transforms:

M t trong nh ng đi u đ u tiên 2 peers ph i th c hi n trong quáộ ữ ề ầ ả ự ệ

trình ISAKMP/IKE giai đo n 1 là vi c đàm phán xem k t n i qu n lý sẽạ ệ ế ố ả

đ c b o v nh th nào. Đi u này đ c th c hi n b ng cách xác đ nhượ ả ệ ư ế ề ượ ự ệ ằ ị

transforms (các bi n đ i). M t transform là m t danh sách các bi n phápế ổ ộ ộ ệ

an ninh nên đ c s d ng đ b o v k t n i. V i riêng ISAKMP/IKE giaiượ ử ụ ể ả ệ ế ố ớ

đo n 1, Transform đôi khi đ c g i là m t chính sách IKE hay ISAKMP.ạ ượ ọ ộ

Các thông tin bao g m trong m t Transform Giai đo n 1 là:ồ ộ ạ Thu t toán mã hóa: DES, 3DES ho c AES.ậ ặ Các hàm HMAC s d ng: MD5 hay SHA-1.ử ụ Ki u xác th c thi t b : pre-shared keys, RSA encryptedể ự ế ị

nonces, or RSA signatures (certificates).

Nhóm khóa Diffie-Hellman: Cisco ch cung c p 1, 2, 5, 7.ỉ ấ

V i 7 thì ch cung c p trên Cisco 3000 concentrators vàớ ỉ ấ

PIX và ASA nh ng ng d ng b o m t đang ch y phiênữ ứ ụ ả ậ ạ

b n 7.0.ả Th i gian t n t i c a m t k t n i qu n lý.ờ ồ ạ ủ ộ ế ố ả

T ng h p l i, t t c nh ng m c này đ c coi nh là m t b bi nổ ợ ạ ấ ả ữ ụ ượ ư ộ ộ ế

đ i (transform set). Thi t b IPsec c a b n có th c n nhi u b transformổ ế ị ủ ạ ể ầ ề ộ

khác nhau. Ví d nh n u thi t b c a b n c n k t n i IPsec đ n 2 peers,ụ ư ế ế ị ủ ạ ầ ế ố ế

m i peer l i có m t ki u mã hóa khác nhau, nh DES hay 3DES. Thì ta ph iỗ ạ ộ ể ư ả

c n nh ng transform khác nhau đ t n d ng l i th v a dùng 3DES đ nầ ữ ể ậ ụ ợ ế ừ ế

m t peer này và DES đ n m t peer khác.ộ ế ộThi t b c a b n c n ph i g i toàn b danh sách ISAKMP/IKEế ị ủ ạ ầ ả ở ộ

transforms đ n remote peer. Th t trong transform đ c g i đi r t quanế ứ ự ượ ở ấ

tr ng vì nh ng cái nào kh p v i remote peer tr c sẽ đ c s d ng ngay.ọ ữ ớ ớ ướ ượ ử ụ

Ví d , thi t b c a b n kh i t o k t n i đ n remote peer và g i đ n 1ụ ế ị ủ ạ ở ạ ế ố ế ở ế

danh sách transform cho thi t b t xa đó. Remote peer sẽ so sánh v i danhế ị ừ ớ

sách c a nó đ tìm nh ng transform nào kh p v i nó. Thi t b b t đ u dòủ ể ữ ớ ớ ế ị ắ ầ

t cái đ u tiên trong danh sách b n g i so v i cái đ u trong danh sách c aừ ầ ạ ở ớ ầ ủ

nó. N u trùng thì transform đó đ c s d ng ngay. N u không, nó ti p t cế ượ ử ụ ế ế ụ

so sánh v i cái th 2 trong danh sách… Tr ng h p khi so sánh cái đ uớ ứ ườ ợ ầ

tiên c a b n v i toàn b danh sách c a nó mà không có s trùng kh p nào,ủ ạ ớ ộ ủ ự ớ

thi t b t xa đó sẽ ti p t c so sánh transform th hai c a b n v i toàn bế ị ừ ế ụ ứ ủ ạ ớ ộ

tranform c a thi t b đó.ủ ế ị

Ví d v quá trình di n ra s th ng l ng ụ ề ễ ự ươ ượ (Ngu n: The Complete Ciscoồ

VPN Configuration Guide – Richard Deal)

L u ý: n u quá trình này không tìm th y s kh p nhau nào gi a 2ư ế ấ ự ớ ữ

peers thì k t n i qu n lý sẽ không đ c thi t l p và IPsec sẽ th t b i. Cóế ố ả ượ ế ậ ấ ạ

m t ngo i l là thông s th i gian t n t i c a m i peer không c n kh pộ ạ ệ ố ờ ồ ạ ủ ỗ ầ ớ

v i nhau, n u không kh p thì chúng sẽ l y giá tr nào nh h n. Tuy nhiên,ớ ế ớ ấ ị ỏ ơ

m t s nhà cung c p không tuân theo m c đ nh c a IPsec, khi đó b n ph iộ ố ấ ặ ị ủ ạ ả

làm kh p 2 giá tr th i gian s ng trên 2 peers.ớ ị ờ ố

B. Giao th c trao đ i key: Diffie-Hellman (DH)ứ ổ :

M t khi các peers đã đàm phán các chính sách b o v s d ng choộ ả ệ ử ụ

k t n i qu n lý trong Giai đo n 1, DH đ c dùng đ t o m t khóa bí m tế ố ả ạ ượ ể ạ ộ ậ

(secret key). Hai giao th c ISAKMP và IKE không dùng đ chia s d li uứ ể ẻ ữ ệ

t o key trên m t m ng không an toàn, mà thay vào đó chính DH sẽ th cạ ộ ạ ự

hi n nhi m v này.ệ ệ ụTa đ nh nghĩa s l c v DH nh sau: c 2 peers đ u t o ta m t k tị ơ ượ ề ư ả ề ạ ộ ế

h p “public/private key”, public. Chúng chia s public key v i nhau. Chúngợ ẻ ớ

gi l i private key và nh n public key t remote access, t hai key nàyữ ạ ậ ừ ừ

thông qua m t hàm tính toán, sẽ t o ra m t secret key, secret key này cộ ạ ộ ở ả

2 peers sẽ gi ng nhau và nó đ c s d ng đ mã hóa b t c nh ng thôngố ượ ử ụ ể ấ ứ ữ

tin quan tr ng nào. N u ng i gi a mu n nghe tr m thông tin thì ph iọ ế ườ ở ữ ố ộ ả

có m t trong hai private key c a 1 trong 2 peers thì m i có th tính raộ ủ ớ ể

secret key, nh ng t t nhiên, private key thì không đ c chia s v i ai c !ư ấ ượ ẻ ớ ả

Nhóm DH key là nh ng nhóm dùng đ dài khác nhau đ mã hóa key.ữ ộ ể

Có nhi u nhóm DH key đ c s d ng, Cisco cung c p ba nhóm sau: ề ượ ử ụ ấ

Nhóm 1: 768 bit

Nhóm 2: 1024 bit

Nhóm 5: 1536 bit

Ngoài ra Cisco còn cung c p nhóm 7 cho m t vài thi t b khác.ấ ộ ế ị

Ví d v vi c trao đ i khóaụ ề ệ ổ DH (hàng th 2 và 5 xem nhứ ư private key, hàng th 3 xemứ nh public key, hàng th 4 làư ứ các public key sau khi trao đ iổ v i nhau, hàng cu i cùngớ ố chính là secret key) (Ngu n:ồ wikipedia)

C. Ch ng th c thi t bứ ự ế ị :

M t v n đ khi th c hi n v i DH là khi b n mu n trao đ i khóaộ ấ ề ự ệ ớ ạ ố ổ

nh ng l i không bi t tr c s l ng remote peers. Do đó, tr c khi có b tư ạ ế ướ ố ượ ướ ấ

kì m t k t n i nào x y ra, b n ph i xác th c danh tính c a remote peer.ộ ế ố ả ạ ả ự ủ

V i Aggressive Mode trong giai đo n 1, vi c đàm phán, DH, và ki m tra xácớ ạ ệ ể

th c di n ra trong 1 b c l n duy nh t. Tuy nhiên v i Main Mode, quáự ễ ướ ớ ấ ớ

trình thi t l p c n 3 b c, trong b c 3 vi c xác th c d ch v lúc này m iế ậ ầ ướ ướ ệ ự ị ụ ớ

đ c di n ra, vi c xác th c hoàn toàn đ c th c hi n d i m t k t n i anượ ễ ệ ự ượ ự ệ ướ ộ ế ố

toàn đã đ c thi t l p trong b c 1 và 2. Do đó, u đi m là b t kì thôngượ ế ậ ướ ư ể ấ

tin trao đ i gi a 2 peers đ u đ c th c hi n trong m t k t n i đã đ cổ ữ ề ượ ự ệ ộ ế ố ượ

b o v .ả ệTrong c hai ch đ mode, vi c xác th c danh tính là ph n quanả ế ộ ệ ự ầ

tr ng trong IPsec. Có 3 ph ng pháp c b n th c hi n vi c này:ọ ươ ơ ả ự ệ ệ

1. Symmetric pre-shared keys (th ng đ c g i ng n g n làườ ượ ọ ắ ọ

preshared-key).

2. Asymmetric pre-shared keys (th ng g i là mã hóa RSA m t l n).ườ ọ ộ ầ3. Digital certificates (th ng đ c g i là ch ký RSA).ườ ượ ọ ữ

Hai peers sẽ đàm phán v i nhau qua transform c a quá trìnhớ ủ

ISAKMP/IKE giai đo n 1 đ th ng nh t sẽ s d ng ph ng pháp nào.ạ ể ố ấ ử ụ ươ

Không ph i m i thi t b đ u h tr c 3 ph ng pháp này. Ví d , khi nhìnả ọ ế ị ề ỗ ợ ả ươ ụ

vào các dòng s n ph m c a Cisco, thì Cisco IOS Router h tr c ba. ả ẩ ủ ỗ ợ ả Các

s n ph m khác c a Cisco ch h tr hai: pre-shared symmetric keys vàả ẩ ủ ỉ ỗ ợ

digital certificates.

IV. ISAKMP/IKE GIAI ĐOẠN 2: TẠO KẾT NỐI DỮ LIỆU:

Ph n này chúng ta sẽ th o lu n làm th nào đ b o v các k t n i dầ ả ậ ế ể ả ệ ế ố ữ

li u ng i dùng d a vào nh ng đi u sau đây:ệ ườ ự ữ ề Nh ng thành ph n trong ISAKMP/IKE giai đo n 2.ữ ầ ạ Các giao th c b o m t trong ISAKMP/IKE giai đo n 2.ứ ả ậ ạ Các ph ng th c k t n i trong ISAKMP/IKE giai đo n 2.ươ ứ ế ố ạ

Transforms.

K t n i d li u.ế ố ữ ệ

A. Nh ng thành ph n trong ISAKMP/IKE giai đo n 2ữ ầ ạ :

ISAKPM/IKE giai đo n 2 ch có m t mode đ c g i là Quick mode.ạ ỉ ộ ượ ọ

Quick mode đ nh nghĩa vi c b o v các k t n i d li u đ c xây d ngị ệ ả ệ ế ố ữ ệ ượ ự

gi a hai IPsec peers. Quick mode có 2 ch c năng chính:ữ ứ Th ng l ng các thông s b o m t đ b o v các k t n i d li u.ươ ượ ố ả ậ ể ả ệ ế ố ữ ệ Luôn đ i m i các thông tin m t cách đ nh kỳ (t c là xây d ng l i k tổ ớ ộ ị ứ ự ạ ế

n i).ốISAKMP/IKE giai đo n 2 có m t đ c tính đ c bi t: có 2 lu ng k t n iạ ộ ặ ặ ệ ồ ế ố

d li u đ n h ng đ c xây d ng gi a hai thi t b ngang hàng. Ví d ,ữ ệ ơ ướ ượ ự ữ ế ị ụ

thi t b A sẽ có m t k t n i d li u đ n thi t b B và thi t b B sẽ có m tế ị ộ ế ố ữ ệ ế ế ị ế ị ộ

k t n i d li u riêng đ đ n thi t b A. Do 2 k t n i này là tách bi t v iế ố ữ ệ ể ế ế ị ế ố ệ ớ

nhau, nên các thông s b o m t đ c đàm phán có th khác nhau gi a 2ố ả ậ ượ ể ữ

thi t b này. Ví d nh k t n i A-B có th s d ng 3DES cho vi c mã hóa,ế ị ụ ư ế ố ể ử ụ ệ

nh ng k t n i B-A có th s d ng DES. Tuy nhiên, đi u này th ngư ế ố ể ử ụ ề ườ

không đ c áp d ng vì các thông s b o m t luôn t ng t nhau.ượ ụ ố ả ậ ươ ựSau đây là các chính sách c n xác đ nh đ c u hình các thi t b nh mầ ị ể ấ ế ị ằ

xây d ng các k t n i ISAKMP/IKE giai đo n 2 phù h p v i yêu c u:ự ế ố ạ ợ ớ ầ Lu ng d li u nào m i th c s c n đ c b o v ?ồ ữ ệ ớ ự ự ầ ượ ả ệ C n s d ng giao th c b o m t nào? AH hay ESP.ầ ử ụ ứ ả ậ D a vào vi c l a ch n các giao th c b o m t, các lu ng d li u sẽự ệ ự ọ ứ ả ậ ồ ữ ệ

đ c b o v b ng cách nào? Dùng hàm băm hay hàm mã hóa.ượ ả ệ ằ Dùng tunnel hay transport mode?

Khi xây d ng l i k t n i, ISAKMP/IKE giai đo n 1 có nên t o l i vàự ạ ế ố ạ ạ ạ

chia s các khóa m i hay không thay vì gi nguyên khóa cũ.ẻ ớ ữ Th i gian s ng c a các k t n i d li u là bao nhiêu?ờ ố ủ ế ố ữ ệ

B. Các giao th c b o m t giai đo n 2ứ ả ậ ạ :

IPsec có th s d ng m t hay hai giao th c b o m t sau đây đ b o vể ử ụ ộ ứ ả ậ ể ả ệ

d li u đ c truy n qua các k t n i d li u đ c xây d ng trongữ ệ ượ ề ế ố ữ ệ ượ ự

ISAKMP/IKE giai đo n 2:ạ AH

ESP

B ng d i đây so sánh 2 giao th c này.ả ướ ứ

Đ c đi m b o m tặ ể ả ậ AH ESP

S hi u giao th c l p 3ố ệ ứ ớ 51 50

H tr tính toàn v n d li uỗ ợ ẹ ữ ệ Yes Yes

H tr ch ng th c d li uỗ ợ ứ ự ữ ệ Yes Yes

H tr mã hóa d li uỗ ợ ữ ệ No Yes

B o v d li u tr c t n côngả ệ ữ ệ ướ ấ

replay

Yes Yes

Ho t đ ng v i NATạ ộ ớ No Yes

Ho t đ ng v i PATạ ộ ớ No No

B o v cho gói tin IPả ệ Yes No

Ch b o v cho d li uỉ ả ệ ữ ệ No Yes

1. Giao thức Authentication Header (AH):

1.1 Giới thiệu:

AH cung cấp xác thực nguồn gốc dữ liệu (data origin authentication),

kiểm tra tính toàn vẹn dữ liệu (data integrity), và dịch vụ chống phát lại

(anti-replay service). Đến đây, cần phải phân biệt được hai khái niệm toàn

vẹn dữ liệu và chống phát lại: toàn vẹn dữ liệu là kiểm tra những thay đổi của

từng gói tin IP, không quan tâm đến vị trí các gói trong luồng lưu lượng; còn

dịch vụ chống phát lại là kiểm tra sự phát lặp lại một gói tin tới địa chỉ đích

nhiều hơn một lần. AH cho phép xác thực các trường của IP header cũng như

dữ liệu của các giao thức lớp trên, tuy nhiên do một số trường của IP header

thay đổi trong khi truyền và phía phát có thể không dự đoán trước được giá trị

của chúng khi tới phía thu, do đó giá trị của các trường này không bảo vệ

được bằng AH. Có thể nói AH chỉ bảo vệ một phần của IP header mà thôi.

AH không cung cấp bất cứ xử lý nào về bảo mật dữ liệu của các lớp trên,

tất cả đều được truyền dưới dạng văn bản rõ. AH nhanh hơn ESP, nên có

thể chọn AH trong trường hợp chắc chắn về nguồn gốc và tính toàn vẹn của

dữ liệu nhưng tính bảo mật dữ liệu không cần được chắc chắn.

Giao thức AH cung cấp chức năng xác thực bằng cách thực hiện một

hàm băm một chiều (one-way hash function) đối với dữ liệu của gói để tạo

ra một đoạn mã xác thực (hash hay message digest). Đoạn mã đó được chèn

vào thông tin của gói truyền đi. Khi đó, bất cứ thay đổi nào đối với nội dung

của gói trong quá trình truyền đi đều được phía thu phát hiện khi nó thực hiện

cùng với một hàm băm một chiều đối với gói dữ liệu thu được và đối chiếu nó

với giá trị hash đã truyền đi. Hàm băm được thực hiện trên toàn bộ gói dữ

liệu, trừ một số trường trong IP header có giá trị bị thay đổi trong quá trình

truyền mà phía thu không thể dự đoán trước được (ví dụ trường thời gian

sống của gói tin bị các router thay đổi trên đường truyền dẫn).

1.2 Cấu trúc gói AH:

Ý nghĩa từng phần:

Next Header (tiêu đề tiếp theo) Có độ dài 8 bit để nhận dạng loại dữ

liệu của phần tải tin theo sau AH. Giá trị này được chọn lựa từ tập

các số giao thức IP đã được định nghĩa trong các RFC gần đây nhất.

Payload length (độ dài tải tin): Có độ dài 8 bit và chứa độ dài của

tiêu đề AH được diễn tả trong các từ 32 bit, trừ 2. Ví dụ trong

trường hợp của thuật toán toàn vẹn mà mang lại một giá trị xác

minh 96 bit (3x32 bit), cộng với 3 từ 32 bit đã cố định, trường độ

dài này có giá trị là 4. Với IPv6, tổng độ dài của tiêu đề phải là bội

của các khối 8.

Reserved (dự trữ): Trường 16 bit này dự trữ cho ứng dụng trong tương

lai.

Security Parameters Index (SPI: chỉ dẫn thông số an ninh): Trường

này có độ dài 32 bit, mang tính chất bắt buộc.

Sequence Number (số thứ tự): Đây là trường 32 bit không đánh dấu

chứa một giá trị mà khi mỗi gói được gửi đi thì tăng một lần.

Trường này có tính bắt buộc. Bên gửi luôn luôn bao gồm trường này

ngay cả khi bên nhận không sử dụng dịch vụ chống phát lại. Bộ đếm

bên gửi và nhận được khởi tạo ban đầu là 0, gói đầu tiên có số thứ tự

là 1. Nếu dịch vụ chống phát lại được sử dụng, chỉ số này không thể

lặp lại, sẽ có một yêu cầu kết thúc phiên truyền thông và SA sẽ được

thiết lập mới trở lại trước khi truyền 232 gói mới.

Authentication Data (dữ liệu nhận thực): Còn được gọi là ICV

(Integrity Check Value: giá trị kiểm tra tính toàn vẹn) có độ dài thay

đổi, bằng số nguyên lần của 32 bit đối với IPv4 và 64 bit đối với

IPv6, và có thể chứa đệm để lấp đầy cho đủ là bội số các bit như trên.

ICV được tính toán sử dụng thuật toán nhận thực, bao gồm mã nhận

thực bản tin (Message Authentication Code MACs). MACs đơn giản

có thể là thuật toán mã hóa MD5 hoặc SHA-1. Các khóa dùng cho mã

hóa AH là các khóa xác thực bí mật được chia sẻ giữa các phần truyền

thông có thể là một số ngẫu nhiên, không phải là một chuỗi có thể

đoán trước của bất cứ loại nào. Tính toán ICV được thực hiện sử dụng

gói tin mới đưa vào. Bất kì trường có thể biến đổi của IP header nào

đều được cài đặt bằng 0, dữ liệu lớp trên được giả sử là không thể

biến đổi. Mỗi bên tại đầu cuối IP-VPN tính toán ICV này độc lập.

Nếu ICV tính toán được ở phía thu và ICV được phía phát truyền đến

khi so sánh với nhau mà không phù hợp thì gói tin bị loại bỏ, bằng

cách như vậy sẽ đảm bảo rằng gói tin không bị giả mạo.

1.3 Quá trình xử lý AH:

Hoạt động của AH được thực hiện qua các bước như sau:

Bước 1: Toàn bộ gói IP (bao gồm IP header và tải tin)

được thực hiện qua một hàm băm một chiều.

Bước 2: Mã hash thu được dùng để xây dựng một AH header,

đưa header này vào gói dữ liệu ban đầu.

Bước 3: Gói dữ liệu sau khi thêm AH header được truyền tới

đối tác IPSec.

Bước 4: Bên thu thực hiện hàm băm với IP header và tải

tin, kết quả thu được một mã hash.

Bước 5: Bên thu tách mã hash trong AH header.

Bước 6: Bên thu so sánh mã hash mà nó tính được mà mã

hash tách ra từ AH header. Hai mã hash này phải hoàn toàn

giống nhau. Nếu khác nhau chỉ một bit trong quá trình

truyền thì 2 mã hash sẽ không giống nhau, bên thu lập tức

phát hiện tính không toàn vẹn của dữ liệu.

a.Vị trí của Header:

AH có hai kiểu hoạt động, đó là kiểu Transport và kiểu Tunnel.

Kiểu Transport là kiểu đầu tiên được sử dụng cho kết nối đầu cuối

giữa các host hoặc các thiết bị hoạt động như host và kiểu Tunnel

được sử dụng cho các ứng dụng còn lại.

Ở kiểu Transport cho phép bảo vệ các giao thức lớp trên, cùng

với một số trường trong IP header. Trong kiểu này, AH được chèn

vào sau IP header và trước một giao thức lớp trên (chẳng hạn như

TCP, UDP, ICMP…) và trước các IPSec header đã được chen vào.

Đối với IPv4, AH đặt sau IP header và trước giao thức lớp trên (ví dụ ở

đây là TCP). Đối với IPv6, AH được xem như phần tải đầu cuối-tới -

đầu cuối, nên sẽ xuất hiện sau các phần header mở rộng hop-to-hop,

routing và fragmentation. Các lựa chọn đích(dest options extension

headers) có thể trước hoặc sau AH.

Khuôn dạng IPv4 trước và sau khi xử lý AH ở kiểu Transport

Khuôn dạng IPv6 trước và sau khi xử lý AH ở kiểu Traport

Trong kiểu Tunnel, inner IP header mang địa chỉ nguồn và đích

cuối cùng, còn outer IP header mang địa chỉ để định tuyến qua

Internet. Trong kiểu này, AH bảo vệ toàn bộ gói tin IP bên trong, bao

gồm cả inner IP header (trong khi AH Transport chỉ bảo vệ một số

trường của IP header). So với outer IP header thì vị trí của AH giống

như trong kiểu Trasport.

Khuôn dạng gói tin đã xử lý AH ở kiểu Tunnel

b. Các thuật toán xác thực:

Thuật toán xác thực sử dụng để tính ICV được xác định bởi kết

hợp an ninh SA (Security Association). Đối với truyền thông điểm tới

điểm, các thuật toán xác thực thích hợp bao gồm các hàm băm một

chiều (MD5, SHA-1). Đây chính là những thuật toán bắt buộc mà một

ứng dụng AH phải hỗ trợ.

c. Xử lý gói đầu ra:

Trong kiểu Transport, phía phát chèn AH header vào sau IP

header và trước một header của giao thức lớp trên. Trong kiểu

Tunnel, có thêm sự xuất hiện của outer IP header. Quá trình xử lý gói

tin đầu ra như sau:

Tìm kiếm SA: AH được thực hiện trên gói tin đầu ra chỉ khi quá

trình IPSec đã xác định được gói tin đó được liên kết với một

SA. SA đó sẽ yêu cầu AH xử lý gói tin. Việc xác định quá trình

xử lý IPSec nào cần thực hiện trên lưu lượng đầu ra có thể xem

trong RFC 2401

Tạo SN: bộ đếm phía phát được khởi tạo 0 khi một SA được

thiết lập. Phía phát tăng SN cho SA này và chèn giá trị SN đó

vào trường Sequence Number. Nếu dịch vụ anti-replay (chống

phát lại) được lựa chọn, phía phát kiểm tra để đảm bảo bộ đếm

không bị lặp lại trước khi chèn một giá trị mới. Nếu dịch vụ anti-

replay không được lựa chọn thì phía phát không cần giám sát

đến, tuy nhiên nó vẫn được tăng cho đến khi quay trở lại 0.

Tính toán ICV: bằng cách sử dụng các thuật toán, phía thu sẽ

tính toán lại ICV ở phía thu và so sánh nó với giá trị có trong

AH để quyết định tới khả năng tồn tại của gói tin đó.

Chèn dữ liệu: có hai dạng chèn dữ liệu trong AH, đó là chèn dữ

liệu xác thực (Authentication Data Padding) và chèn gói ngầm

định (Implicit Packet Padding). Đối với chèn dữ liệu xác thực,

nếu đầu ra của thuật toán xác thực là bội số của 96 bit thì

không được chèn. Tuy nhiên nếu ICV có kích thước khác thì

việc chèn thêm dữ liệu là cần thiết. Nội dung của phần dữ liệu

chèn là tùy ý, cũng có mặt trong phép tính ICV và được truyền

đi. Chèn gói ngầm định được sử dụng khi thuật toán xác thực

yêu cầu tính ICV là số nguyên của một khối b byte nào đó và

nếu độ dài gói IP không thỏa mãn điều kiện đó thì chèn gói

ngầm định được thực hiện ở phía cuối của gói trước khi tính

ICV. Các byte chèn này có giá trị là 0 và không được truyền đi

cùng với gói.

Phân mảnh: khi cần thiết, phân mảnh sẽ được thực hiện sau khi

đã xử lý AH. Vì vậy AH trong kiểu transport chỉ được thực hiện

trên toàn bộ gói IP, không thực hiện trên từng mảnh. Nếu bản

thân gói IP đã qua xử lý AH bị phân mảnh trên đường truyền thì

ở phía thu phải được ghép lại trước khi xử lý AH. Ở kiểu Tunnel,

AH có thể thực hiện trên gói IP mà phần tải tin là một gói IP

phân mảnh.

d. Xử lý gói đầu vào:

Khi nhận được một thông điệp có chứa AH, quá trình xử lí ip

trước tiên sẽ tổng hợp các phân mảnh thành thông điệp hoàn chỉnh.Sau

đó thông điệp này sẽ được chuyển tới quá trình xử lí IPSEC.Quá trình

này gồm các bước như sau:

Bước 1:Xác định inbound SA tương ứng trong SAD.Bước này

được thực hiện dựa trên các thôngsố: SPI, địa chỉ nguồn, giao

thức AH. SA tương ứng kiểm tra trong gói AH để xác định xem

mode nào được áp dụng transport mode hay tunnel mode hay cả

hai.Gói cũng phải cung cấp một số thông số để giới hạn tầm tác

động của SA(ví dụ: port hay protocol). Nếu đây là tunnel header

SA phải so sánh các thông số này trong packer inner vì các thông

số này không được sao chép sang tunnel header. Khi SA phù hợp

được tìm thấy, quá trình được tiếp tục, ngược lại gói tin sẽ bị hủy

bỏ.

Bước 2: Nếu chức năng chống phát lại được kích hoạt, phía xuất

phát của gói tin AH luôn tăng số đếm chống phát lại. Bên nhận

có thể bỏ qua hoặc sử dụng chỉ số này để chống phát lại. Tuy

nhiên giao thức IP không đảm bảo rằng trình tự của các gói khi

đến bên nhận giống như trình tự các gói lúc chúng được gửi đi.

Do đó chỉ số này không thể dùng để xác định thứ tự của các gói

tin.Tuy nhiên chỉ số này vẫn có thể sử dụng để xác định mối liên

hệ về thứ tự với một cửa sổ có chiều dài là bội số của 32 bits.

Đối với mỗi inbound SA, SAD lưu trữ một cửa sổ chống phát

lại. Kích thước của cửa sổ là bội số của 32 bits với giá trị mặc

định là 64 bits. Một cửa sổ chống phát lại có kích thước N kiểm

soát sequence number của N thông điệp được nhận gần nhất. Bất

cứ thông điêp nào có sequence number nhỏ hơn miền giá trị của

cửa sổ phát lại đểu bị hủy bỏ. Các thông điệp có số sequence

number đã tồn tại trong cửa sổ phát lại cũng bị hủy bỏ. Một bit

mask ( hoặc một cấu trúc tương tự ) được sử dụng để kiểm soát

sequence number của N thông điệp được nhận gần nhất đối với

SA này. Ban đầu một bit-mask 64 bít có thể giám sát sequence

number của các thông điệp có sequence number nằm trong đoạn

1 , 64.Một khi xuất hiện một thông điệp có số sequence number

lớn hơn 64 ( ví dụ 70), bit-mask sẽ dịch chuyển để giám sát các

số sequence number trong đoạn 7 70. Do đó nó sẽ hủy bỏ các

thông điệp có sequence number nhỏ hơn 7, hoặc các thông điệp

có số sequence number đã xuất hiện trong cứa sổ chống phát lại.

Hình dưới đây minh họa hoạt động của cửa sổ chống phát lại

Bước 3: Kiểm tra tính xác thực của dữ liệu. Hàm băm được tính

toán tương tự như dữ liệu đầu ra. Nếu kết quả tính không trùng

với ICV trong thông điệp thì hủy bỏ thông điệp, ngược lại sẽ

chuyển sang giai đoạn tiếp theo.

Bước 4: Loại bỏ AH và tiếp tục quá trình xử lí IPSEC cho các

phần còn lại của tiêu đề IPSEC. Nếu có một nested IPSEC

header xuất hiện tại đích đến này. Mỗi header cần phải được xử

lí cho đến khi một trong hai điều kiện được thỏa mãn. Khi ipsec

header cuối cùng đã được xử lí thành công và quá trình xử lí tiếp

cận đến các protocol của lớp trên gói tin được gửi đến chu trình

xử lí gói ip tiếp tục di chuyển trong tầng ip. Trong trường hợp

khác, nếu quá trình xử lí tiếp cận với một tunnel ip header mà

đích đến không phải là host này thì thông điệp được chuyển đến

host phù hợp tại đó các giai đoạn tiếp theo của quá trình xử lí

IPSEC được diễn ra.

Bước 5: Kiểm tra trong SAD để đảm bảo rằng các ipsec policy

áp dụng với thông điệp trên thỏa mãn hệ thống các policy yêu

cầu. Giai đoạn quan trọng này rất khó minh họa trong trường

hợp quá trình xác thực chỉ sử dụng mình AH. Một ví dụ có sức

thuyết phục cao hơn khi chúng ta tiếp tục tìm hiểu một loại tiêu

đề bảo mật khác ESP.

2. Giao th c Encapsulating Security Payload ( ESP):ứ

2.1 Cấu trúc gói tin ESP:

Ho t đ ng c a ESP khác h n so v i AH, ESP đóng gói t t c ho cạ ộ ủ ơ ớ ấ ả ặ

m t ph n d li u g c.ộ ầ ữ ệ ố

Ý nghĩa các tr ng trong ESPườ  :

SPI : Là m t s 32 bit cùng v i đ a ch IP đích. Các giáộ ố ớ ị ỉ

tr SPI t 1-255 đ c dành riêng đ s d ng trong t ng lai.ị ừ ượ ể ử ụ ươ Sequence Number : T ng t nh trong c u trúc góiươ ự ư ấ

AH

Payload Data: Bao g m m t s các byte d li u g cồ ộ ố ữ ệ ố

ho c m t ph n d li u yêu c u b o m t đã đ c mô t trongặ ộ ầ ữ ệ ầ ả ậ ượ ả

tr ng Next Header. Tr ng này đ c mã hóa b ng thu t toánườ ườ ượ ằ ậ

mã hóa đã ch n trong quá trình thi t l p SA, th ng s d ngọ ế ậ ườ ử ụ

thu t toán DES-CBC, 3DES, CDMFậ Padding: N u thu t toán mã hóa đ c s d ng yêu c uế ậ ượ ử ụ ầ

plaintext ph i là s nguyên l n kh i các byte. Ví d , tr ng h pả ố ầ ố ụ ườ ợ

mã kh i thì Padding đ c s d ng đ đi n đ y vàoố ượ ử ụ ể ề ầ

plaintext( g m Payload Data, Pad Length, Next Header vàồ

Padding) có kích th c theo yêu c u. Có th xem Padding nh làướ ầ ể ư

ph n đ m thêm.ầ ệ Authentiaction data: Thông tin xác th c đ c tính trênự ượ

toàn b gói ESP.ộ2.2 Quá trình xử lý ESP:

a. V trí c a Header:ị ủ

Transport mode, ESP đ c chèn vào sau m t IP header và tr cỞ ượ ộ ướ

m t giao th c l p trên ( nh TCP, UDP, ICMP). Đ i v i IPv4, ESP headerộ ứ ớ ư ố ớ

đ t sau IP header và tr c giao th c l p trên ( TCP), ESP trailer bao g mặ ướ ứ ớ ồ

các tr ng Padding, Pad Length, Next header. Đ i v i IPv6, sau ph nườ ố ớ ầ

header m r ng hop to hop, routing và fragmentation.ở ộ

Khuông d ng IPv4 tr c và sau khi x lý ESP Transportạ ướ ử ở

mode

Khuông d ng IPv6 tr c và sau khi x lý ESP Transportạ ướ ử ở

mode.

Trong ki u Tunnel, inner IP header mang đ a ch ngu n và đích cu iể ị ỉ ồ ố

cùng, còn outer IP header m ng đ a ch đ đ nh tuy n qua Internet. Trongạ ị ỉ ể ị ế

ki u này, ESP sẽ b o v toàn b gói tin IP bên trong, bao g m c inner IPể ả ệ ộ ồ ả

header. So v i outer IP header thì v trí c a ESP gi ng nh ki u Trasport.ớ ị ủ ố ư ể

Khuông d n gói tin đã x lý ESP Tunnel modeạ ử ở

b. Các thu t toán:ậ

Thu t toán đ c s d ng v i ESP th ng là:ậ ượ ử ụ ớ ườ

DES, 3DES in CBC

HMAC with MD5

HMAC with SHA-1

NULL Authentication algorithm

NULL Encryption algorithm.

Đ m b o ít nh t m t trong hai d ch v b o m t ho c nh n th cả ả ấ ộ ị ụ ả ậ ặ ậ ự

ph i đ c th c hi n, nên c hai thu t toán xác th c và mã hóa khôngả ượ ự ệ ả ậ ự

đ c đ ng th i b ng NULL.ượ ồ ờ ằ

Các thu t toán mã hóa: Thu t toán mã hóa đ c xác đ nhậ ậ ượ ị

b SA. ESP làm vi c v i các thu t toán mã hóa đ i x ng. Vìở ệ ớ ậ ố ứ

các gói IP có th đ n không đúng th t , nên m i gói ph iể ế ứ ự ỗ ả

mang thông tin c n thi t đ phía thu có th thi t l pầ ế ể ể ế ậ

đ ng b đ gi i mã. D li u này đ c ch đ nh trongồ ộ ể ả ữ ệ ượ ỉ ị

tr ng Payload ( ví d d i d ng các vector kh i t o)ườ ụ ướ ạ ở ạ

ho c thu đ c t header c a gói.ặ ượ ừ ủ Các thu t toán xác th c: Thu t toán xác th c s d ng đậ ự ậ ự ử ụ ể

tính ICV, đ c xác đ nh b i SA. Đ i v i truy n thôngượ ị ở ố ớ ề

point-to-point, các thu t toán xác th c thích h p bao g mậ ự ợ ồ

các hàm băm m t chi u MD5, SHA-1,…ộ ềc. X lý gói đ u ra:ử ầ

Đ i v i Transport mode, phía phát đóng gói thông tin giao th c l pố ớ ứ ớ

trên và ESP header/trailer và gi nguyên IP header. Đ i v i Tunnel mode,ữ ố ớ

có thêm s xu t hi n c a outer IP header. Quá trình x lý c th nh sau:ự ấ ệ ủ ử ụ ể ư

Tìm ki m SA: ESP đ c th c hi n trên m t gói tin đ u raế ượ ự ệ ộ ầ

ch khi quá trình IPSec xác đ nh đ c gói tin đó đã liên k tỉ ị ượ ế

v i m t SA, SA sẽ yêu c u ESP x lý gói tin.ớ ộ ầ ử Mã hóa gói tin: Đ i v i Transport mode ch đóng gói thôngố ớ ỉ

tin giao th c l p cao. V i Tunnel mode, đóng gói toàn bứ ớ ớ ộ

gói IP ban đ u, thêm tr ng Padding n u c n thi t, mãầ ườ ế ầ ế

hóa các tr ng s d ng khóa; thu t toán đ c quy đ nhườ ử ụ ậ ượ ị

b i SA và đ ng b d li u mã hóa n u có.ở ồ ộ ữ ệ ế T o SN: T ng t nh tr ng h p giao th c AH.ạ ươ ự ư ườ ợ ứ Tính toán ICV: N u d ch v xác th c đ c ch n thì phíaế ị ụ ự ượ ọ

phát sẽ tính toán giá tr ICV trên d li u gói ESP trị ữ ệ ừ

tr ng Authentication Data. Các tr ng mã hóa đ c th cườ ườ ượ ự

hi n tr c xác th c. Chi ti t tính toán t ng t nh AH.ệ ướ ự ế ươ ự ư ở Phân m nh: Phân m nh đ c th c hi n sau khi đã x lýả ả ượ ự ệ ử

ESP. Vì v y ESP trong Transport mode ch đ c th c hi nậ ỉ ượ ự ệ

trên toàn b gói IP, không th c hi n trên t ng m nh. N uộ ự ệ ừ ả ế

b n thân gói IP đã qua x lý ESP mà b phân m nh trongả ử ị ả

quá trình truy n qua các router trên đ ng truy n thì cácề ườ ề

m nh ph i đ c ghép l i tr c khi x lý ESP phía thu.ả ả ượ ạ ướ ử ở

V i Tunnel mode, ESP có th đ c th c hi n trên gói IPớ ể ượ ự ệ

mà ph n Payload là 1 gói IP phân m nh.ầ ảd. X lý gói đ u vào.ử ầ

Quá trình x lý gói đ u vào ng c v i quá trình x lý gói đ u ra:ử ầ ượ ớ ử ở ầ

Ghép m nh: Đ c th c hi n tr c khi x lý ESP.ả ượ ự ệ ướ ử

Tìm ki m SA: Khi nh n đ c gói đã ghép m nh ch a ESPế ậ ượ ả ứ

header, phía thu sẽ xác đ nh m t SA phù h p d a trên: đ aị ộ ợ ự ị

ch IP đích, giao th c an ninh ESP và SPI. Thông tin trongỉ ứ

SA sẽ cho bi t c n ph i ki m tra tr ng Sequenceế ầ ả ể ườ

Number hay không, c n thêm tr ng Authentication Dataầ ườ

không, các thu t toán và khóa c n s d ng đ gi i mã ICVậ ầ ử ụ ể ả

n u có. N u không tìm th y SA nào phù h p cho phiênế ế ấ ợ

truy n d n, phía thu sẽ lo i b gói này.ề ẫ ạ ỏ Ki m tra SN: ESP luôn h tr d ch v ch ng phát l iể ỗ ợ ị ụ ố ạ

( anti-replay). N u d ch v xác th c không đ c ch n,ế ị ụ ự ượ ọ

Sequence Number không đ c b o v tính toàn v n , d chượ ả ệ ẹ ị

v anti-replay không th c hi n đ c. N u phía thu khôngụ ự ệ ượ ế

ch n d ch v ch ng phát l i, thì không c n ki m traọ ị ụ ố ạ ầ ể

Sequence Number. N u phía thu ch n d ch v ch ng phátế ọ ị ụ ố

l i thì b đ m gói thu đ c kh i t o là 0 khi thi t l p SA.ạ ộ ế ượ ở ạ ế ậ

V i m i gói thu đ c, phía thu ph i ki m tra r ng gói đóớ ỗ ượ ả ể ằ

có ch a s Sequence Number không l p c a b t kỳ m tứ ố ặ ủ ấ ộ

gói nào trong th i gian t n t i SA đó.ờ ồ ạ Ki m tra ICV: N u d ch v xác th c đ c l a ch n, phíaể ế ị ụ ự ượ ự ọ

thu sẽ tính ICV d a trên d li u gói ESP, tr tr ng AD, sự ữ ệ ừ ườ ử

d ng thu t toán xác th c đ c xác đ nh trong SA và soụ ậ ự ượ ị

sánh v i giá tr ICV trong tr ng Authentication c a gói.ớ ị ườ ủ

N u 2 giá tr ICV hoàn toàn trùng kh p thì gói tin là h p lế ị ớ ợ ệ

và đ c ch p nh n. Ng c l i, phía thu sẽ lo i b gói tinượ ấ ậ ượ ạ ạ ỏ

này. Vi c ki m tra c th nh sau: Giá tr ICV n m trongệ ể ụ ể ư ị ằ

tr ng Authentication Data đ c tách kh i gói ESP vàườ ượ ỏ

đ c l u tr t m. Ti p theo ki m tra đ dài c a góiượ ư ữ ạ ế ể ộ ủ

ESP( tr tr ng AD v a tách). N u Padding ng m đ nhừ ườ ừ ế ầ ị

đ c yêu c u b i thu t toán xác th c thì các byte 0 đ cượ ầ ở ậ ự ượ

thêm vào cu i gói ESP, sau tr ng Next Header. Th c hi nố ườ ự ệ

tính toán ICV và so sánh v i giá tr đã l u tr t m.ớ ị ư ữ ạ

e. Gi i mã gói:ả

N u ESP s d ng mã hóa thì sẽ ph i th c hi n quá trình gi i mã.ế ử ụ ả ự ệ ả

Quá trình gi i mã nh sau:ả ư

Gi i mã ESP ( bao g m tr ng Payload Data, Padding, Padả ồ ườ

Length, Next header) s d ng khóa. Thu t toán mã hóaử ụ ậ

đ c xác đ nh b i SA.ượ ị ở X lý ph n Padding theo đ c t c a thu t toán. Phía thuử ầ ặ ả ủ ậ

c n tìm và lo i b ph n Padding tr c khi chuy n d li uầ ạ ỏ ầ ướ ể ữ ệ

đã gi i mã lên l p trên.ả ớ Xây d ng l i c u trúc gói IP ban đ u t IP header ban đ uự ạ ấ ầ ừ ầ

và thông tin giao th c l p cao trong Payload c a ESP( ứ ớ ủ ở

Transport mode) ho c outer IP header và toàn b gói IPặ ộ

ban đ u trong Payload c a ESP ( v i Tunnel mode).ầ ủ ớ

Có các lý do d n đ n quá trình gi i mã không thành công:ẫ ế ả

SA đ c l a ch n không đúng. SA có th sai các thông sượ ự ọ ể ố

SPI, IP đích.

Đ dài ph n Padding ho c giá tr c a nó b sai.ộ ầ ặ ị ủ ị Gói ESP mã hóa b l i.ị ỗ

Ch ký và mã hóaữ

Nh ph n trên đã nói, ESP mang l i s b o v cho các giao th c cácư ầ ạ ự ả ệ ứ ở

l p trên c a nó. Hình sau đây cho ta th y ph n nào c a ESP sẽ giúp nóớ ủ ấ ầ ủ

th c hi n nhi m v đ m b o tính toàn v n c a d li u và ph n nào làự ệ ệ ụ ả ả ẹ ủ ữ ệ ầ

ph n mã hóa th c hi n nhi m v b o m t d li u.ầ ự ệ ệ ụ ả ậ ữ ệ

“Ch ký và mã hóa” (Ngu n:ữ ồ

http://technet.microsoft.com/en-us/library/cc959510.aspx )

C. Ph ng th c k t n i trong Phase 2ươ ứ ế ố :

Nh đã đ c p trong các ph n trên, có hai cách mà AH và ESP có th sư ề ậ ầ ể ử

d ng đ truy n thông tin b o m t đ n đích: ụ ể ề ả ậ ế Transport mode

Tunnel mode

1. Transport mode :

Transport mode đ c s d ng gi a hai thi t b ngu n và đích đ u cu iượ ử ụ ữ ế ị ồ ầ ố

th c s (đ phân bi t v i tr ng h p Tunnel Mode), t c là k t n i end-ự ự ể ệ ớ ườ ợ ứ ế ốto-end, chính các thi t b này sẽ th c hi n các d ch v b o v cho d li u.ế ị ự ệ ị ụ ả ệ ữ ệ

IPsec Transport Mode (Ngu n: ồ http://www.firewall.cx/networking-

topics/protocols/870-IPsec-modes.html )

Transport mode b o v cho IP Payload, t c là bao g m TCP/UDPả ệ ứ ồ

Header và d li u qua vi c s d ng AH ho c ESP. Trong mode này, IPữ ệ ệ ử ụ ặ

Header ban đ u sẽ gi nguyên không đ i, ch có tr ng protocol là thayầ ữ ổ ỉ ườ

đ i t s 50 (ESP) hay 51 (AH). Mode này th ng đ c s d ng đ b oổ ừ ố ườ ượ ử ụ ể ả

v cho m t giao th c đ ng h m khác, ch ng h n nh GRE, GRE đ u tiênệ ộ ứ ườ ầ ẳ ạ ư ầ

sẽ đóng gói gói tin IP, sau đó IPsec sẽ b o v cho gói tin GRE đó.ả ệ

Gói tin v i giao th c ESP đ c ch ra trong hình sau:ớ ứ ượ ỉ

Gói tin ESP trong Transport Mode (Ngu n:ồ

http://www.firewall.cx/networking-topics/protocols/870-IPsec-

modes.html )

L u ý r ng IP Header phía tr c chính là gói IP ban đ u. Vi c đ t góiư ằ ở ướ ầ ệ ặ

này đ u cho ta th y Transport Mode không mang l i s b o v ho cở ầ ấ ạ ự ả ệ ặ

mã hóa cho IP Header ban đ u.ầ

Gói tin v i giao th c AH đ c ch ra trong hình sau:ớ ứ ượ ỉ

Gói tin AH trong Transport Mode (Ngu n:ồ

http://www.firewall.cx/networking-topics/protocols/870-IPsec-

modes.html )

AH có th ho t đ ng đ c l p ho c k t h p v i ESP khi IPsec đ c sể ạ ộ ộ ậ ặ ế ợ ớ ượ ử

d ng trong Transport Mode. Vi c c a AH là b o v cho c gói tin, tuyụ ệ ủ ả ệ ả

nhiên, IPsec trong transport mode không h t o ra m t IP Header m i ề ạ ộ ớ ở

đ u gói tin mà l i sao chép nguyên IP Header g c ra bên ngoài, có thayầ ạ ố

đ i cũng ch là thay đ i protocol ID sang 51.ổ ỉ ổTóm l i, trong IPsec transport mode, đ i v i c ESP và AH, IP Headerạ ố ớ ả

đ u b l .ề ị ộ

2. Tunnel mode:

Đây chính là mode m c đ nh c a VPN. V i mode này, c gói tin IP banặ ị ủ ớ ả

đ u sẽ đ c b o v . Nghĩa là IPsec sẽ l y c gói tin ban đ u, mã hóa nó,ầ ượ ả ệ ấ ả ầ

thêm m t IP Header m i và g i nó t i đ u kia c a “tunnel”.ộ ớ ử ớ ầ ủMode này đ c s d ng ph bi n gi a các gateway (Cisco routers, ASAượ ử ụ ổ ế ữ

firewalls), gateway lúc này ho t đ ng gi ng nh là m t proxy cho thi t bạ ộ ố ư ộ ế ị đ ng sau nó. Do đó, đ i v i Tunnel mode, nh ng thi t b đích và ngu nằ ố ớ ữ ế ị ồ

không th c hi n d ch v b o m t cho d li u ng i dùng mà chínhự ệ ị ụ ả ậ ữ ệ ườ

nh ng thi t b trung gian sẽ làm chuy n này.ữ ế ị ệCách này đ c s d ng cho k t n i site-to-site và k t n i truy c p tượ ử ụ ế ố ế ố ậ ừ

xa. Gói IP g c ban đ u ch a thông tin v đ u cu i th c s lúc này đ cố ầ ứ ề ầ ố ự ự ượ

b o v và đóng vào trong thông tin c a AH/ESP, sau đó m t IP Headerả ệ ủ ộ

khác ch a đ a ch c a các thi t b trung gian đ c g n thêm vào gói tin,ứ ị ỉ ủ ế ị ượ ắ

do đó thông tin v đ u cu i th c s hoàn toàn đ c b o m t nh ngề ầ ố ự ự ượ ả ậ ư

không làm nh h ng đ n vi c đ nh tuy n gói tin. Nh ng thu n l i chínhả ưở ế ệ ị ế ữ ậ ợ

c a Tunnel mode so v i lo i Transport mode là d ch v b o m t t pủ ớ ạ ị ụ ả ậ ậ

trung trên s l ng thi t b nh h n (ch y u ch là các thi t b trungố ượ ế ị ỏ ơ ủ ế ỉ ế ị

gian), do đó t o thu n l i cho vi c c u hình và qu n lí.ạ ậ ợ ệ ấ ả

IPsec Tunnel Mode (Ngu n:ồ

http://www.firewall.cx/networking-topics/protocols/870-IPsec-

modes.html )

Trong tunnel mode, IPsec Header (AH ho c ESP Header) sẽ đ c chènặ ượ

gi a ph n IP Header và ph n giao th c l p trên. Gi a AH và ESP, ESPữ ầ ầ ứ ớ ữ

đ c s d ng ph bi n h n trong c u hình IPsec VPN Tunnel.ượ ử ụ ổ ế ơ ấ

C u trúc gói tin dùng giao th c ESP trong IPsec tunnel mode nh hìnhấ ứ ư

sau:

Gói tin ESP trong Tunnel mode (Ngu n:ồ

http://www.firewall.cx/networking-topics/protocols/870-IPsec-

modes.html )

C u trúc gói tin dùng giao th c AH trong IPsec tunnel mode nh hình sau:ấ ứ ư

Gói tin AH trong Tunnel mode (Ngu n: ồ http://www.firewall.cx/networking-

topics/protocols/870-IPsec-modes.html )

K t thúc ph n này, ta rút ra m t đi u sau đây: transport mode chế ầ ộ ề ỉ s d ng trong ử ụ nh ngữ k t n i ch c n d li u đ c b o v (ch ngế ố ỉ ầ ữ ệ ượ ả ệ ẳ

h n k t n i dùng giao th c TFTP đ l y file c u hình, ho c k t n i đạ ế ố ứ ể ấ ấ ặ ế ố ể

các máy n i b upload file log h th ng lên server, …). Do v y, đ cóộ ộ ệ ố ậ ể

th b o v đ c c ph n IP Header ch a thông tin đ u cu i c aể ả ệ ượ ả ầ ứ ầ ố ủ

thi t b , ta ph i s d ng tunnel mode, trong tunnel mode, giao th cế ị ả ử ụ ứ

ESP đ c s d ng ph bi n h n do tính t ng thích v i d ch v NATượ ử ụ ổ ế ơ ươ ớ ị ụ

c a nó.ủ

D. Phase 2 Transforms :

D ng bi n đ i d li u (Data Transform) đ nh nghĩa cách mà k t n i dạ ế ổ ữ ệ ị ế ố ữ

li u đ c b o v . Cũng gi ng nh k t n i qu n lý đ c trình bày ph nệ ượ ả ệ ố ư ế ố ả ượ ở ầ

Phase 1, k t n i d li u trong ISAKMP/IKE phase 2 cũng c n ph i đ cế ố ữ ệ ầ ả ượ

đ nh nghĩa d ng c a nó nh th nào đ b o v d li u ng i dùng m tị ạ ủ ư ế ể ả ệ ữ ệ ườ ộ

cách t t nh t. D ng bi n đ i c a d li u bao g m nh ng thông tin sau:ố ấ ạ ế ổ ủ ữ ệ ồ ữ Giao th c b o m t: AH và ESP.ứ ả ậ Lo i k t n i cho giao th c b o m t: Tunnel ho c Transport Mode.ạ ế ố ứ ả ậ ặ Thông tin mã hóa (ch riêng v i ESP): DES, 3DES, AES-128.AES-192,ỉ ớ

AES-256 ho c không dùng thu t toán mã hóa nào.ặ ậ Các hàm HMAC đ ch ng th c: MD5 ho c SHA-1 (ESP có th dùngể ứ ự ặ ể

ho c không).ặ

E. K t n i d li uế ố ữ ệ :

Đ t o đ c k t n i d li u, hai thi t b đ u cu i ph i th ng l ngể ạ ượ ế ố ữ ệ ế ị ầ ố ả ươ ượ

các ph ng th c b o m t d li u sao cho th ng nh t v i nhau. Khiươ ứ ả ậ ữ ệ ố ấ ớ

ISAKMP/IKE Phase 1 hoàn t t, hai thi t b đã có m t k t n i ấ ế ị ộ ế ố qu nả lý để

có th liên l c đ c v i nhau thông qua các thông đi p ISAKMP/IKE. Doể ạ ượ ớ ệ

đó, các thi t b sẽ dùng k t n i này đ đàm phán v i nhau trong vi cế ị ế ố ể ớ ệ

thi t l p Phase 2. M i thi t b sẽ chia s nh ng thông tin sau đây v iế ậ ỗ ế ị ẻ ữ ớ

thi t b kia:ế ị

Đ ng k t n i nào c n đ c b o v .ườ ế ố ầ ượ ả ệ Danh sách các thông tin Data Transform c n đ b o v đ ngầ ể ả ệ ườ

đó, ch ng h n nh giao th c b o m t, hàm HMAC, thu t toán mãẳ ạ ư ứ ả ậ ậ

hóa, …

Đ a ch IP đ c s d ng IP Header ngoài cùng c a gói tin.ị ỉ ượ ử ụ ở ủ Th i gian s ng tính theo giây hay KBs.ờ ố

Ta hãy xem m t ví d sau ộ ụ đây, có 2 thi t b IPsecA và IPsecB, m i thi tế ị ỗ ế

b l i có m t Transform khác nhau. ị ạ ộIPsecA có các thông tin sau đây:

1. Transform 1A: AH v i MD5, ESP v i AES-256, tunnel mode.ớ ớ2. Transform 2A: ESP v i MD5, ESP v i AES-128, tunnel mode.ớ ớ

IPsecB có các thông tin sau đây:

1. Transform 1B: ESP v i MD5, ESP v i AES-128, tunnel mode.ớ ớ2. Transform 2B: ESP v i MD5, ESP v i 3DES, tunnel mode.ớ ớ

Các Transform đó sẽ l n l t đ c so sánh v i nhau cho t i khi chúngầ ượ ượ ớ ớ

gi ng nhau hoàn toàn. M t k t n i d li u sẽ đ c t o ra. Ta l u ý r ngố ộ ế ố ữ ệ ượ ạ ư ằ

đ i v i m t s nhà cung c p thi t b , th i gian s ng c a 2 thi t b thìố ớ ộ ố ấ ế ị ờ ố ủ ế ị

không c n thi t ph i gi ng nhau, chúng sẽ t đ ng ch n giá tr lifetimeầ ế ả ố ự ộ ọ ị

nh nh t.ỏ ấ

V. IPSEC OVER TCP/UDP :

A. Vấn đề chuyển đổi địa chỉ trong IP Sec:

Ph n này nghiên c u v v n đ chuy n đ i đ a ch trong IPsec.ầ ứ ề ấ ề ể ổ ị ỉV n đ chuy n đ i đ a ch là m t trong hai v n đ quan tr ng c nấ ề ể ổ ị ỉ ộ ấ ề ọ ầ

ph i đ c gi i quy t trong đ ng truy n IPsec bên c nh v n đả ượ ả ế ườ ề ạ ấ ề

Firewall.

Nh ta đã bi t có hai lo i k t n i trong IPsec là k t n i qu n lýư ế ạ ế ố ế ố ả

(management connection) và k t n i d li u (data connection). ế ố ữ ệ Nh ngữ

thi t b th c hi n vi c chuy n đ i đ a ch không gây ra v n đ gì choế ị ự ệ ệ ể ổ ị ỉ ấ ề

k t n i qu n lý, nh ng đ i v i k t n i d ế ố ả ư ố ớ ế ố ữ li uệ thì ng c l i. Tr ngượ ạ ườ

h p ngo i l là tr c đây m t s thi t b s d ng PAT sẽ bu c t t cợ ạ ệ ướ ộ ố ế ị ử ụ ộ ấ ả

k t n i qu n lý ph i s d ng giao th c UDP v i port 500 cho c ngu nế ố ả ả ử ụ ứ ớ ả ồ

và đích, gây ra m t s v n đ n u ta s d ng nhi u k t n i song songộ ố ấ ề ế ử ụ ề ế ố

cùng lúc thông qua thi t b PAT; nh vi c c i ti n công ngh nên cácế ị ờ ệ ả ế ệ

thi t b hi n nay đ u đã kh c ph c đ c v n đ này. Sau đây ta sẽế ị ệ ề ắ ụ ượ ấ ề

xem nh h ng c a vi c chuy n đ i đ a ch v i vi c k t n i d li uả ưở ủ ệ ể ổ ị ỉ ớ ệ ế ố ữ ệ

trong IPsec.

Nh đã đ c p trong ph n “ISAKMP/IKE giai đo n 2”, AH hoàn toànư ề ậ ầ ạ

không ho t đ ng khi vi c chuy n đ i đ a ch đ c th c hi n trên m tạ ộ ệ ể ổ ị ỉ ượ ự ệ ộ

gói tin AH. C PAT và NAT đ u không h tr truy n gói tin có ch a AHả ề ỗ ợ ề ứ

này. Đ i v i NAT, nó sẽ th c hi n vi c chuy n đ i đ a ch IP c a ngu nố ớ ự ệ ệ ể ổ ị ỉ ủ ồ

và đích, trong khi gói tin AH ch a các giá tr hàm băm c a h u h t cácứ ị ủ ầ ế

tr ng trong gói tin IP ban đ u ph c v cho vi c b o m t ho c ch ngườ ầ ụ ụ ệ ả ậ ặ ứ

th c. Đ i v i PAT, do AH là giao th c l p 3 nên nó sẽ không thêm ph nự ố ớ ứ ớ ầ

TCP/UCP Header mà PAT c n nên AH không th t ng thích v i PAT.ầ ể ươ ớ

Sau đây ta sẽ ch ng minh rõ h n ph n này d a vào hình vẽ.ứ ơ ầ ựTa s d ng tunnel ử ụ mode vì đây là mode m c đ nh cũng nh nóặ ị ư

t ng ng v i vi c các thi t b trung gian chính là các thi t b th cươ ứ ớ ệ ế ị ế ị ự

hi n NAT ho c PAT.ệ ặ

IPsec Tunnel Mode (Ngu n:ồ

http://www.firewall.cx/networking-topics/protocols/870-IPsec-

modes.html )

Đ i v i giao th c AH. Gói tin c a nó sẽ có c u trúc nh sau:ố ớ ứ ủ ấ ư

C u trúc gói tin AH (Ngu n: ấ ồhttp://www.firewall.cx/networking-topics/protocols/870-IPsec-

modes.html )

Ta th y r ng t t c các ph n bao g m gói tin IP ban đ u (t c là c aấ ằ ấ ả ầ ồ ầ ứ ủ

thi t b đ u cu i th c s ) và ph n IP Header m i đ c g n vào đ uế ị ầ ố ự ự ầ ớ ượ ắ ề

đ c “signed by AH”. T c là AH Header sẽ ch a mã đ c sinh ra tượ ứ ứ ượ ừ

m t hàm băm ph c v cho vi c ch ng th c d li u t i thi t b nh n.ộ ụ ụ ệ ứ ự ữ ệ ạ ế ị ậ

Mã băm này đ c sinh ra t các thành ph n gói IP ban đ u và IPượ ừ ầ ầ

Header m i. Ta quan sát hình sau đ hi u rõ h n v c ch này.ớ ể ể ơ ề ơ ế

Quá trình t o AH Header (Input bao g m gói IP ban đ u và IP Header ạ ồ ầm i, secret key đã ớ đ cượ chia s tr c đó thông qua k t n i qu n lý) ẻ ướ ế ố ả(Ngu n: ồ http://www.unixwiz.net/techtips/iguide-IPsec.html )

T i đ u thu, thi t b đích cũng sẽ t o ra m t mã băm v i input là cácạ ầ ế ị ạ ộ ớ

thông tin nh các thông tin đ c t o mã băm đ u thu. Sau đó, nó soư ượ ạ ở ầ

sánh v i mã băm nh n đ c n m trong AH Header (ICV). N u gi ngớ ậ ượ ằ ế ố

nhau, d li u đ c ch ng th c toàn v n, ng c ữ ệ ượ ứ ự ẹ ượ l iạ , d li u đ c coi làữ ệ ượ

không toàn v n.ẹ

Ph n trên là nh ng công đo n m c đ nh c a giao th c AH. Tuyầ ữ ạ ặ ị ủ ứ

nhiên, khi ta s d ng d ch v NAT, m i chuy n sẽ khác. Ta đ ý r ngử ụ ị ụ ọ ệ ể ằ

c IP Header m i cũng đ c bao g m trong quá trình tính toán AHả ớ ượ ồ

Header. B c ti p theo, NAT đ c th c hi n trên gói tin ướ ế ượ ự ệ này, nó sẽ

thay đ i đ a ch IP đ u và cu i trong IP Header m i trong khi ph n AHổ ị ỉ ầ ố ớ ầ

Header v n không b thay đ i. Đúng nh b c ti p theo, khi gói tinẫ ị ổ ư ướ ế

đ c thi t b thu nh n đ c, nó sẽ t o mã băm và so sánh v i mã bămượ ế ị ậ ượ ạ ớ

nh n đ c n m trong AH Header. Lúc này, hai mã băm sẽ không gi ngậ ượ ằ ố

nhau, gói tin sẽ đ c xem là gi m o và b drop ngay l p t c.ượ ả ạ ị ậ ứTi p t c v i PAT, PAT c n thay đ i s port trên TCP/UDP Headerế ụ ớ ầ ổ ố

c a gói tin. Tuy nhiên, AH là m t giao th c l p 3, ph n TCP/UDPủ ộ ứ ớ ầ

Header th c hi n l p 4 đ i v i AH đã đ c coi nh là d li u ng iự ệ ở ớ ố ớ ượ ư ữ ệ ườ

dùng, vì v y gói tin coi nh không có TCP/UDP Header và PAT khôngậ ư

th th c hi n đ c nhi m v c a nó.ể ự ệ ượ ệ ụ ủĐ i v i giao th c ố ớ ứ ESP, gói tin c a nó có c u trúc nh sau:ủ ấ ư

C u trúc gói tin ESP (Ngu n:ấ ồ

http://www.firewall.cx/networking-topics/protocols/870-IPsec-

modes.html )

Các b c di n ra vi c ch ng th c gi ng h t nh giao th c AH. Tuyướ ễ ệ ứ ự ố ệ ư ứ

nhiên, ph n IP Header m i ầ ớ không đ c “signed by ESP Auth Trailer”,ượ

nó không bao g m trong khi tính toán ICV, ch ESP Header (và c ESPồ ỉ ả

trailer n u có) và d li u ng i dùng (gói IP ban đ u) là đ c bao g mế ữ ệ ườ ầ ượ ồ

trong tính toán ICV mà thôi, và do đó ESP hoàn toàn t ng thích v iươ ớ

NAT.

Tuy nhiên, cũng v i ớ m tộ lý do gi ng nh AH, ESP cũng không t ngố ư ươ

thích v i PAT.ớ

B. Giải quyết vấn đề chuyển đổi địa chỉ trong IP Sec:

Có nhi u gi i pháp đã đ c đ xu t đ gi i quy t v n đ chuy nề ả ượ ề ấ ể ả ế ấ ề ể

đ i đ a ch trong IPsec. M t trong nh ng ph ng pháp ph bi n nh tổ ị ỉ ộ ữ ươ ổ ế ấ

đó là luôn s d ng giao th c đóng gói ESP thay vì s d ng AH. Nhử ụ ứ ử ụ ư

ph n trên ta đã bi t r ng ESP thì ho t đ ng v i NAT, nh ng khôngầ ế ằ ạ ộ ớ ư

ho t đ ng v i PAT. Do đó v n đ c a chúng ta là làm sao đ ESP ho tạ ộ ớ ấ ề ủ ể ạ

đ ng đ c v i nh ng thi t b th c hi n PAT.ộ ượ ớ ữ ế ị ự ệ

Nhi u gi i pháp đã đ c đ xu t ề ả ượ ề ấ trong đó có NAT-T cũng là m t trongộ

nh ng cách ph bi n (Ngu n: The Complete Cisco VPN Configuration Guideữ ổ ế ồ

– Richard Deal)

Đ làm đ c đi u này, ng i ta sẽ chèn m t ph n Header TCP ho cể ượ ề ườ ộ ầ ặ

UDP gi a ph n IP Header bên ngoài và ph n ESP gi ng nh hình sauữ ầ ầ ố ư

đây:

Gi i quy t v n đ chuy n đ i đ a ch trong IPsec (Ngu n: The Completeả ế ấ ề ể ổ ị ỉ ồ

Cisco VPN Configuration Guide – Richard Deal)

Do ph n TCP/UDP Header này thu c ph n Header bên ngoài nên nóầ ộ ầ

sẽ không bao g m trong quá trình tính toán mã băm đ t o ch ký s .ồ ể ạ ữ ố

Đ i v i IPsec over UDP, m t UDP Header chu n luôn luôn đ cố ớ ộ ẩ ượ

chèn vào gi a ph n IP Header bên ngoài và ph n ESP Header. Vi c nàyữ ầ ầ ệ

giúp ESP gi i quy t v n đ v i PAT. Tuy nhiên nó m c m t khuy tả ế ấ ề ớ ắ ộ ế

đi m, đó là thi t b luôn luôn th c hi n vi c chèn này c trong tr ngể ế ị ự ệ ệ ả ườ

h p không có thi t b chuy n đ i đ a ch nào gi a hai đ u cu i, lúc nàyợ ế ị ể ổ ị ỉ ữ ầ ố

ph n UDP Header tr nên d th a.ầ ở ư ừ

(Ngu n: wikipedia)ồ

Đ i v i IPsec over TCP, m t Header TCP sẽ đ c chèn vào gi aố ớ ộ ượ ữ

ph n IP Header bên ngoài và ph n ESP Header. Tuy nhiên, nh c đi mầ ầ ượ ể

c a lo i này so v i IPsec over UDP là ph n TCP Header ch a nhi uủ ạ ớ ầ ứ ề

bytes h n UDP Header. Cũng vì nh c đi m đó nên TCP header th ngơ ượ ể ườ

đ c ít s d ng h n so v i UDP header.ượ ử ụ ơ ớ

(Ngu n: wikipedia)ồ

L u ý:ư đ bi t đ c s t n t i c a NAT gi a hai hosts trong m tể ế ượ ự ồ ạ ủ ữ ộ

m ng nào đó, IPsec có c ch nh sau: ạ ơ ế ư hai thi t b sẽ g i thông tin c aế ị ử ủ

đ a ch IP (ngu n và đích) và các s port cũng v i mã băm c a các thôngị ỉ ồ ố ớ ủ

tin đó cho nhau, n u c hai thi t b đó tính toán mã băm và thu đ cế ả ế ị ượ

cùng k t qu v i mã băm nh n đ c, chúng sẽ bi t là không có NAT ế ả ớ ậ ượ ế ở

gi a. Ng c l i, n u mã băm không gi ng nhau, t c là đã có s thay đ iữ ượ ạ ế ố ứ ự ổ

đ a ch IP ho c s port, khi đó hai thi t b ph i th c hi n đóng gói góiị ỉ ặ ố ế ị ả ự ệ

tin trong UDP ho c TCP Header đ có th s d ng đ c IPsec.ặ ể ể ử ụ ượ

Sau khi chèn ph n TCP/UDP Header vào gói tin, m t s thông tinầ ộ ố

c a gói tin có th b thay đ i, do đó b c đóng gói hoàn ch nh c a IPsecủ ể ị ổ ướ ỉ ủ

over UDP ph i nh sau:ả ư

1) Th c hi n quá trình đóng gói ESP.ự ệ2) Chèn m t UDP Header đã đ c đ nh chu n m t cách h p lý vàoộ ượ ị ẩ ộ ợ

gói tin.

3) Đi u ch nh l i các tr ng Total Length, Protocol và Headerề ỉ ạ ườ

Checksum (đ i v i Ipv4) trong ph n IP Header m i làm sao choố ớ ầ ớ

đúng v i gói IP m i đ c t o ra.ớ ớ ượ ạ

T ng t , quá trình gi i gói cũng đ c th c hi n theo t ng b cươ ự ả ượ ự ệ ừ ướ

sau đây:

1) Lo i b ph n UDP Header kh i gói tin.ạ ỏ ầ ỏ2) Th c hi n quá trình gi i gói ESP (bao g m vi c ch ng th c, …)ự ệ ả ồ ệ ứ ự3) Th c hi n quá trình NAT trong tunnel mode đ tr v gói tin IPự ệ ể ả ề

g c ban đ u.ố ầ

VI. TÀI LIỆU THAM KHẢO:

1) The Complete Cisco VPN Configuration Guide – Richard Deal

2) http://www.tcpipguide.com/free/

t_IPsecEncapsulatingSecurityPayloadESP-4.htm

3) http://technet.microsoft.com/en-us/library/cc959510.aspx

4) http://www.firewall.cx/networking-topics/protocols/870-IPsec-

modes.html

5) http://www.unixwiz.net/techtips/iguide-IPsec.html