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