Hi, See the inline please..
>> -----邮件原件----- >> 发件人: Danny Mayer [mailto:[email protected]] >> 发送时间: 2012年3月11日 7:27 >> 收件人: [email protected] >> 抄送: Dacheng Zhang(Dacheng); [email protected] >> 主题: Re: ´ð¸´: [TICTOC] Please Comment on Practical Solutions for >> Encrypted Synchronization Protocol >> >> On 3/8/2012 6:33 AM, Stewart Bryant wrote: >> > On 08/03/2012 11:08, Dacheng Zhang(Dacheng) wrote: >> >>>> I could see that if the *only* channel he has for data is encrypted >> >>>> then it would make sense to also send the timing encrypted. >> >>>> However it is not clear that this is the only channel available >> >>>> since there usually needs to be one in the clear to run the >> >>>> key exchange. >> >> [Dacheng Zhang] Do you mean there should be a IPsec AH channel or ESP >> Null channel for key exchange? >> >> As far as I know, IKEv2 and IKE can secure themselves and don't need an >> additional security channel to exchange keys. >> >> >> >> >> > My point is that unless there is something unusual about your system the >> > two ends can exchange IP packets any time they wish and use of the >> > secure channel is always optional. [Dacheng Zhang] The condition that we have discussed is that the two ends are connected with an insecure network, and they are mandated to generate an IPsec channel. In this case, if we securely transport the timing information. Should we re-use the ipsec encryption channel or generate a new one? If we use the ipsec encryption channel, then we need to consider whether the encryption and the decryption of the timing packets will introduce any error. >> >> Exactly my point. The packets are already encrypted by IPSec so there is >> nothing further needed. You error budget probablu goes out the window >> but at least noone else can read the packets. So what has been achieved >> here? [Dacheng Zhang] If a timing packet is encrypted, then we need to removed the error introduced by the encryption and decryption... There can be multiple ways and it would be nice if we can list them and give a compare. Not very sure you like this idea. >> >> Danny _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
