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

Watson Ladd <> Sun, 18 September 2016 23:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C748812B034; Sun, 18 Sep 2016 16:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cdfZmxZlN2Vx; Sun, 18 Sep 2016 16:59:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 73848128E19; Sun, 18 Sep 2016 16:59:18 -0700 (PDT)
Received: by with SMTP id t67so122243203ywg.3; Sun, 18 Sep 2016 16:59:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Dj3TA+lE+ZS4gL2KcLhibX9P/jzSSb8haif/GI0g/jU=; b=i0G1XqpoNsUadZr4VI3ppSuOL+OuRaokR+kD3SsEJFGUwcbglrvCAZY1YARgXifvLg N8/NXUYOe+Xvz2U+FMbzSJcYoFWCjyq2hXV2E7elA448f/5HiXka82TagEWBoW97uKTD kvxwassVuT+U32KGbnMKB4tfWBmL1qIi0n4K/tDl6c4GMAjaFfD52aTArmZB6wNp4n5X 2XmYKCfkXMSQC1A5rhn3J8y4HpadDT0L5/8T+LEfkH27DA7G8jbv9pWo3fRCF4y013Yc ejUs4kkqxvLW5nNoU+uodKvWK4ArLcF57DD+PUJke3plLQreAH2GVvSq0cqZ7Tjjfb/S kVdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Dj3TA+lE+ZS4gL2KcLhibX9P/jzSSb8haif/GI0g/jU=; b=AqBV0zwlxBo3S2h7WWyQ2x/CraDS6PoT1PRmt+IeFc6s64497GSIgX1lplqRemBrPf C5zl3UyvmkWgu3P6tUnTFLXS4k/7Vt7aJk7y+9lTnM9r6pIihgnoaddUtvpQLLIlxKdH l11LdKPxDQ/NJEB8fXXQaC5KNYQd1Mi+Ko28EtGKiGbQa1yVj3y9DUdUg38TKh9sJfLr u8IJy1CfUrZBR2sFSd4Eym9b2KWVsHGOhuWwyIpXlE1pmAK92/Pu1hUwQB1wh/qApAf+ 5BbsGEzuAHeDdWip06Rl/tJyWixyuZZhNfPIIGuFm5DwtHtgDoixJ9xDUveVMV1VOhip tosg==
X-Gm-Message-State: AE9vXwNBouziz62bvDB1iwh7MXibK5fJIuhmoQL5vIaE8ptJVm8ughok7SxJijrxvsueygR0XD8LmBKo5gkw6A==
X-Received: by with SMTP id n129mr22892332ywe.196.1474243157631; Sun, 18 Sep 2016 16:59:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 18 Sep 2016 16:59:17 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Watson Ladd <>
Date: Sun, 18 Sep 2016 16:59:17 -0700
Message-ID: <>
To: Tal Mizrahi <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, "Karen ODonoghue (" <>, "<>" <>, Suresh Krishnan <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-tictoc-multi-path-synchronization-05
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Sep 2016 23:59:21 -0000

On Sun, Sep 18, 2016 at 4:22 PM, Tal Mizrahi <> 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 []
>>Sent: Sunday, September 18, 2016 10:41 PM
>>To: <>;; draft-ietf-tictoc-multi-path-
>>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.
>>Watson Ladd

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