Re: addrsel: privacy addresses within/out of a site
Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Tue, 04 January 2011 21:45 UTC
Return-Path: <ipng@69706e6720323030352d30312d31340a.nosense.org>
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 1B4203A6BB4 for <ipv6@core3.amsl.com>; Tue, 4 Jan 2011 13:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_55=0.6]
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 wfnxlmGmPsEI for <ipv6@core3.amsl.com>; Tue, 4 Jan 2011 13:45:12 -0800 (PST)
Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id DE4883A6AB4 for <ipv6@ietf.org>; Tue, 4 Jan 2011 13:45:11 -0800 (PST)
Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1PaEiq-0004Vu-Rg; Wed, 05 Jan 2011 08:17:16 +1030
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 704D93B31E; Wed, 5 Jan 2011 08:17:16 +1030 (CST)
Date: Wed, 05 Jan 2011 08:17:16 +1030
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: Pekka Savola <pekkas@netcore.fi>
Subject: Re: addrsel: privacy addresses within/out of a site
Message-ID: <20110105081716.3b4f8526@opy.nosense.org>
In-Reply-To: <alpine.LRH.2.02.1101031213060.23654@netcore.fi>
References: <alpine.LRH.2.02.1101031151250.23654@netcore.fi> <20110103204031.0c3589b7@opy.nosense.org> <alpine.LRH.2.02.1101031213060.23654@netcore.fi>
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
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: Tue, 04 Jan 2011 21:45:13 -0000
On Mon, 3 Jan 2011 12:21:41 +0200 (EET) Pekka Savola <pekkas@netcore.fi> wrote: > 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..). > I think that could be achieved by using another address/prefix for that purpose, which has a preferred lifetime of 0 and an ordinary valid lifetime, although RFC3484 needs to be updated to use the largest preferred lifetime as a tie-breaker when multiple valid addresses remain as candidate sources. As the addresses have a zero preferred lifetime, they wouldn't be used for outbound connections, but they're still valid for inbound ones. > 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. > I think it is inevitable that some of IPv6's more advanced and dynamic addressing mechanisms and properties are going to make traditional IPv4 addressing related security methods obsolete. When ever a function is to be achieved in IPv6 that is being achieved in IPv4, I think it is better not to assume that the IPv4 method is directly translatable, and to see if there are methods which don't constrain some of IPv6's new addressing mechanisms or possibly takes advantage of them. > 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. > Regards, Mark.
- addrsel: privacy addresses within/out of a site Pekka Savola
- Re: addrsel: privacy addresses within/out of a si… Mark Smith
- Re: addrsel: privacy addresses within/out of a si… Pekka Savola
- Re: addrsel: privacy addresses within/out of a si… Brian E Carpenter
- Re: addrsel: privacy addresses within/out of a si… Pekka Savola
- Re: addrsel: privacy addresses within/out of a si… Mark Smith
- RE: addrsel: privacy addresses within/out of a si… Suresh Krishnan
- Re: addrsel: privacy addresses within/out of a si… Arifumi Matsumoto
- Re: addrsel: privacy addresses within/out of a si… Bob Hinden
- Re: addrsel: privacy addresses within/out of a si… Fernando Gont