a) Điều khiển tắc nghẽn của giao thức TCP
Giao thức TCP áp dụng một số các cơ chế để đạt đƣợc hiệu năng cao và một trong những cơ chế đó chính là cơ chế điều khiển tắc nghẽn [20, 22]. Phụ thuộc vào mức độ của tắc nghẽn mạng, cơ chế này có thể hoạt động ở 2 miền thời gian. Ở miền thời gian nhỏ hơn cỡ thời gian đi về của một gói tin (khoảng từ 10 đến 100ms), điều
khiển tăng theo cấp số cộng và giảm theo cấp số nhân (AIMD – Additive Increase Multiplicative Decrease) đƣợc thực hiện với mục đích giữ cho việc truyền gói tin của mỗi dòng gói tin ở một tốc độ hợp lý so với băng thông của liên kết nghẽn cổ chai của mạng. Khi tắc nghẽn mạng trở nên gay gắt và nguy hiểm hơn, có rất nhiều gói tin bị mất. Ở thời điểm đó, giao thức TCP sẽ hoạt động ở miền thời gian dài hơn của những khoảng thời gian hết hạn truyền phát lại gói tin (1s, 2s, 4s, 8s,…), đây là nơi mà tấn công DoS tốc độ thấp khai thác.
Cơ chế điều khiển tắc nghẽn của giao thức TCP áp dụng khái niệm cửa sổ tắc nghẽn (cwnd). Cwnd là số lƣợng gói tin TCP đã gửi đi và chƣa có báo nhận. Dựa trên các thông tin phản hồi từ mạng, mỗi tiến trình TCP phía gửi sẽ sử dụng cửa sổ tắc nghẽn để thay đổi cửa sổ truyền gói tin. Nó xét đến khả năng của bên nhận và đặc điểm của mạng, do đó cơ chế này giúp tránh tắc nghẽn. Với tắc nghẽn mạng tạm thời, cơ chế truyền phát lại nhanh đƣợc thực hiện khi tiến trình TCP bên gửi nhận đƣợc 3 gói tin ACK giống nhau cùng yêu cầu bên gửi một gói tin. Trong trƣờng hợp tắc nghẽn mạng nghiêm trọng, nếu 3 gói tin ACK giống nhau không về đƣợc đến bên gửi, cơ chế timeout đƣợc thực hiện; nó có nghĩa là, mặc dù khoảng thời gian chờ phát lại gói tin (RTO) đã hết, một gói tin vẫn chƣa đƣợc báo nhận.
Tính toán thời gian chờ phát lại gói tin theo [17] nhƣ sau: Ký hiệu:
RTO: Thời gian chờ phát lại gói tin hiện tại.
RTT: Viết tắt của thời gian đi về của một gói tin.
RTTVAR: Sai khác thời gian giữa hai giá trị RTT của hai lần tính RTT liên tiếp (đã làm trơn).
SRTT: Thời gian đi về của một gói tin (đã làm trơn), dựa trên việc đo lƣờng thời gian đi về của gói tin hiện tại.
G: Đơn vị thời gian của đồng hồ (thƣờng ≤ 100ms). Ban đầu
RTO = 1s
Khi tính toán đƣợc giá trị RTT là R lần đầu tiên thì tiến trình TCP phía gửi đặt:
SRTT = R
RTTVAR = R/2
RTO = SRTT + max(G, 4 * RTTVAR)
Khi tính toán đƣợc giá trị RTT tiếp theo là R’ thì tiến trình TCP phía gửi đặt:
RTTVAR = (1 – β) * RTTVAR + β * |SRTT – R’|
SRTT = (1 - α) * SRTT + α * R’
Trong đó α = 1/8 và β = 1/4 (nhƣ đề nghị trong [9]).
RTO = max(minRTO, SRTT + max(G, 4 * RTTVAR))
Để tính đƣợc thời gian chờ phát lại gói tin hiện tại (RTO) thì cần phải tính đƣợc giá trị RTT hiện tại. Các nhà nghiên cứu đã chỉ ra rằng tính toán RTT cho mỗi gói tin không dẫn đến ƣớc lƣợng giá trị RTT tốt hơn [18]. Một ví dụ tính toán giá trị RTT hiện tại đƣợc mô tả nhƣ hình 2.2 (theo [19, 23]).
Hình 2.2: Tính toán giá trị RTT hiện thời
Chƣơng trình sock gửi 128 gói tin, mỗi gói tin là 256 bytes từ máy slip đến dịch vụ
discard của máy vangogh. Tổng thời gian truyền là 45 giây và ở đây chỉ đề cập việc gửi các gói tin dữ liệu và nhận các gói tin báo nhận trong 3s đầu.
Trong khi truyền dữ liệu trên máy slip ngƣời ta chạy chƣơng trình tcpdump ghi lại thời điểm gửi và nhận các gói tin.
Trong hình 2.2 đánh số các gói tin từ 1 đến 13 và 15 theo thứ tự chúng đƣợc gửi và nhận trên máy slip.
Ba dấu ngoặc nhọn bên trái thể hiện ba gói tin đƣợc tính RTT. Không phải tất cả các gói tin đều đƣợc tính RTT.
Một bộ đếm thời gian cho kết nối này đƣợc khởi động khi gói tin số 1 đƣợc gửi đi và tắt khi gói tin báo nhận của nó (gói số 2) trở về đến máy slip. Khi gói tin số 3 đƣợc gửi đi thì bộ đếm thời gian này lại đƣợc bật. Khi gói tin 4 đƣợc gửi đi 2.4 (ms) sau thì nó sẽ không đƣợc định thời (và nhƣ vậy sẽ không đƣợc tính RTT) bởi vì bộ đếm thời gian đã đƣợc bật. Khi gói 5 trở về đến máy slip báo nhận dữ liệu đã đƣợc định thời thì giá trị RTT hiện tại đƣợc tính và bộ đếm thời gian cũng bị tắt. Bộ đếm thời gian lại đƣợc bật trở lại khi gói 6 đƣợc gửi đi và tắt khi gói tin báo nhận của nó (gói 10) trở về đến máy slip. Gói 7 và gói 9 không đƣợc định thời vì bộ đếm thời gian đã đƣợc bật. Cũng vậy khi gói 8 đƣợc nhận (ACK 769 tức là yêu cầu bên gửi gửi các byte dữ liệu từ 769) thì không có gì để cập nhật cho RTT bởi vì báo nhận đó không phải cho byte đã đƣợc định thời (byte đƣợc định thời là 1025 khi gói 6 đƣợc gửi đi).
Khi tắc nghẽn mạng trở nên nghiêm trọng, cửa sổ tắc nghẽn của tiến trình TCP phía gửi giảm xuống còn một gói tin và giả sử giá trị RTO đƣợc thiết lập tại thời điểm đó là minRTO (=1s) (điều này có thể xảy ra nếu minRTO > SRTT + max(G, 4 * RTTVAR) → RTO=minRTO). Khi đó tiến trình TCP phía gửi tăng gấp đôi RTO từ 1s lên thành 2s và phát lại gói tin. Sau khoảng thời gian RTO là 2s nếu gói tin vẫn chƣa đƣợc báo nhận thì giá trị RTO lại đƣợc tăng gấp đôi thành 4s và cứ nhƣ thế. Đây là cơ chế lùi thời gian phát lại gói tin theo hàm số mũ để tiến trình TCP bên gửi thực hiện khi có hiện tƣợng tắc nghẽn mạng nghiêm trọng xảy ra, nó đƣợc chọn để thực hiện một cuộc tấn công LDoS.
b) Điểm yếu của cơ chế Timeout
Cơ chế Timeout của giao thức TCP thích hợp với tắc nghẽn mạng nghiêm trọng xảy ra nhƣng mặt khác nó cũng có sự rủi ro tiềm tàng bởi lỗ hổng cơ bản của nó. Theo cơ chế này giá trị nhỏ nhất mà RTO có thể nhận là 1s và trong lúc lùi thời gian phát lại gói tin theo hàm số mũ thì RTO nhận các giá trị là bội của 1. Do đặc điểm này của thuật toán, kẻ tấn công có thể tấn công bằng cách sử dụng các khoảng thời gian cách đều nhau, trong mỗi khoảng thời gian đó kẻ tấn công gửi các gói tin với tốc độ cao để làm tràn bộ đệm của kết nối nghẽn cổ chai. Nếu kẻ tấn công biết thời gian của bên gửi, hắn sẽ thực hiện tấn công “xung vuông” đó và liên tiếp làm cho bên gửi rơi vào trạng thái timeout trong khi thông lƣợng của máy chủ xấp xỉ bằng không.