On 3/15/2012 12:04 AM, Dacheng Zhang(Dacheng) wrote: > Hi, Yaakov: > > Thanks a lot for your time. See the inline please.. > >>> >>> Yes, I fully appreciate the scenario you are discussing, where ALL >>> packets MUST be encrypted. >>> >>> I am just questioning whether such a scenario is really mandated by >>> any standard (I believe it is not), in which case one can simply NOT >>> encrypt the timing packets (even if you choose to encrypt the other >>> packets). > > [Dacheng Zhang] > > Could you please answer a question first? Do you think it is really reasonable to send timing packets without any protection through an insecure network especially when they are critical for synchronizing distributed servers? I think the answer is no. Please correct me if I am wrong. ^_^ I just checked RFC 1305 and RFC 4330 again. They all mentioned that in such a condition, timing packets are vulnerable to different attacks and security protection is desired. So, no matter encryption is needed or not, we need to, at least, provide integrity protection and message origin authentication for timing packets.
Those RFC's have been superceded by RFC5905 (NTP Protocol) and RFC5906 (Autokey). > > We have realized that there are several use cases mentioned in the security requirement draft where encryption may need to be provided. However, I don't think whether timing packets are confidential is the core point of this discussion. If we don't worry whether timing packet will be easily identified by attackers, then we don't have to encrypt them. However, considering an attacker may try to disrupt synchronization by sending fault timing information. We insist that there should be a security manner to protect the integrity, freshness, and validity of timing packets. > > Now, let's go back to the scenario where a gateway has generated a large amount of IPsec ESP channels with the enodeBs which it manages. If we try to generate additional IPsec AH channel to transport timing packets, then the number of IPsec channels will be doubled, which will cause additional management burden and service providers will have to pay extra money since the system needs to provide more IPsec channels concurrently, which is not desired. Thus, we believe that it would be nice if we could transport timing packets through those IPsec ESP channels instead of generating new IPsec AH channel. > > However, the encryption and decryption of timing packets will introduce errors into the system. We just try to propose an informational draft and discuss whether we can efficiently and effectively address such issues. As mentioned in Tal's emails, there are efforts in transporting timing packets. Such information is very useful, and we will add it into our draft. > > Those are my humble opinions. ^_^ > > BR > > Dacheng _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
