• IP Multicast & Group security

    Sau một thời gian nghiên cứu, tôi đã hoàn thành project IP Multicast & Group security in Multicast như đã hứa. Project được chia làm hai phần: Phần một giới thiệu về IP Multicast cùng với các khía cạnh khác nhau xoay quanh vấn đề này. Phần hai nêu lên tầm quan trọng của bảo mật trong Multicast và được tập trung ở một số khía cạnh quan trọng nhất liên quan đến bảo mật nhóm trong Multicast.
    Tài liệu tham khảo:
    1. IP Multicast concepts and Applications: Marucus Goncalves and Kitty Niles. McGraw-Hill Companies 1998.
    2. Developing IP Multicast Networks. Cisco Press 2003.
    3. Diot, C, et al, “Deployment Issues for the IP Multicast Service and Architecture”, IEEE Network, Special Issue on Multicasting, January/ February 2000.
    4. Kent, S., and R. Atkinson, ‘‘Security Architecture for the Internet Protocol,’’ RFC 2401 (proposed standard), IETF, November 1998.
    5. D. Estrin, D. Farinacci, A. Helmy, "Protocol Independent Multicast-Sparse Mode (PIM-SM)", RFC 2362, June 1998.
    6. A. Adams, J. Nicholas, W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM)", FRC 3973, January 2005.
    7.Wallner, D., E. Harder, and R. Agee, ‘‘Key Management for Multicast: Issues and Architectures,’’ RFC 2627(informational), IETF, June 1999.
    Cùng một số tài liệu tham khảo nữa từ trên mạng.
    Vì viết bài trên diễn đàn nên tôi cố gắng chỉ đưa ra những kiến thức cốt lõi nhất, nếu bạn nào muốn tìm hiểu thêm có thể liên lạc để tôi gửi bài viết chi tiết.

    1. IP Multicast và các vấn đề liên quan
    1.1 Giới thiệu về IP Multicast
    IP Multicast là một chuẩn mở của IETF dùng để truyền dẫn các gói dữ liệu IP từ một nguồn đến nhiều đích trong một mạng LAN hay WAN. Các host tham gia vào một nhóm Multicast và các ứng dụng chỉ gửi một bản sao của thông tin cho một địa chỉ nhóm. Thông tin này chỉ gửi đến những điểm muốn nhận được lưu lượng đó. Việc gửi bản tin Unicast và Broadcast là các trường hợp đặc biệt của phương pháp Multicast. Truyền Multicast cải thiện đáng kể về hiệu suất, thường sử dụng băng thông nhỏ hơn truyền đơn trên mạng, và cho phép xây dựng các ứng dụng phân tán hợp lý.

    a) Truyền dẫn Unicast
    Truyền dẫn Unicast, hay còn gọi là truyền dẫn điểm- điểm. Trong hình thức truyền dẫn này, nhiều host muốn nhận thông tin từ một bên gửi thì bên gửi đó phải truyền nhiều gói tin đến các bên nhận. Điều này sẽ dẫn đến gia tăng băng thông khi có quá nhiều bên nhận và không hiệu quả về nguồn và bộ đệm

    Minh hoạ cho truyền dẫn Unicast

    b) Truyền dẫn Broadcast
    Kiểu truyền dẫn này cho phép truyền gói tin từ một địa điểm tới tất cả các host trên một mạng con mà không quan tâm đến việc một số host không có nhu cầu nhận nó. Kiểu truyền dẫn này được coi là một sát thủ băng thông do việc sử dụng tài nguyên băng thông không hề hiệu quả.

    Minh hoạ cho truyền dẫn Broadcast

    c) Truyền dẫn Multicast
    Một địa chỉ Multicast cho phép phân phối dữ liệu tới một tập hợp các host đã được cấu hình như những thành viên của một nhóm Multicast trong các mạng con phân tán khác nhau. Đây là phương pháp truyền dẫn đa điểm, trong đó chỉ các host có nhu cầu nhận dữ liệu mới tham gia vào nhóm. Điều này hạn chế tối đa sự lãng phí băng thông trên mạng, hơn nữa còn nhờ cơ chế gửi gói dữ liệu Multicast mà băng thông được tiết kiệm triệt để ( trình bày ở phần sau).

    Minh hoạ cho truyền dẫn Multicast

    1.2 Triển khai Multicast
    1.2.1 Nhóm Multicast
    Một đặc điểm quan trọng của IP Multicast là nhóm Multicast. Việc xây dựng một nhóm Multicast bắt đầu với một server đang chạy một ứng dụng Multicast như audio, video... Khi một server được xây dựng, một địa chỉ Multicast Lớp D được gán cho ứng dụng đó và tất cả các thành viên của nó. Một nhóm Multicast được cấp phát cho một địa chỉ lớp D đại diện cho nhóm đó. Số lượng thành viên của nhóm có thể là 0, 1 hay nhiều thành viên. Các thành viên có thể nằm tại các mạng con khác nhau.
    Khi một host muốn gia nhập một nhóm, nó gửi một bản tin IGMP chứa địa chỉ lớp D của nhóm mong muốn tới Mrouter cục bộ của nó (Mrouter là các router có hỗ trợ Multicast. Một trong những chức năng của router này là giúp các host trên các mạng gắn liền với nó truy nhập hệ thống phân phối Multicast). Sau khi Mrouter nhận bản tin IGMP từ các host, nó chuyển tiếp tất cả lưu lượng Multicast cho nhóm các host đó. Các host có thể gia nhập nhóm hoặc rời bỏ khỏi nhóm bất cứ lúc nào.
    1.2.2 Đường hầm Multicast
    Khi chưa có nhiều router hỗ trợ Multicast được triển khai trên mạng thì đường hầm Multicast là một giải pháp hợp lý để triển khai Multicast. Các bạn hãy tưởng tượng khi số lượng Mrouter trên mạng là rất ít, ta có thể coi mỗi Mrouter như một hòn đảo giữa rất nhiều router Unicast. Hai đảo này có thể kết nối trực tiếp bằng một đường link vật lý hoặc một đường hầm logic. Nếu một đường hầm kết nối 2 Mrouter, khi đó nó đại diện cho một liên kết ảo điểm- điểm giữa chúng. Trong các đường hầm là các router Unicast. Khi một gói tiến vào đường hầm, nó được đóng gói trong một gói IP Unicast với một địa chỉ đích của Mrouter ở phía kia của đường hầm. Khi rời khỏi đường hầm, nó được tháo gói và được xử lý tại các Mrouter. Do đó, một đường hầm cho phép lưu lượng Multicast truyền liên tục giữa 2 Mrouter thông qua các router Unicast.

    Minh hoạ đường hầm Multicast

    1.2.3 Biên dịch địa chỉ Multicast
    Khi một router cục bộ trên một subnet nhận một gói Multicast lớp 3, nó có thể chuyển đổi địa chỉ IP Multicast tới một địa chỉ Multicast lớp 2, như một địa chỉ MAC Ethernet. Do đó phần cứng giao diện LAN của host thu có thể đọc địa chỉ lớp 2 này. Các giao thức lớp 2 LAN điển hình dự trữ những vùng địa chỉ của chúng cho các khung Broadcast và Multicast, chẳng hạn, địa chỉ Broadcast Ethernet FF- FF- FF- FF- FF- FF.

    Chuyển đổi địa chỉ IP Multicast thành địa chỉ Ethernet/FDDI

    Việc biên dịch địa chỉ từ địa chỉ IP (lớp 3) đến địa chỉ Lớp 2 được thực hiện bằng việc sắp xếp trực tiếp địa chỉ IP vào trong một Địa chỉ MAC Ethernet. Điều này được hoàn thành bằng việc sao chép 23 bít cuối cùng của địa chỉ nhóm IP vào 23 bít cuối cùng của địa chỉ Ethernet Multicast. Việc sắp xếp một địa chỉ nhóm lớp D vào địa chỉ MAC không phải là tương ứng một - một, vì 5 bít cao của địa chỉ nhóm Lớp D đã bị loại bỏ. Khả năng này làm nảy sinh một vấn đề là có thể có 32 địa chỉ MAC khác nhau có thể ánh xạ vào cùng một địa chỉ MAC. Do đó, một host Multicast gặp một vấn đề nhỏ khi nó nhận một khung Ethernet của một địa chỉ Multicast. Một MAC có thể tương ứng với 32 địa chỉ Multicast khác nhau. Vì vậy, một host phải nhận và kiểm tra tất cả các khung có MAC mà nó quan tâm. Sau đó host này phải kiểm tra phần địa chỉ IP bên trong mỗi khung để nhận ra phần địa chỉ của từng nhóm Multicast.
    1.2.4 Chuyển tiếp lưu lượng Multicast
    Có một vài phương pháp để chuyển tiếp lưu lượng IP Multicast từ các nguồn đến các host thu. Đầu tiên ta sắp xếp một nhóm bao gồm các host thu với một địa chỉ lớp D chung để đạt được sự phân phối lưu lượng Multicast hiệu quả. Bước tiếp theo là tạo ra một tập hợp các đường phân phối Multicast cho các router sử dụng. Các giao thức được xây dựng trong các router giúp xây dựng cây phân phối Multicast để chuyển tiếp các gói. Giao thức chuyển tiếp Multicast chủ yếu sử dụng một trong hai kỹ thuật sau:
    1.2.4.1 Cây nguồn (source tree)
    Dạng đơn giản nhất của cây phân phối Multicast là cây nguồn có gốc là nguồn Multicast và các nhánh của nó có dạng cây mở rộng dọc theo mạng đến các điểm thu. Nó là một cây đường ngắn nhất (SPT).
    Hình dưới đây là ví dụ về một SPT cho nhóm 224.1.1.1 có gốc đặt tại nguồn, host A và 2 máy thu được nối đến, host B và host C. Kí hiệu (S,G) cho một SPT ở đó S là địa chỉ IP nguồn và G là địa chỉ nhóm Multicast. Ở ví dụ dưới đây SPT có kí hiệu là (192.1.1.1, 224.1.1.1).
    Kí hiệu (S,G) chỉ ra sự tồn tại của một SPT cho mỗi nguồn riêng biệt gửi đến một nhóm. Ví dụ nếu host B cũng đang gửi lưu lượng đến nhóm 224.1.1.1 và host A và C đang nhận, thì khi đó cũng tồn tại một SPT riêng với kí hiệu là (192.2.2.2, 224.1.1.1).

    Ví dụ về cây nguồn

    1.2.4.2 Cây chia sẻ (shared-tree)
    Phương pháp chuyển tiếp cây chia sẻ có nhiều ưu thế nhất trong phân phối Multicast. Phương pháp chuyển tiếp này là một sự lựa chọn tốt hơn so với phương pháp cây chung gốc khi môi trường Multicast bao gồm các nhóm Multicast phân bố rải rác với những kết nối bậc thấp.

    Ví dụ về cây chia sẻ

    Phương pháp cây chia sẻ sử dụng một Mrouter trung tâm, đôi khi được coi như một router lõi. Các host nguồn Multicast gửi các gói Multicast của chúng tới router lõi này, và lần lượt chuyển tiếp các gói này qua cây chia sẻ đến các thành viên của nhóm. Một cây chia sẻ sử dụng một cây đơn giữa các nguồn và các thành viên nhóm.
    Trên đây là một ví dụ về cây chia sẻ cho nhóm 224.2.2.2 với gốc đặt tại router D. Khi sử dụng cây chia sẻ này, các nguồn phải gửi lưu lượng của chúng đến gốc và sau đó lưu lượng được chuyển tiếp xuống cây chia sẻ đến tất cả các máy thu.
    Trong ví dụ trên, lưu lượng Multicast từ các host nguồn A và D chuyển đến gốc (Router D) và sau đó được chuyển xuống 2 điểm nhận theo cây chia sẻ là router B và C. Do tất cả các nguồn Multicast đều sử dụng cây chia sẻ nên kí hiệu wild-card (*,G) được sử dụng đại diện cho cây. Ở đó, * là tất cả các nguồn, G là địa chỉ nhóm Multicast, như ví dụ kí hiệu là (*, 224.2.2.2).

    Cả SPT và shared-tree đều là loop-free. Các bản tin chỉ được nhân lên tại các điểm có nhánh cây.
    Các thành viên của các nhóm Multicast có thể gia nhập hoặc rời nhóm bất cứ thời điểm nào do đó cây phân phối Multicast phải luôn cập nhật một cách linh hoạt. Khi tất cả các host của một nhánh Multicast nào đó ngừng yêu cầu nhận lưu lượng đối với nhóm Multicast nào đó, các router phải xóa nhánh đó ra khỏi cây phân phối Multicast, và ngừng chuyển lưu lượng xuống nhánh đó. Nếu một host trên nhánh đó hoạt động trở lại và yêu cầu lưu lượng Multicast thì router phải linh động thay đổi cây phân phối và chuyển lưu lượng cho nhánh đó trở lại.
    Các SPT có ưu điểm trong việc tạo ra đường dẫn tối ưu nguồn và các máy thu. Điều này đảm bảo trễ chuyển tiếp lưu lượng Multicast thấp nhất cho mạng. Sự tối ưu này có giá của nó đó là các router phải duy trì thông tin đường dẫn từ nó đến nguồn. Trong một mạng có hàng nghìn nguồn và hàng nghìn điểm nhận thì điều này nhanh chóng trở thành vấn đề về tài nguyên trên các router. Sự tiêu thụ bộ nhớ của bảng định tuyến Multicast là một vấn đề đáng quan tâm của người thiết kế.
    Các cây chia sẻ có ưu điểm trong việc hạn chế số trạng thái của mỗi router. Do đó bộ nhớ yêu cầu cho toàn mạng khi sử dụng cây chia sẻ cũng ít hơn. Tuy nhiên, hạn chế của cây chia sẻ là đường dẫn giữa nguồn và máy thu không phải là đường dẫn tối ưu và do đó có thể tạo ra trễ trong phân phối các gói. Các nhà thiết kế mạng phải quan tâm đúng mức đến vị trí đặt các RP (rendezvous point) trong môi trường chỉ có các cây chia sẻ.
    1.3 Định tuyến trong IP Multicast
    Các router phải hỗ trợ một số giao thức để định tuyến đúng các gói tin. Với router Unicast, có một số giao thức định tuyến như RIP và OSPF thường được sử dụng để nhận dạng đường đi từ nguồn đến đích. Tuy nhiên, các phương pháp này không phù hợp với bản chất phi vật lý của các nhóm Multicast. Do đó các Mrouter phải hỗ trợ một số thuật toán định tuyến và giao thức dành riêng cho Multicast.
    Định tuyến lưu lượng Multicast phức tạp hơn định tuyến lưu lượng Unicast. Số các máy thu trong một phiên Multicast có thể khá lớn. Các router mạng phải có khả năng chuyển địa chỉ Multicast sang địa chỉ host. Trong định tuyến Multicast, các router tương tác để trao đổi thông tin về các router hàng xóm. Giao thức quản lý nhóm sẽ chọn một router đơn như router bổ nhiệm (DR_ Designated Router) cho mỗi mạng vật lý. DR thường là router gần nhất với gốc.
    Bằng việc sử dụng các giao thức định tuyến Muticast, các router Multicast thiết lập linh hoạt các cây đường đa điểm sử dụng thông tin thành viên nhóm có được từ việc truyền thông IGMP. Các cây đường đa điểm đó chỉ ra các đường từ một máy phát tới tất cả máy thu. Để hỗ trợ Multicasting, một router cần phải hỗ trợ ít nhất một trong các giao thức định tuyến Multicast.
    Các giao thức định tuyến IP Multicast thường theo một trong hai dạng sau: dạng tập trung hoặc dạng phân tán
    • Định tuyến Multicast dạng tập trung
    Dạng tập trung: các thành viên nhóm Multicast được phân bố tập trung trong toàn mạng với nhiều mạng con chứa ít nhất một thành viên nhóm, có đặc trưng là chiếm băng tần lớn. Các giao thức định tuyến dạng tập trung gồm: DVMRP, MOSPF và PIM-DM. Các giao thức này dựa vào kỹ thuật phát tán thông tin tới tất cả các router mạng.
    • Định tuyến Multicast dạng phân tán
    Dạng phân tán: thành viên nhóm nằm phân tán tại nhiều vùng của mạng và không yêu cầu băng tần lớn. Nó dựa vào kỹ thuật lựa chọn để thiết lập và duy trì cây multcast, sử dụng một quá trình khởi tạo máy thu (receiver-initiated process). Có nghĩa là một router chỉ xây dựng cây phân phối Multicast khi một trong các host thuộc mạng con của nó là thành viên của một nhóm muticast nào đó. Các giao thức định tuyến dạng sparse gồm: cây dựa vào lõi (CBT) và PIM-SM.
    Các giao thức chuyển tiếp muticast sử dụng một trong hai kỹ thuật sau:
    • Cây gốc – nguồn (SRT). Khi sử dụng giao thức cây gốc-nguồn, một cây kết nối mỗi nguồn trong một nhóm tới các thành viên của nhóm đó. Các liên kết SRT tạo ra các đường nối từ nguồn Multicast tới các thiết bị thu. Khi có một cây gốc- nguồn cho một nguồn Multicast và các thành viên của nhóm thì tất cả lưu lượng tới thành viên đều qua cây này. Cả hai giao thức DVMRP và MOSPF đều sử dụng kỹ thuật này.
    • Cây chia sẻ. Cây chia sẻ dành cho các nhóm Multicast phân tán tức là có kết nối mạng ở mức thấp. Đường chuyển tiếp multicat dựa vào một router điểm hội tụ giữa nguồn Multicast và các đích. Router lõi chuyển datagram Multicast qua một cây chia sẻ tới các thành viên của nhóm. Cây chia sẻ chỉ sử dụng một cây đơn giữa tất cả nguồn và máy thu của một nhóm Multicast cho trước. Hai giao thức sử dụng kỹ thuật này là: CBT và PIM-SM.
    Dưới đây là một số thuật toán và giao thức cơ bản đặc trưng nhất của IP Multicast.
    1.3.1 IGMP
    IGMP được các Mrouter sử dụng để thông báo trạng thái thành viên của các host trên các đường kết nối trực tiếp. Điều này được thực hiện thông qua một loạt các truy vấn IGMP liên tục và các thông báo host thành viên.
    IGMP sử dụng một địa chỉ lớp D dành riêng là 224.0.0.1. Đây là một nhóm cố định cho tất cả các hệ thống IP Multicast. Nó đảm bảo tính sẵn sàng của 1 địa chỉ Multicast thông qua subnet có thể liên kết với Mrouter của nó. Một host hỗ trợ Multicast phải gia nhập tất cả các hệ thống nhóm cho mỗi giao diện mạng mà nó
    IGMP v1 được đưa ra trong RFC 1112 (tháng 8/1989) và v2 được chỉ ra trong RFC 2236 (tháng 8/1997). IGMP v3 được chỉ ra ra trong RFC 3376 (tháng 8/2002) là sự kết hợp của v1 và v2.
    1.3.1.1 IGMPv1
    Để tham gia vào một nhóm Multicast, một host sẽ gửi một thông điệp đăng ký nhóm đến router cục bộ của nó. Thông điệp này có tên là Membership Report IGMP chứa địa chỉ nhóm Multicast, thông báo cho router về địa chỉ Multicast mà host muốn tham gia vào. Địa chỉ Multicast 224.0.0.1 all-hosts được dùng như địa chỉ đích. Cứ 60 giây, một router trên mỗi phân đoạn mạng sẽ gửi truy vấn đến tất cả các host để kiểm tra xem các host này có còn quan tâm nhận lưu lượng Multicast nữa không? Router này gọi là IGMPv1 Querier và chức năng của nó là mời các host tham gia vào nhóm. Nếu một host muốn tham gia vào một nhóm, hoặc nó muốn tiếp tục nhận từ một nhóm mà nó đã tham gia, nó phải trả lời lại bằng thông điệp membership-report.
    Các host có thể tham gia vào các nhóm Multicast ở bất kỳ thời điểm nào. Tuy nhiên IGMPv1 không có cơ chế để cho phép một host rời khỏi một nhóm nếu host đó không còn quan tâm đến nội dung của nhóm Multicast đó. Thay vào đó, router sẽ kết luận là một cổng giao tiếp đó không còn thuộc về một nhóm Multicast nào nếu router không nhận được membership-report trong ba chu kỳ truy vấn liên tiếp. Điều này có nghĩa là, ở chế độ mặc định, các lưu lượng Multicast vẫn gửi vào một phân đoạn mạng trong ba chu kỳ truy vấn liên tiếp sau khi tất cả các thành viên của nhóm không còn lắng nghe lưu lượng Multicast nữa.
    Ngoài ra, router không giữ một danh sách đầy đủ các host thành viên cho từng nhóm Multicast. Thay vào đó, nó cần phải lưu những nhóm Multicast nào là đang tồn tại trên những cổng nào của nó.
    1.3.1.2 IGMPv2
    Phiên bản IGMPv2 giới thiệu một vài khác biệt so với phiên bản đầu tiên. Các gói tin truy vấn bây giờ được gọi là General Queries. Các gói này có thể gửi tới địa chỉ all-hosts hoặc tới từng nhóm cụ thể. Một cải tiến khác nữa là các host được phép rời khỏi nhóm. Khi một host quyết định rời khỏi một nhóm nó đã tham gia, nó sẽ gửi thông điệp LeaveGroup đến địa chỉ all-router 224.0.0.2. Tất cả các router trên một phân đoạn mạng nội bộ sẽ lưu ý thông điệp này và router truy vấn sẽ tiếp tục quá trình. Router sẽ hỏi rằng có còn host nào muốn nhận lưu lượng cho nhóm đó nữa không bằng thông điệp truy cập gửi theo nhóm. Bất cứ host nào cũng phải trả lời lại bằng thông điệp membership report. Nếu khác đi, router sẽ kết luận một cách an toàn là không cần thiết chuyển lưu lượng cho nhóm đó trên phân đoạn mạng đó.
    1.3.1.3 IGMPv3
    IGMP v3 là một dự thảo sơ bộ. Nó giới thiệu bổ sung bản tin Group- Source Report cho phép một host có thể quyết định nhận lưu lượng từ các nguồn riêng biệt của một nhóm Multicast. Một bản tin Group- Source Report cho phép một host chỉ ra địa chỉ IP của các nguồn riêng biệt mà nó muốn nhận. Một bản tin Exclusion Group- Source Report cho phép một host nhận dạng chính xác các nguồn mà nó không muốn nhận. Cuối cùng, bản tin Leave Group đã giới thiệu trong IGMPv2 đã nâng cao thành bản tin Group-Source Leave. Đặc điểm này cho phép một host dời khỏi toàn bộ nhóm hay chỉ ra các địa chỉ IP riêng biệt của cặp (nguồn, nhóm) mà nó muốn rời khỏi.

    1.3.2 PIM
    Các router Multicast sử dụng PIM để xác định các router Multicast khác cần nhận được gói Multicast. PIM có hai phương thức làm việc đồng thời thích hợp: Kiểu Dense (tập trung) và Sparse (phân tán). Hỗ trợ PIM hiện có trong một số sản phẩm router. Mục đích của việc nỗ lực phát triển PIM là để mở rộng định tuyến Multicast liên miền qua Internet. Định tuyến dựa vào giao thức PIM độc lập với các cơ chế của các giao thức định tuyến Unicast. Bất kỳ sự triển khai nào hỗ trợ PIM đều yêu cầu sự có mặt của một giao thức định tuyến Unicast để cung cấp thông tin bảng định tuyến và để làm thích nghi với những thay đổi về cấu hình.
    Các router hỗ trợ giao thức PIM được biết đến như các router PIM. Các router chạy giao thức PIM chọn một router PIM liền kề vào một hệ thống host như một host chỉ định. Thông thường là router có địa chỉ IP cao nhất. Định tuyến PIM sử dụng một cây giải thuật đường ngắn nhất. Một router PIM tồn tại ở gốc của mỗi cây đường dẫn ngắn nhất trong khi các router PIM liên kết trực tiếp hệ thống host được coi là các router lá. Các giao thức PIM không định nghĩa các bản tin cập nhật định tuyến, chúng cũng sử dụng giao thức định tuyến Unicast truyền thống trên mạng IP. Sự hỗ trợ này giúp bảo trì thông tin trạng thái bổ sung cho bảng định tuyến Unicast không hỗ trợ Multicast.
    Cả PIM- DM lẫn PIM- SM sử dụng chuyển tiếp đường dẫn đảo ngược. Một router nhận một gói Multicast dựa vào bảng định tuyến Unicast của nó để tìm nguồn và đường dẫn tốt nhất tới nguồn. Khi router nhận được một gói Multicast trên giao diện, bằng đường dẫn tốt nhất trở lại nguồn, router chuyển tiếp một bản sao của gói dữ liệu trên tất cả các giao diện khác. Các gói dữ liệu đến tại đầu vào giao diện được xem xét như đường lên của router. Các gói dữ liệu được chuyển tiếp tới đầu ra của giao diện được xem như đường xuống của router.
    1.3.2.1 PIM- Dense Mode
    Các PIM router có thể được cấu hình theo kiểu Dense Mode (còn gọi là PIM-DM) nếu các host tham gia vào nhóm Multicast nằm ở khắp nơi trên các subnet. Địa chỉ Multicast nguồn trở thành gốc của cây và cây Multicast được xây dựng từ nguồn đến đích. Cơ chế này còn được gọi bằng ký hiệu (S,G) trong đó đường đi từ nguồn đến các thành viên trong nhóm là duy nhất.
    PIM- DM hữu ích khi máy gửi và nhận là gần nhau ở đó ít máy gửi và nhiều máy nhận, mật độ lưu lượng Multicast cao, dòng lưu lượng Multicast không đổi.
    Cây Multicast được xây dựng bằng cách cho phép phát tán các lưu lượng từ nguồn đến tất cả các router trong mạng. Cây sẽ phát triển từ trên xuống dưới. Trong một thời gian ngắn, các lưu lượng không cần thiết sẽ được lưu chuyển giống như trong lưu lượng Broadcast. Tuy nhiên khi các router nhận được lưu lượng cho một nhóm, router sẽ quyết định nó có các máy muốn nhận dữ liệu hay không? Nếu là muốn, router sẽ duy trì tình trạng im lặng và để dòng lưu lượng tiếp tục. Nếu không có host nào đăng ký cho nhóm Multicast đó (thông qua IGMP), router sẽ gửi thông điệp Prune đến các router lân cận của nó theo hướng về gốc của cây. Nhánh của cây sau đó sẽ bị loại bỏ sao cho các lưu lượng không cần thiết sẽ không được phát tán về hướng đó.
    Cây Multicast sẽ được xây dựng theo các yêu cầu tham gia vào nhóm. Sau đó các switch không có các host tham gia sẽ bị xóa ra khỏi cây.
    PIM-DM sẽ nhận biết các thiết bị láng giềng bằng cách trao đổi các gói hello. Thông tin láng giềng này được dùng trước để xây dựng cây đến tất cả các láng giềng. Sau đó, các nhánh của cây sẽ lần lượt được loại bỏ. Khi một luồng Multicast bắt đầu, cây sẽ được xây dựng. Cây sẽ chỉ tồn tại khi các thành viên tích cực còn tồn tại. Nếu một host mới đăng ký tham gia nhóm, nhánh của phân đoạn mạng đó sẽ được đính thêm vào cây.
    1.3.2.2 PIM- sparse Mode
    PIM Sparse Mode (PIM-SM) dùng một giải pháp khác. Cây Multicast không mở rộng đến router cho đến khi nào một host đã tham gia vào một nhóm. Cây Multicast được xây dựng bằng các thành viên ở các nút lá và mở rộng ngược về gốc. Cây được xây dựng từ dưới lên. SM cũng hoạt động dựa trên ý tưởng cấu trúc shared-tree, trong đó gốc của cây không nhất thiết là nguồn Multicast. Thay vào đó, gốc là router PIM-SM thường được đặt ở trung tâm của mạng. Router làm gốc này gọi là Rendezvous Point (RP). Cây từ điểm RP đến các thành viên thật ra là một cây con của cây từ nguồn đến các thành viên. Nếu một router ở bất kỳ đâu trong mạng có thể đăng ký với RP, cấu trúc cây này sẽ hoàn tất. Chế độ spare-mode còn được gọi là Shared tree. Các dòng Multicast được mô tả như (*,G) bởi vì cây luôn cho phép bất cứ nguồn nào gửi đến một nhóm.
    Khi một host tham gia vào một nhóm Multicast dùng IGMP, router cục bộ sẽ chuyển các thông điệp Membership report về gốc của cây Multicast. Mỗi router dọc theo đường đi sẽ thêm nhánh đó vào cây chia sẻ shared-tree. Quá trình loại bỏ nhánh chỉ thực hiện khi một thành viên của nhóm bị xóa ra khỏi một nhóm.
    Chú ý là quá trình này chỉ bao gồm một bước. Các router không tham gia vào nhóm sẽ không bị loại bỏ vì nó không bao giờ là một thành phần của cây.
    PIM – Sparse hữu ích khi có một vài máy thu trong một nhóm, các máy thu và gửi được phân biệt bởi các đường link WAN, lưu lượng Multicast là không liên tục.
    1.3.2.3 PIM Sparse- Dense Mode
    PIM có khả năng hỗ trợ cả hai chế độ Dense và Sparse Mode bởi vì cả hai tồn tại trên những nhóm Multicast khác nhau trên một mạng. Cisco cho phép chế độ lai Sparse-Dense Mode cho phép một PIM router dùng chế độ Dense hay chế độ Sparse tùy thuộc vào từng nhóm. Nếu một nhóm có RP được định nghĩa, Sparse-Mode sẽ được dùng, nếu không có, Dense-Mode sẽ được dùng.
    1.3.3 DVMRP
    DVRMP bắt nguồn từ giao thức thông tin định tuyến (RIP) và sử dụng thuật toán TRPB( Truncated Reverse Path Broadcasting). Để tìm đường tốt nhất tới đích, nó sử dụng hop trước tới nguồn như đơn vị đo. DVMRP thiết lập cây nguồn sử dụng khái niệm cây broadcast rút gọn(Truncated Broadcast Tree- TBT). Đó là cây mở rộng đường đi ngắn nhất từ mạng nguồn tới tất cả các router trong mạng.
    Khi thiết lập cây, DVMRP cho phép router tràn lụt (flooding) datagram tới tất cả các giao diện trừ đường dẫn ngược về nguồn datagram. Các router DVMRP phải chạy các quá trình định tuyến riêng cho các gói Muticast và Unicast.
    DVMRP sẽ được hiểu một cách rõ ràng hơn với một ví dụ sau đây:


    Hình vẽ minh hoạ thiết lập cây broadcast rút gọn

    TBT được xây dựng cho tất các mạng con nhờ việc cập nhật thông tin định tuyến DVMRP định kỳ giữa các router trong mạng. Giống như RIPv2, thông tin cập nhật DVMRP chứa mặt nạ/tiền tố mạng cùng độ dài đường đi (theo hop count) cho biết giá để tới một mạng con cụ thể trong mạng. Tuy nhiên, khác với RIPv2 router DVMRP cấp dưới sử dụng quảng bá Poison- Reverse (PR) để thông báo cho một router cấp trên liên kết này thuộc TBT của mạng nguồn S1. PR này được tạo ra bằng việc thêm 32 vào metric được quảng bá và gửi lại về router cấp trên.
    Trong ví dụ trên, đang trao đổi thông tin cập nhật DVMRP cho mạng nguồn S1. Router A và B quảng bá metric 1 tới router C và D. Với router D, thông báo từ B là đường tốt nhất tới mạng nguồn S1. Router D gửi lại thông báo PR (metric = 33) tới B. Nó thông báo với B rằng router D thuộc TBT của mạng nguồn S1. Với router C, nó nhận thông báo từ cả A và B với cùng metric. Căn cứ vào địa chỉ IP thấp nhất, router C gửi thông báo PR trở lại router B. Bây giờ B biết rằng nó có hai nhánh của TBT, một tới router C, và một tới router D. Khi luồng thông tin cập nhật DVMRP qua toàn mạng mỗi router gửi thông tin PR tới router cấp trên trong TBT cho mạng nguồn S1.
    Kết hợp các bản tin PR, thu được S1 TBT như hình vẽ

    Hình minh hoạ Cây broadcast rút gọn S1

    Nếu có một nguồn Multicast được kích hoạt trong mạng S1, router DVMRP trong mạng sẽ bắt đầu phát fooding lưu lượng này qua S1 TBT.
    Nếu có một mạng nguồn khác như S2, cần một TBT cho S2 như sau

    Hình minh hoạ cây broadcast rút gọn S2

    Ví dụ flooding và rút gọn
    Nguồn S bắt đầu gửi lưu lượng Multicast tới nhóm G. Ban đầu lưu lượng được flooding tới tất cả các router trong mạng qua TBT và tới máy thu 1.

    Hình minh hoạ quá trình flooding

    Do router C là node lá trong TBT và không cần nhận lưu lượng, nó gửi bản tin rút gọn (S,G) DVMRP tới router B. Tương tự với router X,Y
    Router B nhận bản tin rút gọn (S,G) và cắt luồng của lưu lượng (S,G) tới router C. Router E nhận bản tin rút gọn từ tất cả router DVMRP lân cận trong mạng con, nó bỏ giao diện Ethernet nối với router X và Y. Lúc này, tất cả các giao diện luồng xuống của router E trong TBT đã bị loại bỏ và nó không còn nhu cầu nhận lưu lượng. Nó gửi bản tin rút gọn (S,G) tới router D trong TBT.

    Hình minh hoạ quá trình router rút gọn

    Router D nhận được bản tin này, nó cắt giao diện và lưu lượng tới router E.

    Hình minh hoạ trạng thái rút gọn cuối cùng

    Tuy nhiên vì DVMRP là giao thức ‘ flood và rút gọn’, các nhánh được cắt giảm của TBT sẽ time out và khi lưu lượng được phát flooding theo các nhánh của TBT, lại tiếp tục quá trình gửi các bản tin rút gọn tới TBT nhằm giảm lưu lượng không mong muốn.
    Các chức năng router DVMRP
    Khi một router DVMRP khởi tạo, nó tự coi là router chủ cho mạng con nội hạt cho tới khi nhận bản tin Host Membership Query từ router kế cận có địa chỉ IP thấp hơn. Để tránh nhân bản các datagram Multicast khi có nhiều router DVMRP trong một mạng con, thì một router được chọn là router bổ nhiệm cho mạng con nguồn cụ thể.
    Nếu có nhiều router DVMRP trong mạng con, các router chọn router có địa chỉ IP thấp nhất là router bổ nhiệm. Router này chịu trách nhiệm truyền định kỳ bản tin IGMP Host Membership Query.

    1.3.4 MOSPF
    Như các bạn đã biết thì OSPF là một giao thức định tuyến trạng thái liên kết, nội miền, thực hiện tái định tuyến nhanh, hỗ trợ mặt nạ mạng con có chiều dài biến đổi (VLSM) và định tuyến phân cấp trong một hệ thống tự trị (AS). AS có thể được chia thành các vùng định tuyến. Một vùng định tuyến thường gồm một hoặc nhiều mạng con gần nhau. Tất cả các vùng phải được kết nối với vùng đường trục. MOSPF là mở rộng của giao thức định tuyến unicast OSPF và do vậy đòi hỏi OSPF như giao thức định tuyến cơ sở.
    1.3.4.1 Định tuyến nội miền
    MOSPF sử dụng một loại LSA OSPF gọi là LSA thành viên nhóm để thông báo sự tồn tại của thành viên nhóm trong các mạng. LSAs thành viên nhóm được phát flood định kỳ trong cả vùng giống như LSA OSPF. Nó sử dụng thuật toán Dijkstra để tính toán cây đường đi ngắn nhất cho tất cả các cặp nhóm mạng- nguồn.
    Các bạn hãy xem một ví dụ như sau:

    Minh hoạ định tuyến nội miền

    Ở đây, vùng 1 có các thành viên của nhóm A,B trong khi vùng 2 chỉ chứa các thành viên của nhóm A. Các router nối trực tiếp với các thành viên tạo ra các LASs thông báo sự tồn tại của các thành viên trong mạng. LAS thành viên nhóm không truyền qua giữa vùng 1 và vùng 2.
    Khi tất cả router trong vùng biết vị trí của tất cả các thành viên trong cấu hình mạng, ta có thể thiết lập cây mạng – nguồn cho chuyển tiếp Multicast.
    Trong ví dụ trên, nguồn S1 nằm trong vùng 1 bắt đầu gửi lưu lượng Multicast tới nhóm B ( S1,B). Khi dữ liệu tới router trong vùng, nó thực hiện tính toán Dijkstra và tính toán cây đường đi ngắn nhất cho S1. Cây này nối tất cả thành viên nhóm B, và sử dụng cho chuyển tiếp tất cả lưu lượng mulitcast cho nhóm.
    Trong vùng 2, nguồn S2 bắt đầu gửi lưu lượng Multicast tới nhóm A. Router trong vùng sử dụng thông tin thành viên nhóm trong cơ sở dữ liệu MOSPF để thực hiện các phép tính và xác định cây đường ngắn nhất (Shortest path tree-SPT) cho mạng nguồn chứa S2. Lưu lượng được chuyển tới (S2,A) như minh họa.
    1.3.4.2 Định tuyến liên vùng
    Để truyền lưu lượng Multicast giữa các vùng , router biên vùng MOSPF (MOSPF area border router- MABR) sử dụng một cờ ‘ Wildcard Receiver’. Máy thu Wildcard thiết lập cờ ‘Wildcard Receiver’ trong LAS router. Cờ này tương đương với LSA thành viên nhóm wildcard thông báo rằng nó có một thành viên được kết nối trực tiếp cho tất cả các nhóm.
    Các MABR kết nối các vùng với vùng đường trục (vùng 0). MABR luôn nằm trong cây đường đi ngắn nhất của bất kỳ nguồn kích hoạt nào trong vùng không phải đường trục.
    Trong ví dụ này, MABR1 được thêm vào SPT cho lưu lượng (S1,B) và MABR2 được thêm vào ( S2,A). Điều này khiến lưu lượng nguồn trong vùng tới router biên sao cho nó có thể được chuyển tới vùng đường trục.
    Thêm vào đó, có khái niệm LAS thành viên tóm tắt mới( new Summary Membership LSA) dùng để tóm tắt thông tin thành viên nhóm. Nó gắn với vùng đường trục vùng 0, do vậy các router trong vùng đường trục biết sự tồn tại của các thành viên trong các vùng khác.

    Minh hoạ thiết lập đường truyền liên vùng

    Trong vùng trên, sự tồn tại của các thành viên của nhóm A và B trong vùng 1 được đưa tới vùng đường trục qua MABR1 thông qua LSA thành viên tóm tắt. Hơn nữa, MABR2 đưa dạng bản tin đó vào vùng đường trục, LSA này chỉ ra rằng vùng 2 có các thành viên nhóm A. Router vùng đường trục sử dụng thông tin trong bản tin để biết MABR nào thuộc SPT của nguồn nào.

    Minh hoạ truyền liên vùng

    Lưu lượng (S2,A) đang chuyển từ vùng 2 sang vùng đường trục (vùng 0) qua MABR2. Các router trong đường trục chuyển tiếp lưu lượng này tới MABR1 để chuyển tới vùng 1. Router trong vùng 1 thực hiện tính toán Dijkstra cho lưu lượng (S2,A) để thiết lập SPT (S2,A) trong vùng 1 để định tuyến lưu lượng tới các thành viên của nhóm A như minh họa.
    Trong trường hợp nhóm Multicast không có thành viên, lưu lượng vẫn được đẩy tới MABR do kết quả của kỹ thuật Wildcard Receiver. Điều đó khiến băng tần trong vùng được sử dụng không hiệu quả

    1.3.4.3 Định tuyến liên miền
    Cơ bản lưu lượng liên miền giống như lưu lượng liên vùng.
    Khi lưu lượng vào từ một miền khác thông qua router biên AS Multicast (MASBR), lưu lượng này được chuyển qua đường trục tới MABR dựa vào LAS thành viên nhóm rút gọn.

    Minh hoạ định tuyến liên miền

    Nhờ vậy lưu lượng Multicast cho nhóm A và nhóm B xuất phát từ ngoài AS được chuyển tiếp như hình vẽ trên. Kỹ thuật wildcard receiver tự động đẩy lưu lượng nguồn trong vùng. Vì vậy MASBR chuyển được lưu lượng ra ngoài.

    Minh hoạ hạn chế của định tuyến liên miền

    Flood trạng thái liên kết/ thành viên nhóm ảnh hưởng tới hiệu suất và cần phải tính lại thuật toán Dijkstra cho các nguồn Multicast đơn. Do vậy, MOSPF không phù hợp cho các mạng liên kết không ổn định, có quá nhiều cặp mạng-nguồn/nhóm kích hoạt đồng thời.

    ----
    Phần hai của bài viết trình bày về những thách thức của bảo mật nhóm trong IP Multicast. Và đưa ra ba vấn đề cần phải giải quyết để cung cấp bảo mật truyền thông nhóm theo quan điểm của nhóm nghiên cứu SMuG IRTF và nhóm làm việc MSEC IETF:

    2.1 Multicast và những thách thức trong vấn đề bảo mật nhóm
    Với ưu điểm về tiết kiệm băng thông như Multicast, nó là nền tảng để triển khai các dịch vụ đa phương tiện như phân phối dữ liệu, các chương trình truyền hình theo yêu cầu, hội thảo đa phương tiện... Tuy nhiên, khi nhìn vào thực tế chúng ta thấy rằng sau rất nhiều các công trình nghiên cứu và phát triển các giao thức Multicast trong thập kỷ trước, việc triển khai các ứng dụng của Multicast vẫn rất chậm chạp. Nguyên nhân chính là do các dịch vụ Multicast thiếu hỗ trợ về quản lý lưu lượng, độ tin cậy và bảo mật.

    Bảo mật trong Multicast đưa ra cho ta những thách thức kỹ thuật thú vị. Các nhà thiết kế Multicast đưa ra cách sử dụng của nó để phân phối nội dung dữ liệu một cách đồng thời tới số lượng lớn các bên nhận. Nếu chỉ các bên nhận đó được cho phép nhìn thấy nội dung, nội dung dữ liệu phải được mã hóa. Nhưng một khóa mã hóa có thể làm thế nào để được phân phối hiệu quả tới nhiều bên nhận? Hơn nữa, một khóa cho dữ liệu mã hóa nên được thay đổi theo chu kỳ, vì chúng ta không chấp nhận mã hóa nhiều dữ liệu với chỉ cùng một khóa. Và nó có lẽ nên được thay đổi khi các thành viên của nhóm thay đổi. Giả thiết rằng các thành viên nhóm trả tiền để nhận nội dung như các kênh TV đặc biệt, khi một thành viên rời khỏi nhóm, nhóm không thể bắt thành viên đó quên khóa. Thêm nữa là nó muốn thay đổi khóa khi một thành viên mới gia nhập nhóm (để chúng không thể ghi lại nội dung mã hóa mà chúng không được quyền hoặc gia nhập trong một thời gian ngắn để tìm hiểu khóa sau đó chúng sẽ giải mã nội dung mà không được cho phép).

    Vấn đề khác trong bảo mật thông tin là bảo vệ tính sự toàn vẹn và nhận thực dữ liệu. Với một mẫu khóa bí mật, ai đó đang kiểm tra dữ liệu phải biết cùng một bí mật mà được sử dụng để tạo trường kiểm tra tính toàn vẹn. Với thông tin hai bên thì điều đó không phải là vấn đề. Nếu Alice đang gửi cái gì đó cho Bob, với một trường kiểm tra tính toàn vẹn đã được tạo ra từ một khóa mà chỉ hai bên chia sẻ, nếu trường kiểm tra tính toàn vẹn hợp lệ, BoB biết được rằng chỉ có Alice hay Bob có thể đã tạo ra bản tin. Nếu Bob biết nó không phải của anh ấy thì nó phải là của Alice.

    Tuy nhiên, nếu cùng một kiểu đó được sử dụng trong thông tin nhóm, nơi mà Alice đang gửi nội dung tới hàng nghìn bên nhận, mỗi bên trong số hàng nghìn bên nhận đó sẽ phải biết cùng một bí mật mà Alice sử dụng để tạo trường kiểm tra bí mật. Điều này có nghĩa là nội dung có thể đã bắt nguồn từ bất kỳ thành viên nào của nhóm. Do vậy, Alice phải tin tưởng tất cả thành viên nhóm đọc dữ liệu.

    Có ba vấn đề cần lưu tâm trong việc cung cấp các dịch vụ bảo mật Multicast. Đầu tiên, các bên gửi cần phải mã hóa và nhận thực dữ liệu Multicast. Đối với việc mã hóa, các thành viên nhóm yêu cầu một khóa chung giữa chúng. Thêm nữa, điều khiển truy nhập có thể được tiến hành bằng sự phân phối một khóa chung tới các thành viên nhóm, mà không cần tới sự thay đổi mô hình IPMulticast. Khi các thành viên nhóm thay đổi, khóa chung có thể cần thiết phải thay đổi và phân phối lại tới nhóm mới của các thành viên đã được nhận thực. Do đó sự phân phối khóa nhóm khả định cỡ và các kiểu chuyển khóa là một phần quan trọng của giải pháp bảo mật Multicast. Tiếp theo, các thành viên phải có khả năng kiểm tra dữ liệu được nhận đã thực sự được gửi bởi một thành viên đã được nhận thực hay không. Bởi vậy nhận thực nguồn gốc dữ liệu và mã hóa dữ liệu là một trong những vấn đề cần lưu tâm.

    Thêm nữa, những ứng dụng Multicast khác nhau- trong phạm vi từ việc thông tin đa người dùng tới phân phối dữ liệu từ một tới nhiều người dùng có những yêu cầu biến đổi đối với các hệ thống đầu cuối, truyền thông và bảo mật. Chính sách nhóm cho phép chủ nhóm hay nhà cung cấp nội dung chỉ rõ các yêu cầu cũng như trạng thái nhóm mong muốn được thay đổi trong môi trường hoạt động.

    2.2 Vấn đề 1: Nhận thực dữ liệu Multicast
    Vấn đề nhận thực dữ liệu Multicast bao gồm ba yếu tố: toàn vẹn dữ liệu, nhận thực, và không- từ chối.

    Bên nhận phải có khả năng xác định dữ liệu đã không bị chỉnh sửa bởi các thành viên khác của nhóm Multicast hay của các kẻ địch bên ngoài. Tính chất này được gọi là bảo vệ tính toàn vẹn.
    Các bên nhận cần phải có khả năng thiết lập nguồn của dữ liệu, ít nhất là cho chính chúng. Nói cách khác, ta cần nhận thực gốc dữ liệu.
    Một phiên bản mạnh hơn của các tính chất trên, được gọi là không- từ chối, cho phép bên thứ ba kiểm tra nguồn dữ liệu.

    Toàn vẹn dữ liệu và nhận thực dữ liệu liên quan chặt chẽ với nhau. Chú ý rằng nếu dữ liệu đã bị chỉnh sửa trong khi truyền dẫn, nguồn không còn còn là điểm bắt đầu của dữ liệu nữa. Tương tự, nếu một bên nhận có thể thiết lập nguồn của dữ liệu (ít nhất là cho chính nó), dữ liệu đã không bị chỉnh sửa trên đường đi. Do vậy toàn vẹn dữ liệu và nhận thực dữ liệu là phụ thuộc vào nhau. Không- từ chối bản chất là một phiên bản mạnh hơn của nhận thực dữ liệu. Nói cách khác, một giao thức hay cơ chế đảm bảo không từ chối thì cũng đảm bảo nhận thực.

    Hai cơ chế khác nhau thường được sử dụng cho nhận thực nguồn. Đầu tiên là sử dụng chữ ký số cho không- từ chối, và thứ hai là sử dụng MAC chỉ cho việc nhận thực. Phải nhắc lại rằng không- từ chối là dạng mạnh hơn của nhận thực. Tuy nhiên, trong khi MAC không thể cung cấp không- từ chối thì chúng lại hiệu quả hơn khi so sánh với chữ ký số. Đăng ký số mỗi gói của luồng dữ liệu đắt đỏ ghê gớm (cả việc tính toán cùng với việc đảm bảo thông tin tiêu đề cho mỗi gói).

    Trong truyền thông Unicast, MAC hỗ trợ nhận thực dữ liệu như sau: Trong thông tin ngang hàng, Alice và Bob cùng giữ một khóa bí mật để nhận thực. Alice sử dụng khóa và hàm một chiều để tính hàm băm khóa của bản tin và gửi bản tin cùng với MAC tới bên nhận. Bob lặp lại thủ tục để tính MAC, và so sánh nó với MAC nhận được. Nếu các MAC tương ứng, Bob biết được rằng bản tin đã không bị chỉnh sửa trên đường đi. Anh ấy cũng biết được rằng anh ấy không gửi bản tin và do vậy Alice phải gửi nó, giả thiết rằng khóa nhận thực không bị tổn hại. Tuy nhiên, một bên thứ ba không thể kiểm tra bản tin đã được gửi bởi Alice hay Bob. Do vậy, MAC không thể cung cấp không- từ chối.

    Chúng ta có thể sử dụng MAC cho các phiên truyền thông nhóm nhận thực bằng những thủ tục tương tự như ở trên, nhưng với cấp độ giảm hơn về bảo mật. Chú ý tới nhóm, bao gồm Alice, Bob và Cindy, giữ một khóa nhận thực. Alice có thể sử dụng một MAC để nhận thực bản tin gửi tới Bob và Cindy. Bob (hay Cindy) không biết bản tin đã được gửi hay chỉnh sửa lần cuối bởi Alice hay Cindy (hay Bob). Thông thường, các thành viên nhóm có thể chỉ kiểm tra được các đối tượng không phải thành viên, người mà không giữ khóa nhận thực nhóm thì không thay đổi được dữ liệu trong khi truyền dẫn. Tính chất này đảm bảo chỉ bản tin được gửi hay sửa đổi bởi một thành viên của nhóm và được gọi là nhận thực nhóm.

    Nhận thực nguồn có thể thực hiện được bằng cách sử dụng chữ ký số. Bên gửi chia nhỏ dữ liệu thành từng khối. Với mỗi khối, nó tính toán một giá trị hash, đánh dấu hash và gửi chữ ký đi với khối dữ liệu. Khi kích thước mỗi khối tăng, bên gửi sử dụng ít chữ ký số hơn và các thành viên sử dụng kiểm tra chữ ký ít hơn. Tuy nhiên, một thành viên cần nhận một khối dữ liệu đầy đủ trước khi kiểm tra tính nhận thực của nó. Đối với các khối kích thước nhỏ hơn, số lượng chữ ký và kiểm tra tăng lên. Ưu điểm là các thành viên không cần đợi lâu trước khi kiểm tra và sử dụng một khối dữ liệu. Tuy nhiên, trong thực tế, đánh dấu mỗi gói trong luồng thời gian thực tốc độ cao là không khả thi. Sử dụng các chữ ký một lần có chút ít hiệu quả hơn so với đánh dấu mỗi gói. Nhưng chữ ký một lần yêu cầu số lượng lớn tính toán hash và không thể điều khiển tổn thất gói.

    Trong phạm vi bài viết trên diễn đàn, tôi sẽ chỉ nêu hai phương pháp cho nhận thực nguồn sử dụng chữ ký số được áp dụng cho dữ liệu kiểu khối và dữ liệu kiểu luồng:

    2.2.1 Hashing khối
    Có hai kiểu hashing khối thường được sử dụng là Star hashingTree hashing:

    Star hashing
    Bên gửi chia một khối dữ liệu thành m gói. Nó đánh dấu một hash của khối (block hash), và rồi làm giảm giá của chữ ký thông qua m gói. Để nhận thực từng gói riêng rẽ, nó tính toán các hash h1, h2,…,hm của m gói. Hash khối, h, là hàm hash(h1, h2,…,hm), trong đó, hi = hash(Pi), Pi là gói thứ i. Với mỗi gói, bên gửi bao gồm hash khối và các hash của tất cả các gói trong khối. Nó cũng gửi vị trí tương đối của gói trong khối.

    Hình dưới đây minh hoạ kỹ thuật star hashing. Các nhánh là các hash của các gói, và gốc là hash khối. Trong hình cũng mô tả mối quan hệ giữa các hash của các gói và hash khối; đó là: hash khối phụ thuộc vào tất cả các hash nhánh.

    Minh hoạ star hashing

    Trong lúc tiếp nhận gói Pi, bên nhận tính toán hash của nó, gọi là h’i. Nó lặp lại thủ tục tính toán hash như bên gửi. Nếu hash khối đã đánh dấu trùng với hash khối đã tính toán, bên nhận biết được rằng Pi đã được nhận thực. Hơn nữa, nó cũng biết được rằng những hash còn lại cũng được nhận thực, nếu không thì việc so sánh hash khối đã thất bại. Đối với các gói khác trong cùng một khối, bên nhận chỉ cần kiểm tra hash của gói đã được tính xem có bằng với hash nhận được hay không. Nói cách khác, chỉ có một hoạt động kiểm tra chữ ký đơn lẻ cho mỗi khối tại các bên nhận.

    Bên nhận sử dụng một hoạt động kiểm tra chữ ký và hai lần tính toán hash để kiểm tra tính nhận thực của gói đầu tiên nhận được của một khối. Đối với những gói khác của block đó, một tính toán hash đơn lẻ và so sánh là đủ. Cũng phải nhắc lại rằng mỗi gói cần mang các hash của toàn bộ các gói (m) trong một khối, cũng như là một chữ ký số. Một hash thường có độ dài 20 bytes ( sử dụng SHA-1), trong khi đó một chữ ký số thường có kích cỡ 128 bytes.

    Tree hashing
    Tree hashing sử dụng một cơ chế tính toán hash khối khác so với hashing kiểu star. Trong khi cơ chế tính toán hash tự nó đã phức tạp hơn và không hiệu quả, điều này làm giảm thông tin tiêu đề liên kết với hash.
    Bên gửi chia khối dữ liệu thành m gói và tính toán các hash của từng gói riêng rẽ. Đối với việc tính toán hash khối, nó liên kết mỗi hash gói riêng rẽ với node nhánh của cây hash. Mỗi hash của node nội bộ là hash được ghép từ các hash con, do vậy h12= hash (h1, h2). Bằng việc sử dụng hàm này, bên gửi tính toán đệ quy ra được hash của gốc. Với mỗi gói, bên gửi bao gồm hash khối đã đánh dấu, packet ID, và các hash anh em của tất cả các node trong đường dẫn của gói hiện thời đến gốc.

    Các bên nhận theo thủ tục tương tự hash kiểu star để kiểm tra tính nhận thực của mỗi gói. Đầu tiên, bên nhận tính toán hash của gói đã nhận. Nó sử dụng hash đã tính toán và các hash đã nhận để tính hash gốc. Nếu hash gốc đã tính toán trùng với hash khối đã đánh dấu, gói bên nhận được nhận thực.

    Chúng ta sử dụng hình dưới đây để mô tả quá trình tính toán tại bên nhận. Giả sử P2 là gói đến đầu tiên. Bên nhận tính toán h’2 cho gói đã nhận. Với P2, bên gửi bao gồm các hash anh em của tất cả các node trên đường dẫn của P2 tới gốc. Trong ví dụ này, nó bao gồm các hash h1, h34 và h58. Bên nhận tính toán h’12= hash (h1, h’2), h’14= hash (h’12, h34), và h’18= hash (h’14, h58). Nếu h’18 và hash khối đã đánh dấu là h18 tương đồng, P2 đã được nhận thực. Hơn nữa, các hash nhận được và các hash đã tính toán là h1, h34, h58, h2, h12, h14 cũng được nhận thực. Bên nhận nhớ đệm các node đã kiểm tra của cây hash để kiểm tra hiệu quả hơn các gói khác trong cùng một khối.

    Minh hoạ tree hashing

    Hình trên cũng mô tả ưu điểm của việc nhớ đệm kiểm tra các node hash. Ví dụ, nếu lần tiếp theo nhận được P4, bên nhận chỉ cần tính h’34 và so sánh với h34 đã được kiểm tra từ trước. Nếu chúng đồng nhất thì coi như P4 đã được nhận thực.

    Kiểm tra nhận thực của gói nhận được đầu tiên của một khối bao gồm hoạt động kiểm tra chữ ký số và tính toán tất cả các hash trong đường dẫn từ vị trí gói hiện tại trong cây tới gốc. Tổng cộng, bên nhận cần tính logm hash. Việc kiểm tra các gói tiếp theo đó yêu cầu tính toán hash ít hơn và không cần hoạt động kiểm tra chữ ký số.

    Ưu và nhược điểm của Star hashing và tree hashing:
    Chữ ký khối được sử dụng bởi star hashing và tree hashing có một số nhược điểm. Bên gửi muốn có trước một khối dữ liệu khả dụng để tính các hash và chữ ký số. Do vậy, cơ chế này gây trễ trong truyền dẫn luồng. Hơn nữa, bên gửi cần có bộ đệm để lưu trữ khối dữ liệu, nếu m lớn, ta cần một bộ đệm lớn tại bên gửi, cơ chế này còn làm gia tăng độ dài tiêu đề gói tin. Cuối cùng, bên gửi có thể truyền cả một khối các gói cùng lúc sau khi nhận thực, điều này có thể dẫn đến sự bùng nổ băng thông dễ dẫn đến mất gói.
    Tuy nhiên, số lượng chữ ký số trên mỗi luồng giảm khi tăng m. Thêm nữa là bộ đệm bên nhận không phải là bắt buộc. Các bên nhận có thể kiểm tra mỗi gói khi mà chúng nhận được. Hash khối cũng hỗ trợ không- từ chối do hash được đánh dấu bởi bên nhận.

    2.2.2 Chuỗi hash cho nhận thực dữ liệu kiểu luồng
    Chuỗi là giải pháp chung cho việc giảm giá chữ ký số đối với nhận thực dữ liệu kiểu luồng. Đối với truyền dẫn tin cậy của dữ liệu kiểu luồng, ta giả thiết rằng bên gửi đã có sẵn luồng dữ liệu khả dụng.
    Chuỗi hash làm việc như sau: Đầu tiên, bên gửi chia dữ liệu thành n khối. Tiếp theo, nó tính hash (sử dụng MD5 hoặc SHA-1) của khối đầu tiên, đánh dấu tải tin hash, và gửi chữ ký tới các bên nhận. Sau đó nó gửi mỗi khối đã được gắn thêm hash của khối ngay sau nó trừ khối cuối cùng không có hash. Hình dưới đây mô tả chuỗi hash. Dữ liệu được chia vào n khối từ B1 tới Bn. Trong hình vẽ, hash B1 của khối đầu tiên được đánh dấu. Khối đầu tiên bao gồm hash của B2 cùng với dữ liệu B1. Điều này tiếp tục cho tới khối Bn-1 chứa hash của Bn. Khối cuối cùng không chứa hash.

    Hình minh hoạ chuỗi hash

    Mỗi thành viên kiểm tra chữ ký bên gửi, tách hash của khối chữ ký số, và lưu trữ hash. Khi khối đầu tiên tới, bên nhận tính toán hash và so sánh với hash đã lưu trữ. Nếu các hash đồng nhất, tính toàn vẹn và nhận thực của khối thứ nhất được thiết lập. Tiếp tục tách hash của khối thứ hai và lưu trữ chúng. Nó lặp lại thủ tục kiểm tra cho đến khối cuối cùng. Nếu các gói nhận được đúng thứ tự, các bên nhận chỉ cần bộ đệm để lưu trữ một khối và một hash.

    Chú ý rằng do chuỗi nhận thực kết thúc trong một gói chữ ký, chuỗi hash cung cấp không- từ chối. Bất kỳ bên thứ ba nào có thể lặp lại thủ tục kiểm tra tính độc lập và xác định nguồn dữ liệu.
    Chuỗi hash hết sức hiệu quả, chỉ có một khóa công khai duy nhất hoạt động tại bên gửi (chữ ký) và tại mỗi thành viên (kiểm tra). Thêm nữa, tính toán hash thường nhanh hơn 1000 lần so với tính khóa công khai. Thông tin tiêu đề cũng nhỏ. Tổng cộng, cơ chế này tăng thêm một chữ ký (128 bytes) và n hash (n * 20 bytes với SHA-1) đối với tiêu đề trong nhận thực toàn bộ luồng dữ liệu.

    Thật không may là chuỗi hash có một vài giới hạn trong thực tế sử dụng. Đầu tiên, nó chỉ làm việc khi bên gửi có trước toàn bộ luồng dữ liệu khả dụng. Quan trọng hơn là nhận thực chỉ có thể hoàn thành khi gửi các khối theo thứ tự một cách chính xác. Kiểu hash chuỗi này không cho phép tổn thất gói. Các bên nhận không thể nhận thực bất kỳ gói tiếp theo nào khi một đoạn bất kỳ của khối bị mất khi truyền dẫn.Việc nhận các khối không đúng thứ tự cũng là một rắc rối. Một khối không đúng thứ tự phải được giữ lại ở bộ đệm cho đến khi tất cả các khối đứng trước nó được nhận và kiểm tra.

    Giản đồ biểu diễn chuỗi hash
    Chuỗi hash sẽ được hiểu tốt hơn với một giản đồ biểu diễn nhận thực. Mỗi gói chứa thông tin nhận thực biểu diễn bằng một node trên giản đồ. Như vậy một gói chứa hash hay chữ ký số là một node trên giản đồ. Một cạnh gắn trực tiếp biểu diễn mối quan hệ nhận thực giữa hai gói. Nếu gói Pi chứa hash của gói Pj, sẽ có một cạnh nối trực tiếp từ Pi tới Pj. Tương tự, có một cạnh trực tiếp từ gói dữ liệu Pi tới gói chữ ký nhận thực trực tiếp cho Pi. Cuối cùng, để nhận thực nguồn cho gói Pj phải có một đường dẫn từ Pj tới gói chữ ký.

    Hình minh hoạ giản đồ chuỗi hash

    Hình trên mô tả một chuỗi hash được biểu diễn như một giản đồ trực tiếp. Quan trọng nhất là chỉ có một đường dẫn từ bất kỳ node nào tới gốc. Cũng chú ý rằng nếu một gói bị mất khi truyền dẫn, node tương ứng trên giản đồ sẽ bị xóa. Do vậy không thể có đường dẫn nào từ bất kỳ các gói tiếp theo gói bị mất tới gói chữ ký.

    Chuỗi hash đơn giản này có hai hạn chế cần thiết được bổ xung. Đầu tiên, bên gửi cần phải biết trước toàn bộ luồng dữ liệu. Thứ hai là kiểu nhận thực này không cho phép tổn thất gói. Cần phải nhắc lại rằng chúng ta đều muốn hỗ trợ nhiều hơn các ứng dụng cần nhận thực trong thời gian thực và trong điều kiện có tổn thất gói.

    Chú ý rằng chuỗi hash đã được giải thích ở trên sử dụng chuỗi chuyển ngược. Nghĩa là Pi chứa thông tin nhận thực của Pj, mà i<j. Trong dạng đơn giản nhất của chuỗi ta có j= i + 1. Chuỗi chuyển ngược yêu cầu tất cả luồng phải khả dụng trước khi truyền dẫn, nhưng có ưu điểm là nhận thực ngay lập tức tại bên nhận (giả thiết rằng phân phối đúng thứ tự gói). Chuỗi chuyển tiếp là dạng đối lập với chuỗi chuyển ngược trong đó gói chữ ký theo sau các gói dữ liệu. Do vậy bên gửi có thể bắt đầu gửi dữ liệu thời gian thực trong khi đó bên nhận không thể nhận thực dữ liệu cho đến khi nhận được gói chữ ký, chuỗi chuyển tiếp sẽ dẫn đến trễ nhận thực.

    Chìa khóa cho việc chấp nhận tổn thất gói là gửi hash của gói trên nhiều gói, và đưa nhiều hash (của các gói khác nhau) vào trong các gói chữ ký. Truyền dẫn tin cậy của các gói chữ ký là điều cốt yếu trong kiểu này. Chú ý rằng trong việc hỗ trợ chấp nhận tổn thất, tiêu đề các gói tăng lên. Ngoài ra, cùng với số lượng các gói chữ ký tăng lên, giá thành đánh dấu và kiểm tra tại bên gửi và bên nhận cũng tăng lên tương ứng.

    Ngoài ra đối với các luồng không tin cậy, nhận thực nguồn dựa trên MAC (Message authentication code) được đưa vào sử dụng. Trong kiểu nhận thực này, dù cho có một số gói bị rớt trong khi truyền dẫn thì bên nhận vẫn có thể lấy được khoá MAC nhận thực dựa vào các gói đến sau. Cơ chế của kiểu nhận thực này như sau:

    Bên gửi tạo ra một chuỗi khóa MAC: k1, k2,…kt, sử dụng một hàm một chiều f. Để làm như vậy, đầu tiên nó tạo ngẫu nhiên khóa cuối cùng kt của chuỗi và sử dụng phương trình kj-1 = f(kj), tạo ra những khóa còn lại. Chú ý rằng trong định nghĩa hàm một chiều, từ kj-1 cho trước, không thể tính được kj. Bên gửi tạo các khóa MAC k’j = g(kj), 1 ≤ j ≤ t, trong đó g là hàm một chiều khác.

    Với một khóa cho trước, ka trong chuỗi, bên nhận có thể tính tất cả các khóa ki, i < a, bằng cách áp dụng lặp lại hàm một chiều f. Do vậy, cho dù một số khóa bị mất trong khi truyền dẫn, bên nhận có thể tính chúng khi nó nhận được một khóa sau đó trong chuỗi. Nói cách khác, giao thức này cho phép tổn thất gói. Sau đó là một chuỗi các xử lý ở bên nhận để tính toán nhận thực nguồn cho dữ liệu.
    This article was originally published in forum thread: IP Multicast & Group security started by KIRA View original post
    Comments 12 Comments
    1. Avatar của vanhungvi
      vanhungvi -
      bài viết hay quá!anh có thể gởi cho em bản đầy đủ được không ạ?
      email của em:vanhungvi122@gmail.com
      em cảm ơn ạ!
    1. Avatar của huynhlong
      huynhlong -
      cho em hoi: anh co tai lieu ve mang 3g khong. gui cho em dc khong?
      email:visaotoicodon_1505@yahoo.com.vn
    1. Avatar của boy_ict3000
      boy_ict3000 -
      chẳng biết lâu rùi anh còn lưu cái này ko. em đang cần tài liệu về ki thuat multicast. mong anh giúp đỡ. mail em la: minhdiep172@gmail.com
      ( hy vong la mình may mắn..hj)
    1. Avatar của aphao0510
      aphao0510 -
      may quá em đang cần tìm tài liệu về ip multicast mong anh giúp đỡ nhé mail em là : vancuong0510@gmail.com
      mong sớm được hồi âm của anh.
      thanks !
    1. Avatar của dinhdai1001
      dinhdai1001 -
      anh gửi cho em nha email của em là dinhdai1001@gmail.com
    1. Avatar của hoangbao1350
      hoangbao1350 -
      anh ơi,anh gui cho em bản đầy đủ với : hoangbao1350@gmail.com
      cam ơn anh nhiều
    1. Avatar của leduchao
      leduchao -
      Chào anh, anh có thể cho e xin bản đầy đủ được ko ạ:
      Mail: duchaoa3@gmail.com
    1. Avatar của firewallhi
      firewallhi -
      Hi all,
      Bài viết hay quá, ban có thể gửi cho mình tài liệu đầu đủ vào mail learnvtc@gmail.com

      Thanks
    1. Avatar của bahonxauxi
      bahonxauxi -
      Bài này rất hay, mình đang cần tài liệu về Multicast. Bạn vui lòng gửi tài liệu đầy đủ cho mình theo mail: nxtinfo@yahoo.com
      Thanks so much.
    1. Avatar của nguyenminh2
    1. Avatar của nguyenminh2
    1. Avatar của nguyenminh2