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

[Danny Mayer]

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 aut

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

[Kevin Gross]

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

On Thu, Oct 13, 2011 at 8:43 AM, Danny Mayer  wrote:

> On 9/18/2011 9:41 PM, Cui Yang wrote:
>

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.
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Danny Mayer]

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  > wrote:
> 
> On 9/18/2011 9:41 PM, Cui Yang wrote:
> 
> 
> 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.
> 
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Nico Williams]

On Thu, Oct 13, 2011 at 7:07 PM, Danny Mayer  wrote:
> 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.

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
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Greg Dowd]

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: tictoc-boun...@ietf.org [mailto:tictoc-boun...@ietf.org] On Behalf Of 
Danny Mayer
Sent: Thursday, October 13, 2011 5:08 PM
To: Kevin Gross
Cc: ipsec@ietf.org; tic...@ietf.org; Cui Yang; David L. Mills
Subject: Re: [TICTOC] Review request for IPsec security for packet based 
synchronization (Yang Cui)

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  > wrote:
> 
> On 9/18/2011 9:41 PM, Cui Yang wrote:
> 
> 
> 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.
> 
> 

___
TICTOC mailing list
tic...@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[David L. Mills]

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


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.
   



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



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Nico Williams]

On Fri, Oct 14, 2011 at 7:19 PM, David L. Mills  wrote:
> 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.

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
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Danny Mayer]

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

> 
> 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: tictoc-boun...@ietf.org [mailto:tictoc-boun...@ietf.org] On Behalf Of 
> Danny Mayer
> Sent: Thursday, October 13, 2011 5:08 PM
> To: Kevin Gross
> Cc: ipsec@ietf.org; tic...@ietf.org; Cui Yang; David L. Mills
> Subject: Re: [TICTOC] Review request for IPsec security for packet based 
> synchronization (Yang Cui)
> 
> 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 > > wrote:
>>
>> On 9/18/2011 9:41 PM, Cui Yang wrote:
>>
>>
>> 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.
>>
>>
> 
> ___
> TICTOC mailing list
> tic...@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Danny Mayer]

On 10/15/2011 9:29 PM, Nico Williams wrote:
> On Fri, Oct 14, 2011 at 7:19 PM, David L. Mills  wrote:
>> 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.
> 
> 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?
> 

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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul_Koning]

>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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Kevin Gross]

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 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 :)
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Kevin Gross]

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

> 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
>
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul_Koning]

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: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Kevin 
Gross
Sent: Tuesday, October 18, 2011 12:43 PM
To: Nico Williams
Cc: ipsec@ietf.org; Danny Mayer; tic...@ietf.org; 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 
mailto:n...@cryptonector.com>> 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 :)
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Kevin Gross]

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,  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:* ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] *On Behalf
> Of *Kevin Gross
> *Sent:* Tuesday, October 18, 2011 12:43 PM
> *To:* Nico Williams
> *Cc:* ipsec@ietf.org; Danny Mayer; tic...@ietf.org; 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 
> 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 :)
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul_Koning]

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:kevin.gr...@avanw.com]
Sent: Tuesday, October 18, 2011 1:45 PM
To: Koning, Paul
Cc: n...@cryptonector.com; ipsec@ietf.org; ma...@ntp.org; tic...@ietf.org; 
cuiy...@huawei.com; mi...@udel.edu
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, 
mailto:paul_kon...@dell.com>> 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: ipsec-boun...@ietf.org<mailto:ipsec-boun...@ietf.org> 
[mailto:ipsec-boun...@ietf.org<mailto:ipsec-boun...@ietf.org>] On Behalf Of 
Kevin Gross
Sent: Tuesday, October 18, 2011 12:43 PM
To: Nico Williams
Cc: ipsec@ietf.org<mailto:ipsec@ietf.org>; Danny Mayer; 
tic...@ietf.org<mailto:tic...@ietf.org>; 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 
mailto:n...@cryptonector.com>> 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 :)

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Kevin Gross]

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,  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:kevin.gr...@avanw.com]
> *Sent:* Tuesday, October 18, 2011 1:45 PM
> *To:* Koning, Paul
> *Cc:* n...@cryptonector.com; ipsec@ietf.org; ma...@ntp.org;
> tic...@ietf.org; cuiy...@huawei.com; mi...@udel.edu
>
> *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,  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:* ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] *On Behalf
> Of *Kevin Gross
> *Sent:* Tuesday, October 18, 2011 12:43 PM
> *To:* Nico Williams
> *Cc:* ipsec@ietf.org; Danny Mayer; tic...@ietf.org; 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 
> 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 :)
>
> ** **
>



-- 
Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul_Koning]

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:kevin.gr...@avanw.com]
Sent: Tuesday, October 18, 2011 2:57 PM
To: Koning, Paul
Cc: n...@cryptonector.com; ipsec@ietf.org; ma...@ntp.org; tic...@ietf.org; 
cuiy...@huawei.com; mi...@udel.edu
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.
...

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Nico Williams]

On Tue, Oct 18, 2011 at 1:57 PM, Kevin Gross  wrote:
> 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.

[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
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Nico Williams]

On Tue, Oct 18, 2011 at 12:45 PM, Kevin Gross  wrote:
> 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.

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?

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

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
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Nico Williams]

On Tue, Oct 18, 2011 at 10:37 AM, Tim Frost  wrote:
> 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.

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

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 for encryption are wide of 
> the mark - the packets are encrypted by 3GPP architecture, we have to work 
> out how to deal with that.

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
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Danny Mayer]

On 10/18/2011 11:37 AM, Tim Frost wrote:
> 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.

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

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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Michael Richardson]

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.



pgpvHTJBm3vkU.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Danny Mayer]

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

> Kevin Gross
> 
> On Fri, Oct 14, 2011 at 11:25 AM, Nico Williams  > 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 :)
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tim Frost]

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: tictoc-boun...@ietf.org [mailto:tictoc-boun...@ietf.org] On Behalf Of 
paul_kon...@dell.com
Sent: 17 October 2011 11:49
To: ma...@ntp.org; n...@cryptonector.com
Cc: ipsec@ietf.org; mi...@udel.edu; tic...@ietf.org; cuiy...@huawei.com
Subject: Re: [TICTOC] [IPsec] Review request for IPsec security for packet 
based synchronization (Yang Cui)

>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
___
TICTOC mailing list
tic...@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tim Frost]

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:n...@cryptonector.com] 
Sent: 18 October 2011 20:14
To: Tim Frost
Cc: paul_kon...@dell.com; ma...@ntp.org; ipsec@ietf.org; mi...@udel.edu; 
tic...@ietf.org; cuiy...@huawei.com
Subject: Re: [TICTOC] [IPsec] Review request for IPsec security for packet 
based synchronization (Yang Cui)

On Tue, Oct 18, 2011 at 10:37 AM, Tim Frost  wrote:
> 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.

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

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 for encryption are wide of 
> the mark - the packets are encrypted by 3GPP architecture, we have to work 
> out how to deal with that.

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
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Bhatia, Manav (Manav)]

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

> -Original Message-
> From: tictoc-boun...@ietf.org 
> [mailto:tictoc-boun...@ietf.org] On Behalf Of Tim Frost
> Sent: Wednesday, October 19, 2011 3:57 PM
> To: Nico Williams
> Cc: cuiy...@huawei.com; ipsec@ietf.org; tic...@ietf.org; 
> paul_kon...@dell.com; mi...@udel.edu
> 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
> 
> 
> -Original Message-
> From: Nico Williams [mailto:n...@cryptonector.com]
> Sent: 18 October 2011 20:14
> To: Tim Frost
> Cc: paul_kon...@dell.com; ma...@ntp.org; ipsec@ietf.org; 
> mi...@udel.edu; tic...@ietf.org; cuiy...@huawei.com
> Subject: Re: [TICTOC] [IPsec] Review request for IPsec 
> security for packet based synchronization (Yang Cui)
> 
> On Tue, Oct 18, 2011 at 10:37 AM, Tim Frost 
>  wrote:
> > 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.
> 
> 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 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.
> 
> 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 for encryption are wide of the mark - 
> the packets are encrypted by 3GPP architecture, we have to 
> work out how to deal with that.
> 
> I don

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

[Nico Williams]

On Wed, Oct 19, 2011 at 6:57 AM, Danny Mayer  wrote:
>> The problem with this is once the packets have been encrypted, it is
>> not possible for the femtocell to timestamp them on reception because it
>> doesn't recognise them until after decryption, which is what this draft
>> tries to address.
>
> You could always timestamp all packets and then worry about whether or
> not you need the timestamp or is this prohibitive in cost?

That's my take as well.  If you can timestamp some packets, you can
timestamp them all.  Perhaps the reading of a hi-res timer is a slow
operation, or perhaps it can have deleterious effects.  For example, a
hi-res timer might be available only w/o reference to a single clock,
with each hi-res timer being CPU core-/thread-specific, in which case
the system would have to arrange for the packet to continue to be
processed on the same core/thread even if it'd be better not to for
other reasons.  Modern CPUs can count CPU cycles though, which can be
used as a good proxy for hi-res timers for relatively short runs of
code, but perhaps tracking CPU cycles used to process a packet might
require extensive changes to an implementation.  Or perhaps some
femtocells are implemented almost entirely in HW whose architecture
makes it expensive to timestamp every packet.  Details would be nice.

As it becomes clear that this proposal is really a case of allowing
local limitations of *some* implementations (possibly not even real
limitations; details are missing, so we can't tell for sure) to bleed
into protocol architecture, I'm now much more in the "this is not a
good idea" camp.  It might yet turn out that these limitations are
much more universal than I imagine though.

>> I totally agree with the comments people like Danny have made that
> point out the difficulties that identifying timing packets just opens
> them up to attack. However, comments attacking the rationale for
> encryption are wide of the mark - the packets are encrypted by 3GPP
> architecture, we have to work out how to deal with that.
>
> The rationale was attacked because it was not spelled out in the
> document, it's as simple as that. The next question becomes is there a
> better way to accomplish the goal given the architecture?

I second this.  The draft wasn't ready for review by the IPsec list.
The result was bound to be either silence or skepticism.

Nico
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Stephen Kent]

At 10:53 AM -0400 10/19/11, Danny Mayer wrote:

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


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

Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Danny Mayer]

On 10/18/2011 2:16 PM, paul_kon...@dell.com 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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Nico Williams]

On Wed, Oct 19, 2011 at 3:31 PM, Danny Mayer  wrote:
> On 10/18/2011 2:16 PM, paul_kon...@dell.com 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!

You're assuming symmetric routing...
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul_Koning]

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:n...@cryptonector.com] 
Sent: Wednesday, October 19, 2011 5:13 PM
To: ma...@ntp.org
Cc: Koning, Paul; kevin.gr...@avanw.com; ipsec@ietf.org; tic...@ietf.org; 
cuiy...@huawei.com; mi...@udel.edu
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  wrote:
> On 10/18/2011 2:16 PM, paul_kon...@dell.com 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!

You're assuming symmetric routing...
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Nico Williams]

On Wed, Oct 19, 2011 at 8:14 PM,   wrote:
> 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.

Ah, yes, right, observed from one of the end-nodes.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Kevin Gross]

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.

On Wed, Oct 19, 2011 at 9:53 AM, Stephen Kent  wrote:

> At 10:53 AM -0400 10/19/11, Danny Mayer wrote:
>
>> 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
>>
>
> For most symmetric algs, and many modes of use, the times are the same.
> The timing tend to differ for asymmetric algs.
>
> Steve
>



-- 
Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com , www.X192.org
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Kevin Gross]

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.

On Wed, Oct 19, 2011 at 9:41 AM, Nico Williams wrote:

> On Wed, Oct 19, 2011 at 6:57 AM, Danny Mayer  wrote:
> >> The problem with this is once the packets have been encrypted, it is
> >> not possible for the femtocell to timestamp them on reception because it
> >> doesn't recognise them until after decryption, which is what this draft
> >> tries to address.
> >
> > You could always timestamp all packets and then worry about whether or
> > not you need the timestamp or is this prohibitive in cost?
>
> That's my take as well.  If you can timestamp some packets, you can
> timestamp them all.  Perhaps the reading of a hi-res timer is a slow
> operation, or perhaps it can have deleterious effects.  For example, a
> hi-res timer might be available only w/o reference to a single clock,
> with each hi-res timer being CPU core-/thread-specific, in which case
> the system would have to arrange for the packet to continue to be
> processed on the same core/thread even if it'd be better not to for
> other reasons.  Modern CPUs can count CPU cycles though, which can be
> used as a good proxy for hi-res timers for relatively short runs of
> code, but perhaps tracking CPU cycles used to process a packet might
> require extensive changes to an implementation.  Or perhaps some
> femtocells are implemented almost entirely in HW whose architecture
> makes it expensive to timestamp every packet.  Details would be nice.
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Nico Williams]

On Wed, Oct 19, 2011 at 9:15 PM, 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.

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

Nico
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Nico Williams]

On Wed, Oct 19, 2011 at 9:21 PM, Kevin Gross  wrote:
> 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.

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...
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Kevin Gross]

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.

On Wed, Oct 19, 2011 at 8:36 PM, Nico Williams  wrote:
> On Wed, Oct 19, 2011 at 9:21 PM, Kevin Gross  wrote:
>> 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.
>
> 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...
>



-- 
Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com, www.X192.org
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Cui Yang]

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 [kevin.gr...@avanw.com]
发送时间: 2011年10月20日 11:13
到: Nico Williams
Cc: Danny Mayer; Cui Yang; ipsec@ietf.org; tic...@ietf.org; 
paul_kon...@dell.com; mi...@udel.edu
主题: Re: [TICTOC] [IPsec] Review request for IPsec security for packet based 
synchronization (Yang Cui)

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.

On Wed, Oct 19, 2011 at 8:36 PM, Nico Williams  wrote:
> On Wed, Oct 19, 2011 at 9:21 PM, Kevin Gross  wrote:
>> 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.
>
> 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...
>



--
Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com, www.X192.org
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Danny Mayer]

On 10/18/2011 3:33 PM, Nico Williams wrote:
> On Tue, Oct 18, 2011 at 12:45 PM, Kevin Gross  wrote:
>> 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.
> 
> 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?
> 
>> 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.
> 
> 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.

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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Danny Mayer]

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

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

Danny

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Kevin Gross]

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

On Thu, Oct 20, 2011 at 6:22 AM, Danny Mayer  wrote:
> On 10/18/2011 3:33 PM, Nico Williams wrote:
>> On Tue, Oct 18, 2011 at 12:45 PM, Kevin Gross  wrote:
>>> 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.
>>
>> 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?
>>
>>> 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.
>>
>> 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.
>
> 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
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Leonid Goldin (lgoldin)]

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: tictoc-boun...@ietf.org [mailto:tictoc-boun...@ietf.org] On Behalf
Of Kevin Gross
Sent: Wednesday, October 19, 2011 10:15 PM
To: Stephen Kent
Cc: Cui Yang; ipsec@ietf.org; tic...@ietf.org; 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.

On Wed, Oct 19, 2011 at 9:53 AM, Stephen Kent  wrote:

At 10:53 AM -0400 10/19/11, Danny Mayer wrote:

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

 

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

Steve





 

-- 
Kevin Gross

+1-303-447-0517

Media Network Consultant

AVA Networks - www.AVAnw.com  , www.X192.org

 

 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Danny Mayer]

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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Stephen Kent]

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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Nico Williams]

On Tue, Oct 18, 2011 at 10:37 AM, Tim Frost  wrote:
> 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.

"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
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Nico Williams]

On Mon, Oct 24, 2011 at 1:38 PM, Doug Arnold  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
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Nico Williams]

On Mon, Oct 24, 2011 at 6:19 PM, Doug Arnold  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 t