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

Michael Richardson <> Wed, 26 June 2019 15:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FFC712041C; Wed, 26 Jun 2019 08:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3lRO0We0FYyk; Wed, 26 Jun 2019 08:54:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C60EE1203C4; Wed, 26 Jun 2019 08:54:20 -0700 (PDT)
Received: from (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by (Postfix) with ESMTP id 3DBEC3808A; Wed, 26 Jun 2019 11:52:35 -0400 (EDT)
Received: by (Postfix, from userid 179) id B8974E68; Wed, 26 Jun 2019 11:54:18 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id B7205E37; Wed, 26 Jun 2019 11:54:18 -0400 (EDT)
From: Michael Richardson <>
To: "Pascal Thubert (pthubert)" <>
cc: Tero Kivinen <>, David Mandelberg <>, "" <>, "" <>, "" <>, Thomas Watteyne <>, =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= <>
In-Reply-To: <>
References: <> <> <> <> <28910.1561477164@localhost> <>
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: Wed, 26 Jun 2019 11:54:18 -0400
Message-ID: <17322.1561564458@localhost>
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Jun 2019 15:54:29 -0000

Pascal Thubert (pthubert) <> wrote:
    >> 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) <> 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.

    > Do you mean the replayed ones? When the pledge does not have the keys,
    > the attacker can forge the beacon with any ASN, and place random bytes
    > in the MIC, can't it?

Yes, the replayed one has a "fake" ASN that is in the past.

    > If the attacker fakes an ASN that is tomorrow and intercepts a join
    > request, it could make the pledge seem to appear now on the network
    > tomorrow even if the real pledge is long gone.

But that one won't validate.

    >> So the L2-ACKs can be faked, was the point.

    > I can see that an ACK can be replayed. But the ACK that was stored in
    > advance can only work if the attacked node speaks on the very ASN for
    > which the attacker intercepted an ACK in the past. The attacker is not
    > in control of that and that makes its life harder.

When I said faked, I should have said replayed.

I think that we don't need to do this: just wait for a beacon.  If the
attacker can block and replay them all, then they absolutely win, and the
network can not form.  Such an attacker probably can also put faraday cages
around all the nodes.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-