Re: [TICTOC] 答复: ´ð¸´: Please Comment on Practical Solutions for Encrypted Synchronization Protocol

[Cui Yang <[e-mail]>]

Hi, Danny

Please see inline below.

==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [e-mail]


> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表
> Danny Mayer
> 发送时间: 2012年3月12日 12:01
> 收件人: Dacheng Zhang(Dacheng)
> 抄送: [e-mail]
> 主题: Re: [TICTOC] 答复: ´ð¸´: Please Comment on Practical Solutions for
> Encrypted Synchronization Protocol
> 
> On 3/11/2012 10:05 PM, Dacheng Zhang(Dacheng) wrote:
> > Hi, See the inline please..
> >
> >>> -----邮件原件-----
> >>> 发件人: Danny Mayer [mailto:[e-mail]]
> >>> 发送时间: 2012年3月11日 7:27
> >>> 收件人: [e-mail]
> >>> 抄送: Dacheng Zhang(Dacheng); [e-mail]
> >>> 主题: 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?
[Cui Yang] It is recommended to encrypt all traffic in existing IPsec tunnel, since there has existed one, though IPsec AH or ESP-NULL is more essential.

> 
>  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
[Cui Yang] As we have analyzed in the new draft, encryption time has no influence to two-step protocol, and decryption time could be completely removed by using a "STEP method". So, there does exists practical solution for synchronization with encrypted timing packets, which does not decrease the time accuracy. Another proposal, is "identifier encrypted timing packets", named as "STIP method" in Sec 3.2, see also draft-xu-tictoc-ipsec-security-for-synchronization.

Our new draft has described and explained this. 

> 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
[Cui Yang] This is only talking about the constant encryption/decryption delay case, as Tal just commented. But referring to Tal's mail, there exists some concrete product using the exact method to solve this problem.

> 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.
[Cui Yang] This is not only from "some document", but from practical requirements. Lots of security GWs and other devices have been designed and deployed following the standard, which MUST support the implementation of all transportation in IPsec tunnel.

> 
> >>>
> >>> 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.
[Cui Yang]  So，there are cases where accurate synchronization is required when timing packets are transported in an encrypted way.

Thanks.

> 
> Danny
> _______________________________________________
> TICTOC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tictoc