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

From: Danny Mayer <[email-masked]>
Date: Thu, 13 Oct 2011 10:43:42 -0400

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

---

From: Kevin Gross <[email-masked]>
Date: Thu, 13 Oct 2011 12:28:38 -0600

Definitely important issues for some synchronization protocols but it seems
though two-step 1588 would work through such a connection. The followup
message will contain an accurate (and encrypted) timestamp. Encryption
delays would not result in significant loss of accuracy with respect to an
unencrypted connection also using two step.

Kevin Gross

---

From: Danny Mayer <[email-masked]>
Date: Thu, 13 Oct 2011 20:07:35 -0400

On 10/13/2011 2:28 PM, Kevin Gross wrote:
> Definitely important issues for some synchronization protocols but it
> seems though two-step 1588 would work through such a connection. The
> followup message will contain an accurate (and encrypted) timestamp.
> Encryption delays would not result in significant loss of accuracy with
> respect to an unencrypted connection also using two step.
> 

Has anyone tested or measured that? I have not seen any information how
this will work without losing accuracy. Don't forget the followon
message will also have to be encrypted and decrypted when sent making
for additional uncertainties and errors. I have not reviewed how the
two-step IEEE 1588 protocol works so I don't have a good understanding
of the effects of IPsec encryption on such packets.

Danny
> Kevin Gross
> 
> On Thu, Oct 13, 2011 at 8:43 AM, Danny Mayer <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Greg Dowd <[email-masked]>
Date: Fri, 14 Oct 2011 17:08:06 +0000

Hi Danny,
	Yes, we (Symmetricom) have tested this.  It does work.  It basically is what the 2step clock was designed for.  You create an event message (SYNC) and send it out.  As it gets transmitted, you record the actual time of transmission.  Then you follow up with a general message (FOLLOW UP) in which timing doesn't matter to send the corrected tx time.  The slave sees the follow up bit set in the SYNC message which tells the slave to wait for the follow up packet before processing the timestamp.

	This was designed as hardware wasn't available to insert timestamps accurately but it was/is relatively easy to tap the G/MII channel to see the packet flowing into the PHY.  Obviously, you need to correlate the packet with the timestamp which you can do by serializing transmission or looking at the frame.  This is part of the reasoning behind the draft in that, if the frame is encrypted, it makes it easier to identify if there is a bit set somewhere.  

Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com
"A clever person solves a problem.  A wise person avoids it." Albert Einstein

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Danny Mayer
Sent: Thursday, October 13, 2011 5:08 PM
To: Kevin Gross
Cc: [email-masked]; [email-masked]; Cui Yang; David L. Mills
Subject: Re: [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)

Danny
>     encapsulated which decreases it's accuracy. It's no longer on-wire.

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: "David L. Mills" <[email-masked]>
Date: Sat, 15 Oct 2011 00:19:10 +0000

Nico and Danny,

It might help to explain the issues in the NTP white papers at the NTP 
project page www.eecis.udel.edu./ntp.html. Chapter 16 in the book shows 
the results of experiments using interleaved mode, which might be of 
interest in PTP broadcast issues. The paper on Simulation and Analysis 
of the NTP On-Wire protocol uses a two-step process similar to PTP. The 
paper on NTP Security Analysis may have lessons for PTP authentication. 
The NTP Autokey model needs help, as suggested in that paper.

Dave

Nico Williams wrote:

>On Thu, Oct 13, 2011 at 7:07 PM, Danny Mayer <[email-masked]> wrote:
>  
>
>The cost of crypto can be measured, and performance generally
>deterministic (particularly when there's no side channels in the
>crypto) (assuming no mid-crypto context switches), so that it should
>be possible to correct for the delays introduced by crypto (just as
>it's possible to measure and estimate network latency).  Indeed,
>crypto processing will likely be more deterministic than network
>latency :)
>
>However, I do agree that there's no point to encrypting time
>synchronization signals unless they facilitate traffic analysis (say).
> Nor do I see the point of using WESP for this.  Also, NTP has a
>public key authentication facility nowadays -- why not use it?
>
>Nico
>--
>  
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 14 Oct 2011 12:25:28 -0500

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 15 Oct 2011 20:29:59 -0500

On Fri, Oct 14, 2011 at 7:19 PM, David L. Mills <[email-masked]> wrote:
> project page www.eecis.udel.edu./ntp.html. Chapter 16 in the book shows the
> results of experiments using interleaved mode, which might be of interest in
> PTP broadcast issues. The paper on Simulation and Analysis of the NTP
> On-Wire protocol uses a two-step process similar to PTP. The paper on NTP
> Security Analysis may have lessons for PTP authentication. The NTP Autokey
> model needs help, as suggested in that paper.

Also helpful was to note the cc list and then look at the TICTOC WG charter.

If I understand the I-D we're talking about a an extension to IPsec to
minimize overhead in handling of packets carrying time data,
particularly in an SG environment.  This would allow NTP to be run
with no crypto inside the security boundary, with IPsec providing
security outside.  Is this correct?  And this performs better than the
interleaved NTP scheme with asymmetric key signatures?

Nico
--

---

From: "David L. Mills" <[email-masked]>
Date: Sun, 16 Oct 2011 16:12:27 +0000

Nico,

My apologies on the white papers link. The correct one is 
www.eecis.udel.edu/~mills/ntp.html. There is no intent in these papers 
or in this message to promote NTP in addition to or an alternate for 
PTP, just to provide additional context in the TICTOC discussion..

NTP interleaved modes, like the two-step PTP modes have nothing to do 
with security. With NTP the intent is to avoid latencies due to 
cryptographic computation, output queuing and message transmission. In 
its present design, NTP interleaved mode is not useful in client/server 
mode, but the suggestions on server state mentioned in the NTP Security 
Analysis page might fix that.

An IPSEC tunnel between security gateways with constant delay is 
invisible to NTP as well as PTP, as simply adds to the propagation delay 
without dilution of the source ad destination timestamps. However, any 
means to improve the delay measurement accuracy would benefit PTP as 
well as NTP. The mention in the ID of possible revenue in the service is 
intriguing; I hadn't thought of that. In the NTP model it is necessary 
only to verify authenticity of the source, since the timestamps are 
considered public values. Nevertheless, encryption is not much more 
expensive than hash computations and does have constant delay.

In practice, the use of the NTP symmetric keys model and wrapping the 
raw NTP datagram in a IPSEC header does not change the model, just 
compicates module decomposition, as IPSEC support must be in the end 
system. At least on and end-end basis, the two are equivalent.

Dave

---

From: Danny Mayer <[email-masked]>
Date: Sun, 16 Oct 2011 13:52:30 -0400

On 10/14/2011 1:08 PM, Greg Dowd wrote:
> Hi Danny,
> Yes, we (Symmetricom) have tested this. It does work. It basically
> is
what the 2step clock was designed for. You create an event message
(SYNC) and send it out. As it gets transmitted, you record the actual
time of transmission. Then you follow up with a general message (FOLLOW
UP) in which timing doesn't matter to send the corrected tx time. The
slave sees the follow up bit set in the SYNC message which tells the
slave to wait for the follow up packet before processing the timestamp.

Good to know that. This implies that if these are NTP packets you need
to be in interleave mode in order to support this.

> This was designed as hardware wasn't available to insert timestamps
accurately but it was/is relatively easy to tap the G/MII channel to see
the packet flowing into the PHY. Obviously, you need to correlate the
packet with the timestamp which you can do by serializing transmission
or looking at the frame. This is part of the reasoning behind the draft
in that, if the frame is encrypted, it makes it easier to identify if
there is a bit set somewhere.

How does identifying the packet help? If you want to do correlation then
properly speaking you should be adding an ID to the packet so that the
followon packet can carry the same ID to give you a way of updating that
packet. According to what you are saying it doesn't matter that they
have to be decoded at the receiving end, they will be processed and
associated with the original packet.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sun, 16 Oct 2011 23:08:02 -0400

> interleaved NTP scheme with asymmetric key signatures?

I cannot answer for the performance but if I was worried about making
sure I got the correct time I'd be more likely to be concerned about
authenticating the server than encrypting the contents. Encryption
doesn't do a thing for ensuring you got a valid packet.

Danny

---

From: <[email-masked]>
Date: Mon, 17 Oct 2011 05:48:34 -0500

>I cannot answer for the performance but if I was worried about making sure I got the correct time I'd be more likely to be concerned about authenticating the server than encrypting the contents. Encryption doesn't do a thing for ensuring you got a valid packet.

You don't need data confidentiality, but you do need data integrity and anti-replay, both of which you get from the integrity part of IPSec.  This  is a place where the integrity-only cipher suites are applicable.

	paul

---

From: Tim Frost <[email-masked]>
Date: Tue, 18 Oct 2011 15:37:40 +0000

I think most of the reviewers are missing the point of this draft.

The point is not that the timing packets are inherently secret and need encryption, but that the 3GPP architecture mandates that EVERYTHING flowing to the femtocell must be inside a secure tunnel, whether the security is needed or not. It's a wider architecture issue, not the issue about whether encryption is needed and how best to do it.

The key figure from the draft is Figure 1:

          +-------------+
          |             |
          |  Femtocell  |<-----------------------------+
          |             |                              |
          +-------------+                              |
                                                       |
                                                       |
                                           /---------------------\
                                           |                     |
                                           |   Public Network    |
                                           |                     |
                                           \---------------------/
                                                       |
                                                       |
          +------------+           +-------------+     |
          |Clock Server|---------->|             |     |
          +------------+           |             |     |
                                   | Security GW |->---+
          +------------+           |             |
          |Femto GW    |---------->|             |
          +------------+           +-------------+

   Figure 1.  Typical Architecture of a Femtocell Network

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.

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.

We could argue that 3GPP should never have mandated this type of architecture, but we would be better off arguing that at 3GPP, not here in IETF.

Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 17 October 2011 11:49
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui)

	paul

---

From: Kevin Gross <[email-masked]>
Date: Tue, 18 Oct 2011 10:42:57 -0600

It does seem reasonable to consider modeling encryption and decryption in as
part of network latency. As long as delays introduced are the same each
direction, the sync protocols will naturally subtract out this contribution.

Kevin Gross

---

From: Kevin Gross <[email-masked]>
Date: Tue, 18 Oct 2011 10:44:18 -0600

My previous comments about two-step took into account only the transmitter.
Of course the the receiver needs to timestamp arrival times. Most hardware
does this by recognizing packet format, a strategy that would be thwarted by
encryption. It is my understanding that some network hardware timestamps all
packets attaching a hardware-generated timestamp to each receive queue
entry. That's what seems to be required here. This type of hardware combined
with two-step sync announcements (apparently supported by both 1588 and NTP)
could make for a workable solution.

Kevin Gross

On Tue, Oct 18, 2011 at 9:37 AM, Tim Frost <[email-masked]> wrote:

> The point is not that the timing packets are inherently secret and need
> encryption, but that the 3GPP architecture mandates that EVERYTHING flowing
> to the femtocell must be inside a secure tunnel, whether the security is
> needed or not. It's a wider architecture issue, not the issue about whether
> encryption is needed and how best to do it.
>
> 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.
>
> 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.
>
> We could argue that 3GPP should never have mandated this type of
> architecture, but we would be better off arguing that at 3GPP, not here in
> IETF.
>
> Tim
>
>
>

---

From: <[email-masked]>
Date: Tue, 18 Oct 2011 11:49:24 -0500

But why would you assume that the delays are consistent?

In the non-encrypted case, you can reasonably assume that because there is an underlying assumption that there are no malicious agents in the network.  However, if you believe that encryption is needed because the network does contain malicious agents, you would want to assume that anything that's interesting to attack is in fact attacked.

In particular, if you assume that active attacks are taking place where time sync packets are selectively delayed, what does that do to your protocol?

                paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin Gross
Sent: Tuesday, October 18, 2011 12:43 PM
To: Nico Williams
Cc: [email-masked]; Danny Mayer; [email-masked]; Cui Yang; David L. Mills
Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)

It does seem reasonable to consider modeling encryption and decryption in as part of network latency. As long as delays introduced are the same each direction, the sync protocols will naturally subtract out this contribution.

Kevin Gross

On Fri, Oct 14, 2011 at 11:25 AM, Nico Williams <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Kevin Gross <[email-masked]>
Date: Tue, 18 Oct 2011 11:45:13 -0600

Nico's contention is that it should take a constant amount of time to
decrypt a packet once it is received. I don't think this is exactly true but
when compared to other (variable) latencies in the system, possibly a
reasonable approximation.

If an attacker delays or drops synchronization packets, clock quality will
suffer. In the extreme case, all useful clock communication is lost and
nothing works. I don't think this situation is any different for clock
traffic than it is for other traffic. Encryption cannot prevent denial of
service.

Kevin Gross

On Tue, Oct 18, 2011 at 10:49 AM, <[email-masked]> wrote:

> But why would you assume that the delays are consistent?****
>
> ** **
>
> In the non-encrypted case, you can reasonably assume that because there is
> an underlying assumption that there are no malicious agents in the network.
> However, if you believe that encryption is needed because the network does
> contain malicious agents, you would want to assume that anything that’s
> interesting to attack is in fact attacked.****
>
> ** **
>
> In particular, if you assume that active attacks are taking place where
> time sync packets are selectively delayed, what does that do to your
> protocol?****
>
> ** **
>
>                 paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Kevin Gross
> *Sent:* Tuesday, October 18, 2011 12:43 PM
> *To:* Nico Williams
> *Cc:* [email-masked]; Danny Mayer; [email-masked]; Cui Yang; David L.
> Mills
> *Subject:* Re: [IPsec] [TICTOC] Review request for IPsec security for
> packet based synchronization (Yang Cui)****
>
> ** **
>
> It does seem reasonable to consider modeling encryption and decryption in
> as part of network latency. As long as delays introduced are the same each
> ****
> ** **
> Kevin Gross****
> ** **
> On Fri, Oct 14, 2011 at 11:25 AM, Nico Williams <[email-masked]>
> wrote:****
>
> ** **
>
> latency :)****

---

From: <[email-masked]>
Date: Tue, 18 Oct 2011 13:16:41 -0500

Absolutely.  But if you allow, say, one second round trip time, you have to assume that your time is off by that amount from the master.  In an environment without active attackers you would assume that the error is a fair amount smaller, basically the estimate of the difference between the two legs of the trip plus some allowance for jitter.  If you introduce attackers, you might have an underlying network that offers near-zero latency, and all the latency you're seeing is due to active attack on one or the other legs of the round trip.

                paul

From: Kevin Gross [mailto:[email-masked]]
Sent: Tuesday, October 18, 2011 1:45 PM
To: Koning, Paul
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)

Nico's contention is that it should take a constant amount of time to decrypt a packet once it is received. I don't think this is exactly true but when compared to other (variable) latencies in the system, possibly a reasonable approximation.

If an attacker delays or drops synchronization packets, clock quality will suffer. In the extreme case, all useful clock communication is lost and nothing works. I don't think this situation is any different for clock traffic than it is for other traffic. Encryption cannot prevent denial of service.

Kevin Gross
On Tue, Oct 18, 2011 at 10:49 AM, <[email-masked]<mailto:[email-masked]>> wrote:
But why would you assume that the delays are consistent?

                paul

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kevin Gross
Sent: Tuesday, October 18, 2011 12:43 PM
To: Nico Williams
Cc: [email-masked]<mailto:[email-masked]>; Danny Mayer; [email-masked]<mailto:[email-masked]>; Cui Yang; David L. Mills
Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)

Kevin Gross

---

From: Kevin Gross <[email-masked]>
Date: Tue, 18 Oct 2011 12:57:12 -0600

I suppose there is a possible selective attack vector here based on messing
with packets based on their length and transmission timing. It's an
interesting topic but I don't think that was the intended topic of this
discussion. We want to figure out how/if can we make clock distribution work
through an IPSec connection. I guess your point is that an "IPSec
connection" should be defined as an IPSec connection _under active attack_.
I'm afraid not qualified to assess these larger-picture security questions.

Kevin Gross

On Tue, Oct 18, 2011 at 12:16 PM, <[email-masked]> wrote:

> Absolutely.  But if you allow, say, one second round trip time, you have to
> assume that your time is off by that amount from the master.  In an
> environment without active attackers you would assume that the error is a
> fair amount smaller, basically the estimate of the difference between the
> two legs of the trip plus some allowance for jitter.  If you introduce
> attackers, you might have an underlying network that offers near-zero
> latency, and all the latency you’re seeing is due to active attack on one or
> the other legs of the round trip.****
>
> ** **
>
>                 paul****
>
> ** **
>
> *From:* Kevin Gross [mailto:[email-masked]]
> *Sent:* Tuesday, October 18, 2011 1:45 PM
> *To:* Koning, Paul
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
>
> reasonable approximation.****
>
> ** **
>
> service.****
> On Tue, Oct 18, 2011 at 10:49 AM, <[email-masked]> wrote:****
>

-- 
Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

---

From: <[email-masked]>
Date: Tue, 18 Oct 2011 14:11:47 -0500

That's what I was thinking.

The point is that IPSec is a security mechanism, so if you're specifying its use you need to discuss the security considerations.  (The RFC will need to do so.)  That translates into discussing the possible attacks and what effect they would have on the integrity of the service.  And yes, active attacks are very much part of the world in which IPSec is intended to live.

Usually, IPSec protects data, and the data carried by IPSec is protected from eavesdropping and from undetected modification or replay.  It is not protected from denial of service.

All that is true for time synchronization as well.  But unlike most data transfer protocols, in your case it's not just the content of the packets that matters, but also their arrival times.  And my point is that IPSec does not protect you from an attacker tampering with the arrival times.  So you'd want to call out the fact that a measured round trip time T means the time obtained by the sync process is accurate to T - but that you cannot assume it is accurate to better than T as you usually would.

                paul

From: Kevin Gross [mailto:[email-masked]]
Sent: Tuesday, October 18, 2011 2:57 PM
To: Koning, Paul
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)

I suppose there is a possible selective attack vector here based on messing with packets based on their length and transmission timing. It's an interesting topic but I don't think that was the intended topic of this discussion. We want to figure out how/if can we make clock distribution work through an IPSec connection. I guess your point is that an "IPSec connection" should be defined as an IPSec connection _under active attack_. I'm afraid not qualified to assess these larger-picture security questions.
...

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Oct 2011 14:20:01 -0500

> I'm afraid not qualified to assess these larger-picture security questions.

[Nit: it's IPsec, not IPSec.]

There's no such thing as an "IPsec connection".  (The closest to that
would be RFC5660.)

I don't understand what it is about IPsec that makes it difficult or
impossible to distribute time ("[w]e want to figure out how/if we can
make clock distribution work through [IPsec]").  My guess is that you
are referring to IPsec processing latency, but that's only a guess.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Oct 2011 14:33:03 -0500

> reasonable approximation.

Not constant so much as deterministic (for some algorithms, and some
implementations, but I assume that side-channels are not desirable,
which leads to the assumption of deterministic timing) or measurable.
In practice measuring this time is probably difficult, for example, in
preemptible kernel designs, or if the HW lacks a sufficiently high
resolution timer or CPU cycle counter.  I grant then that the proposed
solution is simpler to implement.  But should the proposal be
negotiable, and if so, how?

> traffic than it is for other traffic. Encryption cannot prevent denial of

However, encryption can make it harder for an attacker to delay just
the timing packets (though not impossible given enough meta-data
leaking to mount effective traffic analysis).  Or, to put it
differently, making timing packets identifiable makes it easier for an
attacker to DoS only the timing exchanges but not the rest.

DoS attacks based on not allowing packets through, or delaying them,
generally cannot be avoided, so perhaps there's no cause for concern.
I think you'd want to have a security consideration describing the
problems that might arise from a selective DoS attack on timing, as
well as mitigations.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Oct 2011 14:13:45 -0500

> The point is not that the timing packets are inherently secret and need encryption, but that the 3GPP architecture mandates that EVERYTHING flowing to the femtocell must be inside a secure tunnel,…

OK, but what's the point of WESP then?  Is it simply to reduce the
overhead on timing packets?  Special handling of timing packets is
claimed to be desired, but when I read the I-D I must have missed what
the special handling was.

Also, if the point can be made so succintly, then please make it so in
the abstract.

> The key figure from the draft is Figure 1:

Doesn't help me.

> 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…

OK, so you want receive time to be tracked for timing packets as soon
as the NIC interrupts the CPU, but you don't want to bother with this
for all packets, just timing packets.  Yes?

Assuming I get this, then why not write the abstract so that it says
all this.  E.g., something like this:

   This document describes how to use Wrapped Encapsulating Security
Payload (WESP) to carry timing packets, such as for the Network Time
Protocol (NTP), such that they be may recognized as such early on
during inbound processing.  This allows end-nodes to easily track the
time at which timing packets are received prior to decapsulation
without having to do so for all encapsulated packets.  Timing packets
generally bear no confidential data, which means they do not require
confidentiality protection.  Finally, in the interest of performance,
WESP is used without having to create additional SA pairs.

The fact that Femtocell is the motivator doesn't seem that
interesting.  If this is a problem for Femtocell it's likely to be a
problem for others.

> 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…

I don't understand this comment.  Are these packets encrypted, or not?

> We could argue that 3GPP should never have mandated this type of architecture, but we would be better off arguing that at 3GPP, not here in IETF.

I have no problem with the architecture.  I have a problem
understanding what's actually being proposed.  As to what I think the
proposal is, I'm not sure that it's necessary, but I also don't have
any objections (assuming I did understand correctly).

Nico
--

---

From: Tim Frost <[email-masked]>
Date: Wed, 19 Oct 2011 10:26:58 +0000

Nico,

I am not an author of this draft, so I don't propose to defend the contents. I was merely pointing out that those people criticizing it on the basis that encryption of timing packets was unnecessary were missing the point, which was that timing packets are encrypted because the 3GPP architecture says they must be, so we have to work out how to deal with that.

I think your revised abstract is good and explains the point clearly; I would recommend that the authors take note of this in the next revision.

Tim

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: 18 October 2011 20:14
To: Tim Frost
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui)

Doesn't help me.

Nico
--

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 19 Oct 2011 17:20:54 +0530

Hi,

I had spoken to one of the initial authors of this IPsec draft and I was told that setting up an Ipsec tunnel exclusively for shipping 1588 may not be possible in the femto architecture. They are thus trying to use WESP (that I have co-authored) to identify 1588 packets within an IPSec stream.

I have tried to describe the problem that this draft is attempting to address here:

http://www.ietf.org/mail-archive/web/tictoc/current/msg00755.html

As an author of WESP I can say that the way this draft uses WESP to protect 1588 is not very appropriate. The draft tries to add some additional identifiers in each protocol packet to uniquely identify 1588 packets. This in the security land will not be accepted as anybody snooping on the wire will be easily able to disambiguate 1588 packets from other packets in the stream. If the authors want to use WESP then they must negotiate this unique ID (or a set of IDs) in IKE and pad the packets randomly so that the attackers cant identify the 1588 packets in the Ipsec stream.

Cheers, Manav

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tim Frost
> Sent: Wednesday, October 19, 2011 3:57 PM
> To: Nico Williams
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [TICTOC] [IPsec] Review request for IPsec 
> security for packet based synchronization (Yang Cui)
> 
> Nico,
> 
> I am not an author of this draft, so I don't propose to 
> defend the contents. I was merely pointing out that those 
> people criticizing it on the basis that encryption of timing 
> packets was unnecessary were missing the point, which was 
> that timing packets are encrypted because the 3GPP 
> architecture says they must be, so we have to work out how to 
> deal with that.
> 
> I think your revised abstract is good and explains the point 
> clearly; I would recommend that the authors take note of this 
> in the next revision.
> 
> Tim
> 
> 
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [TICTOC] [IPsec] Review request for IPsec 
> security for packet based synchronization (Yang Cui)
> 
> > The point is not that the timing packets are inherently 
> secret and need encryption, but that the 3GPP architecture 
> mandates that EVERYTHING flowing to the femtocell must be 
> inside a secure tunnel, whether the security is needed or 
> not. It's a wider architecture issue, not the issue about 
> whether encryption is needed and how best to do it.
> 
> OK, but what's the point of WESP then?  Is it simply to 
> reduce the overhead on timing packets?  Special handling of 
> timing packets is claimed to be desired, but when I read the 
> I-D I must have missed what the special handling was.
> 
> Also, if the point can be made so succintly, then please make 
> it so in the abstract.
> 
> > 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.
> 
> OK, so you want receive time to be tracked for timing packets 
> as soon as the NIC interrupts the CPU, but you don't want to 
> bother with this for all packets, just timing packets.  Yes?
> 
> Assuming I get this, then why not write the abstract so that 
> it says all this.  E.g., something like this:
> 
>    This document describes how to use Wrapped Encapsulating 
> Security Payload (WESP) to carry timing packets, such as for 
> the Network Time Protocol (NTP), such that they be may 
> recognized as such early on during inbound processing.  This 
> allows end-nodes to easily track the time at which timing 
> packets are received prior to decapsulation without having to 
> do so for all encapsulated packets.  Timing packets generally 
> bear no confidential data, which means they do not require 
> confidentiality protection.  Finally, in the interest of 
> performance, WESP is used without having to create additional 
> SA pairs.
> 
> interesting.  If this is a problem for Femtocell it's likely 
> to be a problem for others.
> 
> > 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.
> 
> > We could argue that 3GPP should never have mandated this 
> type of architecture, but we would be better off arguing that 
> at 3GPP, not here in IETF.
> 
> understanding what's actually being proposed.  As to what I 
> think the proposal is, I'm not sure that it's necessary, but 
> I also don't have any objections (assuming I did understand 
> correctly).
> 
> Nico
> --

---

From: Danny Mayer <[email-masked]>
Date: Wed, 19 Oct 2011 07:57:05 -0400

On 10/18/2011 11:37 AM, Tim Frost wrote:
> The point is not that the timing packets are inherently secret and
need encryption, but that the 3GPP architecture mandates that EVERYTHING
flowing to the femtocell must be inside a secure tunnel, whether the
security is needed or not. It's a wider architecture issue, not the
issue about whether encryption is needed and how best to do it.

Thank you for clarifying this. This information is totally missing in
the draft which should be providing a rationale for the proposal. I
might argue that the 3GPP architecture is wrong when dealing with timing
packets but this is the wrong forum to discuss that and that boat has
probably sailed anyway.

> 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?

> 
> 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?

> We could argue that 3GPP should never have mandated this type of
architecture, but we would be better off arguing that at 3GPP, not here
in IETF.

Agreed.

Danny

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Oct 2011 10:00:34 -0400

If I was an off-path attacker, and I couldn't drop your packets
(but maybe I can see them), and I am not going to try to decrypt your
packets, I would simply replay/make-up some packets.  If I do this
within the IPsec replay window, the receiving machines have to run the
auth check, and so due to head-of-queue effects, the decrypt time might
not be constant.

---

From: Danny Mayer <[email-masked]>
Date: Wed, 19 Oct 2011 10:53:04 -0400

On 10/18/2011 12:42 PM, Kevin Gross wrote:
> It does seem reasonable to consider modeling encryption and decryption
> in as part of network latency. As long as delays introduced are the same
> each direction, the sync protocols will naturally subtract out this
> contribution.

I very much doubt that encryption and decryption take the same length of
time but I'm sure people with experience with this will be able to tell
us definitively. Almost certainly you will have asymmetric delays in the
network path anyway even if the path is identical in both directions.

Danny

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Oct 2011 10:41:44 -0500

> 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.

> 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
--

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Oct 2011 11:53:37 -0400

>network path anyway even if the path is identical in both directions.

For most symmetric algs, and many modes of use, the times are the same.
The timing tend to differ for asymmetric algs.

Steve

---

From: Danny Mayer <[email-masked]>
Date: Wed, 19 Oct 2011 16:31:07 -0400

On 10/18/2011 2:16 PM, [email-masked] wrote:
> Absolutely.  But if you allow, say, one second round trip time, you have
> to assume that your time is off by that amount from the master.

No, half that amount. Round trip means exactly that!

  In an
> environment without active attackers you would assume that the error is
> a fair amount smaller, basically the estimate of the difference between
> the two legs of the trip plus some allowance for jitter.  If you
> introduce attackers, you might have an underlying network that offers
> near-zero latency, and all the latency you’re seeing is due to active
> attack on one or the other legs of the round trip.
> 

I doubt that the interference would be that close and you certainly
cannot count on that.

Danny

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Oct 2011 16:12:31 -0500

> No, half that amount. Round trip means exactly that!

You're assuming symmetric routing...

---

From: <[email-masked]>
Date: Wed, 19 Oct 2011 20:14:39 -0500

I think Danny is right: if the round trip time is 1 second, and you pick the midpoint as the outcome of the sync process, you're off at most plus or minus half a second.  I was mixing up the error bound with the size of the error range.

	paul

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 5:13 PM
To: [email-masked]
Cc: Koning, Paul; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)

On Wed, Oct 19, 2011 at 3:31 PM, Danny Mayer <[email-masked]> wrote:
>> Absolutely.  But if you allow, say, one second round trip time, you 
>> have to assume that your time is off by that amount from the master.
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Oct 2011 20:30:56 -0500

> I think Danny is right: if the round trip time is 1 second, and you pick the midpoint as the outcome of the sync process, you're off at most plus or minus half a second.  I was mixing up the error…

Ah, yes, right, observed from one of the end-nodes.

---

From: Cui Yang <[email-masked]>
Date: Thu, 20 Oct 2011 02:09:55 +0000

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-masked] >
________________________________________
发件人: Nico Williams [[email-masked]]
发送时间: 2011年10月19日 23:41
到: Danny Mayer
Cc: Tim Frost; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Cui Yang
主题: Re: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui)

Nico
--

---

From: Kevin Gross <[email-masked]>
Date: Wed, 19 Oct 2011 20:15:06 -0600

We don't need decrypt and encrypt to take the same amount of time. We need
encrypt+decrypt from master to slave to take the same time as
encrypt+decrypt from slave to master.

---

From: Kevin Gross <[email-masked]>
Date: Wed, 19 Oct 2011 20:21:33 -0600

It would be nice to have timestamps on every packet but, for whatever
reason, this is not how most existing 1588 hardware works. Current hardware
keys off specific protocol identifier fields in packets and takes a
timestamp on match.  There's some small amount of hardware buffer dedicated
to holding timestamps.

---

From: "Leonid Goldin (lgoldin)" <[email-masked]>
Date: Wed, 19 Oct 2011 21:28:57 -0500

The encryption and decryption may or may not take the same time.
Different manufacturers may have different latency for the same
function. Therefore it would be hard to say for sure that the encrypt +
decrypt delay in each direction would be the same . 

my $0.02

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Kevin Gross
Sent: Wednesday, October 19, 2011 10:15 PM
To: Stephen Kent
Cc: Cui Yang; [email-masked]; [email-masked]; Nico Williams; David L.
Mills
Subject: Re: [TICTOC] [IPsec] Review request for IPsec security for
packet based synchronization (Yang Cui)

We don't need decrypt and encrypt to take the same amount of time. We
need encrypt+decrypt from master to slave to take the same time as
encrypt+decrypt from slave to master.

 It does seem reasonable to consider modeling encryption and decryption
 in as part of network latency. As long as delays introduced are the
same
 each direction, the sync protocols will naturally subtract out this
 contribution.

Danny

Steve

-- 
Kevin Gross

+1-303-447-0517

Media Network Consultant

AVA Networks - www.AVAnw.com <http://www.avanw.com/> , www.X192.org

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Oct 2011 21:35:33 -0500

> encrypt+decrypt from slave to master.

Since the plaintext lengths will differ, the ciphertext lengths might
too, and so might the time needed.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Oct 2011 21:36:44 -0500

> timestamp on match.  There's some small amount of hardware buffer dedicated

This is key, and needs to be stated in the I-D, quite possibly in the
abstract.  I guess it's time to set aside time to go read IEEE 1588...

---

From: Kevin Gross <[email-masked]>
Date: Wed, 19 Oct 2011 21:13:15 -0600

The IEEE 1588 standards are quite abstract so you won't find these
implementation details there. You need to read NIC datasheets. Many of
these are only available under NDA.

-- 
Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com, www.X192.org

---

From: Cui Yang <[email-masked]>
Date: Thu, 20 Oct 2011 05:39:43 +0000

As I have noted in the last email, timestamping all packets is too costly to afford to. We have done some experiments on our products, the degrading of performance is unacceptable. That is why we need to distinguish 1588 packet from others with high priority, and is the crucial reason that we equip WESP with identifier.

Yang
________________________________________
发件人: Kevin Gross [[email-masked]]
发送时间: 2011年10月20日 11:13
到: Nico Williams
Cc: Danny Mayer; Cui Yang; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui)

---

From: Danny Mayer <[email-masked]>
Date: Thu, 20 Oct 2011 08:22:34 -0400

> problems that might arise from a selective DoS attack on timing, as

For NTP at least, the loss of some packets doesn't matter, it will
continue on disciplining the clock at the same rate until it decides it
has enough reliable data to adjust the frequency of the clock to bring
it back in line with its NTP reference clock servers. Even then it will
throw out packets which show large variations. In the worst case it will
be receiving no valid packets and just won't make changes to the clock.
NTP is robust enough that the clock will be accurate enough even if it
hasn't received a single packet for hours. I cannot answer for PSP since
I don't know what it does.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Thu, 20 Oct 2011 09:01:55 -0400

On 10/19/2011 7:50 AM, Bhatia, Manav (Manav) wrote:
> Hi,
> 
> I had spoken to one of the initial authors of this IPsec draft and I
was told that setting up an Ipsec tunnel exclusively for shipping 1588
may not be possible in the femto architecture. They are thus trying to
use WESP (that I have co-authored) to identify 1588 packets within an
IPSec stream.
> 
> I have tried to describe the problem that this draft is attempting
> to
address here:
> As an author of WESP I can say that the way this draft uses WESP to
protect 1588 is not very appropriate. The draft tries to add some
additional identifiers in each protocol packet to uniquely identify 1588
packets. This in the security land will not be accepted as anybody
snooping on the wire will be easily able to disambiguate 1588 packets
from other packets in the stream. If the authors want to use WESP then
they must negotiate this unique ID (or a set of IDs) in IKE and pad the
packets randomly so that the attackers cant identify the 1588 packets in
the Ipsec stream.

In that case the receiving end will also be unable to identify those
packets which defeats the purpose of the draft.

Danny

---

From: Kevin Gross <[email-masked]>
Date: Thu, 20 Oct 2011 07:08:45 -0600

IEEE 1588 (PTP) specifies how updates are delivered. Unlike NTP, PTP
does not specify what devices do with these updates. In both cases,
stability in the absence of updates is mostly a function of the
quality of the local oscillator and not so much dependent on the time
protocol.

Kevin Gross

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 21 Oct 2011 06:22:21 +0530

> protect 1588 is not very appropriate. The draft tries to add 
> some additional identifiers in each protocol packet to 
> uniquely identify 1588 packets. This in the security land 
> will not be accepted as anybody snooping on the wire will be 
> easily able to disambiguate 1588 packets from other packets 
> in the stream. If the authors want to use WESP then they must 
> negotiate this unique ID (or a set of IDs) in IKE and pad the 
> packets randomly so that the attackers cant identify the 1588 
> packets in the Ipsec stream.
> 
> In that case the receiving end will also be unable to 
> identify those packets which defeats the purpose of the draft.

The end node would know the IDs carried in WESP as those would have been exchanged before. They will recognize the 1588 packets and process them accordingly.

Cheers, Manav

---

From: Danny Mayer <[email-masked]>
Date: Fri, 21 Oct 2011 09:01:22 -0400

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

---

From: Danny Mayer <[email-masked]>
Date: Fri, 21 Oct 2011 09:14:13 -0400

On 10/20/2011 1:39 AM, Cui Yang wrote:
> As I have noted in the last email, timestamping all packets is too
costly to afford to. We have done some experiments on our products, the
degrading of performance is unacceptable. That is why we need to
distinguish 1588 packet from others with high priority, and is the
crucial reason that we equip WESP with identifier.

Costly in what way? Hardware, implementation, something else? Can you
expand on this?

Danny

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Oct 2011 13:04:13 -0400

At 8:15 PM -0600 10/19/11, Kevin Gross wrote:
>We don't need decrypt and encrypt to take the same amount of time. 
>We need encrypt+decrypt from master to slave to take the same time 
>as encrypt+decrypt from slave to master.

That further reduces the likely variance that is algorithm or mode specific,
but it does increase the potential for variance due to differences in 
the processing capabilities of masters and slaves.

Steve

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Oct 2011 12:42:13 -0500

> The point is not that the timing packets are inherently secret and need encryption, but that the 3GPP architecture mandates that EVERYTHING flowing to the femtocell must be inside a secure tunnel,…

"Everything"??

Some bits can't be in a tunnel.  For example, the outer IP headers.
Obviously some bits of IKE also go in the clear.

What exactly is "everything" intended to encompass?   It can't be
truly all bits.  At most it can only be "all bits that can be
tunneled".

I don't see why timing signals need to be protected by IPsec if they
can carry their own cryptographic protection.  I know very little
about IEEE 1588 (PTP), but if there's any way that it can provide its
own security protocol[*] then I think it'd be fair to keep PTP out of
the "everything" that must be tunneled.  OTOH, if PTP lacks sufficient
security functionality, then my suggestions would be to either use NTP
or else we'll all have to hold our noses for the proposed solution.
Is PTP mandated for Femtocell as well?

[*] The paper "Security Flaws and Workarounds for IEEE 1588
(Transparent) Clocks" by A. Treytl and B. Hirschler tells me that PTP
does have a secure mode and that it's not very good.  Have those
issues been addressed since?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Oct 2011 16:01:14 -0500

On Mon, Oct 24, 2011 at 1:38 PM, Doug Arnold <[email-masked]> wrote:
> This debate has been going on since before the PTP v2 standard was released, and the consensus in the timing community agrees with you.  Timing packets do not need to be encrypted.  Authentication would be a more appropriate security mechanism, since time is not a secret.  There is even an experimental authentication mechanism in the standard, as you suggested (See Annex K of IEEE 1588-2008).
>
> Nevertheless, there is a requirement for PTP over IPsec.  The reason is that some system architects/admins want to have a policy that all packets go through the IPsec tunnel.  We timing geeks like to think of PTP as special, but to many system architects it is just one of many management protocols that run on their network. They don't want the complexity of making an exception for one protocol.

There's no reason to agree to a bad architecture just because it
appears to be written in stone.  Agreeing to document it on account of
its being deployed is another story, but there's no requirement that
we do that either.

Timing packets *should* need no more protection than the outer IP
headers on an IPsec-protected packet (hello) or than the cleartext
bits of IKE.  Some things have to go in the clear.  So much so -so
much so!- that the proposal on the table is to make enough of the
timing packets go in the clear that the end nodes can get more
accurate time.  Imagine that.  What better proof is there that the
architecture is broken?

But does PTP need protection?  Or would it need any
modifications/extensions to make it safe to use without IPsec?  You
didn't clarify this.  It may well be easier for IPsecme WG and the
IETF to agree to the proposal than it would be to fix PTP if it needs
fixing, but it'd be nice if we could establish that too.  This is the
sort of homework that the proposal's proponents should be doing.

> TICTOC could make a big push to educate the system architects that ptp should not be encrypted.  We could even convert some of them, but not all of them.  The only thing that could kill this requirement is if we convincingly show that ptp over IPsec could absolutely not be made to work in wireless backhaul networks.  I don't think that such an argument is forthcoming.

If TICTOC WG won't say "no" then the maybe IPsecme WG, the IETF,
and/or the IESG will.  I guess we're about to find out what IPsecme
thinks of this.

> GET OVER IT EVERYONE, THE REQUIREMENT FOR PTP OVER IPsec IS NOT GOING AWAY!  We need to figure out how to make it work as well as it can.

There is no requirement that the IETF rubber-stamp this either.  Using
caps won't help achieve consensus.

Now that the issue is clear, I think we could actually work towards
establishing consensus on one or another proposals, or even simply
show that there's consensus for none if that's what happens.  As part
of this process it'd be useful to find out what the process might be
to change the femtocell architecture so as to remove the requirement
that timing packets be encrypted.

What if the IETF consensus is that the femtocell architecture should be changed?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Oct 2011 19:23:11 -0500

On Mon, Oct 24, 2011 at 6:19 PM, Doug Arnold <[email-masked]> wrote:
> I don't agree that it is incumbent on those preparing a draft on PTP over IPsec to show the need.  The wireless system architects have already said they want this.  If someone disagrees, they are the ones who need to explain why an exception for timing is necessary.

Really?  So, just publish any I-D and don't show why it's needed, just
by dint of submitting your I-D you get to have volunteers review your
I-D and ultimately have an RFC published?  I don't think so.

I-D authors do need to justify their proposals.  Their justification
*can* be "we have no choice because this other standard development
organization left us no choice", but it has to be stated -- certainly
when that is their motivation, and especially if there's also any
controversy as to the proposal.

> You raise the possibility of the IETF as a whole taking a stand on architecture.  This would certainly carry a lot more weight than a stand by one obscure WG, TICTOC.  Such a stand happens sometimes, around big issues.  For example, the IETF has taken a stand that security shall be implemented via IPsec, and not with separate mechanisms for each application, such as https.   The IETF has taken a stand promoting IPv6.  (note: IPv4 and https persist despite these stands.) I'm pessimistic, though, about the possibility of convincing those high up in the IETF organization that encrypted PTP is a big enough issue for the IETF as whole to weigh in on.  At the very least they are likely to say that we haven't tried hard enough to make this work yet. This is basically the same problem that we have with network architects.  Timing is a very small part of the big world of networking.

No, I raised the possibility that the IPsecme WG and IETF might not
reach consensus of publishing the proposal on the Standards-Track or
any track.  There may not be any need to take a stand on the issue --
the I-D requires consensus to progress, and may not be able to obtain
it.  The IESG can take a stand, as can the IAB in an appeal.  But long
before we get there it's perfectly fair for participants to question
the proposal and propose alternatives.

In any case, the IETF didn't say "we won't standardize SSL/TLS because
IPsec is what should be used" or anything of the sort.  The IPsec
vision for end-to-end security certainly has failed, and IPv6 has not
yet dethroned IPv4 -- all true, but that says nothing about the
current issue other than that you can put together a strawman :)

> However, you have brought up an interesting possibility.  The IPsecme WG might be persuaded to create an option for leaving timestamps in the clear, in some fashion.  If such a thing were implemented in a future version of IPsec, then the system architects who want everything to run through the tunnel would likely be mollified.  This is probably the best long term solution.  I expect that IPsecme WG would want to see something written down that quantitatively documents the advantage of not encrypting time, either in terms of hardware cost or timing performance on the same hardware.  At least to the level of a paper study or simulation.  Since you have passion for this, perhaps you would like to start a draft of such a document?

Did I bring that up?  I did not.  However, there is an interesting
idea: fold PTP/NTP into IKE, then it will be easy to timestamp all IKE
packets (since there should be so few IKE packets compared to ESP)!
Bonus: the timing packets can be fully encrypted and not be identified
as such.

Nice try on volunteering me though! :)

> Even if the IPsecme WG were persuaded to address this, It would probably take a while before it was in the field in servers and routers.  I predict that there will be a "lock-out spec" for encrypted PTP from at least one major wireless infrastructure company sometime soon.  And those of us who sell to them are either going to build it, or lose the business to someone who will. And if the IETF won't define it then the ITU, IEEE or someone other organization will.  I suggest that the IETF is the organization which is best suited to define PTP over IPsec, since the IETF controls IPsec.

Isn't that true of the proposed WESP extension as well?  In any case,
if the proponents don't care if the IETF blesses their proposal then
why not just not bother?  If many proposals rejected here are simply
standardized elsewhere, why bother coming here at all?  Or why bother
standardizing anything?  I submit that the reason why one should
bother is that the IETF has significant brand value and significant
value in getting *others* to implement valuable ideas, and part of
that value surely derives from having the sort of review that does
sometimes lead to a decision (or lack of consensus) to not publish
some proposal.

I'm not scared by threats of going elsewhere, especially when the
authors haven't made such threats in the first place.  I don't see why
the proponents should be scared of rejection by yours truly either,
since my opinion is hardly the determinant of consensus here.
Proponents should be more concerned by the relative silence of many of
the key IPsecme WG participants.

> One last thing, I promise, no more all caps statements.

Thanks!  :)

Nico
--