Re: [DNSOP] Clarification question: compression pointers always to names earlier in the packet?

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 24 October 2018 16:54 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9C71288BD for <dnsop@ietfa.amsl.com>; Wed, 24 Oct 2018 09:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 vJM6OdVGGFtJ for <dnsop@ietfa.amsl.com>; Wed, 24 Oct 2018 09:54:54 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D5C126CB6 for <dnsop@ietf.org>; Wed, 24 Oct 2018 09:54:54 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 56F28709B8; Wed, 24 Oct 2018 12:54:52 -0400 (EDT)
Date: Wed, 24 Oct 2018 12:54:52 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop <dnsop@ietf.org>
Message-ID: <20181024165452.GM983@straasha.imrryr.org>
Reply-To: dnsop@ietf.org
References: <BC2CDF40-4FF0-4111-88B7-04969491D2E0@dukhovni.org> <CAJhMdTONFZ=DRvLscUdiUF6e1ZfUM2DsuRjpWLt+9wUL+4MOSQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJhMdTONFZ=DRvLscUdiUF6e1ZfUM2DsuRjpWLt+9wUL+4MOSQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wf0Zb7jdUsbpdTGXU08xfts5wv8>
Subject: Re: [DNSOP] Clarification question: compression pointers always to names earlier in the packet?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2018 16:54:57 -0000


On Oct 24, 2018, at 5:57 AM, dnsop-request@ietf.org wrote:

> Surely any sequence of labels that terminates with a pointer to any
> label within that same sequence is an existence proof of such a loop.
> The degenerate case is a single label terminated by a pointer to
> itself.

So I gather that:

  1.  Pointers must indeed go back to an earlier location in the packet.
  2.  This is not alone quite sufficient to prevent loops.

Thus, given "1" we get the follow possibilities:

    a.  The most recent pointer expands to a name that terminates
        at an offset prior to the pointer.

    b.  The most recent pointer leads to an earlier label of the
        same domain (length-1 pointer loop).  This is easy to detect.

    c.  The most recent pointer expands to a domain that moves
        past the location of the pointer, without arriving at that
        pointer, because it is just part of the data of some label.
        For example:

           ... 10 05 l a r r y 10 m o e  NNN MMM     c u r l y [...]
              | initial length 10 label |ptr 10 back|
                 |len 5 label |len 10 pointer-skipping label |

        yielding the domain name:

		\005larry\010moe.larry.moe\NNN\MMMcurly.[...]

	in which the double occurence of "larry" and "moe" just
	happens to be possible to compress away, due to a fortuitous
        position in the packet, with the pointer bytes also matching
        label content within the domain name.

So it seems that with "1" enforced, and "b" easily handled, it seems
to me (ready to be proved wrong again) that the remaining way one
can get loops is for some pointer to expand to something that
(directly without traversing any other pointer) reaches that very
same pointer or skips past it as ordinary data in the expanding
name.  Such a packet does not violate the restriction on pointers
going forward, but supposing no loop results, is this a valid
compressed name?

I'm inclined to say that such a compressed name, by creating a
pointer to a name that ultimately that same pointer as label content,
is all too clever and that I would not be wrong to write a decoder
that rejects such compressed encodings.

Am I missing something this time?

-- 
	Viktor.