Re: [OPSEC] New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt
Fernando Gont <fernando@gont.com.ar> Tue, 06 March 2012 06:41 UTC
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CE021E8045 for <opsec@ietfa.amsl.com>; Mon, 5 Mar 2012 22:41:45 -0800 (PST)
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 u40U5lxIxLFK for <opsec@ietfa.amsl.com>; Mon, 5 Mar 2012 22:41:44 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36E9621E8024 for <opsec@ietf.org>; Mon, 5 Mar 2012 22:41:44 -0800 (PST)
Received: by ggmi1 with SMTP id i1so2316424ggm.31 for <opsec@ietf.org>; Mon, 05 Mar 2012 22:41:43 -0800 (PST)
Received-SPF: pass (google.com: domain of fernando.gont.netbook.win@gmail.com designates 10.236.125.130 as permitted sender) client-ip=10.236.125.130;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of fernando.gont.netbook.win@gmail.com designates 10.236.125.130 as permitted sender) smtp.mail=fernando.gont.netbook.win@gmail.com; dkim=pass header.i=fernando.gont.netbook.win@gmail.com
Received: from mr.google.com ([10.236.125.130]) by 10.236.125.130 with SMTP id z2mr30693053yhh.94.1331016103942 (num_hops = 1); Mon, 05 Mar 2012 22:41:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=A9tO9ad1mAeRxC6jSprbjtByB4OZG8f72/iXxg/QwkA=; b=JrpbGLmkdip9A0rDzlXSvMqw3Or4AxvehXGm3xgOScj9qtn4Ub1MgnpJuqjD+Mt4JU 4a/IiOYSE641VHSnJuA+ulUzMz+OlF0lGvUs6/Mp4V9gEhao/nBKUQiz5OdoCGGxOQ2c N/vYwOqtTieRowqr2XWL/kMRSQRi8XTeqZQl94IZHip4qLHmZROukB+lbpCFuDIiMvUG OB4zcRhDG1RLw6bJIuH6m8jgDDpIrx1JWq12gCJX5ItSoqzeZVtyrlgBkb5go0zXfdq/ zwymc23VyHnp4htwZrCioOY5gb8OMnsSH7lMt3KPFOP2BOw1YepMePgxrbtNo3y/fW2G IcXQ==
Received: by 10.236.125.130 with SMTP id z2mr24197886yhh.94.1331016103878; Mon, 05 Mar 2012 22:41:43 -0800 (PST)
Received: from [192.168.123.102] ([186.134.8.162]) by mx.google.com with ESMTPS id e45sm46685183yhk.2.2012.03.05.22.41.41 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 22:41:42 -0800 (PST)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4F55B1A2.7000909@gont.com.ar>
Date: Tue, 06 Mar 2012 03:41:38 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: Andrew Yourtchenko <ayourtch@cisco.com>
References: <alpine.DEB.2.00.1203051204580.20167@ayourtch-lnx>
In-Reply-To: <alpine.DEB.2.00.1203051204580.20167@ayourtch-lnx>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: opsec@ietf.org, mircea.pisica@bt.com, sasad@cisco.com
Subject: Re: [OPSEC] New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2012 06:41:45 -0000
Hi, Andrew, I read the I-D. Here are some comments: * Section 4 states: The problem is twofold: first, from the security point of view, one should try to avoid the easy to guess patterns that the traditional address assignment entails. At the same time, the naive approach of assigning purely random addresses to servers is not very scalable in real world for maintenance reasons I think this one is somewhat incorrect: What's usually deemed as hard to manage is temporary addresses (RFC 4941), rather than the fact that the identifiers are random (see e.g., <http://tools.ietf.org/id/draft-gont-6man-managing-slaac-policy-00.txt>). * Section 5 states: The idea is to exploit the randomness property of the encryption function output. The interface identifier, used within the IPv6 address of the host, would be derived from the 64-bit data corresponding to hostname, encrypted with a site-wide "secret". How would you distribute the secret. That aside: have you read <http://tools.ietf.org/id/draft-gont-6man-stable-privacy-addresses-00.txt>. It solves the scanning problem and the management problem, with no need to distribute secrets. Thanks, Fernando On 03/05/2012 08:06 AM, Andrew Yourtchenko wrote: > Hi all, > > We will be very thankful for the review/comments on this draft and hope > to present it in Paris. > > --a > > ---------- Forwarded message ---------- > Date: Mon, 05 Mar 2012 03:04:14 -0800 > From: internet-drafts@ietf.org > To: ayourtch@cisco.com > Cc: mircea.pisica@bt.com, sasad@cisco.com > Subject: New Version Notification for > draft-yourtchenko-opsec-humansafe-ipv6-00.txt > > A new version of I-D, draft-yourtchenko-opsec-humansafe-ipv6-00.txt has > been successfully submitted by Andrew Yourtchenko and posted to the IETF > repository. > > Filename: draft-yourtchenko-opsec-humansafe-ipv6 > Revision: 00 > Title: Human-safe IPv6: Cryptographic transformation of > hostnames as a base for secure and manageable addressing > Creation date: 2012-03-02 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > Although the IPv6 address space within a single /64 subnet is very > large, the typical distribution of the addresses in this space is > very non-uniform. This non-uniformity, together with the dictionary- > based DNS brute-force enumeration, allows practical remote mapping of > the IPv6 addresses in these subnets. This document proposes a > technique which can be used to decrease the exposure of the server > subnets to trivial scanning. As a side effect, the proposed > technique allows to drastically simplify the address management. > > > > > The IETF Secretariat > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
- [OPSEC] New Version Notification for draft-yourtc… Andrew Yourtchenko
- Re: [OPSEC] New Version Notification for draft-yo… Fernando Gont
- Re: [OPSEC] New Version Notification for draft-yo… Andrew Yourtchenko
- Re: [OPSEC] New Version Notification for draft-yo… Fernando Gont
- Re: [OPSEC] New Version Notification for draft-yo… Andrew Yourtchenko
- Re: [OPSEC] New Version Notification for draft-yo… Fernando Gont
- Re: [OPSEC] New Version Notification for draft-yo… Andrew Yourtchenko
- Re: [OPSEC] New Version Notification for draft-yo… Fernando Gont