Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 29 June 2021 11:09 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19D43A3035; Tue, 29 Jun 2021 04:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.596
X-Spam-Level:
X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CccGnTlB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=C2x6Af56
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCL1CEdjrZZd; Tue, 29 Jun 2021 04:09:31 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE26E3A3037; Tue, 29 Jun 2021 04:09:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4198; q=dns/txt; s=iport; t=1624964970; x=1626174570; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tsbo5/jdE6AkwN218AV0VZfBEyGpFUlskFBfaxMtCXU=; b=CccGnTlBXGcKjyLfekfkQDvPZuCNpHA2E6P5x8bdfWx6TRQxS1YVP0IG PL2XisbWRlbzUJFV9u1pMqs1E5KRrnmBtSiOPnKdLmjEMfM+7dGIFTEPd 1w7Ta+HVgrbz0ivt77y6I+/+FB685ksOkaKyvQuNuo+IR/oZ++TNFyTrs A=;
X-IPAS-Result: =?us-ascii?q?A0BZAwDy/tpgl4UNJK1aHgEBCxIMQIMsUYFYNzELiAUDh?= =?us-ascii?q?TmIagOPXYpDglMDVAsBAQENAQE/AgQBAYRSAoJwAiU4EwIEAQEBAQMCAwEBA?= =?us-ascii?q?QEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFaA2GRQEBAQMBEhUTBgEBMgUBCwQCA?= =?us-ascii?q?QgOAwQBAQEeEDIdCAIEDgUIGoJPglYDDiEBA50qAYE6AoofeIEBM4EBggcBA?= =?us-ascii?q?QYEBIVUGIIyCYE6gnuKbyccgUlEgRVDgmA+hCwag0uCLoN6DRQeEQhfQSwjG?= =?us-ascii?q?gIFKQEzlCaWCJIHCoMgnjYSpg+1IjoNhGQCBAIEBQIOAQEGgm8igVtwFYMkU?= =?us-ascii?q?BcCDo4fDA0JFYM5il5zOAIGCgEBAwl8iDUHgS8BgRABAQ?=
IronPort-PHdr: A9a23:1OpuTx3gbWs8OXyksmDPt1BlVkEcU/3cJAMZ6pM7zblJd/fr85fjO RnZ4vNgxB/MUJ7A4v1Jw+zRr+j7WGMG7JrA1RJKcJFFWxIfz8lDmQsmDZ2fBEH7JeKsZCs/T 4xOUVZ/9CS9Nk5YUM/1e1zVpCi06jgfUhXyPAZ4PKL7AInX2s+2zOu1vZbUZlYguQ==
IronPort-HdrOrdr: A9a23:fO8TyqqbdocWCYKwcRSmSZ8aV5uXL9V00zEX/kB9WHVpm5Oj9v xGzc506farslkssSkb6K+90KnpewK6yXcH2/huAV7EZninhILIFvAi0WKG+V3d8kLFh5VgPM tbAs1D4ZjLfCRHZKXBkUqF+rQbsaO6GcmT7I+0pRoAPGIaCZ2IrT0JdzpzeXcGIjWucKBJbK Z0kfA33gZIF05nCviTNz0gZazuttfLnJXpbVotHBg88jSDijuu9frTDwWY9g12aUIM/Z4StU z+1yDp7KSqtP+2jjXG0XXI0phQkNz9jvNeGc23jNQPIDmEsHfsWG0hYczHgNkGmpDo1L8Yqq iUn/7mBbUq15rlRBDznfIq4Xi67N9h0Q659bbSuwqTnSWwfkNLNyMGv/MFTvMcgHBQ4+2VF8 lwrj6kXtNsfGD9tTW46N7SWx5wkE2o5XIkjO4IlnRaFZATcblLsOUkjQ5o+bo7bWnHAbocYa NT5QDnlYBrWELfa2qcsnhkwdSqUHh2FhCaQlIassjQ1zRNhnh2w0YR2cRaxx47hd0AYogB4/ 6BPrVjlblIQMNTZaVhBP0ZSc/yDmDWWxrDPG+bPFyiHqAaPHDGrYLx/dwOla2XkVwzvdMPcb H6IR1lXEIJCjbT4Py1rdR2G0r2MRCAtBzWu7ZjDrZCy8/BeIY=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.83,308,1616457600"; d="scan'208";a="741333511"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jun 2021 11:09:29 +0000
Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 15TB9T17024132 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Jun 2021 11:09:29 GMT
Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 29 Jun 2021 06:09:29 -0500
Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 29 Jun 2021 06:09:28 -0500
Received: from NAM04-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 29 Jun 2021 06:09:28 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hboz8NBV+XM2CQ96zrlQ7A5huBHgqTG94fTx2HIgo45qU6ljFFqaO5HNo5Fkgk+0Vv6W87kKLMKxv6QFnrGO3X8BVWaWrwH++HMJxIkoeMeQyqOIMeGWRD5CO4cpaxJNeHi88zJKmzXUIsAMFL4LnFtWnf48GDPBtJWq9G3OXVDhGZFqYui2vMBzBPUqGGyiN4tEJRJsFaeClwww+DgLnKyDshmq/5ZHUwm8I3Lvy7e5MwPApBU2pjCG+tWx8FDvWFju69KxZwXK2NZT2nWMXUT6yNffuK80WaI2cTBc54AJpi0KZ7OLpY8h1t4YzJxjjiNrkM/dt2CXrU9ghDpGoA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kmiELs+r7peZsKSm/hLjWlkzE1tUr7flTcjLCXfZ2kg=; b=K94vlCEa/CJoXA8Puna/FWrcMbmY/K/tfHQdsDt4l7/TlWxiTFSU5K9KyBG6j6w4Dt4kACSHsNwTjS4bJjQwntRsSKnIN0wx+g8Sq0NED7Q8BnCbniOK49FvjV5ysBNXSqXeW4if1/8cQZ1qZ6A7ZoXnbj+fF5SUBtVR9ml3WmJmy9ikA7Hz0XoAXGNLo9RPnAk1WKSi6ruFAekVmnF6UtupDk8aZSHDvqDGJkgiOKJDfMEHny/2fXYkcNSC5bcQOZERp4K3KbqTqLWYBT+dzx7Riye3050mzyrQrC2GuYb1kdmHd0AKHxpQvHwxdLZ7YcUVReorwLK8BCsZvesf1g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kmiELs+r7peZsKSm/hLjWlkzE1tUr7flTcjLCXfZ2kg=; b=C2x6Af56lIbATgXJdCCpZlDoI1EABnw90m/V8HY8zlDQGnjFmDz3BwX9IFnsXCS56ysv2y/GtjE4VT3TqUBPtBh7RJNLzBoJ4R8z6Fz3AAuVxbmpIx6Pu1Fq5xknjceXJUooG143HykOFEoGxoBNR6RHD0Dj1KoX2CXnRtnOlC0=
Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM4PR11MB5374.namprd11.prod.outlook.com (2603:10b6:5:395::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Tue, 29 Jun 2021 11:09:27 +0000
Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c%7]) with mapi id 15.20.4264.026; Tue, 29 Jun 2021 11:09:27 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Miroslav Lichvar <mlichvar@redhat.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-ntp-interleaved-modes@ietf.org" <draft-ietf-ntp-interleaved-modes@ietf.org>, "ntp-chairs@ietf.org" <ntp-chairs@ietf.org>, "ntp@ietf.org" <ntp@ietf.org>, "odonoghue@isoc.org" <odonoghue@isoc.org>
Thread-Topic: Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)
Thread-Index: AQHXbDYckPzQrs8bA0GlSzmvfu+2MKsqr+qAgAABXeCAABZQgIAAC5MA
Date: Tue, 29 Jun 2021 11:09:27 +0000
Message-ID: <DM4PR11MB5438C3C7FAE56D5DFA7FDE68B5029@DM4PR11MB5438.namprd11.prod.outlook.com>
References: <162489575248.15557.5659898954890340208@ietfa.amsl.com> <YNrfb6JIcfEa25pb@localhost> <DM4PR11MB5438A23994F586634481EF37B5029@DM4PR11MB5438.namprd11.prod.outlook.com> <YNrzSy0jtuY65IPn@localhost>
In-Reply-To: <YNrzSy0jtuY65IPn@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.12.233.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e73dd910-8e1a-4a27-70b7-08d93aee5c6a
x-ms-traffictypediagnostic: DM4PR11MB5374:
x-microsoft-antispam-prvs: <DM4PR11MB5374289BAECAF2944DA6EC34B5029@DM4PR11MB5374.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: E8i0SRr6xmiGJs4Nebr+BwKUM2yA9stSUPFBGaCYEDjhOmJwhm4hrDD2k8g+0YVLVbw9oI4Et1x4MHwmZtVVF79ex2auv0vnFMQK0/dEjveBjvdNxhkarj0j6+IFsvJDVt+OLLK9+BMR5519PikqQKugDV8sGX0lEJeZ/ZcmbUCVnxVBZQjvtq9RLQuZl5G9evjll2Ix+99cOOIGykfO8kRkJ3etNnGCvN2aFCM1Bproy1tuFuNt4V3xgw5u01ZzOExD/nWhfqqS6RrU56vrvSyrZYXwaNUfq+nsMAyDHC2hm9kttmDW/EXdnIkYb2nj2vhre5rfGm2//Obz5bzNDcAays2lyMD8zayqFKy4n4zpwuAzAg4D9Gy+xUnysIsTOBCFXffqe7EZmuv4SfgIHYzhpXKAZxfaa3OKdUjR4iag3rEN8G3SyI5Sus/DAb4MqQZ1Kw/hyviI5N1jqxNbqqezFhzHDKwPm4IMeObSIoU13hbXsNAuXZtTqKyknBeguWdt+eFCHm/htNgiknFRzbAEpHfTwmX9VLGwu8GZOoqpuZ8WBH850kc6+LapToo7UbbFd6WJyJ0ODzPyYwaFx3d7DTJbzsd4pqghYcyf2dkqwhHNa/RX9VMijLWEuDs7V81g5ETSmYSoS19NBe1B9g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(366004)(39860400002)(346002)(396003)(122000001)(33656002)(83380400001)(478600001)(9686003)(6916009)(55016002)(6506007)(52536014)(7696005)(8936002)(66446008)(64756008)(316002)(66476007)(66946007)(66556008)(26005)(186003)(86362001)(76116006)(38100700002)(2906002)(4326008)(5660300002)(53546011)(71200400001)(54906003)(8676002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?CKFU/PaiYQBYLepl7ewV2/KYTPsiOEGH30wpHQzfhPI+DlGPa8Bu7q1kn9GA?= =?us-ascii?Q?IZyzsEgEptfOc5uZhM19tHUi13slsWAc+5eqvK+s3B1kWO7RBp1pzod7rD6f?= =?us-ascii?Q?Z6zrbasV4LEkOmtnjAQ7XhE8rPZ0IETKaIWw3ynklyeEvoYXVCDBqEca4Axp?= =?us-ascii?Q?/EiwXM/gR3L+CvlCpfuXbWHw7VwFvXayCHNDl38JpBut2k+LPxviKr3CxUFg?= =?us-ascii?Q?WXicEC+/CON81TQ6purIvHBMyNHE0y/4q1H+t6LV1jAfq2yR41wxqduHZD1A?= =?us-ascii?Q?VaOvMAoxPYSBo/CvorcCzGULbIanmMyOVtKorCeCI51B7GZ6Xjb6NG3gOfqp?= =?us-ascii?Q?1yQ16ZkJfpuDICKO1Z5SiZ2kMmS5Raksc5zwY5PQv8FD4R73EWpv7aZszOcV?= =?us-ascii?Q?W1O+lDCfe9yj/igZfTS17vWO9oOJiEN7dHFYplcCJbzvdDOF+pEkM/yhwUWF?= =?us-ascii?Q?i5Q/BvdcF/O5Gf27z7bD8I14SR27YsyAcDKJfZkKgmDDFMKQ6SXteB5lnEjg?= =?us-ascii?Q?C2JlED+CnqCLQoFD9Klx5vTl/Np6574zjcRhi0uANJVL/l4Jn/eRsWxOU2U+?= =?us-ascii?Q?gckGKgbx1wQIBMT1pH4XLXVL6kM+lN4fXWJ3Eq9B/pgcsV4xmmz7PpkEDoXy?= =?us-ascii?Q?TPDyXSGrKjg/zoS6H47TuDOCEmBb9KD2AtG/2hOPFg9Ppqi7etz2b4kOwAU3?= =?us-ascii?Q?/S3tBQ1lZdGjQiXxBHNQsHYuQetI2cfE9XVGdDGMv1IzvUvVD43BmFaixW/F?= =?us-ascii?Q?PsXr4/Ix5NJPMzmGDD4J56fzNRWpu1vE24e5Td7rPPcwnPBKfZpERy+uyHbK?= =?us-ascii?Q?jBJ8lIZaRQRMBy+M5RtEEFQDKKTNbkzJa/m+rLcfhMP+DBD9DG60rUErMcp+?= =?us-ascii?Q?ojR9Yu33vGOU7fxeXY63rSeRdyOFDgxXkmhrcenlAHhVbBgNzxN1WPp5EToL?= =?us-ascii?Q?YD0lDr/pttnsW8xjaVU3aKlsQUATaMkh4kN0mMpV21Qt3kPAVLZFEky0FIk+?= =?us-ascii?Q?r1+00SsMb1jbkBiCP3UsNjuHuYeKGIygns5SrD0s8IS/U1xXhnV8rKGaJmdt?= =?us-ascii?Q?n+M2/l8u5suZ2P49zEFKY7e8I5j5s1HSa86H94Kx4GoyHNFBlIKSmerNsbmo?= =?us-ascii?Q?JAr/JDAy59D2/WU7jbWo0qUZLlBsljQ1VeCWRnVl9TRIJ8IMRJtXsI3DB1UF?= =?us-ascii?Q?y9NvuRGGOnTbt2NvU1Ciu7RFgoCHuOatwQh1IUsQsP52v0ETdiPMVu6C/edo?= =?us-ascii?Q?GiEMfjG/R46l4UjKIVF3buRn59yjAhZ5A+LZLwfctVBtS0GzgxXcom3Fxrvu?= =?us-ascii?Q?3NKtzu47Jmu80Ul0202L/6IX?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e73dd910-8e1a-4a27-70b7-08d93aee5c6a
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2021 11:09:27.5896 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DMS4BWbjdjEWBTUA18h/qDe7+K2AL+uzR3aXjP/aG0LFWY19BII1HzCGU0ZjALHdARHcZ63sf2KcfkwLcC1OEg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5374
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/pKNM3FW4SEqbTWWxs4OP37pXos8>
Subject: Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jun 2021 11:09:36 -0000


> -----Original Message-----
> From: Miroslav Lichvar <mlichvar@redhat.com>
> Sent: 29 June 2021 11:18
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: The IESG <iesg@ietf.org>rg>; draft-ietf-ntp-interleaved-modes@ietf.org; ntp-
> chairs@ietf.org; ntp@ietf.org; odonoghue@isoc.org
> Subject: Re: Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05:
> (with DISCUSS and COMMENT)
> 
> On Tue, Jun 29, 2021 at 09:44:35AM +0000, Rob Wilton (rwilton) wrote:
> > > That's a good point. The problem is that there is no good way to
> > > negotiate it. Some widely-used server implementations drop requests
> > > with unknown extension fields. From a missing response the client
> > > cannot tell if the server doesn't support it, or if it's under heavy
> > > load or there is a packet loss in the network somewhere.
> >
> > That makes it sound like the NTPv4 extension mechanism is just broken.
> I.e., nobody can define new extensions in practice?
> 
> Yes, that's one of the problems we are trying to fix in NTPv5.
> 
> NTPv4 practically has only Autokey and NTS as extensions. They are
> both authentication mechanisms, so there is no point in negotiating
> the extension, e.g. to fall back to unauthenticated NTP. Also, NTS has
> a separate protocol for key establishment (NTS-KE). If there is a
> misconfigured client trying to use a server that does not support it,
> at least there should be a "Could not connect" error message.
> 
> > But it isn't clear to me how processing this as a bogus packet helps (noting
> that I don't know NTP).
> 
> A client request is never bogus.

I'm still confused.

Section 2 of the draft states:

   The origin timestamp is a cookie, which is used to detect a packet
   which is not a response to the last packet sent in the other
   direction.  Such packets are called bogus packets in RFC 5905.

   A client request in the basic mode has an origin timestamp equal to
   the transmit timestamp from the previous server response, or is zero.

   A client request in the interleaved mode has an origin timestamp
   equal to the receive timestamp from the previous server response.

Looking at the t5 -> t6 packet from client to server in figure 1,
The Org timestamp has been set to the server's previous Rx timestamp, not the Tx timestamp.

When the server receives this packet from the client then would it not regard it as bogus?

And just for clarity, if the server did interpret this as a bogus packet, are you saying that a server (that knows nothing about this extension) would still be expected to respond back to the client with a basic mode packet?

I was trying to look at definition of receive() in A.5.1 of rfc5905, which seems to sometimes do a short return if it receives a bogus packet (at least under some circumstances), but not being familiar with the protocol or code, I cannot tell what the impact of that is.


 Only server response can be bogus,
> for a client that doesn't support the interleaved mode, if it somehow
> managed to form a request that from the server's point of view looks
> like interleaved. This doesn't happen in practice as far as I can
> tell.

Okay.

Thanks,
Rob


> 
> > E.g., looking at figure 1 in section 2, then what would the flow look like
> between a client that supports interleaved mode and a server that doesn't
> know this extension at all?
> >
> > I presume that the first 2 packets (client (B) -> server, server(B) -> client)
> would just be regular basic NTP.
> > At this stage, wouldn't the client now send an I mode packet to the server?
> Wouldn't the server treat this as a bogus packet, drop it, and not reply?  Or
> does the server still reply regardless in this scenario?
> 
> A server is always expected to respond (except rate limiting, etc). If
> it doesn't support the interleaved mode, or has the support disabled,
> it doesn't care in what mode the request it is and always responds in
> the basic mode. Clients are required to accept it, even if they are
> sending interleaved requests.
> 
> Thanks,
> 
> --
> Miroslav Lichvar