On 3/11/2012 10:05 PM, Dacheng Zhang(Dacheng) wrote: > 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?
You lost me here. Why would you generate a new one if you already have one? Is there some benefit to doing so? 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. Of course it will. You need to put the timestamp in the packet before it gets put in the IPSec tunnel and the cost of the encryption of the packets cannot be taken into account since you don't know a priori how long it's going to take before it gets on the wire and you cannot have the wire driver timestamp the packets as they go out. As I said before your error budget has just gone out the window and the encryption does not benefit you in any way just because some document says to encrypt all packets. >>> >>> 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. Which gets back to the original question of why you are encrypting them in the first place. While you might be able to estimate or time how long it took to decrypt the packet on the receiving system. assuming you have a way of measuring that, you have no way of measuring this on the sender's system as it will only know after it's completed that action and its costs will be different on each end, not just because it takes different lengths of time (usually) to encrypt than to decrypt but also because the processor speeds are normally different. The only way for the receiver to know how long it took for the sender to encrypt the packet is if the sender sends a follow-on packet with this information. Danny _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
