Dưới đây là các trường hợp khác nhau của từng loại bản tin bị giả mạo. Chú ý rằng trước khi xử lý một bản tin MLD, nút sẽ xác minh rằng địa chỉ nguồn của bản tin có phải một địa chỉ link-local hợp lệ không,
trường Hop Limit có được thiết lập bằng 1 không, và tùy chọn Router Alert có được thể hiện trong mào đầu Hop-by-Hop Options của gói tin IPv6 không. Nếu bất kỳ kiểm tra nào trong các kiểm tra này xảy ra lỗi, gói tin sẽ bị loại bỏ. Điều này bảo vệ nút MLDv2 khỏi hoạt động trên các bản tin MLD bị giả mạo có nguồn gốc off-link. Do đó phần tiếp theo chỉ đề cập tới các ảnh hưởng của giả mạo on-link.
13.1 Bản tin Query
Bản tin Query bị giả mạo từ một máy với địa chỉ IPv6 thấp hơn so với Querier hiện tại sẽ làm cho nhiệm vụ Querier được chỉ định cho đối tượng giả mạo. Nếu sau đó đối tượng giả mạo không gửi đi bất kỳ bản tin Query nào, bộ đếm thời gian cho Querier khác của các router khác sẽ kết thúc và một router sẽ tiếp tục vai trò Querier. Trong suốt thời gian này, nếu Querier bỏ qua các bản tin Done, lưu lượng có thể sẽ chuyển sang những địa chỉ multicast không có đối tượng nghe trong thời gian lên đến [khoảng thời gian đối tượng nghe địa chỉ multicast].
Bản tin Query phiên bản 1 bị giả mạo sẽ đặt các đối tượng nghe MLDv2 trên liên kết đó sang chế độ tương thích host MLDv1. Kịch bản này có thể được tránh bằng cách sử dụng các host MLDv2 có tùy chọn cấu hình bỏ qua các bản tin phiên bản 1 một cách hoàn toàn.
Một tấn công DoS trên một nút có thể được tiến hành thông qua các bản tin Multicast Address and Source Specific Query bị giả mạo. Kẻ tấn công có thể tìm ra trạng thái nghe của một nút cụ thể vớimột bản tin General Query. Sau đó, chúng có thể gửi đi một lượng lớn các bản tin Multicast Address and Source Specific Query, mỗi bản tin này có một danh sách nguồn lớn hoặc/ và trễ phản hồi tối đa dài. Mỗi nút sẽ phải chứa và duy trì các nguồn được quy định trong tất cả các bản tin Query đó cho tới khi chúng gửi đi các phản hồi được làm trễ. Điều này có thể tiêu tốn cả về bộ nhớ và CPU khi ghi lại các nguồn trong danh sách nguồn của các bản tin Query thành công.
Để bảo vệ lại các tấn cống DoS như vậy, việc thực thi ngăn xếp nút sẽ giới hạn số lượng bản tin Multicast Address and Source Specific Query cho từng địa chỉ multicast trong khoảng thời gian này, và/hoặc chỉ ghi lại một số hữu hạn các nguồn.
13.2 Các bản tin Current State Report
Bản tin Report bị giả mạo làm cho các router multicast nghĩ rằng có các đối tượng nghe một địa chỉ multicast trên một liên kết trong khi không tồn tại đối tượng nào. Tuy nhiên, vì việc nghe một địa chỉ multicast trên một host là một hành động không cần cấp quyền, nên người sử dụng có thể đạt được các kết quả tương tự mà không giả mạo bất kỳ bản tin nào.
Bản tin Report phiên bản 1 bị giả mạo có thể đặt router vào trong chế độ tương thích địa chỉ multicast MLDv1 cho một địa chỉ multicast cụ thể, nghĩa là router sẽ bỏ qua các bản tin trạng thái nguồn cụ thể MLDv2. Điều này có thể làm cho lưu lượng chuyển từ những nguồn không mong muốn trong thời gian lên đến [khoảng thời gian đối tượng nghe địa chỉ multicast]. Điều này có thể được giải quyết bằng cách thiết lập các router có một cấu hình chuyển mạch cho phép bỏ qua các bản tin phiên bản 1 một cách hoàn toàn. Điều này phá vỡ tính tương thích tự động với các host phiên bản 1, nên nó sẽ chỉ được sử dụng trong trường hợp việc lọc nguồn là cần thiết.
13.3 Bản tỉn State Change Report
Bản tin State Change Report bị giả mạo sẽ làm cho Querier gửi đi các bản tin Multicast Address Specific Query và bản tin Multicast Address and Source Specific Query cho một nguồn nhất định dưới dạng hỏi đáp. Điều này gây ra những xử lý bổ sung trên mỗi router và trên mỗi đối tượng nghe của địa chỉ multicast nhưng không thể gây ra mất lưu lượng mong muốn.
Phụ lục A
Lý do thiết kế căn bản A.1 Sự cần thiết của các bản tin thay đổi trạng thái
MLDv2 chỉ rõ 2 loại bản tin Report: bản tin Current State Report và bản tin State Change Report. Phần này mô tả lý do căn bản cho sự cần thiết của cả hai loại bản tin Report trên.
Router cần phân biệt các bản tin Report được sử dụng cho việc phản hồi lại các bản tin Query cho việc thay đổi trạng thái của từng giao diện. Các bản tin Report được sử dụng chủ yếu để làm mới lạitrạng thái đang tồn tại của router, thì không gây ra sự chuyển đổi trạng thái tại các router. Các bản tin Report được gửi để phản hồi các thay đổi trong trạng thái từng giao diện, thì yêu cầu router có các xử lý để hồi đáp lại bản tin Report đã nhận (xem điều 7.4).
Việc không có khả năng phân biệt giữa hai loại bản tin Report sẽ làm cho router xử lý tất cả các bản tin Report giống như các thay đổi có khả năng xảy ra trong trạng thái và có thể làm tăng thêm các xử lý tại router cũng như làm tăng lưu lượng MLD trên liên kết.
A.2 Việc ngăn chặn host
Trong MLDv1, một host sẽ không gửi đi bản tin Report đang ở trạng thái chờ nếu một bản tin tương tự đã được gửi đi bởi một đối tượng nghe khác trên liên kết. Trong MLDv2, việc ngăn chặn các bản tin Report đã bị gỡ bỏ. Các ý sau giải thích rõ ràng tính năng này.
1. Các router có thể muốn theo dõi trạng thái đối tượng nghe multicast theo từng host trên một giao diện. Điều này sẽ cho phép router thực thi tính năng rời nhóm nhanh (ví dụ, cho cơ chế điều khiển tắc nghẽn multicast được phân tầng), cũng như theo dõi trạng thái đối tượng nghe cho các mục đích bảo mật hoặc thống kê. Tiêu chuẩn hiện tại không yêu cầu router thực thi việc theo dõi từng host. Tuy nhiên, việc không ngăn chặn các thông báo từ host trong MLDv2 tạo ra khả năng thực thi quyền sở hữu hoặc các cách xử lý chính xác trong tương lai của router (khi đó, router có khả năng hỗ trợ tính năng theo dõi từng host), trong khi tương tác với các đối tượng nghe và router MLDv2 đang thực thitiêu chuẩn này.
2. Việc ngăn chặn bản tin Report không hoạt động trên mạng LAN được bắc cầu (bridged LAN). Nhiều thiết bị bắc cầu hoặc các bộ chuyển mạch tầng 2/ tầng 3 thực thi MLD snooping không chuyển tiếp các bản tin MLD qua các phần tử LAN để hạn chế việc ngăn chặn báo cáo đối tượng multicast.
3. Việc chấm dứt ngăn chặn bản tin Report khiến host phải xử lý ít bản tin hơn; điều này dẫn tới việc máy thực thi có trạng thái đơn giản hơn.
4. Trong MLDv2, một bản tin Report đơn lẻ gộp nhiều Multicast Address Record để giảm số lượng góitin gửi đi. Để so sánh, phiên bản MLDv1 yêu cầu rằng mỗi địa chỉ multicast được báo cáo trong một bản tin riêng rẽ.
A.3 Chuyển chế độ lọc của router từ EXCLUDE sang INCLUDE
Nếu trên một liên kết có các nút ở các chế độ EXCLUDE và INCLUDE với một địa chỉ multicast độc lập, router phải ở chế độ EXCLUDE (điều 7.2.1). Trong chế độ EXCLUDE, router chuyển tiếp lưu lượng từ các nguồn nằm ngoài danh sách EXCLUDE. Nếu tất cả các nút trong chế độ EXCLUDE dừng nghe hoặc không còn khả dụng, router phải được chuyển ngược về chế độ INCLUDE một cách liền mạch, mà lưu lượng tới các đối tượng nghe đang tồn tại không bị gián đoạn.
Một trong nhiều phương án để thực thi điều này là cho phép các router theo dõi tất các nguồn mà các nút đang ở trong chế độ INCLUDE đang nghe, ngay cả khi router ở trong chế độ EXCLUDE. Nếu bộ đếm thời gian cho chế độ lọc cho một địa chỉ multicast kết thúc (tức là không còn nút nào trong chế độ EXCLUDE trên liên kết) thì sau đó router sẽ chuyển sang chế độ INCLUDE một cách liền mạch; các nguồn từ danh sách được yêu cầu sẽ chuyển sang danh sách INCLUDE, trong khi các nguồn trong danh sách EXCLUDE sẽ bị xóa bỏ.
Phụ lục B
(Tham khảo)
Bảng đối chiếu nội dung tương đương của TCVN 9802-5:2017 và tài liệu RFC 3810
TCVN 9802-5:2017 Tài liệu RFC 3810