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

Tal Mizrahi <> Sun, 18 September 2016 23:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0700C12B15C; Sun, 18 Sep 2016 16:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gyb0IDI-coXn; Sun, 18 Sep 2016 16:22:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB6DD12B03B; Sun, 18 Sep 2016 16:22:55 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u8INKGk4015313; Sun, 18 Sep 2016 16:22:52 -0700
Received: from ([]) by with ESMTP id 25h36k4n81-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Sep 2016 16:22:51 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Sep 2016 02:22:43 +0300
Received: from ([fe80::5d63:81cd:31e2:fc36]) by ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1104.000; Mon, 19 Sep 2016 02:22:43 +0300
From: Tal Mizrahi <>
To: Watson Ladd <>, "<>" <>, "" <>, "" <>, Suresh Krishnan <>, "Karen ODonoghue (" <>
Thread-Topic: secdir review of draft-ietf-tictoc-multi-path-synchronization-05
Thread-Index: AQHSEeSgVxkDrkl/jE+0/2Rx8wj6kqB/4pcA
Date: Sun, 18 Sep 2016 23:22:42 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-18_14:, , signatures=0
X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609180323
Archived-At: <>
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:22:57 -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.


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