Kiểm thử NTS cho NTP: xác thực nguồn thời gian mà không bỏ quên độ chính xác

RFC 8915 mô tả NTS dùng TLS cho NTS Key Establishment (NTS-KE), sau đó dùng cookie và extension fields để xác thực trao đổi NTP. Mục tiêu là giúp client xác nhận bản tin liên quan tới phiên khóa đã thiết lập và giảm khả năng giả mạo. NTS không tự sửa asymmetry, oscillator kém, timestamp software hoặc server quá tải.

Do đó phải tách hai câu hỏi. Security plane: client có từ chối server/certificate/bản tin không hợp lệ và giữ bí mật khóa/cookie đúng cách không? Time plane: khi dùng nguồn hợp lệ, offset, frequency error, jitter và convergence có đáp ứng mục tiêu không? Một hệ thống có thể bảo mật nhưng không chính xác, hoặc chính xác trong lab nhưng fallback sang nguồn không xác thực khi lỗi.

Trước khi thử, định nghĩa threat model: giả DNS, server giả, replay packet, certificate hết hạn, cookie không hợp lệ, chặn TCP NTS-KE, chặn UDP NTP hay làm bất đối xứng delay. Không khẳng định “chống mọi tấn công thời gian” nếu test chỉ kiểm tra TLS handshake.

Topology gồm NTS-capable client, primary/secondary NTS server, DNS resolver, CA/trust store, network emulator và time reference độc lập. Thu packet ở hai phía emulator; lấy client/server log, NTS-KE status, NTP peer state và OS clock metrics. Nếu có thiết bị không hỗ trợ NTS, đặt nhóm đối chứng NTP thường để quan sát fallback.

Time reference phải tốt hơn đáng kể so với hiện tượng cần đo. Có thể dùng GNSS/PTP/lab reference đã hiệu chuẩn hoặc bộ so sánh clock độc lập. Ghi uncertainty của reference và timestamp path. Không dùng chính server NTS đang thử làm chuẩn duy nhất rồi kết luận offset bằng 0.

Chạy topology đường ngắn để calibration trước, rồi thêm latency, jitter, packet loss, reordering và asymmetry. Ghi đường thuận/nghịch riêng; symmetric RTT không bảo đảm one-way path đối xứng.

Khóa client/server implementation và version, OS/kernel, NTP polling interval, number of sources, selection algorithm, TLS version/cipher, certificate chain, DNS mode, MTU và network path. Ghi hardware/software timestamp, virtualization và CPU load vì chúng ảnh hưởng time quality.

Với certificate, thử valid, expired/not-yet-valid, wrong hostname, untrusted issuer, missing intermediate và rollover. Có nghịch lý bootstrapping: clock sai lớn có thể làm certificate bị coi là chưa hiệu lực/hết hạn. Test phải ghi initial clock error và behavior của implementation, không tự đặt clock gần đúng rồi bỏ qua ca khó.

Với cookie, thay đổi số lượng còn lại, reuse, corruption và server restart/rotation theo cách an toàn trong lab. Với network, tách TCP port của NTS-KE khỏi UDP 123; firewall có thể cho một pha nhưng chặn pha kia. Không quy lỗi chung là “NTP down”.

KPI security gồm NTS-KE success/failure reason, certificate validation, authenticated NTP response ratio, bad authenticator/replay rejection, cookie inventory/refresh và fallback mode. KPI time gồm offset, frequency error, jitter, root dispersion, reachability, time-to-synchronize, step/slew event, holdover drift và recovery.

Lớp · KPI · Bằng chứng · Câu hỏi pass/fail NTS-KE · TLS/cert result · Handshake + client log · Chỉ trust đúng chain/hostname Cookie · Acquire/refresh/reject · Extension fields + log · Không dùng cookie lỗi NTP auth · Valid response ratio · Packet + peer state · Bản tin giả bị loại Time quality · Offset/jitter · Reference comparison · Trong ngân sách đã chốt Recovery · Time-to-resync · Fault marker + time series · Không step ngoài policy Fallback · Mode/source change · Config + audit log · Không hạ cấp im lặng

Chuỗi bằng chứng cần nối event mạng với clock behavior. Ví dụ chặn NTS-KE khi client còn cookie: client có thể tiếp tục một thời gian; điều đó khác với chặn NTP data. Báo rõ thời điểm hết cookie, mất reach và chuyển nguồn.

Ma trận negative test có giá trị hơn một ca happy path. Mỗi ca chỉ đổi một biến và giữ initial clock, source list, poll interval như nhau.

Tình huống · Thao tác · Kỳ vọng · Rủi ro cần quan sát Valid · Chain/hostname đúng · NTS-KE và NTP thành công · Baseline Expired cert · Dùng cert hết hạn · Từ chối có log · Hạ cấp im lặng Wrong name · SAN không khớp · Từ chối · Bỏ kiểm tra hostname Bad cookie · Sửa extension/cookie · Loại response · Chấp nhận bản tin giả TCP blocked · Chặn NTS-KE · Hành vi theo cookie còn lại · Lỗi chậm khó thấy UDP blocked · Cho KE, chặn NTP · Không sync; alert rõ · Nhầm handshake là healthy Asymmetry · Tăng delay một chiều · Offset thay đổi có giải thích · Kết luận sai về server Server failover · Mất primary · Chuyển nguồn có kiểm soát · Clock step/source không trust

Pha A calibration với một client/server và reference. Pha B chạy happy path, xác minh NTS-KE, cookie và authenticated NTP. Pha C chạy certificate/cookie negative tests. Pha D thêm impairment. Pha E tăng số client và tạo reconnect/KE burst. Pha F failover primary/secondary và đo time quality xuyên suốt.

Scale test cần phân biệt steady NTP traffic với burst NTS-KE sau reboot diện rộng. Theo dõi TLS handshake latency/error, CPU, socket, rate limit, cookie issue rate và NTP response loss. Một server chịu được packet/s NTP không chứng minh chịu được đồng loạt key establishment.

• Ghi initial offset, trust store, source list và policy step/slew.
• Xác nhận DNS, TCP NTS-KE và UDP NTP riêng.
• Thu handshake, extension field metadata và peer statistics.
• So client clock với reference độc lập.
• Thử certificate expiry/rollover và hostname mismatch.
• Thử cookie corruption, depletion và server restart.
• Tạo latency, jitter, loss và asymmetry theo bậc.
• Tăng client scale, theo dõi handshake rate và server load.
• Ngắt primary; đo source selection, holdover và recovery.
• Khôi phục, kiểm tra không oscillation giữa nguồn.

Rollout theo nhóm nhỏ, giữ ít nhất hai nguồn độc lập và ghi rõ policy fallback. Nếu tổ chức không cho NTP thường, client phải fail closed có cảnh báo thay vì âm thầm dùng nguồn không xác thực. Nếu cho fallback có thời hạn, log phải cho biết thời điểm và nguồn.

Giám sát cả security lẫn quality: tỷ lệ NTS-KE lỗi theo nguyên nhân, certificate expiry, cookie refresh, source selection, reach, offset/jitter và số client unsynchronized. Alert certificate trước hạn nhưng cũng thử rollover thực tế; dashboard xanh không chứng minh client trust đúng chain mới.

Runbook sự cố cần phân biệt DNS, CA/trust, TLS, UDP reachability, server load, asymmetry và reference failure. Lưu gói capture có giới hạn, không để lộ dữ liệu nhạy cảm; bảo vệ log/keys và tuân thủ chính sách vận hành.

NTS xác thực trao đổi theo mô hình của RFC 8915, không bảo đảm server cung cấp thời gian đúng nếu chính server bị lỗi hoặc bị kiểm soát. Multi-source selection và monitoring độc lập vẫn cần thiết. Kết quả offset phụ thuộc topology, path asymmetry, oscillator, timestamp mode và load.

Implementation có thể khác về fallback, cookie cache, bootstrapping và log. Một client/server pair pass không đại diện toàn bộ hệ điều hành hay appliance. Phải lặp sau cập nhật version, certificate chain, firewall hoặc time architecture.

• NTS-KE: Pha thiết lập khóa qua TLS cho NTS.
• NTS cookie: Dữ liệu server cấp để client xác thực các trao đổi NTP sau đó.
• Offset: Chênh lệch giữa clock được đo và reference.
• Jitter: Biến thiên của phép đo thời gian.
• Holdover: Khả năng duy trì time quality khi mất nguồn tham chiếu.
• Step/slew: Điều chỉnh clock tức thời hoặc từ từ.
• Trust store: Tập CA/certificate được client tin cậy.