On Oct 24, 2018, at 5:57 AM, dnsop-requ...@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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
