Sorry for the late response, I am on a business trip and will return to Beijing Office next week. Thanks for this long thread and many helpful comments and objections, it did help us enhance the draft accordingly, I believe.
I quickly look through those emails on tictoc & ipsec ML(please tell me if I missing some important comments). As the first reply, I would like to point out several facts in the following: 1. Most doubts have been cast on the rationale of encryption. Thanks to comments by Tim and others, this requirement comes from 3GPP spec., as explained in the Introduction, where it says that 3GPP spec. SHALL support encryption/tunnel in backhaul link. 2. Then the problem arisen is the (intermediate) nodes cannot recognize the timing if using an encrypted IEEE 1588, unless an identifier is attached to such packets. Timing packets with an identifier does not destroy its integrity protection, where ITUT[G.8265] defines security requirements on synchronization, as we described in the draft (Sec. 3). An unauthorized client or a rouge time server without knowing the secret key cannot decrypt the timing information, and thus cannot benefit from the protocol. 3. Identified timing packets gives a little more information to attackers than normal, considering DoS attack, but it is out of the scope of this draft and can hardly be prevented. If an attacker is willing to focus on dropping packets or blocking traffic, I am afraid that most of current security countermeasures are useless. Similarly, any intentional delay by attackers can mislead the client to receive a false timing. In contrast, latency from crypto operations can be measured easily. 4. Hardware based protocol, timestamping on all packets, will lead to an unacceptable performance down of Femtocell, due to our experimental results. So, it is not correct to claim that "if you can timestamp some packet, then you can timestamp all", at least from a performance point of view. It does not satisfy our requirement 3(Sec. 3), as well. 5. Thanks Nico for his abstract, it is much clearer. 6. Thanks Manav's explanation, http://www.ietf.org/mail-archive/web/tictoc/current/msg00755.html it is indeed one of the motivation to identify timing under security tunnel. Finally, all comments and objections are highly appreciated. We are thankful to all those have contributed to this discussion, and will revise the draft correspondingly. Cheers, Yang < [email protected] > ________________________________________ 发件人: Nico Williams [[email protected]] 发送时间: 2011年10月19日 23:41 到: Danny Mayer Cc: Tim Frost; [email protected]; [email protected]; [email protected]; [email protected]; Cui Yang 主题: Re: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui) On Wed, Oct 19, 2011 at 6:57 AM, Danny Mayer <[email protected]> wrote: >> The problem with this is once the packets have been encrypted, it is >> not possible for the femtocell to timestamp them on reception because it >> doesn't recognise them until after decryption, which is what this draft >> tries to address. > > You could always timestamp all packets and then worry about whether or > not you need the timestamp or is this prohibitive in cost? That's my take as well. If you can timestamp some packets, you can timestamp them all. Perhaps the reading of a hi-res timer is a slow operation, or perhaps it can have deleterious effects. For example, a hi-res timer might be available only w/o reference to a single clock, with each hi-res timer being CPU core-/thread-specific, in which case the system would have to arrange for the packet to continue to be processed on the same core/thread even if it'd be better not to for other reasons. Modern CPUs can count CPU cycles though, which can be used as a good proxy for hi-res timers for relatively short runs of code, but perhaps tracking CPU cycles used to process a packet might require extensive changes to an implementation. Or perhaps some femtocells are implemented almost entirely in HW whose architecture makes it expensive to timestamp every packet. Details would be nice. As it becomes clear that this proposal is really a case of allowing local limitations of *some* implementations (possibly not even real limitations; details are missing, so we can't tell for sure) to bleed into protocol architecture, I'm now much more in the "this is not a good idea" camp. It might yet turn out that these limitations are much more universal than I imagine though. >> I totally agree with the comments people like Danny have made that > point out the difficulties that identifying timing packets just opens > them up to attack. However, comments attacking the rationale for > encryption are wide of the mark - the packets are encrypted by 3GPP > architecture, we have to work out how to deal with that. > > The rationale was attacked because it was not spelled out in the > document, it's as simple as that. The next question becomes is there a > better way to accomplish the goal given the architecture? I second this. The draft wasn't ready for review by the IPsec list. The result was bound to be either silence or skepticism. Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
