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

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Mon, 03 January 2011 10:08 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 94B4628C10E for <ipv6@core3.amsl.com>; Mon, 3 Jan 2011 02:08:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.515
X-Spam-Level:
X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 vmbJoAuvvOWU for <ipv6@core3.amsl.com>; Mon, 3 Jan 2011 02:08:27 -0800 (PST)
Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id BCAC028C0FE for <ipv6@ietf.org>; Mon, 3 Jan 2011 02:08:27 -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 1PZhN2-0005Hp-Ny; Mon, 03 Jan 2011 20:40:32 +1030
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 0AED83B335; Mon, 3 Jan 2011 20:40:32 +1030 (CST)
Date: Mon, 03 Jan 2011 20:40:31 +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: <20110103204031.0c3589b7@opy.nosense.org>
In-Reply-To: <alpine.LRH.2.02.1101031151250.23654@netcore.fi>
References: <alpine.LRH.2.02.1101031151250.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: Mon, 03 Jan 2011 10:08:28 -0000

Hi Pekka,

On Mon, 3 Jan 2011 11:51:38 +0200 (EET)
Pekka Savola <pekkas@netcore.fi> wrote:

> Hi,
> 
> Operational input: when discussing the use of RFC4941 (privacy) addresses with 
> our LAN/workstation admins, it seemed as if there would be great benefit from 
> being able to specify an RFC3484 rule which would in essence say:
> 
> "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. 


> I don't think this is possible today because rfc3484 policy table only allows 
> matching by prefixes, not by address type.
> 
> Has this come up in discussions / has anyone else thought about this?
> 

Regards,
Mark.