Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)

[Danny Mayer <[e-mail]>]

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