My proposal is orthogonal to what is being discussed here. I believe it can be implemented alongside Harlan's proposal in suggest-refid.
I want to emphasize that my proposal is backwards compatible and can be implemented today without an extension field. Whereas Harlan's idea is super clever but it requires both the client and the server to understand an extension field. First off, to reiterate why I care about this, pretty much all the off-path attacks that we and Cisco have done have the following first step: Query the target client. Get the response. Learn its refID. Now you know the client's server. $Attack the server. (Potentially rinse and repeat if the client moves to another server.) Sure, mode 6 reveals this information but modern NTP configurations should prevent remote IPs from launching mode 6 queries, as it is not only an amplification vector and also leaks state making it easier to attack the system. (See also Cisco's "origin leak" bug [1].) So I do not have a "warm fuzzy" feeling when I see NTP leaking information. Especially since most NTP traffic is not usually cryptographically protected. I think NTP should leak less information, not more. My proposal offers a backwards compatible way for a system to limit the information leaked in its reference ID. It solves the IPv6 refID collision problem. And it seems to be compatible with what NTP is doing today. Some exceptions could be made for stratum 1 servers to broadcast to all clients that your refID is GPS or some other external source, if this really a problem. But we should be sure its really a problem, because information leakage always makes it easier to launch attacks. Much of this discussion has been regarding a future use case in which a client had two IP addresses B and C. This client sends a query from interface B and wants to make sure it is not in a timing loop with another system A who is taking time from interface B. One could deal with this usecase using Harlan's proposal, but this does not preclude my proposal running in parallel. To deal with this, the client "B and C" uses Harlan's extension field to signal "if you take time from me, put this nonce as your refID." If it decided to signal the *same* nonce to all clients, it has explicitly taken on the risk than an attacker can use this information as a first step in an attack, as I have described above. If it signals a different nonce to all clients, then it is protected from this. This non-backwards compatible feature would therefore only be used by systems that need it, eg those that have two IP addresses. All other systems could limit the amount of information being leaked in their refID by using my proposal. Sharon [1] http://www.talosintel.com/reports/TALOS-2016-0078/
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
