Re: addrsel: privacy addresses within/out of a site

Pekka Savola <pekkas@netcore.fi> Mon, 03 January 2011 10:19 UTC

Return-Path: <pekkas@netcore.fi>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0697B28C118 for <ipv6@core3.amsl.com>; Mon, 3 Jan 2011 02:19:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IbRleUtN+P5 for <ipv6@core3.amsl.com>; Mon, 3 Jan 2011 02:19:56 -0800 (PST)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id DB1EC28C10C for <ipv6@ietf.org>; Mon, 3 Jan 2011 02:19:55 -0800 (PST)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p03ALhhc024722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jan 2011 12:21:43 +0200
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p03ALfcn024719; Mon, 3 Jan 2011 12:21:42 +0200
Date: Mon, 03 Jan 2011 12:21:41 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
Subject: Re: addrsel: privacy addresses within/out of a site
In-Reply-To: <20110103204031.0c3589b7@opy.nosense.org>
Message-ID: <alpine.LRH.2.02.1101031213060.23654@netcore.fi>
References: <alpine.LRH.2.02.1101031151250.23654@netcore.fi> <20110103204031.0c3589b7@opy.nosense.org>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi
X-Virus-Status: Clean
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jan 2011 10:19:57 -0000

On Mon, 3 Jan 2011, Mark Smith wrote:
>> "do not use privacy addresses when communicating inside the site [a set of
>> designated destination prefixes], use it by default otherwise"
>>
>
> I'd be curious what the benefits are.
>
> The only reason I could think of as to why to do this is to be able to
> associate internal application access logs with internal hosts. At face
> value that sounds useful, however if you really care about auditing
> application access and use, it isn't the hosts you need to worry about,
> but the people behind them - and they can usually easily change hosts.
> So I think those applications should be using proper AAA to identify the
> user, rather than using IPv6 host identifiers as very poor substitutes
> for user identities.

One use case is administrators running ssh, vnc or some such remote 
management to the client OS.  The conclusion from looking at various 
similar cases was that systems need to have a well-known (non-privacy) 
IP where they can be reached and run TCP services at, or the privacy 
IP needs to be stored in DNS (not much point in that..).

Also, many site-internal access control mechanisms (for example, 
hosts.allow for ssh, some others for e.g. web browsing) use 
host-specific IPs in addition to other checks.  In some cases these 
could be substituted with stronger upper-layer identities e.g with 
certificates.

On the other hand, user identification due to static EU64 is a little 
bit of concern e.g. with web surfing, but this also applies to other 
applications so the issue does not go away with application-specific 
tuning.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings