[babel] Packet trailer

Juliusz Chroboczek <jch@irif.fr> Wed, 07 November 2018 11:25 UTC

Return-Path: <jch@irif.fr>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A725128A5C for <babel@ietfa.amsl.com>; Wed, 7 Nov 2018 03:25:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Y7NddknoBMAu for <babel@ietfa.amsl.com>; Wed, 7 Nov 2018 03:25:11 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B6A12785F for <babel@ietf.org>; Wed, 7 Nov 2018 03:25:10 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id wA7BP3Wo023952 for <babel@ietf.org>; Wed, 7 Nov 2018 12:25:03 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 441AD59B18 for <babel@ietf.org>; Wed, 7 Nov 2018 12:25:09 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id qIX1S_rRUvHv for <babel@ietf.org>; Wed, 7 Nov 2018 12:25:07 +0100 (CET)
Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C0BBC59B12 for <babel@ietf.org>; Wed, 7 Nov 2018 12:25:07 +0100 (CET)
Date: Wed, 07 Nov 2018 12:25:07 +0100
Message-ID: <87r2fxjfjg.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: babel@ietf.org
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 07 Nov 2018 12:25:03 +0100 (CET)
X-Miltered: at korolev with ID 5BE2CB8F.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5BE2CB8F.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5BE2CB8F.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/S0y1XW-k4pCRJwH05Yue92DiArc>
Subject: [babel] Packet trailer
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2018 11:25:12 -0000

In RFC6126bis Section 4.2, I say:

   The packet body and trailer are both sequences of TLVs.  The packet
   body is the normal place to store TLVs; the packet trailer only
   contains specialised TLVs that do not need to be protected by
   cryptographic security mechanisms.  When parsing the trailer, the
   receiver MUST ignore any TLV unless its definition explicitly states
   that it is allowed to appear there.  Among the TLVs defined in this
   document, only Pad1 and PadN are allowed in the trailer; since these
   TLVs are ignored in any case, an implementation MAY silently ignore
   the packet trailer without even parsing it, unless it implements at
   least one extension that defines TLVs that are allowed to appear in
   the trailer.

In Appendix C, I say:

   The packet trailer is intended to carry cryptographic signatures that
   only cover the packet body; storing the cryptographic signatures in
   the packet trailer avoids clearing the signature before computing a
   hash of the packet body, and makes it possible to check a
   cryptographic signature before running the full, stateful TLV parser.
   Hence, only TLVs that don't need to be protected by cryptographic
   security protocols should be allowed to appear in the packet trailer.
   Any such TLVs should be easy to parse, and in particular should not
   require stateful parsing.

Speak now, or forever hold your peace.

-- Juliusz