Subject: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05

From: Watson Ladd <[email-masked]>
Date: Sun, 18 Sep 2016 12:41:05 -0700

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document presents a mechanism for servers and clients to conduct
synchronization protocols over multiple paths. I didn't see anything
wrong with the mechanism, but I am worried that its security benefits
are overstated: independent paths may only be partially independent,
and attackers can easily migrate from one router to another in most
networks.

Sincerely,
Watson Ladd

---

From: Tal Mizrahi <[email-masked]>
Date: Sun, 18 Sep 2016 23:22:42 +0000

Dear Watson,

Thanks for reviewing the draft.

To address your comments, I would like to suggest the following text for the Security Considerations section.
Please let us know if this addresses the comments:

The security aspects of time synchronization protocols are discussed in detail in [TICTOCSEC]. The methods describe in this document propose to run a time synchronization protocol through redundant paths, and thus allow to detect and mitigate man-in-the-middle attacks, as described in [DELAY-ATT]. It should be noted that when using multiple paths, these paths may partially overlap, and thus an attack that takes place in a common segment of these paths is not mitigated by the redundancy. Moreover, an on-path attacker may in some cases have access to more than one router, or may be able to migrate from one router to another. Therefore, when using multiple paths it is important for the paths to be as diverse and as independent as possible, making the redundancy scheme more tolerant to on-path attacks.

Regards,
Tal.

>-----Original Message-----
>From: Watson Ladd [mailto:[email-masked]]
>Sent: Sunday, September 18, 2016 10:41 PM
>To: <[email-masked]>; [email-masked]; draft-ietf-tictoc-multi-path-
>[email-masked]
>Subject: secdir review of draft-ietf-tictoc-multi-path-synchronization-05
>
>I have reviewed this document as part of the security directorate's ongoing
>effort to review all IETF documents being processed by the IESG.  These
>comments were written primarily for the benefit of the security area
>directors.  Document editors and WG chairs should treat these comments just
>like any other last call comments.
>
>synchronization protocols over multiple paths. I didn't see anything wrong
>with the mechanism, but I am worried that its security benefits are
>overstated: independent paths may only be partially independent, and
>attackers can easily migrate from one router to another in most networks.
>
>Sincerely,
>Watson Ladd

---

From: Watson Ladd <[email-masked]>
Date: Sun, 18 Sep 2016 16:59:17 -0700

> The security aspects of time synchronization protocols are discussed in detail in [TICTOCSEC]. The methods describe in this document propose to run a time synchronization protocol through redundant…

Multipath shouldn't be discussed as a security measure at all. My
reading of the document was that it was simply to get more reliable
packet delays and synchronization. You cannot throw this claim into
the security considerations alone without explaining the rest of the
picture. Why not remove it entirely?

Real attackers get the job done: they grab the community strings and
use them to own every single router you have, or own the sysadmins PC
and go for all the routers at once.  And it's not uncommon for
machines to be connected to only one router: most desktops and laptops
have a single Ethernet port. The proposed text makes extremely common
things sound rare.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 19 Sep 2016 00:34:33 +0000

Dear Watson,

Thanks for the prompt response.

>Multipath shouldn't be discussed as a security measure at all. My reading of
>the document was that it was simply to get more reliable packet delays and
>synchronization. You cannot throw this claim into the security considerations
>alone without explaining the rest of the picture. Why not remove it entirely?
>

The multi-path scheme addresses both an accuracy issue and a security issue. The security aspect is mentioned well before the security considerations section, including in the abstract and in the introduction.

>Real attackers get the job done: they grab the community strings and use
>them to own every single router you have, or own the sysadmins PC and go
>for all the routers at once.  And it's not uncommon for machines to be
>connected to only one router: most desktops and laptops have a single
>Ethernet port. The proposed text makes extremely common things sound
>rare.

Time protocols have a pretty unique property: even if you use the strongest cryptographic mechanisms, the protocol can still easily be attacked by a man-in-the-middle who simply adds a constant delay to some of the packets, and thereby easily manipulates the protocol. The only way to mitigate delay attacks is by redundancy: multiple time sources and/or multiple network paths.
The delay attack is one of the most significant threats in time protocols, and therefore we defined delay attack protection as a MUST in RFC 7384.
Security is an important aspect of multi-path synchronization, and I believe the current draft has to talk about this aspect.

Best regards,
Tal.

>Sent: Monday, September 19, 2016 2:59 AM
>To: Tal Mizrahi
>Cc: <[email-masked]>; [email-masked]; draft-ietf-tictoc-multi-path-
>[email-masked]; Suresh Krishnan; Karen ODonoghue
>([email-masked])
>Subject: Re: secdir review of draft-ietf-tictoc-multi-path-synchronization-05
>
>> The security aspects of time synchronization protocols are discussed in
>detail in [TICTOCSEC]. The methods describe in this document propose to run
>a time synchronization protocol through redundant paths, and thus allow to
>detect and mitigate man-in-the-middle attacks, as described in [DELAY-ATT].
>It should be noted that when using multiple paths, these paths may partially
>overlap, and thus an attack that takes place in a common segment of these
>paths is not mitigated by the redundancy. Moreover, an on-path attacker may
>in some cases have access to more than one router, or may be able to
>migrate from one router to another. Therefore, when using multiple paths it is
>important for the paths to be as diverse and as independent as possible,
>making the redundancy scheme more tolerant to on-path attacks.
>
>Multipath shouldn't be discussed as a security measure at all. My reading of
>the document was that it was simply to get more reliable packet delays and
>synchronization. You cannot throw this claim into the security considerations
>alone without explaining the rest of the picture. Why not remove it entirely?
>
>Real attackers get the job done: they grab the community strings and use
>them to own every single router you have, or own the sysadmins PC and go
>for all the routers at once.  And it's not uncommon for machines to be
>connected to only one router: most desktops and laptops have a single
>Ethernet port. The proposed text makes extremely common things sound
>rare.
>
>>
>>
>>
>> Regards,
>> Tal.
>>
>>>Subject: secdir review of
>>>draft-ietf-tictoc-multi-path-synchronization-05
>>>
>>>are

---

From: Ben Laurie <[email-masked]>
Date: Mon, 19 Sep 2016 12:00:41 +0100

On 19 September 2016 at 01:34, Tal Mizrahi <[email-masked]> wrote:

> Time protocols have a pretty unique property: even if you use the
> strongest cryptographic mechanisms, the protocol can still easily be
> attacked by a man-in-the-middle who simply adds a constant delay to some of
> the packets, and thereby easily manipulates the protocol. The only way to
> mitigate delay attacks is by redundancy: multiple time sources and/or
> multiple network paths.

Surely not - challenge/response, for example, would also reveal a delay.

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 19 Sep 2016 13:23:57 +0000

Hi Ben,

Just to clarify, we are talking about an attacker that adds a malicious delay that may be as low as, say five microseconds (yes, microseconds) beyond the ‘normal’ path delay. A five microsecond additional delay is certainly enough to kill the protocol in various environments such as mobile base stations or power substations.

Five microseconds is just an example. The point is that the attacker adds some additional delay which is at least an order of magnitude lower than the path delay.

Correct me if I am wrong, but a challenge/response will probably not be effective in detecting delay attacks in this order of magnitude.

Best regards,
Tal.

From: Ben Laurie [mailto:[email-masked]]
Sent: Monday, September 19, 2016 2:01 PM
To: Tal Mizrahi
Cc: Watson Ladd; [email-masked]; Karen ODonoghue ([email-masked]); <[email-masked]>; Suresh Krishnan; [email-masked]
Subject: Re: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05

On 19 September 2016 at 01:34, Tal Mizrahi <[email-masked]<mailto:[email-masked]>> wrote:
Time protocols have a pretty unique property: even if you use the strongest cryptographic mechanisms, the protocol can still easily be attacked by a man-in-the-middle who simply adds a constant delay to some of the packets, and thereby easily manipulates the protocol. The only way to mitigate delay attacks is by redundancy: multiple time sources and/or multiple network paths.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 19 Sep 2016 07:41:35 -0700

> The multi-path scheme addresses both an accuracy issue and a security issue. The security aspect is mentioned well before the security considerations section, including in the abstract and in the i…

What should a client do with multipath to integrate the data in a way
that is strong against malicious delays inserted even on one path?
This draft says there are various discussed algorithms, but some (like
pure Kalman filtering, which the draft suggests) won't be robust
against adversarial manipulation. It needs to say more about this!

> Security is an important aspect of multi-path synchronization, and I believe the current draft has to talk about this aspect.

Just because you demanded that a certain solution have a property
doesn't mean it actually has that property. In fact RFC 7384 is
unreasonably strong: most applications can survive with degraded
clocks and degrading the clock accuracy (say to an amount depending on
observed roundtrip time) is probably acceptable, and in the face of
the standard network attacker (who manipulates all packets at will)
this is the best we can do.

Multipath is extremely limited as a mitigation technique. Given the
demands the systems you are discussing place on reliable timing (to
the point where downthread you indicate microseconds required)
multipath shouldn't be considered effective. If you really need
microseconds secure timing, and actually need things to be secure you
need to trust at least one path.