Quá trình chuyển tiếp các gói tin tới địa chỉ CoA được thực hiện bằng cơ
chế đóng gói. Các HA và FA phải có khả năng sử dụng một cơ chếđóng gói ngầm
định IP trong IP. Ngoài ra, còn có các cơ chế đóng gói khác nhưĐóng gói tối thiểu
a) Đóng gói IP trong IP
Hình 26: Đóng gói IP trong IP
Mobile IP xem xét việc đóng gói là cách chung nhất để chuyển các khối từ
một Home Network của MN đến một đại lý. Trong phương pháp đóng gói IP trong IP có một số hạn chế như sau :
- không giải quyết được vấn đề an toàn trong việc sử dụng các tuỳ chọn IP source routing.
- có nhiều node di động Internet xử lý tùy chọn IP source routing không hợp lệ.
- Firewall có thể loại bỏ các khối IP source-routed.
Để đóng gói khối IP sử dụng phương pháp đóng gói IP trong IP, một Outer IP Header được chèn vào trước IP Header đã tồn tại của khối như hình trên. Địa chỉ
nguồn và địa chỉđích của mào đầu gói tin Outer IP Header xác định điểm kết thúc của đường ngầm, địa chỉ đích và nguồn của mào đầu gói tin IP được đóng gói (Inner IP) chỉ ra người gửi và người nhận thực sự của gói tin. Việc đóng và mở gói tin không làm thay đổi nội dung của phần mào đầu IP phía trong ngoại trừ việc có thể trường TTL giảm đi một đơn vị.
Ý nghĩa của các trường :
- Version : 4
- IHL : Internet Header Length – là độ dài của Outer IP Header có giới hạn 32 bit từ khoá.
- TOS : Type of Service – là một bản sao từ một Inner IP Header
- Total Length: được quy định là độ dài của thực thể khối IP đã được đóng gói bao gồm cả outer header, inner header và IP payload.
- Indentification, Flags, Fragment Offset,TTL : Các trường này được đặt theo qui định của phần mào đầu IP. Tuy nhiên nếu bit “Không phân mảnh” (don’t fragment) của phần mào đầu gói IP được đóng gói được đặt bằng 1 thì bit này của phần mào đầu của gói IP ngoài cũng phải được đặt bằng 1.
- Protocol 4
- Header Checksum : Phần kiểm tra tính chính xác của phần mào đầu gói IP ngoài.
- Source Address : Địa chỉ IP của điểm đóng gói gói tin IP
- Destination Address : Địa chỉ IP của điểm mở gói gói tin IP
Khi đóng gói một khối trường TTL trong Inner IP Header giảm đi một đơn vị nếu ống dẫn là một phần của việc chuyển tiếp khối, mặt khác Inner IP Header TTL không thay đổi trong quá trình đóng gói nếu giá trị TTL trong Inner IP Header
được đặt bằng 0
b) Phương pháp đóng gói Minimal Encapsulation for IP
Hình 27: Đóng gói Minimal Encapsulation for IP
IP Header
IP Payload Minimal forwarding header
IP Payload Modified IP Header
Cũng tương tự phương pháp đóng gói IP trong IP, nhưng phương pháp này sử dụng cho gói tin nhỏ hơn.
Các trường trong Modified IP Header.
Protocol 55 (Minimal Encapsulation for IP) Destination Address
Địa chỉ IP của điểm mở gói gói tin
Source address
Địa chỉ IP của điểm đóng gói gói tin
Total Length
Độ dài của toàn bộ gói tin bao gồm cả phần mào đầu thêm vào (minimal forwarding header) (chiều dài từ 8 đến 12 octet).
Hình 28: Minimal Encapsulation Header
Protocol
Được chép lại từ trường tương ứng của gói IP ban đầu.
Original Source Address Present (S)
0 Original Source Address không được dùng. Chiều dài của Minimal forwarding headder là 8 octets.
Header Checksum Protocol Resserved
Original Destination Address (if present) Original Source Address
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1 Original Source Address được sử dụng. Chiều dài của Minimal forwarding headder là 12 octets
Reserced
Được đặt bằng 0, sử dụng trong tương lai.
Header checksum
Phần kiểm tra tính chính xác của toàn bộ gói kể cả phần mào đầu được thêm vào (minimal forwarding header).
Original Destination Address
Được chép lại từđịa chỉđích của gói tin IP gốc.
Original Source Address
Được chép lại từđịa chỉ nguồn của gói tin IP gốc nếu bit S =1.
c) Phương pháp đóng gói GRE ( Generic Routing Encapsulation )
Cả hai phương pháp đóng gói đã trình bày ở trên đều có những ưu nhược
điểm cụ thể, tuy nhiên một phương pháp đóng gói khác có thể khắc phục được những nhược điểm kể trên là phương pháp đóng gói GRE. Phương pháp đóng gói GRE thực hiện tốt quá trình đóng gói gói tin của giao thức A gửi qua một giao thức B nào đó.
Delivery Header GRE Header Payload packet
Checksum Present (bit 0)
Nếu bit này bằng 1 thì các trường Checksum và Reserved1 chứa thông tin và ngược lại.
Reserved 0
Bên nhận sẽ huỷ gói tin nhận được nếu các bit từ 1-5 của trường này khác 0 (trừ khi bên nhận tuân theo RFC 1701 khuyến nghị về GRE trước đây ). Các bit từ 6 - 12 được đặt bằng 0 và để dùng trong tương lai.
Version Number
Giá trị bằng 0.
Protocol type
Trường này chứa giá trị xác định giao thức được sử dụng của gói tin trong phần tải tin (payload).
Checksum
Giá trị 16 bit là kết quả của việc cộng modulo 2 các đơn vị 16 bit của GRE header và phần tải tin. Giá trị của Checksum khi đưa vào tính bằng 0.
Reserved1 Đang nghiên cứu 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Protocol Type Reserved0 Ver C
2.8. Kết luận chương
Mobile IP là một chuẩn định nghĩa bởi IETF. Mobile IP cho phép người dùng giữ nguyên địa chỉ IP trong khi vẫn giữ kết nối và duy trì các ứng dụng trong khi di chuyển giữa các mạng IP. Mobile IP đã giúp loại bỏ việc ngắt kết nối, và kết nối lại khi điểm kết nối vào mạng thay đổi.
Chương 3 GIẢI PHÁP BẢO MẬT CHO MOBILE IP
3.1. Nguy cơ an ninh và bảo mật trong Mobile IP
3.1.1. Các yêu cầu bảo mật thông tin trên mạng
Các mục tiêu chính của bảo mật thông tin trong mạng bao gồm:
- Bí mật dữ liệu (Data confidentiality): chỉ cho phép những người có quyền mới được truy cập thông tin;
- Toàn vẹn dữ liệu (Data integrity): những người không được phép thì không được quyền thay đổi dữ liệu;
- Xác thực (Authentication): đảm bảo định danh của đích cũng như xuất xứ của thông tin;
- Nhất quán (Non-repudiation): một thực thể không thể tùy ý phủ nhận việc gửi đi một gói tin hợp lệ do thực thểđó gửi đi;
- Kiểm soát truy cập (Access control): những người không có quyền không thể truy cập các tài nguyên;
- Tính sẵn sàng và hoạt động đúng của dịch vụ (Availability and correct functioning of services): thông tin luôn sẵn sàng cho những người dùng hợp lệ khi người dùng cần tới.
3.1.2. Các nguy cơ với bảo mật của Mobile IP
Môi trường điện toán di động về tiềm năng là rất khác biệt so với môi trường điện toán truyền thống. Trong hầu hết trường hợp, các máy tính di động sẽ
kết nối với mạng thông qua các liên kết không dây. Các liên kết trong môi trường không dây là dễ bị tổn thương bởi việc nghe lén thụđộng (eavesdropping), tấn công replay chủđộng (active replay attack) và các kiểu tấn công chủđộng khác.
Bên cạnh các nguy cơ của kết nối không dây (không xét tới trong luận văn này như: nghe lén - eavesdropping, truy cập trái phép – unauthorized access, các kiểu tấn công trên tầng MAC…) các vấn đề và nguy cơ về bảo mật do đặc thù của Mobile IP bao gồm:
- Định hướng lại (redirection): trong cơ chế hoạt động của Mobile IP có sự định hướng lại gói tin từ HA tới MN khi MN không ở mạng thường trú. Do dó, các định hướng giả mạo lại gói tin là một nguy cơ
an ninh chính của Mobile IP. Xác thực giữa MN và HA của Mobile IP
đã cung cấp một cơ chế cơ bản để tránh kiểu tấn công này.
- Các thông điệp ARP (Addresss Resolution Protocol): không được xác thực có thể bị lợi dụng để đánh cắp dữ liệu của một trạm khác. Việc sử dụng ARP trong Mobile IP sẽ chứa đựng nguy cơ đó, các trạm không có quyền vẫn có thể sử dụng ARP để tiến hành tấn công giả
mạo (masquerading attack). Hiện tại chưa có giải pháp nào để cung cấp ARP một cách bảo mật. Tuy nhiên, đây là một vấn đề của tầng liên kết dữ liệu và cần được khắc phục ở tầng liên kết dữ liệu chứ
không phải Mobile IP.
- Xác thực (authentication): bên nhận một thông điệp phải có khả năng xác định xuất xứ của thông điệp đó. Do đó, các thủ tục xác thực giữa MA và MN là một chức năng cần có. Tuy nhiên, kỹ thuật xác thực trong Mobile IPv4 giữa MN và FA chưa đủ tin cậy [21]
- Mobile IP không đưa ra yêu cầu xác thực các thông điệp quảng bá (Agent Advertisement) của HA, FA cũng như thông điệp mời quảng bá (Agent Solicitation) của MN. Do đó, một FA giả mạo có thể gửi một quảng bá để nhận được từ MN một yêu cầu đăng ký mới và chưa
được sử dụng. FA giả mạo này sau đó có thể dùng dữ liệu đó để thực hiện các tấn công đối với HA như tấn công từ chối dịch vụ (DoS – Denial-of-Service) hay nghe trộm (man-in-the-middle).
- Tuy Mobile IP chỉ ra rằng một thông điệp quảng bá từ một FA mới không nên tác động để một MN tiến hành đăng ký mới nếu nhưđăng ký hiện tại của MN chưa hết hạn và vẫn đang nhận quảng bá từ FA mà MN đã đăng ký. Nhưng một FA giả mạo vẫn có thể khiến các MN
đang yêu cầu FA mới hoặc các MN đã mất kết nối với FA trước đó. - Lọc đầu vào (Ingress Filtering): Các bộđịnh tuyến ngoại biên của các
nhà cung cấp dịch vụ (ISP) hay của một mạng ngoài có thể bỏ qua các gói tin chứa địa chỉ IP nguồn không thuộc mạng đó. Vấn đề này được gọi là lọc đầu vào. Trong Mobile IP, các MN đang ở mạng ngoài – nhưđang ở một mạng của ISP khác - sử dụng địa chỉ IP gốc của MN sẽ dẫn tới gói tin sẽ bị thiết bịđịnh tuyến bỏ qua.
- Thêm váo các nguy cơ, Mobile IP không chỉ ra phương thức để đảm bảo tính bí mật (confidentiality) và tính toàn vẹn (integrity).
- Mobile IP chưa đưa ra môt cơ chế quản lý khóa. Do đó việc quản lý khóa thủ công trong trường hợp mạng lớn, phức tạp với nhiều nút di
động có thể là một nguy cơ.
Các công nghệ mạng trong tương lai cần hỗ trợ nhiều hơn nữa các dịch vụ
bảo mật. Trong đó, tính toàn vẹn và bí mật thông tin đầu – cuối (end-to-end integrity and confidentiality) là một vấn đề quan trọng. Tuy nhiên, các mạng thông tin di động hiện tại chưa hỗ trợđầy đủ tính bí mật và toàn vẹn thông tin.
3.1.3. Các giải pháp bảo mật cho Mobile IP
Qua phân tích các nguy cơ, các giải pháp bảo mật cho Mobile IP bao gồm: - Giải pháp chống tấn công trong giao thức Mobile IP: Đây là giải pháp
chống replay bằng nhãn thời gian và nonce được đưa ra trong chuẩn giao thức Mobile IP [2] .
- Giải pháp xác thực trong Mobile IP: các gói tin trong Mobile IP được xác thực thông qua mở rộng của các gói tin Mobile IP[2] ; xác thực
theo giao thức yêu cầu/đáp ứng (challenge/response[5] ; xác thực với khóa công khai [14] ; hoặc xác thực với khóa công khai tối thiểu [22] .
- Giải pháp kết hợp xác thực, kiểm soát, tính phí và quản lý khóa thông qua kiến trúc AAA (authentication, authorization, and accounting) [6] , [20] , [7]
- Giải pháp tránh xung đột với với hệ thống tường lửa có chức năng lọc đầu vào (Ingress Filtering) bằng định hướng nghịch (reverse tunnneling) [11] .
- Giải pháp bổ sung vào các hệ thống tương lửa (firewall) nhằm hỗ trợ Mobile IP: ngoài chức năng vốn dĩ của firewall sẽ giúp nâng cao tính sẵn sàng của hệ thống tránh các tấn công, việc bổ sung thêm chức năng hỗ trợ Mobile IP sẽ giúp các hệ thống tường lửa đảm bảo tính hoạt động đúng đắn với Mobile IP của các hệ thống mạng được bảo vệ [12] .
- Giải pháp bảo mật dữ liệu với IPsec: Đây là giải pháp đảm bảo tính bí mật của thông tin và toàn vẹn dữ liệu trong quá trình truyền đi trên mạng.
Từng giải pháp trên sẽđược trình bày trong từng phần dưới đây.
3.2. Chống tấn công replay trong Mobile IP
Trường định danh (Identification) trong thông điệp đăng ký của MN với HA để HA có thể kiểm tra rằng một thông điệp đăng ký mới được gửi đi bởi MN mà không phải là một thông điệp tấn công replay lợi dụng được từ một lần đăng ký trước đó. Có hai phương pháp để chống tấn công replay được đưa ra trong chuẩn giao thức Mobile IP: sử dụng nhãn thời gian (bắt buộc) và sử dụng nonce (tùy chọn). Theo chuẩn giao thức Mobile IP [2] , tất cả các MN và HA đều phải cài đặt
cơ chế chống tấn công replay sử dụng nhãn thời gian. MN (bắt buộc); và HA cũng có thể cài đặt cơ chế chống tấn công replay dựa trên nonce (tùy chọn).
Cách thức chống tấn công replay trong cài đặt cụ thể giữa một MN và HA tương ứng là một phần của thiết lập bảo mật giữa MN và HA. Theo đó, MN và HA sẽ thống nhất phương thức chống tấn công replay được sử dụng. Cách hiểu trường
định danh trong thông điệp đăng ký sẽ phụ thuộc vào phương thức chống replay cụ
thể.
Cho dù phương pháp chống replay nào được sử dụng thì 32bit thấp trong trường định danh phải được sao nguyên vẹn từ yêu cầu đăng ký sang trả lời đăng ký. FA sử dụng các bit đó (và địa chỉ gốc của MN) để khớp các yêu cầu đăng ký với các trả lời tương ứng. MN phải kiểm tra rằng 32bit của mọi trả lời đăng ký là khớp với 32 bit mà MN đã gửi trong yêu cầu đăng ký.
Trường định danh trong một yêu cầu đăng ký mới phải không giống một yêu cầu ngay trước đó. Trường định danh cũng không nên được sử dụng lại khi một ngữ cảnh bảo mật vẫn đang được dùng giữa MN và HA.
3.2.1. Chống tấn công replay bằng nhãn thời gian
Nguyên lý cơ bản của biện pháp chống tấn công bằng nhãn thời gian (timestamp) là một nút tạo một thông điệp sẽ chèn thời gian hiện tại; nút nhận được thông điệp kiểm tra nhãn thời gian đảm bảo rằng thời gian đó tương đối gần với ngày giờ của chính MN. Trừ khi được chỉ ra khác đi trong ngữ cảnh bảo mật cho nút, giá trị ngầm định là 7 giây – được sử dụng để giới hạn sự khác nhau về thời gian. Giá trị này cần lớn hơn 3 giây. Giải pháp này hiển nhiên chỉ khả thi khi hai nút tham gia có đồng hồđồng bộ.
Theo phương thức sử dụng nhãn thời gian thì MN sẽ phải thiết lập giá trị định danh của thông điệp đăng ký theo khuôn dạng 64 bit của giao thức NTP (Network Time Protocol). Trong đó, 32 bit thấp của khuông dạng NTP biểu thị
phần phân của thời gian tính theo giây, nếu các bit này không nhận được từ các nguồn thời gian thì chúng cần được sinh từ các nguồn ngẫu nhiên. Lưu ý rằng, khi
sử dụng nhãn thời gian cho trường định danh 64 bit trong thông điệp yêu cầu đăng ký của MN tới HA, trường định danh đó phải có giá trị lớn hơn giá trị trường định danh đã sử dụng trong các yêu cầu đăng ký trước đó bởi HA cũng sử dụng trường này như là số thứ tự (sequence number). Nếu không có số thứ tự, một bản yêu cầu
đăng ký bị trễ của một đăng ký trước đó có thể tới HA và sẽ được xử lý một cách nhầm lẫn, gây ra thay đổi trong địa chỉ COA đã đăng ký của MN.
Khi nhận được một thông điệp yêu cầu đăng ký có mở rộng xác thực, HA sẽ phải kiểm tra tính xác thực của trường định danh. Để đảm bảo tính đúng đắn, nhãn thời gian trong trường định danh phải có độ lệch với thời gian của HA trong khoảng giá trị cho phép; đồng thời nhãn thời gian đó phải lớn hơn tất cả các nhãn thời gian đã được chấp nhận của cùng MN đó.
Nếu nhãn thời gian là hợp lệ, HA sẽ chép toàn bộ trường định danh vào thông điệp trả lời đăng ký (registration reply) để trả lời MN. Nếu nhãn thời gian không hợp lệ, HA sẽ chỉ chép 32 bit thấp sang thông điệp trả lời yêu cầu và cung