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

From: Danny Mayer <[email-masked]>
Date: Wed, 23 May 2012 23:16:25 -0400

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
>  [email-masked]
> 
> 
>> -----é‚®ä»¶åŽŸä»¶-----
>> å‘ä»¶äºº: [email-masked] [mailto:[email-masked]] ä»£è¡¨
>> Danny Mayer
>> å‘é€æ—¶é—´: 2012å¹´3æœˆ12æ—¥ 12:01
>> æ”¶ä»¶äºº: Dacheng Zhang(Dacheng)
>> æŠ„é€: [email-masked]
>> ä¸»é¢˜: 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:[email-masked]]
>>>>> Ã¥Ââ€˜Ã©â‚¬ÂÃ¦â€”Â¶Ã©â€”Â´: 2012Ã¥Â¹Â´3Ã¦Å“Ë†11Ã¦â€”Â¥ 7:27
>>>>> Ã¦â€Â¶Ã¤Â»Â¶Ã¤ÂºÂº: [email-masked]
>>>>> Ã¦Å â€žÃ©â‚¬Â: Dacheng Zhang(Dacheng); [email-masked]
>>>>> Ã¤Â¸Â»Ã©Â¢Ëœ: 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

---

From: Danny Mayer <[email-masked]>
Date: Fri, 25 May 2012 23:18:31 -0400

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