Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 25 June 2019 15:39 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8442412016E; Tue, 25 Jun 2019 08:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 0uXum6GWn1lp; Tue, 25 Jun 2019 08:39:26 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1AC120131; Tue, 25 Jun 2019 08:39:25 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id BB4F43808A; Tue, 25 Jun 2019 11:37:42 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id CFD99109C; Tue, 25 Jun 2019 11:39:24 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CD5109BC; Tue, 25 Jun 2019 11:39:24 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
cc: Tero Kivinen <kivinen@iki.fi>, David Mandelberg <david@mandelberg.org>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-6tisch-architecture.all@ietf.org" <draft-ietf-6tisch-architecture.all@ietf.org>, Thomas Watteyne <thomas.watteyne@inria.fr>, =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= <malisav@ac.me>
In-Reply-To: <MN2PR11MB35655F77D328CD9B27029413D8E30@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <MN2PR11MB35651735463F27A247B4B0F0D8E00@MN2PR11MB3565.namprd11.prod.outlook.com> <23825.24715.882644.180316@fireball.acr.fi> <MN2PR11MB35655F77D328CD9B27029413D8E30@MN2PR11MB3565.namprd11.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 25 Jun 2019 11:39:24 -0400
Message-ID: <28910.1561477164@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/4YwffvAbGF2Hjp2bJ1SE6EtnM7o>
Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2019 15:39:28 -0000

Tero:
    >> Note, that attacker might be able to replay valid ACKs for the frame
    >> sent by the JN, provided that the JRC (or whoever JN sent the message
    >> to) happened to ack message using the same ASN attacker faked for JN.

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > Your mean that the faked ASN is only slightly in the future, so the
    > attacker can repeat messages from the pledge after that delay?

The faked ASN is always in the past.
So the L2-ACKs can be faked, was the point.

The best scenario would be to distribute the ASN within the JRC reply (CoJP),
but (as Malisa has pointed out) that also has the problem that it requires
the JRC to get ASN coordination/update messages from the 6LBR if they are not co-located.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-