Luận văn Mobile IP& 4G

hập nào, bao gồm cả các mạng hữu tuyến (PSTN, ISDN, ETHERNET, XDSL,…) và các mạng vô tuyến (WLAN, GPRS, UMTS,…). Hình 3.1: Vị trí của Mobile IP Mobile IP là một giải pháp di động lớp 3 (lớp mạng). bằng cách sử dụng Mobile IP, mọi ứng dụng dựa trên TCP/IP sẽ được giữ nguyên. chỉ các lớp giao thức ip và thấp hơn nhận biết được về sự di động. các lớp giao thức cao hơn (TCP, UDP, RTP,…) không phát hiện thấy sự di động. Nhược điểm của Mobile Ipv4 khi dùng trong 4G đã được trình bầy trong chương 1 đó là: vấn đề thiếu địa chỉ, vấn đề với NAT, vấn đề với FA, hiện tượng “triangular routing”. Với Mobile Ipv6 sử dụng địa chỉ 128 bit thay cho địa chỉ 32bit của Ipv4, tạo ra số lượng địa chỉ lớn, nên không chỉ cho phép nhiều nút mạng hơn kết nối với mạng mà còn cho phép một giao diện có thể có nhiều hơn một địa chỉ sử dụng cho các quy mô mạng khác nhau. Do đó Mobile Ipv6 có một số cải tiến như: mobile ip token ring gtp ppp wlan 802.11b bluetooth tcp udp network applications and protocols tính di động là trong suốt với các lớp này .... ethernet lớp liên kết dữ liệu có thể là bất cứ giao thức nào 46 không còn khái niệm FA, MN luôn được gán địa chỉ CoA duy nhất trên mạng khách; MN sử dụng địa chỉ CoA làm địa chỉ nguồn trong phần mào đầu của gói tin gửi đi, các gói tin gửi đến MN bằng cách sử dụng tiêu đề định tuyến trong gói tin Ipv6 thay vì sử dụng cách đóng gói vào một gói tin IP khác như trước đây [5]. Ta có thể mô tả vị trí của Mobile IP trong mạng GPRS và mạng WCDMA như sau: Hình 3.2: Mobile IP trong mạng GPRS Hình 3.3: Mobile IP trong mạng WCDMA 3.2 Quản lý di động tại tầng mạng Mạng 4G là mạng di động không dây vì vậy chức năng hỗ trợ việc truyền thông tin di động là quan tâm hàng đầu khi phát triển mạng, trong đó quản lý di động là thành phần quan trọng nhất, qua đó đặc tính “mọi lúc”, “mọi nơi” được thực hiện. Việc quản lý di động có thể thực hiện ở nhiều tầng của mô hình OSI như tầng liên kết dữ liệu, dịch vụ, mạng nhưng quản lý di động tại tầng mạng là quan trọng. Nhiệm vụ của tầng mạng là làm thế nào để có thể dịch chuyển các gói tin đến đích, thực hiện quản lý di động tại tầng này là đảm bảo các kết nối ở các tầng trên vẫn có thể duy trì một cách liên tục. Nói đến quản lý di động tại tầng mạng thường chia làm 2 loại quản lý, ứng với mỗi loại sẽ có những giải pháp phù hợp: 47 - Macromobility: Macromobility là sự di động trong một khu vực rộng. Các giao thức chuyển giao Macromobility bao gồm: các hỗ trợ di động và các cơ chế đăng ký địa chỉ liên kết cần thiết khi mà node di động (Mobile Node - viết tắt là MN) chuyển động giữa các IP domain khác nhau. Ngoài ra, có thể hiểu Macromobility là sự di động giữa các Mạng truy cập (Access Network - viết tắt là AN) khác nhau. Ví dụ: chuyển giao giữa các WLAN khác nhau. - Micromobility: Micromobility là sự di động trong một khu vực có phạm vi hẹp, thường có nghĩa trong phạm vi một IP domain, một AD. Vì vậy, các giao thức chuyển giao Micromobility không gây ra tác động đến toàn bộ hệ thống mà chỉ ảnh hưởng trong phạm vi một AD. Ví dụ: chuyển giao giữa các trạm cơ sở trong cùng một WLAN Việc phân chia này để thực hiện việc phân cấp chuyển giao trong hệ thống, qua đó làm tăng hiệu năng của toàn hệ thống. Với Macromobility việc chuyển giao sẽ xảy ra không thường xuyên, nhưng khi xảy ra thì yêu cầu nhiều chức năng được thực hiện, nhiều thành phần mạng bị ảnh hưởng, ví dụ: các MN phải được xác thực lại, địa chỉ IP, các cơ chế ưu tiên, QoS cũng phải bị thay đổi (đầu cuối các domain khác nhau sẽ có những chính sách của riêng mình). Những thay đổi này sẽ làm giảm hiệu năng làm việc của hệ thống, tăng trễ chuyển giao. Chính vì vậy, nếu chuyển giao chỉ thực hiện trong nội bộ một domain thì các giải pháp hỗ trợ cho Macromobility là không phù hợp, điều đó dẫn đến các giải pháp cho Micromobility với nền tảng dựa trên Macromobility nhưng có những cải tiến phù hợp nhằm nâng cao hiệu năng hệ thống. Hơn nữa với việc tin cậy cũng như khả năng mở rộng của hệ thống. 3.2.1 Quản lý di động tại tầng mạng: Giải pháp cho Macromobility Giải pháp cho Macromobility là sử dụng MobileIP, tổng quan về MobileIP đã được trình bầy trong chương 1, vấn đề cần quan tâm là làm sao phát hiện chuyển động trong MobileIP: phát hiện chuyển động (move detection) là tiến trình mà MN sử dụng để xác định sự thay đổi các liên kết truy cập có thể sử dụng được. Thông tin này đi cùng với chính sách chuyển giao Mobile IP để xác định khi nào MN cần khởi tạo một Chuyển giao Mobile IP. Chính sách chuyển giao Mobile IP được chia thành hai loại: reactive (phản ứng lại) và proactive (chủ động trước). Dưới đây sẽ là một số giải thuật trong hai loại này: a. Giải thuật trạng thái bền vững (Steady-State Algorithm) Trong giải thuật này, sau khi MN thiết lập một đăng ký hợp lệ với một FA, nó tiếp tục tiếp nhận các quảng cáo từ các FA khác. Tuy nhiên, MN không đăng ký với một FA mới nào đến tận khi thời gian lifetime của thông điệp quảng cáo của FA hiện tại bị hết hạn. 48 Giải thuật trạng thái bền vững tối thiểu hoá số lần đăng ký Mobile IP, bởi vì MN sẽ không gửi đăng ký tới FA mới nếu nó nghĩ rằng vẫn còn giữ liên kết nối với FA hiện tại. Vấn đề đối với giải thuật này là MN có thể đợi thời gian sống của thông điệp quảng cáo hết hiệu lực trong khi kết nối đã bị ngắt b. Giải thuật mạng mới (New network algorithm) Giải thuật này yêu cầu sử dụng trường mở rộng chiều dài tiền tố (đã mô tả ở trên). Mỗi khi nhận dược một thông điệp quảng cáo, MN sẽ sử dụng trường chiều dài tiền tố để xác định được subnet hiện tại nó đang kết nối (mạng nhà hay mạng khách). Khi MN nhận được quảng cáo về một liên kết ở một subnet khác, nó biết rằng nó đã thay đổi điểm kết nối mạng (thông qua so sánh địa chỉ mạng của subnet hiện tại-trong quảng cáo của tác tử hiện tại - với địa chỉ mạng trong quảng cáo mới), nghiã là cần phải khởi tạo một chuyển giao Mobile IP. Giải thuật mạng mới này hiệu quả hơn giải thuật trạng thái bề vững, bởi vì MN không phải đợi đến khi thời gian sống của thông điệp hết hiệu lực. Tuy nhiên nếu nhịp thời gian giữa các thông điệp quảng cáo của tác tử mới lơn hơn thời gian sống của thông điệp của tác tử cũ thì hiệu quả lại ngược lại khi so sánh với giải thuật trạng thái bền vững. c. Các báo hiệu từ trạng thái liên kết (Link-State Triggers) Chính sách chuyển giao Mobile IP được khuyến nghị là Link-State Triggers và phương pháp này có thể dược coi là reactive hoặc proactive, phụ thuộc vào hành động. Phương pháp này không được chỉ rõ trong Mobile IP bởi vì nó không thể được thực hiện ở tầng 3, nhưng có thể dựa trên thông tin đến từ tầng 2. Hơn nữa, chất lượng và số lượng của Link-State Triggers phụ thuộc vào liên kết truy cập và thiết bị. Tuy nhiên, trong khi triển khai thực tế, nhiều MN có khả năng phát hiện trạng thái liên kết hiệu quả, ví dụ, khi các cáp vật lý bị đứt hoặc khi các liên kết không dây bị đứt. Sử dụng thông tin từ tầng 2 cùng với các yêu cầu quảng cáo tác tử của Mobile IP, MN có thể xác định chuyển động nhanh hơn. Khi sử dụng các kích hoạt trạng thái liên kết một cách chủ động, MN có thể chủ động thực hiện khởi tạo chuyển giao kể cả khi liên kết đang tồn tại vẫn còn hoạt động. Trong trường hợp này chuyển giao được thực hiện ở cả tầng 2 và 3, và kết nối có thể chuyển từ giao diện kết nối này sang giao diện kết nối khác, hoặc yêu cầu giao diện phải kết nối với BS mới.Với phương pháp này không phải giao diện yêu cầu MN chuyển đổi, mà MN yêu cầu giao diện chuyển đổi. Điều này đặc biệt hữu ích trong môi trường không dâyvì ở đó MN có thể xác định được các thông tin như: độ lớn, chất lượng của tín hiệu đến từ các BS khác. 49 3.2.2 Quản lý di động tại tầng mạng: Giải pháp cho Micromobility Khi một MN thay đổi điểm kết nối mạng (Access Point) với một tần suất khá thường xuyên, thì các giải pháp IP Macromobility trở nên không hiệu quả, do sẽ xuất hiện quá nhiều thông điệp phục vụ cho quá trình đăng ký và do đó làm giảm hiệu năng hệ thống (trễ chuyển giao tăng, độ mất gói tăng,...) Chính vì những lý do trên mà các giải pháp IP Micromobility ra đời với mục đích phục vụ cho các MN với tần suất chuyển giao khá thường xuyên, và việc chuyển giao diến ra trong nội bộ một domain (một subnet), hay trong một mạng điểm truy cập (Access Network-AN), ví dụ: chuyển giao xảy ra khi MN di chuyển giữa các điểm truy cập của một WLAN. Các giải pháp IP Micromobility được khá nhiều tổ chức phát triển, dành cho cả IPv4 và IPv6, dưới đây luận văn sẽ giới thiệu những giải pháp phổ biến nhất như: giao thức Mobile IP phân cấp, giao thức chuyển giao nhanh cho Mobile IPv6, giao thức Mobile IPv6 phân cấp, cuối cùng giải pháp kết hợp giữa chuyển giao nhanh và phân cấp cho Mobile IPv6 được đề xuất. 3.2.2.1 Mobile IP phân cấp Một số khái niệm cơ bản: Gateway Foreign Agent (viết tắt GFA): là một FA được thiết lập địa chỉ IP được sử dụng để kết nối Internet. Home Registration: là quá trình đăng ký được thực hiện bởi HA và GFA. Regional Registration: là quá trình mà MN sử dụng để thực hiện đăng ký cục bộ với mạng khách, thông qua việc gửi thông điệp yêu cầu đăng ký với GFA và nhận về thông điệp trả lời đăng ký. CoA cục bộ (Local Care-of-Address - viết tắt là LcoA): địa chỉ được gán cho MN hoặc FA để phục vụ cho kết nối cục bộ trong một khu vực quản lý của một GFA. Định danh truy cập mạng (Network Access Identifier - viết tắt là NAI): NAI là định danh người sử dụng (uerID) được cung cấp bởi client trong suốt quá trình xác thực PPP. Trong Mobile IP phân cấp, NAI được sử dụng để định danh MN phục vụ cho việc xác định vị trí của MN. Cấu trúc NAI tương tự như cấu trúc của email với phần định danh người sử dụng và phần định danh vùng (user@realm). Tổng quan về Mobile IP phân cấp 50 Hình 3.4: Kiến trúc mô hình mạng Mobile IP phân cấp Mobile IP phân cấp (Hierarchical Mobile IP) còn được gọi là Mobile IP đăng ký theo khu vực (Regional Registration Mobile IP), với giao thức được mô tả như sau: Khi một MN đến mạng khách đầu tiên, MN sẽ thực hiện đăng ký với mạng nhà của mình. Với đăng ký này, HA sẽ nhận được thông tin về CoA của MN. Trong trường hợp mạng khách hỗ trợ đăng ký theo vùng (regional registration), CoA đăng ký với HA chính là CoA của GFA. GFA lưu một bản danh sách khách (víitir list) chứa thông tin về mọi MN có trong mạng khách. Vì CoA đăng ký với HA là CoA của GFA, vì vậy địa chỉ này sẽ không thay đổi khi mà MN thay đổi FA kết nối, với điều kiện các FA này thuộc về cùng một GFA. Vì thế. HA không cần phải được thông báo về sự dịch chuyển của MN trong nội bộ mạng khách. Hình 3.5: MN đăng ký với HA 筆 記 型 電 腦 筆 記 型 電 腦 Internet GFA FA1 FA FA3 HA Registration request Registration request Registration request Registration reply Registration reply Registration reply MN FA1 GFA HA 51 Hình 3.5 chỉ ra luồng thông điệp báo hiệu phục vụ cho đăng ký với mạng nhà. Sau khi quá trình đăng ký tại HA được thực hiện xong, HA sẽ coi địa chỉ GFA chính là địa chỉ CoA của MN. Hình 3.6 chỉ ra luồng thông điệp báo hiệu phục vụ cho đăng ký theo vùng. Mặc dù địa chỉ LCoA cuả MN thay đổi, HA sẽ vấn coi CoA của MN chính là CoA của GFA. Hình 3.6: MN đăng ký tại vùng hoạt động Các vấn đề cơ bản của Mobile IP phân cấp - Quảng cáo FA và GFA FA được quảng cáo thông qua các thông điệp quảng cáo tác tử. Nếu trong mạng hỗ trợ đăng ký theo vùng, thì trong quảng cáo tác tử, cờ I sẽ được thiết lập và khi đó trường CoA của thông điệp sẽ có ít nhất một địa chỉ CoA. Nếu cờ I được thiết lập và chỉ có một địa chỉ trường CoA thì đó chính là địa chỉ của GFA. Khi đó địa chỉ CoA của FA (không phải GFA) sẽ không được quảng bá và vì vậy để giúp MN xác định việc chuyển đổi giữa các vùng dịch vụ của các FA khác nhau, trường mở rộng FA-NAI (chứa NAI của FA) được thêm vào, trường này cũng được MN dùng để xác định đang ở mạng nhà hay mạng khách. Việc này được thực hiện thông qua so sánh phần định danh vùng (realm part) trong NAI của MN và phần mở rộng FA-NAI. - Đăng ký với mạng nhà: được thực hiện với cả MN, FA, GFA và HA. - Đăng ký theo vùng: Khi HA coi địa chỉ của GFA là địa chỉ CoA của MN, MN sẽ thực hiện đăng ký theo vùng đối với dịch chuyển trong một khu vực do GFA quản lý. Khi thực hiện đăng ký theo vùng, MN có thể đăng ký FCoA hoặc CCoA với GFA. Trong phần dưới đay các vấn đề được trình bày với giả sử đăng ký với mạng nhà đã được thực hiện GFA có một liên kết an ninh di động với MN. Giả sử MN di chuyển từ FA này sang FA khác trong cùng một mạng khách quản lý bởi một GFA. MN sẽ nhận được quảng cáo tác tử từ FA mới. Hơn nữa nếu quảng cáo tác tử chỉ ra rằng mạng khách hỗ trợ đăng ký theo vùng, và hoặc Registration reg req Registration reg reply Registration reg reply Registration reg req MN FA1 GFA HA 52 địa chỉ GFA được quảng cáo trùng với địa chỉ của GFA mà MN đăng ký với HA, hoặc phần định danh vùng của mở rộng FA-NAI của quảng cáo hiện thời trùng với quảng cáo trước đó, thì MN có thể thực hiện một đăng ký theo vùng với FA và GFA. MN phát ra thông điệp yêu cầu đăng ký vùng tới GFA thông qua FA. Yêu cầu này được xác thực sử dụng khoá đăng ký được phân phối cho GFA và MN từ mạng nhà và thông điệp được xác thực bởi mở rộng xác thực MN-GFA. CoA được thiết lập là FCoA của FA cục bộ, hoặc được đặt giá trị 0 nếu FA cục bộ không quảng cáo CoA của nó. Nếu yêu cầu đăng ký vùng không chứa CoA, FA sẽ thêm vào mở rộng “Hierarchical Foreign Agent” vào thông điệp và chuyển tiếp thông điệp đến GFA. Dựa trên thông tin này, GFA sẽ cập nhật địa chỉ hiệntại của MN trong danh sách khách của nó. GFA sau đó gửi lại thông điệp trả lời đăng ký vùng tới MN thông qua FA. Nếu địa chỉ của GFA trong thông điệp quảng cáo không trùng với GFA mà MN đăng ký với HA, và nếu MN vẫn còn trong vùng mà nó đăng ký địa chỉ CoA với HA, MN có thể sẽ thực hiện đăng ký theo vùng với GFA đã đăng ký. Nếu FA không hỗ trợ đăng ký theo vùng tới một GFA, FA sẽ từ chối với mã trả về với mạng nhà thông qua GFA mới. Cần thiết phải phân biệt cho MN khi nào thực hiện đăng ký theo vùng khi nào đăng ký với mạng nhà, vì trong trường hợp đầu tiên cần phải liên lạc với HA. Hơn nữa, một quá trình đăng ký mạng nhà phải được định hướng tới mạng nhà trước khi lifetime của địa chỉ CoA vùng GFA hết hạn. - An toàn: Trong Mobile IP phân cấp, các mở rộng xác thực được đưa vào trong các thông điệp để chống lại các giả mạo. Trong đó mở rộng xác thực FA-FA được sử dụng bởi FA cục bộ để đảm bảo độ tin cậy cho mở rộng “Hierarchical Foreign Agent” trong thông điệp yêu cầu đăng ký tới HA hoặc theo vùng. Sở dĩ cần có thêm mở rộng xác thực này vì trường mở rộng “Hierarchical Foreign Agent” được thêm vào sau phần đã được xác thực trước. Một mở rộng xác thực nữa là mở rộng xác thực giữa MN-GFA được sử dụng khi MN có địa chỉ CCoA. Hơn nữa, mở rộng MN-GFA được sử dụng để cung cấp xác thực cho yêu cầu đăng ký theo vùng. 3.2.2.2 Giao thức chuyển giao nhanh cho Mobile Ipv6 Giao thức chuyển giao nhanh cho Mobile IPv6 (Fast Handovers for Mobile IPv6 - viết tắt là FMIP6) là giao thức mở rộng của Mobile IPv6 với mục đích tối thiểu hoá thời gian trễ chuyển giao (handoff latency). Giao thức này phù hợp đối với các ứng dụng đòi hỏi yếu tố thời gian thực. 53 Các khái niệm cơ bản Access Router (AR): router mặc định của MN. Previous AR (PAR): router mặc định của MN trước khi xảy ra chuyển giao. New AR (NAR): router dự đoán là router mặc định của MN sau khi chuyển giao. Anchor AR (AAR): AR mà thiết lập CoA đầu tiên. Router Soliciation for Proxy (RtSolPr): thông điệp được gửi từ MN đến PAR yêu cầu thông tin cho chuyển giao có khả năng xảy ra. Proxy Router Advertisement (PrRtAdv): thông điệp từ PAR chỉ ra MN chuẩn bị chuyển giao. Fast Binding Update (FBU): thông điệp từ MN báo cho PAR chuyển hướng dữ liệu của nó đến NAR. Fast Neighbor Advertisement (FNA): thông điệp gửi từ MN đến NAR để khẳng định sử dụng CoA mới khi MN không nhận được FBACK. Handover Initiate (HI): Thông điệp từ PAR gửi tới NAR để khởi tạo chuyển giao Handover Acknowledge (HACK): Thông điệp từ NAR đến PAR trả lời cho HI. Bidirectional Tunnelv(BT): đường hầm cho cả PAR và NAR để chuyển tiếp các gói tin trao đổi với MN tại địa chỉ CoA cũ. Tổng quan về giao thức Các hoạt động chính của giao thức bao gồm thiết lập một đường liên kết giữa hai router truy cập để cho phép MN có thể gửi và nhận các gói IP khi chuyển giao xảy ra. Việc thiết lập đường hầm này có thể được “kích hoạt” bởi MN khi MN yêu cầu thực hiện chuyển giao, hoặc bởi mạng. Một khi đường hầm được thiết lập, việc chuyển tiếp gói tin trên đường hầm đến MN được bắt đầu khi PAR nhận thông điệp FBU từ MN. Vì vậy, có tất cả ba pha trong các hoạt động của giao thức: khởi tạo chuyển giao, thiết lập đường hầm vầ chuyển tiếp gói tin. Khởi tạo chuyển giao Giao thức được bắt đầu khi sự chuyển giao MN đến điểm kết nối mới xảy ra. Việc phát sinh sự kiện này có thể dựa trên các sự kiện của tầng 2 hoặc từ các chính sách xác định nhu cầu chuyển giao dựa trên các yếu tố khác như: chi phí, thay đổi băng thông,... 54 Hình 3.7: Thủ tục chuyển giao trong FMIPv6 Khi có sự kiện chuyển giao phát sinh, MN sẽ gửi thông điệp RtSoIPr đến PAR trong đó có định danh tầng liên kết dữ liệu (ví dụ ID của BS) của điểm kết nối dự định kết nối sau khi chuyển giao (NAR). PAR sẽ gửi lại thông điệp PrRtAdv, trong đó cung cấp địa chỉ tầng liên kết dữ liệu, và thông tin về mạng của NAR. Đối với chuyển giao khởi tạo mạng, PAR gửi PrRtAdv mà không cần phải tiếp nhận RtSoIPr trước đó, và cung cấp các thông số cần thiết, ví dụ: địa chỉ tầng 2 và IP của NAR để MN có thể gửi các gói tin IP, cũng như địa chỉ mạng cho MN để xác định địa chỉ CoA mới dự định. MN có thể cài định danh tầng 2 với giá trị đặc biệt 0 vào trong RtSoIPr, và PAR sẽ phản đói với một danh sách các thông số router truy cập hàng xóm tương ứng. Hơn nữa, MN được phép gửi thông điệp RtSoIPr tại bất kỳ khoảng thời gian thích hợp nào. Ví dụ, MN được phép gửi thông điệp RtSoIPr tại bất kỳ thời gian thích hợp nào. Ví dụ, MN có thể gửi thông điệp sau khi thực hiện tiến trình phát hiện router. Sự cho phép này cung cấp cho MN khả năng di chuyển tời một router hàng xóm tuỳ ý và gửi các thông điệp giao thức cần thiết để nhận và gửi các gói tin liên quan đến địa chỉ CoA tại PAR. Mục đích của RtSoIPr là yêu cầu cung cấp các thông số cần thiết (địa chỉ IP, địa chỉ tầng 2 và địa chỉ mạng của NAR) cho MN để có thể gửi các gói tin ngay lập tức khi kết nối với NAR. Mục đích của PrRtAdv là cung cấp các thông số và thông tin địa chỉ mạng cho phép MN thiết lập địa chỉ CoA mới. Thiết lập đường hầm và chuyển tiếp gói tin Đường hầm hai hướng được thiết lập giữa hai router để phục vụ mục đích: IPv6 Internet Movemen CN PRA HA 55 - Do MN không thể sử dụng CoA mới đến tận khi nó hoàn tất việc cập nhật liên kết với HA và CN, vì vậy thông qua đường hầm MN vẫn nhận được các gói tin gửi đến CoA cũ. - Khi CN đã được cập nhật liên kết với CoA mới của MN, CN có thể vẫn tiếp tục gửi gói tin đến CoA cũ, trong trường hợp PAR sẽ tạo đường hầm gửi gói tin đến NAR, rồi NAR gửi đến MN tại CoA mới. PAR không gửi trực tiếp đến CoA mới với lý do cần thiết lập cơ chế độc lập cấu hình địa chỉ với CoA mới. Tuy nhiện, MN có thể sử dụng CoA mới này trong gói tin gửi đi. Với mục đích như vậy, giao thức thực hiện như sau: Sau khi nhận thông điệp PrRtAdv, MN gửi một FBU. MN cũng có thể gửi một FBU sau khi kết nối với NAR (nếu không dự đoán được chuyển giao). Thông điệp FBU này liên kết CoA cũ của MN với địa chỉ IP của NAR để các gói tin đến PAR có thể được chuyển sang NAR theo cơ chế đường hầm. Đáp lạ, PAR gửi thông điệp HI đến NAR.. Thông điệp HI được gửi đi với hai mục đích. Thứ nhất, HI khởi tạo việc thiết lập đường hầm hai hướng giữa hai router để MN có thể tiếp tục sử dụng CoA cũ cho các phiên truyền thông đã tồn tại của nó. Thứ hai, HI được sử dụng để thẩm tra xem CoA mới (được cung cấp bởi PAR hoặc được xác định bởi NAR khi sử dụng cấu hình địa chỉ có trạng thái - stateful address configuration) đã được cung cấp cho MN, MN có thể sử dụng liên kết với NAR hay chưa. Sau khi xử lý HI, NAR thiết lập một đường liên kết cho địa chỉ CoA cũ của MN và trả lời thông qua thông điệp HACK. Sau khi nhận được thông điệp HACK, PAR gửi một FBACK đến MN. Thông điệp này khẳng định CoA mới có thể sử dụng hay không, và sau khẳng định này là có thể, MN phải sử dụng CoA mới trên liên kết mới. Ngay khi kết nối đến liên kết NAR, MN gửi một thông điệp Router Solicitation, trong đó chứa một tuỳ chọn Fast Neighbor Advertisement (FNA). FNA chứa CoA cũ của MN và các địa chỉ tầng 2, và thông qua FNA để khẳng định CoA mới khi FBACK không thể nhận được trước đó cũng như thông báo sự xuất hiện của MN tới NAR. Phúc đáp lại, NAR gửi thông điệp Router Advertisemant với lựa chọn Neighbor Advertisemant Acknowledge (NAACK) chỉ ra việc sử dụng CoA mới có được chấp nhận hay không. Thủ tục Return Routability được thực hiện để đảm bảo an toàn cho BU, nghĩa là, một CN sẽ loại bỏ các gói tin được gửi tới địa chỉ CoA mới cho đến khi bản ghi về liên kết này được thiết lập trong cache của nó. Vì thế, giao thức phải tiếp tục cho phép sử dụng địa chỉ CoA đã tồn tại trong cache của CN khi CoA mới cập nhật. Hơn nữa, việc cập nhật này, được thực hiện hết sức nhanh chóng. 56 Vì vậy, việc phối hợp sử dụng cơ chế tạo đường hầm (các gói tin liên quan đến CoA cũ) và việc dự đoán (liên quan đến CoA mới) sẽ làm tăng hiệu năng. Chuyển giao ba thành phần (Three Party Handover) MN có thể di chuyển từ NAR này sang NAR khác trước khi kết thúc chuyển giao tầng 3 của mình cũng như kết thúc cập nhật liên kết đến các CN. Nếu MN di chuyển trước khi thiết lập CoA mới tại NAR, PAR sẽ vẫn được coi là router mặc định của MN cho đến khi MN kết nối với NAR’ (kế tiếp NAR mới vừa rời khỏi). Vì vậy, MN có thể gửi FBU đến PAR để thiết lập một đường hầm giữa PAR và NAR’. Mặc khác, nếu CoA mới đã được thiết lập cho MN tại NAR, MN sé gửi các FBU đến đồng thời cả PAR và NAR để có thể tạo hai đờng hầm riêng rẽ. Nếu thay vì đến NAR’, MN lại quay về PAR, thì MN sẽ gửi FBU với lifetime được đặt giá trị 0 để PAR có thể huỷ bỏ đường hầm. Các vấn đề an ninh PAR phải đảm bảo rằng gói FBU đến từ một node sở hữu CoA cũ một cách hợp pháp . Ngược lại, một node giả mạo nào đó có thể làm cho các gói tin gửi đến MN không đến được đích và chuyển hướng chúng đến các router truy cập khác. Khi FBU được gửi trực tiếp (không qua đường hầm), cơ chế an ninh đợưc hỗ trợ bởi Neighbor Discovery. Router truy cập một liên kết an ninh. Khi một liên kết an ninh được thiết lập trước, cơ chế này sẽ phải được sử dụng để đảm bảo an ninh cho FBU. Nếu một router truy cập có thể đảm bảo địa chỉ IP nguồn trong một gói tin đến chỉ có thể được tạo ra rừ node mà địa chỉ tầng 2 của nó có trong cache “hàng xóm” của router, thì một node giả mạo không thể sử dụng địa chỉ IP chiếm dụng để chuyển hướng lưu thông. Việc đảm bảo này được thực hiện thông qua các thông điệp phát hiện “hàng xóm” bao gồm cả thông điệp RtSolPr. Khi FBU được gửi thông qua đường hầm, FBU này phải được bảo vệ bởi một liên kết an ninh thiết lập giữa node gửi FBU và PAR. Đích đến của việc chuyển hướng giao thông giả mạo bị giới hạn là một router truy cập mà với nó PAR có một liên kết an ninh. Vì lý do này, luồng dữ liệu có thể chỉ bị chuyển hướng tới địa chỉ IP của NAR, và khả năng “spam” không bị nguy ngờ” bị loại bỏ. 3.2.2.3 Mobile Ipv6 phân cấp Các khái niệm cơ bản Mobility Anchor Point (Điểm neo di động - viết tắt MAP): MAP là một router được định vị trong mạng khách. MAP được sử dụng bởi MN như là HA cục bộ. Một hoặc nhiều MAP có thể được cài đặt trong mạng khách. 57 Regional CoA (CoA khu vực - viết tắt là RCoA): RcoA là địa chỉ được gán cho MN trong mạng khách. RCoA được tự động thiết lập bởi MN khi nhận được tuỳ chọn MAP. HMIPv6-aware Mobile Node (MN có khả năng HMIPv6): Một MN có khả năng HMIPv6 là một MN có thể nhận và xử lý tuỳ chọn MAP nhận từ router mặc định của mình. MN này cũng có khả năng gửi các cập nhật liên kết cục bộ. On-link CoA (LCoA): LCoA lầ địa chỉ CoA được cấu hình cho giao diện MN dựa trên tiền tố đợc quảng bá bởi router mặc định của nó. Local Binding Update (cập nhật liên kết cục bộ): MN gửi cập nhật liên kết cục bộ tới MAP để thiết lập liên kết giữa RCoA và LCoA. Tổng quan về HMIPv6 HMIPv6 đề xuất một thành phần mới, điểm neo di động (MAP), và các mở rộng trong hoạt động của MN. CN và HA không bị tác động thay đổi trong giao thức này. Giống như Mobile IPv6, giải pháp HMIPv6 cũng độc lập với các công nghệ truy cập bên dưới, cho phép di động trong nội bộ hoặc giữa các mạng truy cập khác nhau. MN khi di chuyển đến một khu vực bao phủ dịch vụ của MAP sẽ nhận được các Router Advertisemant chứa thông tin về một hoặc nhiều MAP cục bộ. MN có thể liên kết các vị trí hiện tại của mình (on-link CoA) với địa chỉ trong subnet của MAP (RCoA). Với cơ chế hoạt động như một HA cục bộ, MAP sẽ nhận mọi gói tin đến MN và bao gói rồi chuyển tiếp chúng đến địa chỉ hiện tại của MN. Nếu MN thay đổi địa chỉ kết nối hiện tại trong nội bộ một miền MAP cục bộ (đổi địa chỉ LCoA), MN chỉ cần đăng ký địa chỉ mới với MAP. Vì vậy, chỉ có RCoA cần được đăng ký với CN và HA. RCoA không thay đổi miễn là MN vẫn nằm trong nội bộ miền MAP. Điều này làm cho sự di động của MN là trong suốt với CN mà nó đang kết nối. Các khu vực biên giới của miền MAP được xác định bởi các AR có nhiệm vụ quảng cáo thông tin MAP đến các MN liên kết với nó. Cần phải chú ý rằng HMIPv6 chẳng qua chỉ là sự mở rộng của MIPv6, vì vậy, MN có khả năng thực hiện giao thức HMIPv6 sẽ sử dụng cơ chế đợc cung cấp bởi MAP nếu mạng khách hỗ trợ, còn không nó sẽ hoạt động với giao thức MIPv6 cơ bản. Ví dụ: trong trường hợp MN hoạt động trong mạng khách nằm trong “home site”, trong trường hợp này, HA được định vị gần mạng khách và có thể được sử dụng thay cho MAP. 58 Hình 3.8: Kiến trúc mạng HMIPv6 Hình 3.8, MAP có thể trợ giúp việc di động “seamles” khi một MN dịch chuyển từ AR1 sang AR2. Các vấn đề cơ bản của HMIPv6 Giao thức HMIPv6 là một mở rộng của MIPv6, trong đó: có thêm thành phần MAP và chỉ có hoạt động của MN được mở rộng, còn các thành phần khác CN và HA hoạt động vẫn không thay đổi. Các thủ tục thực hiện bởi MN Khi MN dịch chuyển đến một miền MAP mới, MN cần phải được thiết lập với hai CoA: RCoA trên subnet của MAP và LCoA. Sau khi thiết lập RCoA dựa trên tiền tố nhận được từ tuỳ chọn MAP, MN gửi một BU cục bộ đến MAP. BU cục bộ là BU trong đó trường mở rộng Home Address chứa địa chỉ RCoA của MN. LCoA đợc sử dụng như là địa chỉ nguồn của BU. BU này sẽ liên kết địa chỉ RCoA (có vai trò tương tự HAddr) của MN với LCoA. MAP (hoạt động tương tự HA) sẽ gửi một báo nhận liên kết đến MN. Báo nhận này sẽ chỉ rõ liên kết thành công hay lỗi tương tự với mã lỗi trả về. Sau khi đăng ký MPA mới, MN sẽ đăng ký RCoA của nó với HA bằng cách gửi một BU chỉ ra sự liên kết (RCoA, HAddr) như trong MIPv6. Tuỳ chọn địa chỉ được thiết lập theo HAddr, RCoA có thể được tìm thấy trong trường địa chỉ nguồn hoặc trong tuỳ chọn thay thế CoA. MN có thể gửi một BU tương tự tới 59 các CN. Nếu cờ I được thiết lập, MN có thể sử dụng RCoA của nó như là địa chỉ nguồn của BU. Nếu cờ P được thiết lập, MN phải sử dụng RCoA như là địa chỉ nguồn. Nếu MN sử dụng RCoA của nó như là địa chỉ nguồn, tuỳ chọn thay thế CoA là không cần thiết. Nếu cả cờ P và V được thiết lập, MN phải sử dụng RCoA như là địa chỉ nguồn và tạo đường hầm gửi mọi gói tin đến MAP. Địa chỉ nguồn trong header ngoài là địa chỉ LCoA và địa chỉ đích là địa chỉ của MAP. Cơ chế này được áp dụng khi quản trị mạng muốn MN sử dụng RCoA như là địa chỉ nguồn trong khi vẫn giữ các cơ chế an ninh (ví dụ: firewall) MN đợi báo nhận liên kết từ MAP trước khi đăng ký với HA. Chú ý rằng khi liên kết RCoA với HA và CN, lifetime của liên kết này không được lớn hơn lifetime liên kết của MN với MAP, nhận được thông báo nhận liên kết. Để tăng tốc độ chuyển giao giữa các MAP, MN có thể gửi một BU địa phươn đến MAP trước của nó trong đó chỉ ra LCoA của MN. MN sẽ tháo bao gói của các gói tin và xử lý chúng theo cách thông thường. Khi MN di chuyển cục bộ (không thay đổi MAP), MN chỉ nên thay đăng ký địa chỉ LCoA mới với MAP của nó mà thôi. Trong trường hơpk này, RCoA không thay đổi. Chú ý rằng: MN có thể gửi BU chứa LCoA của nó (thay vì RCoA) đến CN kết nối trên cùng một liên kết. Các gói tin sẽ được chuyển tiếp thay vì qua MAP. Nhà quản trị mạng muốn ẩn địa chỉ LCoA của MN đối với các node ngoài miền của MAP. Để thực hiện điều này, tuỳ chọn MAP có thể được gửi với cờ P được thiết lập. Trong trường hợp này, MN phải sử dụng RCoA như là địa chỉ nguồn của BU khi gửi tới CN và HA. Hơn nữa, MN phải sử dụng RCoA như là địa chỉ nguồn của mọi gói tin gửi đi. Mặt khác, MN muốn ẩn đi vị trí của nó với các CN và HA liên kết với nó. Để thực hiện điều này, MN bảo đảm nó không cung cấp cả định danh và vị trí của nó cho bất kỳ CN nào. Vì định danh của MN được chứa trong mọi gói tối ưu đờng đi (địa chỉ Haddr), MN đảm bảo rằng nó không cung cấp vị trí chính xác cho CN và HA. Vì thế, MN sử dụng RCoA như là địa chỉ nguồn của tất cả các gói tin gửi đi. Điều này được thực hiện nếu cờ I hoặc P được thiết lập trong tuỳ chọn MAP. Ngược lại sự riêng tư về vị trí không thể được cung cấp. Nếu cờ V được thiết lập (cùng với cờ P hoặc cờ I), MN phải tạo đường hầm gửi mọi gói tin đến MAP. Điều này là cần thiết để cho phép sự bí mật vị trí trong khi vẫn giữ được các cơ chế lọc phục vụ cho an ninh. Gửi gói tin đến CN 60 MN có thể truyền thông với CN thông qua HA, hoặc trực tiếp. Nếu MN truyền thông trực tiếp với CN, MN phải sử dụng cùng địa chỉ CoA được sử dụng để thiết lập một bản ghi liên kết trong CN (RCoA) như là địa chỉ nguồn. MN cũng phải đưa lựa chọn Home Address trong các gói tin gửi đi. Lựa chọn này chứa địa chỉ HAddr của MN. Vì RCoA được sử dụng như là địa chỉ nguồn của mọi gói tin gửi đi, MN phải xét các cờ P, I, V để quyết định các gói tin nên được gửi trực tiếp với RCoA là địa chỉ nguồn, hay tạo đường hầm gửi đến MAP. Khi tạo đường hầm cho các gói tin gửi đi đến MAP, địa chỉ nguồn trong header ngoài là LCoA của MN và địa chỉ đích là địa chỉ của MAP. Các thủ tục thực hiện bởi MAP MAP hoạt động như một HA, MAP tiếp nhận mọi gói tin gửi đến MN và thiết lập đường hầm gửi đến địa chỉ LCoA. MAP không biết đến địa chỉ HAddr của MN. MN sẽ gửi một BU địa phương đến MAP với các cờ M, A, D được thiết lập. Mục đích của việc thiết lập này thông báo cho MAP, Mn đã thiết lập được địa chỉ RCoA (chứa trong BU như là HAddr). Nếu thành công, MAP phải gửi lại một báo nhận liên kết tới MN. Ngược lại, MN sẽ gửi một báo nhận với trường mã sai tương ứng. MAP phải có khả năng tiếp nhận các gói tin được gửi thông qua đường hầm từ MN, với MN như là đầu vào của đường hầm và MAP là đầu ra của đường hầm. MAP sau đó hoạt động như là một HA đối với địa chỉ RCoA. Các gói tin gửi đến RCoA sẽ được tiếp nhận bởi MAP, sau đó được đóng gói rồi chuyển đến LCoA của MN. Các vấn đề an ninh Trong giao thức HMIPv6, MAP hoạt động tương tự như một HA, vì vậy, mối liên quan an ninh giữa MN và MAP (bao gồm: sự xác thực lẫn nhau, bảo vệ toàn vẹn và bảo vệ chống lại tấn công sử dụng lại) cần được hết sức coi trọng. Việc thiếu vắng bất kỳ một cơ chế bảo vệ nào có thể sẽ dẫn tới các MN gỉa mạo có thể “đóng giả” các MN hợp pháp và “đóng giả” MAP. Bất kỳ các cuộc tấn công nào sẽ gây ra các ảnh hưởng không mong muốn đến việc truyền thông giữa MN và các CN biết địa chỉ RCoA của MN. Có ba mối quan hệ an ninh khác nhau cần phải được xem xét, bao gồm: MN và MAP; MN và HA; MN và CN. 3.2.2.4 Giải pháp kết hợp Mobile Ipv6 phân cấp và Mobile IP chuyển giao nhanh. Giải pháp kết hợp giữa phân cấp và chuyển giao nhanh (H+FMIPv6) dựa trên các đánh giá sau: 61 - Xét MAP được đặt trên một router kết hợp phía trên các AR bị ảnh hưởng trong quá trìnhcg. Tiến trình chuyển giao nhanh bình thường chuyển tiếp các gói tin từ AR cũ sang AR mới sẽ gây ra sự không hiệu quả vì gia tăng trễ chuyển giao do các gói tin phải dịch chuyển theo liên kết MAP-AR cũ hai lần và có thể đến AR mới theo thứ tự không đúng. Nếu thành phần chịu trách nhiệm cho việc thiết lập chuyển hướng trước chuyển giao là MAP, thì sự không hiệu quả trên sẽ bị loại bỏ. Vì vậy, trong mô hình này thành phần thực hiện chức năng của tiến trình chuyển giao là MAP thay vì một tác tử di động trong AR cũ. - Chú ý rằng với FMIPv6 luồng dữ liệu sẽ được chuyển hướng khi AR cũ nhận được F-BU nhưng trong trường hợp này nếu MN thực hiện chuyển giao ngay sau khi gửi F-BU đến MAP, sẽ bị mất. Thêm vào đó, nếu MH thực hiện chuyển giao ngay sau khi gửi F-BU, MN sẽ không thể ngay lập tức nhận bất kỳ một gói tin được chuyển hướng nào bởi cùng một lý do, điều này làm tăng trễ chuyển giao và độ mất gói. Để giải quyết vấn đề này, giải pháp đề suất phải thiết lập một khoảng thời gian đợi FBACK đến liên kết cũ trước khi khởi tạo chuyển giao. Trong trường hợp này, chắc chắn khi nhận được FBACK sẽ không có gói tin bị mất gởi đến địa chỉ CoA cũ và các gói tin được chuyển hướng đến CoA mới sẽ được lưu đệm. Thêm vào đó, giả sử rằng các gói tin trải qua một khoảng thời gian trễ giống nhau trên đường liên kết giữa MAP và AR (các AR bị ảnh hưởng trong chuyển giao), sự tiếp nhận gói tin FBACK tương tự như nhận gói tin đồng bộ hoá, thông báo các gói tin mới đã sẵn sằng đợi hoặc đã đến AR mới và vì thế, trễ chuyển giao liên kết liên quan đến các liên kết có dây được hầu như loại bỏ. 3.3 An toàn và bảo mật trong Mobile IP Liên kết không dây là liên kết đặc biệt rất dễ bị nghe trộm và bị tấn công từ bên ngoài và các kiểu truy nhập khác. Phần dữ liệu của Mobile Node khi truyền đường hầm (tunnel) tới địa chỉ COA (Care-of-address) cũng dễ bị tấn công. Mobile IP cũng sử dụng APR, đây là kẽ hở mà những kẻ tấn công có thể xâm nhập trái phép vào quá trình trao đổi giữa các Node, cũng chính là vấn đề bảo mật được đặt ra trong Internet hiện nay. Giao thức Mobile IP được xây dựng trên nền là giao thức TCP/IP do vậy nó cũng sử dụng tất cả các biện pháp bảo mật dữ liệu như giao thức TCP/IP và ngoài ra còn sử dụng thêm một số phương pháp trong đó xem xét phương pháp xác thực trong quá trình đăng ký An toàn và bảo mật là những yêu cầu tối quan trọng trong quá trình đăng ký trong Mobile IP. Vì trong quá trình này có thể có dạng tấn công sau: 62 - Giả mạo MN: Một trạm giả mạo sẽ phát ra bản tin, yêu cầu đăng ký với địa chỉ HAddr của một MN hợp lệ, điều này sẽ làm cho mọi bản tin thay vì đến MN hợp lệ sẽ đến trạm giả mạo. - Giả mạo FA: một trạm giả moạ FA sẽ gửi các quảng cáo đến các trạm trong mạng để thu hút luồng dữ liệu đến MN, hơn nữa, FA giả mạo có thể tự động gửi các bản đăng ký hoặc trả lời đến MN hoặc FA để qua đó nhận trái phép dữ liệu. Để giải quyết vấn đề chống giả mạo trong Mobile IP đặt các cơ chế xác thực, bao gồm: - Sử dụng các mở rộng xác thực. - Sử dụng trường Identification. 3.3.1 Sử dụng các mở rộng xác thực (authentication extensions) Mở rộng xác thực được thực hiện giữa hai bên truyền thông (MN-FA, FA- HA, HA-MN). Các mở rộng xác thực được chèn vào trong thông điệp đăng ký giúp cho hai bên kiểm tra tính xác thực. Có tất cả ba mở rộng xác thực được định nghĩa cho Mobile IP cơ bản, tất cả đều cho phép đưa thêm vào cơ chế xác thực khác trong quá trình đăng ký: - Mở rộng xác thực MN-HA. - Mở rộng xác thực MN-FA. - Mở rộng xác thực FA-HA. Mỗi mở rộng bao gồm một SPI chỉ ra liên kết an ninh di động, liên kết an ninh này chứa các thông tin bí mật cần thiết để tính xác thực có trong mở rộng. Ngoài ra cần lưu ý rằng chỉ có duy nhất một trường mở rộng cho hai thực thể bất kỳ trong số MN, HA, FA. Để xây dựng được các mở rộng xác thực này mỗi đối tượng: MN, FA, HA được yêu cầu có khả năng hỗ trợ một liên kết an ninh di động (mobility security association) đối với các thực thể di động, liên kết này được đánh chỉ số bởi Chỉ số tham số an ninh (security parameters index - viết tắt là SPI) và địa chỉ IP. Tính toán các giá trị mở rộng xác thực: Việc tính toán dựa trên SPI thoả thuận giứa hai đối tác cần xác thực. SIP trong bất kỳ các mở rộng xác thực nào cũng định nghĩa cơ chế an ninh được sử dụng để tính toán giá trị xác thực và được sử dụng bởi bên nhận để kiểm tra giá trị này. Cụ thể, SIP sẽ lựa chọn giải thuật, chế độ và khoá xác thực được sử dụng để tính giá trị xác thực. Để đảm bảo sự phối hợp giữa các thể hiện khác nhau của giao thức Mobile IP, mỗi thể hiện được yêu cầu liên kết bất kỳ giá trị SPI nào lớn hơn 255 với các thuật toán và chế độ xác thực sẽ thực hiện. 63 Thuật toán xác thực mặc định được sử dụng trong Mobile IP là MD5 (Message Digest 5) với chế độ prefix+suffix, nghĩa là “bí mật”được chèn vào trước và sau dữ liệu mà nó xác thực. Kết quả của tính toán mặc định là 128bit MD của thông điệp đăng ký, và kết quả này là việc tính toán dựa theo giải thuật MD5 với đầu vào là các dữ liệu sau: (1) Thông tin mật được định nghĩa bởi liên kết an ninh di động giữa các node và bởi giá trị SPI được chỉ ra trong mở rộng xác thực. (2) Các trường header của thông điệp yêu cầu đăng ký và trả lời đăng ký. (3) Các mở rộng đứng trước đó. (4) Kiểu, độ dài và SPI có trong bản thân các mở rộng. (5) Thông tin bí mật Chú ý rằng bản thân trường xác thực, UDP header, IP header không được đưa vào tính toán giá trị xác thực. Giá trị xác thực này sẽ được chèn vào mở rộng xác thực, khi nhận được thông điệp, phía nhận sẽ căn cứ vào SPI, tính toán lại giá trị này và so sánh: nếu nhận, ngược lại sẽ loại bỏ. Khuôn dạng của một trường mở rộng như sau: Type: 32 Mở rộng xác thực MN-HA 33 Mở rộng xác thực MN-FA 34 Mở rộng xác thực FA-HA Length: 4 cộng với độ dài của giá trị xác thực (authenticator) SPI: 4 byte. Authenticator: Độ dài biến đổi phụ thuộc vào thuật toán SPI quy định. 3.3.2 Xác thực thông qua trường Identification Nếu trên mạng có một tác tử giả mạo trong suốt quá trình đăng ký, tác tử đó có thể thu thập mọi thông tin cần thiết cho đăng ký đó, bao gồm cả dữ liệu xác thực. dữ liệu xác thực này có thể được sử dụng lại trong một lần nào đó, vì vậy cần có một trường dữ liệu mà giá trị thay đổi ngẫu nhiên giứa các lần nào đó, vì vậy cần có một trường dữ liệu mà giá trị thay đổi ngẫu nhiên giữa các lần gửi thông điệp, đó chính là trường Identification. Sử dụng trường Identification HA sẽ biết được chắc chắn rằng yêu cầu mà nó nhận được là một yêu cầu mới, không phải là yêu cầu được kẻ tấn công sử dụng lại. Việc xác định Identification phụ thuộc vào việc lựa chọn chiến lược Bảo vệ chống sử dụng lại (replay protection), có hai chiến lược: - Chiến lược sử dụng Time stamps: Nền tảng của chiến lược này là việc, các node sẽ chèn dữ liệu về thời gian hiện tại vào trong thông điệp, và khi bên nhận được thông điệp sẽ kiểm tra xem thời gian có trong thông điệp có gần với thời gian hiện tại ở bên nhận hay 64 không. Vì vậy, hai bên cần phải đồng bộ đồng hồ, việc này được thực hiện theo một cơ chế có xác thực được định nghĩa bởi cơ chế an ninh giữa hai bên. Nếu timestamp được sử dụng, trường identification sẽ có kích thước 64bit có khuôn dạng được quy định theo giao thức NTP (Network Time Protocol)32bit thấp là thời gian thời gian chèn vào, 32 bit còn lại được sinh ngẫu nhiên.Tuy nhiên, 64 bit này phải có giá trị lớn phù hợpn thì sẽ gây khó khăn trong việc cập nhật thông tin di động. Identification được cho là hợp lệ: nếu thời gian trong 32 bit thấp gần với đồng hồ của HA và lớn hơn tất cả timestamp đã được gửi trước đó. Sau đó, khi trả lời, HA sẽ sao trường identification này vào thông điệp trả lời. Tuy nhiên, nếu sai: chỉ có 32 bit thấp được sao, còn 32 bit cao là thời gian theo đồng hồ cảu HA giúp cho MN đồng bộ lại đồng hồ (chú ý: MN chỉ đồng bộ lại khi mà 32 bit thấp của thông điệp trả lời trùng với 32 bit thấp của thông điệp yêu cầu mà MN đã gửi đi) Phương pháp bảo vệ chống phát lại (replay protection) dựa trên timestamp là phương pháp hay được sử dụng. Ngoài ra những Node này cũng có thể sử dụng phương thức bảo vệ dựa trên Nonce. Bảo vệ chống phát lại (replay protection) được sử dụng giữa Mobile Node và trạm gốc của Node là một phần của liên kết bảo mật di động MSA (Mobile Security Association). Mobile Node và trạm gốc của Node phải thống nhất phương pháp bảo vệ chống phát lại (replay protection), thông thường là dùng trường nhận dạng (Identification), cấu trúc của trường nhận dạng phụ thuộc vào phương pháp sử dụng trong bảo vệ chống phát lại. Bất kể sử dụng phương pháp nào thì các bit có thứ tự thấp hơn 32 của trường nhận dạng của trả lời đăng ký đều mang cùng một giá trị giống như trong yêu cầu đăng ký. Trạm ngoài sử dụng các bit này và địa chỉ gốc của Mobile Node có các trả lời tương ứng với các yêu cầu của đăng ký. Mobile Node sẽ kiểm tra xem các bit có thứ tự thấp hơn 32 của trả lời đăng ký giống với các bit mà Node gửi tới yêu cầu đăng ký hay không, nếu không đúng thì trả lời này bị huỷ bỏ. Giá trị trường nhận dạng trong yêu cầu đăng ký mới không được giống như trong yêu cầu đăng ký có ngay trước đó và tránh không nên lặp lại trong khi Mobile Node và trạm gốc cùng sử dụng cùng một phạm vi bảo vệ. Nguyên tắc cơ bản cách thức bảo vệ dùng timestamp là Node tạo bản tin sẽ chèn thêm thời gian hiện tại của ngày và Node nhận bản tin sẽ kiểm tra độ chính xác của timestamp này với thời gian của chính nó. Rõ ràng hai Node về thời gian phải được đồng bộ một cách tương ứng. Như với bất kỳ bản tin nào, bản tin 65 đồng bộ thời gian có thể được cơ chế nhận thực xác nhận bảo vệ tránh khỏi sự xáo trộn. Cơ chế này do phạm vi bảo mật giữa hai Node quyết định. Nếu sử dụng timestamp, Mobile Node sẽ dùng trường nhận dạng tới 64 bit, các giá trị có cấu trúc như được đề cập trong NTP (Network Time Protocol, RFC 1035). Tuy nhiên nên lưu ý rằng khi sử dụng timestamp, trường nhận dạng 64 bit được sử dụng trong yêu cầu đăng ký từ Mobile Node bắt buộc phải có giá trị lớn hơn giá trị trường nhận dạng trong bất kỳ yêu cầu đăng ký trước đó vì trạm gốc cũng sử dụng trường này như trường thứ tự tuần tự. Khi không có số thứ tự tuần tự như vậy, Mobile Node có khả năng làm bản sao của yêu cầu đăng ký trước đó đến trạm gốc bị chậm (trong thời gian đồng bộ thời gian trạm gốc yêu cầu) và như vậy yêu cầu này sẽ yêu cầu không đúng lúc và do vậy làm thay đổi địa chỉ động đã đăng ký hiện thời của Mobile Node. Khi nhận yêu cầu đăng ký với mở rộng có xác nhận Mobile Home, trạm gốc bắt buộc phải kiểm tra tính hợp lệ của trường nhận dạng. Để hợp lệ, timestamp trong trường nhận dạng phải đủ gần đúng với thời gian của trạm gốc và timestamp này phải lớn hơn tất cả các timestamp được chấp nhận trước đó dành cho các Mobile Node yêu cầu đăng ký. Nếu timestamp hợp lệ, trạm gốc sẽ copy toàn bộ trường nhận dạng vào trả lời đăng ký mà nó sẽ gửi lại Mobile Node. Nếu timestamp không hợp lệ trạm gốc chỉ copy 32 bit thấp và cung cấp các bit có số thứ tự lớn hơn 32 có từ thời gian ngày của chính nó. Trong trường hợp này trạm gốc sẽ loại bỏ đăng ký này bằng cách đáp lại với mã số 133 trong trả lời đăng ký. Mobile Node sẽ kiểm tra xem các bit có số thứ tự thấp hơn 32 của trường nhận dạng trong trả lời đăng ký giống với trường nhận dạng trong đăng ký bị loại bỏ, trước khi sử dụng các bit có số thứ tự cao hơn để đồng bộ lại đồng hồ. - Chiến lược sử dụng Nonce: Nguyên tác cơ bản của việc sử dụng Nonce để bảo mật trả lời là trong mỗi bản tin gửi tới Node B, Node A kèm theo một con số ngẫu nhiên và Node A kiểm tra xem trong bản tin tiếp sau tới Node A, Node B có gửi lại con số tương tự hay không. Cả hai bản tin đều sử dụng một mã số xác nhận để tránh sự biến đổi do kẻ tấn công gây ra. Cùng lúc đó Node B có thể gửi Nonce của chính nó trong tất các các bản tin tới Node A (Node A sẽ lặp lại như vậy), do đó Node B có thể xác minh là nó đang nhận bản tin mới. Trạm gốc có thể có cách để tính các số ngẫu nhiên có ích như các nonce. Trạm gốc cài một nonce mới như các bit có số thứ tự dưới 32 của trường nhận dạng trong mỗi trả lời đăng ký. Trạm gốc copy 32 bit thấp nhất của trường nhận dạng trong bản tin yêu cầu đăng ký vào các bit tương tư của trường nhận dạng trong trả lời đăng ký. Khi Mobile Node nhận trả lời đăng ký đã được xác nhận từ 66 trạm gốc, Node lưu các bit có số thứ tự lớn hơn 32 của yêu cầu đăng ký tiếp theo. Mobile Node chịu trách nhiệm tạo các 32 bit thấp của trường nhận dạng trong mỗi yêu cầu đăng ký. Các Node cần tạo nonces của chính nó . Tuy nhiên Node có thể sử dụng bất kỳ biện pháp thích hợp, kể cả nhân đôi giá trị ngẫu nhiên mà trạm gốc gửi. Phương pháp chọn nonce do Mobile Node quyết định, bởi vì nó là Node kiểm tra giá trị hợp lệ đó trong trả lời đăng ký. Các bit cao và các bit thấp hơn 32 của trường xác nhận được chọn phải khác với các giá trị trước đó của chúng. Trạm gốc sử dụng 32 bit cao và Mobile Node sử dụng giá trị mới cho 32 bit thấp cho mỗi bản đăng ký. Trạm ngoài sử dụng giá trị có số thứ tự thấp hơn và địa chỉ gốc của Mobile Node để các trả lời đăng ký phù hợp với các yêu cầu chưa hoàn thành. Nếu bản tin đăng ký bị từ chối vì một nonce không hợp lệ, trả lời đăng ký luôn luôn cung cấp cho Mobile Node một Nonce mới để sử dụng trong đăng ký tiếp theo, do vậy thủ tục nonce tự nó đồng bộ. Trong các bản tin trao đổi (bản tin yêu cầu và bản tin trả lời) giữa một cáp Node Mobile IP sử dụng các giá trị an toan bảo mật di động MSA có cấu trúc như sau: - Type - Length = 4 cộng với số lượng các bytes trong chỉ số xác nhận. - SPI : chỉ số tham số bảo mật (Security Parameter Index) 4 bytes. - Authenticator : Độ dài biến đổi Trong đó các giá trị của Type như sau: Type= 32 là chỉ phần mở rộng cần xác nhận MSA Mobile - Home Type= 33 là chỉ phần mở rộng cần xác nhận MSA Mobile - Foreign Type= 34 là chỉ phần mở rộng cần xác nhận MSA Foreign - Home Đối với trường xác nhận dùng để thực hiện việc xác nhận các bản tin. Thuật toán để mã hoá sử dụng tại đây là thuật toán mã hoá MD5 với kích thước là 128 bit. Phương thức mã hoá là mã phần trước hoặc phần sau số liệu sẽ bị xáo trộn bởi từ mã 128 bit có nghĩa là MD5 được sử dụng theo phương thức tiền tố + hậu tố. Trạm nào cũng được hỗ trợ phương pháp xác nhận sử dụng MD5 và cỡ từ mã là 128 bit hoặc lớn hơn, với sự phân bổ mã từ theo quy định cụ thể. Nhiều thuật toán xác nhận, phương thức phân bổ từ mã và kích thước từ mã, kiểu từ mã như dùng mã Random cũng được sử dụng để hỗ trợ. 67 KẾT LUẬN Với mục đích bước đầu tìm hiểu về mạng thông tin di động 4G, và một số kỹ thuật sử dụng trong mạng, cũng như cơ chế xác thực để đảm bảo an toàn cho mạng, luận văn đã nghiên cứu một số vấn đề sau: - Giao thức Mobile IP, tìm hiểu các loại bản ghi trong giao thức, cách giao tiếp sử dụng các loại bản ghi này để thực hiện các chức năng của giao thức, tìm hiểu thông qua phiên bản Mobile Ipv4, đánh giá ưu nhược điểm của Mobile Ipv4. - Nghiên cứu về mạng di động 4G, về kiến trúc tổng quan, về các dịch vụ chủ yếu có thể hướng tới của mạng 4G, các mô hình được khuyến nghị cho 4G. - Tìm hiểu cơ chế xác thực trong quá trình đăng ký của Mobile IP. Tuy nhiên luận văn vẫn còn nhiều vấn đề cần được nghiên cứu tiếp để hoàn thiện hơn như: - Nghiên cứu chi tiết về việc quản lý tính di động trong Mobile IP để có thể áp dụng đối với mạng 4G. - Tìm hiểu các phương thức mà mạng 4G có thể bị tấn công khi việc truyền thông đa phương tiện được đáp ứng với tốc độ ngày càng cao mọi lúc, mọi nơi để qua đó có thể tìm hiểu các giải pháp ngăn chặn. 68 TÀI LIỆU THAM KHẢO Tiếng Việt 1. Nguyễn Phạm Anh Dũng (2002), Thông tin di động thế hệ ba, Học viên Công nghệ Bưu chính Viễn thông. Tiếng Anh 2. Charles E.Perkins (1997), Mobile IP Design Principles and Practices, Prentince Hall PTR. 3. C. Perkins (2002), Rfc 3344: IP Mobility Support for Ipv4, IETF. 4. D.Johnson, C.Perkins and J.Arkko (2004), Rfc3375: Mobility Support in Ipv6, IETF. 5. Dave Wisley, Philip Eard Ley and Louise (2002), IP for 3G Networking Technologies for Mobile Communications, John Wiley & Sons. 6. Harri Holma and Anti Toskala (2000), W-CDMA for UMTS, John Wiley & Sons. 7. Luis Correia (2006), Mobile Broadband Multimedia Networks, Elsevier. 8. Michael A.Gallo and William M.Hancock (2001), Computer Comunications and Networking Technologies, Course Technology. 9. Ramjee Prasad and Marina Ruggieri (2003), Technology Trends in Wireless Communication, Artech House Publishers. 10. Savo G.Glisic (2006), Advance Wireless Networks 4G Technologies, John Wiley & Sons. 11. Shinsuke Hara and Ramjee Prasad (2003), Multicarrier Techniques for 4G Mobile Communications, Artech House. 12. S.Gundavelli, K.Leung, V.Devarapalli, K.Chowdhury and B.Patil (2008), Rfc5213: Proxy Mobile Ipv6, IETF. 13. Vijay K.Gary (2007), Wireless Communications and Networking, Elsevier. 14. William C.Y.Lee (1996), Mobile Communication Design Fundamental, John Wiley & Sons. 15. 4G Mobile Communications Committee (2005), Towards the 4G Mobile Communications Systems.. 16. 4G Mobile Communications Committee (2006), 4G Technical Survey Report – System Infrastructure. 17. 4G Mobile Communications Committee (2006), 4G Technical Survey Report – Service Platform.