Re: [secdir] Secdir review of draft-ietf-behave-nat64-learn-analysis-03.txt
Alexey Melnikov <alexey.melnikov@isode.com> Wed, 11 April 2012 18:29 UTC
Return-Path: <alexey.melnikov@isode.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 A537811E80BA; Wed, 11 Apr 2012 11:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.355
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d42epjUSV2kw; Wed, 11 Apr 2012 11:29:27 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (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; d=isode.com; s=selector; i=@isode.com; 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 [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <T4XNXgAg2yY7@rufus.isode.com>; Wed, 11 Apr 2012 19:29:20 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F85CD84.1010903@isode.com>
Date: Wed, 11 Apr 2012 19:29:24 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: David Harrington <ietfdbh@comcast.net>, jouni korhonen <jouni.nospam@gmail.com>
References: <CBAADFD3.212CA%ietfdbh@comcast.net>
In-Reply-To: <CBAADFD3.212CA%ietfdbh@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 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. +1. > -- > 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.
- [secdir] Secdir review of draft-ietf-behave-nat64… Alexey Melnikov
- Re: [secdir] Secdir review of draft-ietf-behave-n… Alexey Melnikov
- Re: [secdir] Secdir review of draft-ietf-behave-n… jouni korhonen
- Re: [secdir] Secdir review of draft-ietf-behave-n… David Harrington
- Re: [secdir] Secdir review of draft-ietf-behave-n… jouni korhonen
- Re: [secdir] Secdir review of draft-ietf-behave-n… jouni korhonen
- Re: [secdir] Secdir review of draft-ietf-behave-n… Alexey Melnikov
- Re: [secdir] Secdir review of draft-ietf-behave-n… Alexey Melnikov
- Re: [secdir] Secdir review of draft-ietf-behave-n… Samuel Weiler
- Re: [secdir] Secdir review of draft-ietf-behave-n… Samuel Weiler
- Re: [secdir] Secdir review of draft-ietf-behave-n… Samuel Weiler
- Re: [secdir] Secdir review of draft-ietf-behave-n… jouni korhonen
- Re: [secdir] Secdir review of draft-ietf-behave-n… Samuel Weiler