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

Alexey Melnikov <> Wed, 11 April 2012 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A537811E80BA; Wed, 11 Apr 2012 11:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.355
X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d42epjUSV2kw; Wed, 11 Apr 2012 11:29:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1A2CC11E8098; Wed, 11 Apr 2012 11:29:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334168960;; s=selector;; bh=KlYRpO8rVqbegeT4V7jFTyBLxIRTV/lqL/4GdwSbD48=; 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=qUWPZtmG92+nc+C/5brs53HFbAx5dTYegTZJivq/HslKiNFEdWbehe9pURleH9Ul6Oizup 7wEeSlNQTlbIUquPlpQOom3tXrmu6ywRCLBy7e6Ac0Sn9jeTHeoB3dAF3ZpYRplZh/KPfB lvt9Xv+2jXQ2mI4KXvGggKI6nNRyivo=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Wed, 11 Apr 2012 19:29:20 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <>
Date: Wed, 11 Apr 2012 19:29:24 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: David Harrington <>, jouni korhonen <>
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc:, IESG <>, Dan Wing <>, Teemu Savolainen <>
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: Wed, 11 Apr 2012 18:29:28 -0000

On 11/04/2012 12:16, David Harrington wrote:
> Hi,
> For IANA to provide an assignment, a document usually needs to request
> such an assignment.
> Is this document requesting the assignment, or is another document doing
> so?
> If this document wants to mention such an IANA assignment, it should also
> provide a reference to the document that requests IANA to do so.
> --
> David Harrington
> +1-603-828-1401
> On 4/11/12 6:00 AM, "jouni korhonen"<>  wrote:
>> Hi,
>> Thank you for the review. See my comments inline.
>> On Apr 10, 2012, at 3:36 PM, Alexey Melnikov wrote:
>>> Hi,
>>> I have reviewed this document as part of the security directorate's
>>> ongoing effort to review all IETF documents being processed by the
>>> IESG.  These comments were written primarily for the benefit of the
>>> security area directors. Document editors and WG chairs should treat
>>> these comments just like any other last call comments.
>>> The document reviews possible solutions for the problem of allowing
>>> hosts and applications to learn if an IPv6 address is synthesized, which
>>> means a NAT64 is used to reach the IPv4 network or Internet. The
>>> document analyzes pros and cons of various approaches and also concludes
>>> with some recommendations about which approach is recommended.
>>> Overall I think the Security Considerations section is reasonable (see
>>> some minor comments below). I think it is reasonable for the document to
>>> point to RFC 6147 for DSN64 related Security Considerations. The
>>> document also talks about Man-in-the-middle and Denial-of-Service
>>> attacks caused by forging of information required for IPv6 synthesis
>> >from corresponding IPv4 addresses.
>> Good point. We'll add the reference.
>>> Additionally, the document says:
>>>    The DHCPv6 and RA
>>>    based approaches are vulnerable for the forgery as the attacker may
>>>    send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6
>>>    authentication or SEND are used).
>>> I think some Informative references to relevant documents should be
>>> inserted here in order to help readers find relevant information.
>> Will add references to RFC3315 and RFC3971.
>>>    If the attacker is already able to
>>>    modify and forge DNS responses (flags, addresses of know IPv4-only
>>>    servers, records, etc), ability to influence local address synthesis
>>>    is likely of low additional value.  Also, a DNS-based mechanism is
>>>    only as secure as the method used to configure the DNS server's IP
>>>    addresses on the host.  Therefore, if the host cannot trust e.g.
>>>    DHCPv6 it cannot trust the DNS server learned via DHCPv6 either,
>>>    unless the host has a way to authenticate all DNS responses.
>>> Maybe add an explicit DNSSEC reference here?
>> Will add a reference to RFC4033.
>>> One other possible issue that you should consider:
>>> 5.1.2.  Analysis and discussion
>>>    The CONs of the proposal are listed below:
>>> I don't know how much of an issue this is in a real world, but one
>>> thought:
>>> Can use of a well known IPv4-only FQDN be used for tracking
>>> applications/hosts which try to employ this algorithm? Such IPv4-only
>>> host might be an attractive target for compromise, if such information
>>> is valuable to an attacker.
>> I guess it could be possible in theory.. if we assume the
>> DNS server hosting the IPv4-only FQDN would be hostile,
>> which is not a realistic assumption imho.
>>> (This might also apply to other DNS methods.)
>>> Other comments (not really SecDir related):
>>> I found the Abstract to be quite hard to read. Maybe reword to use
>>> shorter/simpler sentences?
>> Ok. We'll look into it.
>>> 5.1.1.  Solution description
>>>    The Well-Known Name may be assigned by IANA or provided some third
>>>    party, including application or operating system vendor.  The IPv4
>>>    address corresponding to the Well-Known Name may be resolved via A
>>>    query to Well-Known Name, assigned by IANA, or hard-coded.
>>> Is IANA already providing one of these? If not, why speculate about
>>> this, as there is no action for IANA specified in this document.
>> IANA is going to provide one. I think it is good to have
>> this part still in the document. It was a non-trivial issue
>> who is going to host the well-known name.