On 10/19/2011 10:09 PM, Cui Yang wrote: [...] > 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.
If it says SHALL support encryption/tunnel in backhaul link does it say that you MUST use it for timing packets or is it silent on required usage? > > 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. Noone cares about an unauthorized client. In NTP at least a rogue time server would have its packets dropped because it would be so out-of-line with other NTP servers sending NTP packets, irrespective of whether or not they have access to the secret key. Even with autokey enabled NTP won't accept falseticker packets. > > 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. An intentionally delayed packet or a false timing packet in NTP would be automatically dropped and the clock would continue to be disciplined as normal. While you can never totally defend against a DOS attack, NTP can continue for hours if not days (depending on the quality of the clock crystal) and keep accurate time. If you are concerned about this use OCXO clock crystals which are much more stable long-term and will be better if you are concerned about receiving good truechimer NTP packets. > > 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. You *can* timestamp all packets. The real question here is whether or not the hardware and software can handle it and whether it solves the problem and is of benefit. Danny _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
