Re: [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)
Danny Mayer <mayer@ntp.org> Thu, 13 October 2011 14:43 UTC
Return-Path: <mayer@ntp.org>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49DE21F8B6D; Thu, 13 Oct 2011 07:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkuFiRFuFhAA; Thu, 13 Oct 2011 07:43:58 -0700 (PDT)
Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9440321F8AF9; Thu, 13 Oct 2011 07:43:55 -0700 (PDT)
Received: from [198.22.153.6] (helo=[10.60.102.37]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from <mayer@ntp.org>) id 1REMVh-0007vP-EZ; Thu, 13 Oct 2011 14:43:52 +0000
Message-ID: <4E96F91E.3020202@ntp.org>
Date: Thu, 13 Oct 2011 10:43:42 -0400
From: Danny Mayer <mayer@ntp.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Cui Yang <cuiyang@huawei.com>
References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com>
In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com>
X-Enigmail-Version: 1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 198.22.153.6
X-SA-Exim-Rcpt-To: cuiyang@huawei.com, ipsec@ietf.org, TICTOC@ietf.org, gnn@neville-neil.com
X-SA-Exim-Mail-From: mayer@ntp.org
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail1.ntp.org)
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "TICTOC@ietf.org" <TICTOC@ietf.org>
Subject: Re: [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Oct 2011 14:44:00 -0000
On 9/18/2011 9:41 PM, Cui Yang wrote: > Dear IPsec experts, > cc TICTOC WG > > May I make a review request for the draft on > "IPsec security for packet based synchronization" > > http://datatracker.ietf.org/doc/draft-xu-tictoc-ipsec-security-for-synchronization/ > > Abstract: > Cellular networks often use Internet standard technologies to handle > synchronization. This document defines an extension based on WESP. > Usually, several traffic flows are carried in one IPsec tunnel, for > some applications, such as, 1588 or NTP, the packets need to be > identified after IPsec encryption to handle specially. In order to > achieve high scalability in implement, a separate IPsec tunnel will > not be established for some special traffic. This document analyses > the need for security methods for synchronization messages > distributed over the Internet. This document also gives a solution > on how to mark the synchronization message when IPSec is implemented > in end to end frequency synchronization." > > This work is proposed in TICTOC WG, but closely related to the IPsec security issues in synchronization. > We would like to get advices from security experts. I have strong objections to this draft. There are no clear reasons to do it, it totally ignores the requirements for what a timing packet needs in favor of identifying the timing packets which once identified externally become a potential target for attack. Since this draft is about security for synchronization you've just lost your security. This draft concentrates totally on identifying how to identify timing packets but there is no consideration for the timing packet's requirements and why you should do it in the first place. I also note that this is marked as Standards Track so there needs to be very good justification for doing something like this. Sending an NTP packet through an IPsec tunnel with all of the encryption/decryption involved throws out the error budget needed for timing packets. So why are you doing this in the first place? There is no need for encryption on a timing packet since it has no secrets. IEEE-1588 (PTP) also cannot benefit from this as it is basically a hardware-stamping protocol and now you are routing it through a software tunnel which means it has to be timestamped before it is IPsec encapsulated which decreases it's accuracy. It's no longer on-wire. Please also note that this is an IETF Working Group. Your informative References need to provide a publicly available location where to get them. Furthermore the NTP RFC (RFC5905) is not even referenced. Going into details: In Section 1 (Introduction) you state that: "the timing signal purports to come from a higher quality clock than it actually does.... this may be used to attack the integrity of the network, to disrupt the synchronization flow, or cause authentication failures". However the proposal in your draft is to identify those very packets you are trying to protect, so an attacker just needs to create fake timing packets and inject them into the stream causing disruption or in a MIM attack just cause them to be dropped. Knowing how to identify them makes this easy. You also say that "it may be possible for unauthorized users to request service from a clock server" but you do not state why this is a problem. You don't care about other clients, if they get a packet it makes no difference. A NTP server can be told which requests to respond to and PTP is basically unidirectional and all packets flow downstream. In NTP the autokey protocol (RFC 5906) can be used to authenticate the server if the receiving client needs to ensure the validity of it's timing packet. "Femtocell ... requires time synchronization" But it fails to state what kind of synchronization or accuracy is needed. If you don't know the error budget you don't know whether or not the recommendations being made will support the requirements nor is there any reference to a publicly available document that states such requirements. I cannot analyze this any further as your reference [3GPP.33.320] does not provide a publicly available document reference required of all IETF RFC's and drafts. Section 3 talks about ITUT [G.8265] which also does not point to a publicly available document reference and that "timing packets flow across multiple network domains which may introduce specific security requirements". It does not say what those specific security requirements are or how they should be addressed. NTP (RFC 5905) can use the Autokey protocol (RFC 5906) to authenticate the packets and can tolerate packet loss over a very large Wide-Area Network with no problems so it's not clear what the concern is. >From items in section 3: 1. "synchronization client SHOULD be prevented from connecting to rogue clock servers". How do you identify a "rogue" clock server? In NTP the client requests NTP packets of a specific set of servers and can authenticate them through autokey and furthermore does not rely on a single NTP server and is likely to throw out packets received from a server that is out of the range of the other servers. In NTP terms this is designated as a falseticker. See RFC 5905. 2. "clock servers SHOULD be prevented from providing service to unauthorized synchronization client" Again how do you know what is "unauthorized"? The server can be configured to ignore requests from clients not on its list but why do you care about this? How is this a security concern? 3. "Security mechanisms to achieve synchronization SHOULD minimize any degradation in performance and this side effect SHOULD be controlled to meet specific synchronization requirements (e.g. Femtocell synchronization)." It's not clear why this is in this document since that would always be a goal. IPsec will always degrade performance to some degree but the real concern here is not the degradation in performance but the degradation in accuracy of the timing packets and IPsec definitely makes it worse. Section 4 talks about "Security mechanism for synchronization" and talks about authentication-based and encryption-based security. If you are talking about IPsec the packets are already encrypted so where are you going with this? If you already have a rogue within the tunnel you have bigger problems than worrying about the timing packets. "Full encryption might be required for various reasons. The content of the packet may be considered secret, such as might be the case where the accuracy of time distribution is sold as a service." This is a rather bizarre statement. If you are selling a service, you refused to respond to requests unless you are listed at the server and you provide the secret key for authentication purposes through an OOB mechanism to the customer buying the service. There is nothing secret about a timing packet. It is already "out-of-date" the moment it goes on the wire. The only thing of importance for a timing packet is how quickly you can deliver it to the recipient. Nothing else matters. It is also worth pointing out that there are lots of publicly available NTP servers out there which are available through the NTP pool (pool.ntp.org) so most clients do not need to look for other sources like the ones you are discussing. A customer that NEEDS good timing packets is going to make sure that they get a good source and not try to piggyback off a third-party's mechanisms. If funneling all traffic through an IPsec tunnel for other reasons then you still need to consider whether it will degrade the accuracy of the timing packet to such as an extent that the timing packet becomes useless as a synchronization source. The error budget is all important here, security is just a minor issue. You don't want or need to protect the time packets, you need to get them delivered as fast as possible and to allow the receiving client to authenticate the server by whatever means you deem best. In Section 5 you discuss how to identify the synchronization messages in IPsec in the physical layer in order to improve the synchronization accuracy but you do not say how identifying the packets will accomplish this task. While the document is not about that there should at least be a reference to a document that describes how identifying the synchronization packets will improve the synchronization accuracy. Ignored in Section 6 description of the operation of how it works with the Security Gateway and the Femtocell is the fact that a lot of processing is taking place, there is additional transmission of the packet and it doesn't take advantage of the fact that the WESP packet can potentially add some sort of timestamp information so that the receiver can calculate some of the additional timing delays introduced by these additional mechanisms. Section 8 - Security Considerations mentions security properties of ESP but does not discuss the reduction in security that would result in the ability to identify the time packets which would allow the attacker to block or intercept the time packets. Yet it is critical to discuss this part otherwise why would you use IPsec at all? I don't know anything about Frequency synchronization packets so what those affects would be I cannot discuss but that also needs attention. Under Nits, a lot of acronyms are used in the document without spelling out what they mean. Acronyms needs to be spelled out on first use and documents referenced where relevant. External documents (non-IETF) need to provide an online publicly available location reference. Danny
- [TICTOC] Review request for IPsec security for pa… Cui Yang
- Re: [TICTOC] Review request for IPsec security fo… Danny Mayer
- Re: [TICTOC] Review request for IPsec security fo… Kevin Gross
- Re: [TICTOC] Review request for IPsec security fo… Danny Mayer
- Re: [TICTOC] Review request for IPsec security fo… Greg Dowd
- Re: [TICTOC] [IPsec] Review request for IPsec sec… David L. Mills
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams
- Re: [TICTOC] [IPsec] Review request for IPsec sec… David L. Mills
- Re: [TICTOC] Review request for IPsec security fo… Danny Mayer
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Danny Mayer
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Paul_Koning
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Tim Frost
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Kevin Gross
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Kevin Gross
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Paul_Koning
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Kevin Gross
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Paul_Koning
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Kevin Gross
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Paul_Koning
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Tim Frost
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Bhatia, Manav (Manav)
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Danny Mayer
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Michael Richardson
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Danny Mayer
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Stephen Kent
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Danny Mayer
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Paul_Koning
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams
- [TICTOC] 答复: [IPsec] Review request for IPsec sec… Cui Yang
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Kevin Gross
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Kevin Gross
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Leonid Goldin (lgoldin)
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Kevin Gross
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Cui Yang
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Danny Mayer
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Danny Mayer
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Kevin Gross
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Bhatia, Manav (Manav)
- Re: [TICTOC] ´ð¸´: [IPsec] Review request for IPs… Danny Mayer
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Danny Mayer
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Stephen Kent
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams
- Re: [TICTOC] [IPsec] Review request for IPsec sec… Nico Williams