Re: [babel] Packet trailer

Toke Høiland-Jørgensen <toke@toke.dk> Wed, 07 November 2018 12:09 UTC

Return-Path: <toke@toke.dk>
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 CD7C812D4E9 for <babel@ietfa.amsl.com>; Wed, 7 Nov 2018 04:09:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
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 vc0UHwZOxGeh for <babel@ietfa.amsl.com>; Wed, 7 Nov 2018 04:09:50 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BD7129619 for <babel@ietf.org>; Wed, 7 Nov 2018 04:09:50 -0800 (PST)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1541592588; bh=5lNQKZYpt1HI0qO6O5oBHykbGoyKzJpdYIIpMy6L3tE=; h=From:To:Subject:In-Reply-To:References:Date:From; b=mp4yb/nLfJlJ6GFqPGNIHsLKlp4Csi9Tr8nnRKKBbVQ637PpX2NLpJZT9H9xOfl2k WA3VEm1CRfK00saRG+EXiLo+g9Ttqq6wNVhoqFOiNDL8u//YSH3c65x6xLlIB4lNBg f9WRcPdtVojbDjjDyTw+FCVY0b6KdZR5cZxdVeQruyubXLIqrSj+XkufZ37m0oFQaW d0EXxrxu/WYBT3prrjSshe4cKKYXomeRI6WxDAs+skCA/ItXasE6Ne7zdeJWZI9GtC jU82ORYtvtU78y2uAwLHaGuhr7T+gMDZF296tVM37pUn813rAUlBfzluCVcpvcocy7 xN9s4DpgBjLZw==
To: Juliusz Chroboczek <jch@irif.fr>, babel@ietf.org
In-Reply-To: <87r2fxjfjg.wl-jch@irif.fr>
References: <87r2fxjfjg.wl-jch@irif.fr>
Date: Wed, 07 Nov 2018 13:09:47 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <877ehpw0l0.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/JwvC6XHpPkOT9aX6PqS0MkTv1RU>
Subject: Re: [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 12:09:53 -0000

Juliusz Chroboczek <jch@irif.fr> writes:

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

LGTM

-Toke