Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.txt

Alexey Melnikov <> Tue, 10 April 2012 12:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCB1821F85D2 for <>; Tue, 10 Apr 2012 05:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.181
X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VHZDN+rZlMdE for <>; Tue, 10 Apr 2012 05:40:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E275A21F85D1 for <>; Tue, 10 Apr 2012 05:40:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334061608;; s=selector;; bh=5W48+2I3BYRwsr2Ga/GToQiXO53S24Qog8FPtYfQSqU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=wNpATuv/F6CViFPcStPRi3qlDpjT2m2EICrZg3yCC6jpF0HV5Z/EsVtdbEU386k/0YKhJ6 ACtNA+ujG5BCHDzztbZwNb4dfzCkfxPjqN3017weUsMi1zh/mrHzja4ze4DEMbASeL0EyP NbaSudlObW0fTnH6aJUxBNTI2YVa5pY=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Tue, 10 Apr 2012 13:40:08 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <>
Date: Tue, 10 Apr 2012 13:40:45 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Apr 2012 12:40:11 -0000

I have to admit that my knowledge of DNSSEC is lacking, so can somebody 
help me answer this question (which I didn't mention in my SecDir review):

5.2.  EDNS0 option indicating AAAA Record synthesis and format

5.2.1.  Solution description

    The third revision of "EDNS0 Option for Indicating AAAA Record
    Synthesis and Format", a draft document submitted to the behave WG in
    February 2011 by Jouni Korhonen and Teemu Savolainen, defined a new
    EDNS0 option [RFC2671], which contained 3 flag bits (called SY-bits).
    The EDNS0 option served as an implicit indication of the presence of
    DNS64 server and the NAT64 device.  The EDNS0 option SY-bit values
    other than '000' and '111' explicitly told the NSP prefix length.
    Only the DNS64 server could insert the EDNS0 option and the required
    SY-bits combination into the synthesized AAAA Resource Record.

Will DNS64 insertion of this option invalid DNSSEC signature?