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

jouni korhonen <jouni.nospam@gmail.com> Wed, 11 April 2012 12:21 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7C611E808F; Wed, 11 Apr 2012 05:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekPTo7dtsKgx; Wed, 11 Apr 2012 05:21:16 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 574DD21F8526; Wed, 11 Apr 2012 05:21:15 -0700 (PDT)
Received: by lbok13 with SMTP id k13so704810lbo.31 for <multiple recipients>; Wed, 11 Apr 2012 05:21:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=TH6rQXPxSyTF2ifnDNkI/z6uyotD5XLKjugPTV6jD+A=; b=XvALsxCTjUDJCcC7hNnZPZnssypsWj0LBZqW4d5bEJdl4YoRmkJVvmKO+PHUIyEMyj U8mRvV422h8x4YQf9grB/FkFpo8t2i4ABVHfmAgu+ddZeE1m4AxvnKEqe6W6x3FlFCWu RV83mX9j+5LJG0eHo1eMUXNc38w3SAk68g1fgOz9BqGOYoDqQv79Vp6j3yONIVCA32PS /nRclM1U37JVchfz4B0m6W10qqhD4r757gIaFPaoGckp0qJnlbv/hOqocouS4lti61Xb DUXsciaKTcjM5qL6vhzC3jg7/5ovIGsoWcFU0MNyK43QbMO3iByk1JQPiabKfBMM/EBp 7J7Q==
Received: by 10.152.112.132 with SMTP id iq4mr17729477lab.28.1334146874089; Wed, 11 Apr 2012 05:21:14 -0700 (PDT)
Received: from [10.10.1.67] ([194.100.237.57]) by mx.google.com with ESMTPS id ng2sm3259523lbb.13.2012.04.11.05.21.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 05:21:12 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <CBAADFD3.212CA%ietfdbh@comcast.net>
Date: Wed, 11 Apr 2012 15:21:10 +0300
Content-Transfer-Encoding: 7bit
Message-Id: <DC82284E-7181-442A-AA13-B797802A2792@gmail.com>
References: <CBAADFD3.212CA%ietfdbh@comcast.net>
To: David Harrington <ietfdbh@comcast.net>
X-Mailer: Apple Mail (2.1084)
Cc: secdir@ietf.org, IESG <iesg@ietf.org>, Dan Wing <dwing@cisco.com>, Teemu Savolainen <teemu.savolainen@nokia.com>
Subject: Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 12:21:16 -0000

Hi,

On Apr 11, 2012, at 2:16 PM, 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?

Another document.

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

The document that requests the actual assignment is already referenced 
in the same section.

- Jouni

> 
> --
> David Harrington
> Ietfdbh@comcast.net
> +1-603-828-1401
> 
> 
> 
> 
> 
> On 4/11/12 6:00 AM, "jouni korhonen" <jouni.nospam@gmail.com> 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.
>> 
>> - Jouni
>> 
>>> 
>> 
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
> 
>