kết nối quản lý:dulieu.tailieuhoctap.vn/.../file_goc_774463.docx · web viewthông qua kết...
TRANSCRIPT
Đ 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