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

[Danny Mayer <[e-mail]>]

I really need to put an analysis together, but in the meantime a few
comments inline. Sorry for the delay in responding, I've been rather busy.

On 3/12/2012 6:03 AM, Cui Yang wrote:
> 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. 
> 

I apologize for not having had the time to read the new draft. I'll get
to it. I would need to know what this STEP method is.

>> 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.

The encryption/decryption delay is not constant, it will always be be
variable and different between encryption and decryption. If you are
already using an IPSec tunnel then you don't need to encrypt the packets
separately from the IPSec encryption, you just use what's in the IPSec
protocol. This is no different than sending packets over a standard
IP/UDP protocol stream. It's only different if you are sending packets
in the clear over IP/UDP.

> 
>> 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.

Encryption necessarily decreases accuracy and the question is whether or
not you can measure and re-mediate the effects of the
encryption/decryption processing.

Danny