ipsec October 2011 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] [TICTOC] Review request for IPsec security fo

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

From: Kevin Gross <kevin.gross_at_nospam>
Date: Tue Oct 18 2011 - 17:45:13 GMT
To: Paul_Koning@dell.com

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, <Paul_Koning@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-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] *On Behalf
> Of *Kevin Gross
> *Sent:* Tuesday, October 18, 2011 12:43 PM
> *To:* Nico Williams
> *Cc:* ipsec@ietf.org; Danny Mayer; TICTOC@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 <nico@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