From brian@innovationslab.net Mon Feb 9 09:20:07 2009 Return-Path: X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1E23A6AFF for ; Mon, 9 Feb 2009 09:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] 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 hd8nKrjSn9N2 for ; Mon, 9 Feb 2009 09:20:07 -0800 (PST) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id AE8203A6AB4 for ; Mon, 9 Feb 2009 09:20:03 -0800 (PST) Received: from ([128.244.206.11]) by pilot.jhuapl.edu with ESMTP with TLS id 5502123.134920609; Mon, 09 Feb 2009 12:19:50 -0500 Message-ID: <499065B6.7050805@innovationslab.net> Date: Mon, 09 Feb 2009 12:19:50 -0500 From: Brian Haberman User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: addr-select-dt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [addr-select-dt] Administrative request X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:20:07 -0000 All, I have a request from katsuno@auone.jp to join the design team. Does anyone know who this person is and why they would want to join the DT? Thanks, Brian From arifumi@nttv6.net Tue Feb 10 02:08:13 2009 Return-Path: X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC8B3A6BEA for ; Tue, 10 Feb 2009 02:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599] 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 Hatdo0YO1eXu for ; Tue, 10 Feb 2009 02:08:12 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 080373A6B75 for ; Tue, 10 Feb 2009 02:08:11 -0800 (PST) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n1AA8D74024803; Tue, 10 Feb 2009 19:08:13 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: From: Arifumi Matsumoto To: alh-ietf@tndh.net In-Reply-To: <0f0001c980c5$1f9c9d40$5ed5d7c0$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Feb 2009 19:08:08 +0900 References: <661F613C-46CB-42F0-AD3B-C5C9E6A1B811@nttv6.net> <082401c97c02$f97e90d0$ec7bb270$@net> <0ce488a96c04863beb845905d8ba3494.squirrel@localhost> <20090127.162712.118490281.fujisaki@syce.net> <0f0001c980c5$1f9c9d40$5ed5d7c0$@net> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [192.16.178.5]); Tue, 10 Feb 2009 19:08:13 +0900 (JST) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] Too quiet --- restarting discussion X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 10:08:14 -0000 Tony, let me reply to an old e-mail, On 2009/01/28, at 6:20, Tony Hain wrote: > Tomohiro -INSTALLER- "Fujisaki wrote: > ......... >> | So, we have the following choices: >> | - We give up merging policies in any case, and just chooses >> | one policy set. i.e. A host just uses policies from server-A, or >> server-B, >> | or manually configured policies. >> | - Merge policies. conflicting policies are merged by some means of >> | prioritization. >> | - As Dthaler suggested before, divide policy table into dst addr >> selection >> | table and src addr selection table, and policy distribution just >> updates >> | src addr selection table, which makes merging process far easier. >> >> I like second option, merging by some priority value, such as >> interface priority in Windows OS. I think nodes should be configured >> as automatically as possible (from this point of view, option one >> with >> no user interaction may be acceptable i.e. using default policy >> table >> if nodes find multiple policies). And I think the third option have >> a big impact to existing implementation, so, even if we choose option >> 3, >> we should have some method to update the policy table. > > Splitting the tables only compounds the merge problems, because the > likelihood of src/dst/router-rpf conflicts would be very high. > > The more I think about it, the more I find that the idea of a merged > table > is a bad idea. There should be some basic rule prioritization like > default/network-announced/manual-config/enterprise-config, but > sorting out > conflicts within the network-announced set creates more problems > than it > resolves. If router-A sends 75 1000 2001:db8:1::/48 and router-B > sends 70 > 2222 2001:db8:2::/48, no matter what value ends up as ::/0, when the > node > sends to something outside those prefixes it would need to choose a > src > address that aligns with the router it will be sending through. A > merged > table would always choose router-A's announcement as the src prefix, > even if > it sent via router-B. This would cause the operators of A & B to go > into an > arms-race to set the highest precedence value they could, so they > all end up > at precedence-of-loopback -1. Rather than go there, we should offer a > default label that they all use to cause traffic between their > customers to > stay on-network in both directions. Sorting out the > routing/rpf/src-selection problem is not resolved by a simple > announcement > of policy table precedence. > Rather than go there, we should offer a > default label that they all use to cause traffic between their > customers to > stay on-network in both directions. I fail to see why default label approach you proposed in previous e-mail solves the above mentioned problem of mis-alignment of router and src- prefix. I'm glad if you can elaborate on it. Regards. -- Arifumi Matsumoto Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net From hiromi@inetcore.com Fri Feb 13 07:31:09 2009 Return-Path: X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9551C28C161 for ; Fri, 13 Feb 2009 07:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.659 X-Spam-Level: * X-Spam-Status: No, score=1.659 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_JP=1.265, RDNS_DYNAMIC=0.1, SARE_RECV_IP_218216=0.629] 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 GQCP3GpSmzFB for ; Fri, 13 Feb 2009 07:31:08 -0800 (PST) Received: from uranus.bugest.net (194-135-216-218.mexne.jp [218.216.135.194]) by core3.amsl.com (Postfix) with ESMTP id C7BE93A6B49 for ; Fri, 13 Feb 2009 07:31:04 -0800 (PST) Received: from [192.168.3.4] (softbank126064023134.bbtec.net [126.64.23.134]) by uranus.bugest.net (Postfix) with ESMTPA id 1FC14E65E20; Sat, 14 Feb 2009 00:30:42 +0900 (JST) Message-Id: <09E91037-3EAB-43DE-810F-FE7BCB6FDDAA@inetcore.com> From: Ruri Hiromi To: Brian Haberman In-Reply-To: <499065B6.7050805@innovationslab.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 14 Feb 2009 00:30:39 +0900 References: <499065B6.7050805@innovationslab.net> X-Mailer: Apple Mail (2.930.3) Cc: addr-select-dt@ietf.org Subject: Re: [addr-select-dt] Administrative request X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 15:31:09 -0000 Hi, I know him, he was in the past IETF in Dublin and knowing this activity at that time, he said. He is working for KDDI (a telecom career in Japan) and from their future network architecture and operational view wants to join and discuss about this. Regards, On 2009/02/10, at 2:19, Brian Haberman wrote: > All, > I have a request from katsuno@auone.jp to join the design team. > Does anyone know who this person is and why they would want to join > the DT? > > Thanks, > Brian > _______________________________________________ > addr-select-dt mailing list > addr-select-dt@ietf.org > https://www.ietf.org/mailman/listinfo/addr-select-dt ------------------------------- Ruri Hiromi Intec NetCore, Inc. / Keio university hiromi@inetcore.com From arifumi@nttv6.net Thu Feb 26 22:32:01 2009 Return-Path: X-Original-To: addr-select-dt@core3.amsl.com Delivered-To: addr-select-dt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BECE3A688E for ; Thu, 26 Feb 2009 22:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 iYjWd4luWizz for ; Thu, 26 Feb 2009 22:32:00 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id D983F3A67A5 for ; Thu, 26 Feb 2009 22:31:56 -0800 (PST) Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n1R6W9hx031702 for ; Fri, 27 Feb 2009 15:32:09 +0900 (JST) (envelope-from arifumi@nttv6.net) Message-Id: From: Arifumi Matsumoto To: addr-select-dt@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 15:32:04 +0900 X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [192.16.178.5]); Fri, 27 Feb 2009 15:32:09 +0900 (JST) Subject: [addr-select-dt] Regarding Policy Merge X-BeenThere: addr-select-dt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPv6 Address Selection Design Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 06:32:01 -0000 All, I'm trying to summarize the discussion we recently had at this ML, and my personal views on them. I hope this helps further discussion. * policy originator - default built-in policy - from an entity in a network - a PC user's manual configuration - site administrator These can lead to *vertical* policy conflict, however, these originator should be given priority, and a policy set should be chosen exclusively, or merged in accordance with a pre-defined rule, or overrider's policy. What matters is that multiple same-level originators give policy sets. (horizontal conflict) And this case is seemed to usually happen for multiple network entities case. * how policies conflict happen - For a prefix, multiple originators give different labels or precedences. - Two or more originators try to give higher precedence for their prefixes (arms race). - By accident, a label coincides with another entity's label that is intended for different use. IMO, precedence has a relative meaning to all the other entries. On the other hand, label has basically a relative meaning to all the entries with the same label. So, inserting an policy entry into a policy set can change all the meaning of the existing entries' precedence. What I mean is that merging different set of policies with their precendence meanings unchanged is impossible. So, how about taking away precedence value control from a policy originator in network, especially if the policy originator is not authenticated by another means, such as DHCP-AUTH. * where policies conflict happen 1) host multi-interface environment +--- server +-+ +-+ |R| |R| +-+ +-+ | +--+ | VPN +---+PC+---+ +--+ - Each router R distributes policy. - uRPF does not matter in this case. - Dave Thaler's favorite ;) - One interface can be a VPN interface. - Policy originators can be in different management domain, and can be uncoordinated with each other. Tony mentioned about the possibility of precedence arms race. By doing so, a policy originator can make PC send a packet to a server in his office not through VPN. This happens if the server has both a globally reachable address and intra-site address, such as ULA and if the policy originator puts higher precedence for ::/0 than ULA. IMO, however, in this case the server should not present confidential contents to the PC if the PC is connected through non-VPN address. Otherwise, the confidential contents is accessible from every node. IMO, the policy merge of this case can be implemented by making use of Interface priority/metric, that is often? usually? implemented in the existing OSes. The priority of interface is used for route selection, e.g. in multiple default router case. That is, the policy merge can be implemented in coordinated manner with the routing table. Of course, the precedence values cannot be merged in this case also, so above-mentioned process is needed. 2) router multi-interface multi-home +-+ +-+ |R| |R| +-+ +-+ | +--+ | +---+GW+---+ +--+ | +--+ |PC| +--+ - Each router distributes policy. Usually, GW makes a decision about routing, e.g. which route to take for the default route. If so, the address selection policy have to be coordinated with the routing policy, and sets of address selection policy should be merged at GW. Then this case of policy merging at GW can come down to case 1). 3) one-link multi-router multi-home +-+ +-+ |R| |R| +-+ +-+ | | --+----+----+-- | +--+ |PC| +--+ - Each router distributes policy. - uRPF matters in this case. IMO, in this case, we can assume that these two routers belong to the same administration domain. So, the administrator should and can take care of policy conflicts. 4) router one-link multi-home +-+ +-+ |R| |R| +-+ +-+ | | --+----+----+-- | +--+ |GW| +--+ | +--+ |PC| +--+ This case come down to 3). Any comments are welcome. Kindest regards, -- Arifumi Matsumoto Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net