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

[Watson Ladd <[e-mail]>]

On Sun, Sep 18, 2016 at 5:34 PM, Tal Mizrahi <[e-mail]> wrote:
> 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.

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!

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

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.

>
> Best regards,
> Tal.
>
>
>
>>-----Original Message-----
>>From: Watson Ladd [mailto:[e-mail]]
>>Sent: Monday, September 19, 2016 2:59 AM
>>To: Tal Mizrahi
>>Cc: <[e-mail]>; [e-mail]; draft-ietf-tictoc-multi-path-
>>[e-mail]; Suresh Krishnan; Karen ODonoghue
>>([e-mail])
>>Subject: Re: secdir review of draft-ietf-tictoc-multi-path-synchronization-05
>>
>>On Sun, Sep 18, 2016 at 4:22 PM, Tal Mizrahi <[e-mail]> wrote:
>>> 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.
>>
>>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.
>>>
>>>>-----Original Message-----
>>>>From: Watson Ladd [mailto:[e-mail]]
>>>>Sent: Sunday, September 18, 2016 10:41 PM
>>>>To: <[e-mail]>; [e-mail]; draft-ietf-tictoc-multi-path-
>>>>[e-mail]
>>>>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.
>>>>
>>>>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
>>
>>
>>
>>--
>>"Man is born free, but everywhere he is in chains".
>>--Rousseau.



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